Re: FTP Team -- call for volunteers
On Sun, Mar 15, 2020 at 01:53:44PM +0100, Simon Richter wrote:
>
> > Personally, I was shocked when I found out we do review on the same server that
> > hosts the archive. I would have expected a separate server for review. However,
> > my expectation comes from younger environments, where CD/CI and extensive code
> > review processes are expected. When I try to picture how the current system
> > evolved (more evident as you dig into dak source...), it makes sense.
>
> There are two aspects to distribution: a license from the copyright
> holders, and export permissions from the country where the archive is
> hosted.
>
> Both of these are *currently* rather relaxed in the US, with DMCA safe
> harbor provisions and a blanket permission to export cryptography (the
> existence of which Debian had a large hand in), which allows places like
> Github to operate.
>
> It is unclear how much the DMCA protects us if we have a review process
> before publication (i.e. are we still good if we have any manual step,
> or must publication be fully automated?), and there is also a bill
> underway that would tighten requirements on cryptography software again
> if not defeated.
Personally I think this worry that a private copying from
ftp-master.debian.org constitutes a legal risk is really way
overblown. However, if we want to assume this highly paranoid
reading, one thing we could do is have an *optional* way where someone
who is uploading a package which is going to end up in the ftp-master
tar pit^H^H^H^H^H^H^H queue can pass a URL where ftp master assistants
can download the various artifacts to their own local laptop.
Sha256sum can be used to make sure what has been uploaded to debian
matches what has been downloaded from the sideload URL.
That way, *Debian* is not distributing, but the uploader is
distributing from their server. So the legal risk (if any) isn't on
Debian.
The bigger thing which we might be able to do is to require minimal
review if the source package is already in the distribution, but the
main reason why it is in the ftp-master tar pit is because upstream
has bumped the major version number of a shared library, and so there
is a new binary package triggering what appears to be de novo review
by the ftp master team. I understand there is a super-abundance of
caution which seems to drive all ftp-master team decisions, but
perhaps this could be eased, in the interests of reduce a wait time
of, in some cases greater than a year?
- Ted
Reply to: