[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30346 [Internal Services/Service - nextcloud]: Can't create or open riseup pads in Nextcloud
#30346: Can't create or open riseup pads in Nextcloud
-------------------------------------------------+-------------------------
Reporter: alsmith | Owner:
| nextcloud-admin@…
Type: defect | Status: new
Priority: Medium | Milestone:
Component: Internal Services/Service - | Version:
nextcloud |
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by micah):
Hi,
I had added this pad plugin to nextcloud to test it before Tor started
using the nextcloud instance, but had determined that it was not something
we could support, and so removed the plugin. I removed it after Tor
started using nextcloud. I was hoping nobody would notice that this was
removed, clearly I was wrong :(
There were a couple reasons why I removed it. The main reason is that it
creates pads that will be destroyed by riseup's pad cleanup process, and
it does so without it being obvious. This means that the pads would be
created, content added, and then in 60 days, the pad would be removed from
the system, but it would still be in nextcloud as a file. This would
result in people thinking they still had their pads, but the pads would be
empty, and you wouldn't know it. This seemed like a very unfortunate,
hidden UI gotcha that seemed dangerous.
The other main reason I removed it was that the code had not been audited,
and all the other add-ons we've set the policy that they have to be
'official', or reviewed, I had not reviewed this code. It is not a very
'popular' or heavily installed plugin, which makes me worried that it will
not continue to be working forever, and the longer we have it enabled, the
more dependent on it people become, which will cause us a problem if it
becomes abandoned upstream.
I'm not sure what to do here. The code could be audited, and we could even
change the code to create permanent pads only. All of this is technically
possible. However, the honest truth is I do not want to maintain a fork of
this plugin for the purpose of encouraging people to create permanent pads
that we need to carry forever. This ends up meaning a bunch of extra work
for me to do: fork the plugin, and carry that fork forward through all
upgrades, re-applying the changes each time, and following all the changes
that the plugin or nextcloud makes over time in order to adjust the forked
changes. That extra work would result in more permanent pads, which means
more work for me to carry those pads forever. So it feels to me like the
wrong thing to do to spend a lot of time making something that will cause
me to have to spend more time.
I don't like this answer, and I suspect you all do not either. You
probably found this plugin to be particularly useful, and would like it if
it were re-enabled... and I feel bad that I disabled it after people
started to use it.
There is another possible solution, which would be for tor to run its own
etherpad installation, and then we set the plugin to use that instead.
This isn't a great solution either, because this nextcloud instance is
used by other people outside of tor, so it would have to be something done
after the evaluation was done, and it was determined that this project
should continue, and a tor-specific nextcloud was setup.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30346#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs