Re: FTP Team -- call for volunteers
If you think about it, even if you connect with ssh and use vim or
whatever remotely, the content of the files are reaching your screen,
so are being distributed anyway. Might as well just download them no?
Il giorno dom 15 mar 2020 alle ore 18:25 Theodore Y. Ts'o
<tytso@mit.edu> ha scritto:
>
> 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
>
--
Salvo Tomaselli
"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei
http://ltworf.github.io/ltworf/
Reply to: