Kurt Roeckx writes: > It's been a longstanding problem that the uploads to the security > archive are not encrypted in any way. I think this is a problem > for all embargoed uploads that we are doing. > > Upstream might actually do all that's possible to keep the > security issues secret. But it can potentionally leak when it gets > uploaded to the security archive. As far as I know only ftp is > currently supported. > > I can think of several ways of doing this, but you probably want > to talk to DSA about some of those options. They include: > - Allow uploads over ssh / sftp. This could be anonymous, or give > access to the same user with all the ssh keys or something.
DDs can now upload packages via ssh (scp, sftp, rsync+ssh) to ssh.security.upload.debian.org[1]. [1] <https://lists.debian.org/debian-devel-announce/2017/10/msg00000.html> Depending on how the uploads happen, they can remain readable by other DDs for a short while (see the bugs mentioned in the announcement). But this might be less bad than uploading via unencrypted ftp. DDs can also see which packages were uploaded as debianqueue's logs are readable by local users, but I believe this shouldn't be too large of a problem. I'm not sure if buildds are already configured to upload to the security archive via ssh as they do for the main archive. It might be a good idea to do so. > - Use ftps (ftp over ssl), but I'm not sure how good that is > supported. > - Encrypt the thing that is uploaded, then still use ftp. > We'd probably need a tool like debsign that puts it right > format. I don't think we should use ftp for new services. > - Some upload mechanism over https This might still be useful as an alternative to ftp for DMs, also for uploads to the main archive. But DMs currently can't upload to the security archive anyway (the DM permissions aren't synced to security-master). Ansgar
