Re: Bug#840104: Encrypted uploads to the security archive
On 01.02.2018 10:30, Ansgar Burchardt wrote:
> Philipp Kern writes:
>> On 31.01.2018 01:11, Ansgar Burchardt wrote:
>>> 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.
>> What's the requirement here? I think traditionally we use machine-local
>> SSH authorized_keys for role accounts. So we already provision keys to
>> every buildd that allows it to talk to wanna-build, but I'm not sure how
>> we'd maintain that with another host. Especially one that presumably can
>> be repointed?
> There is already a `buildd-uploader` role account on the upload hosts
> both main and security archive, a `rsync-ssh-wrap` script, and someone
> also set up authorized_keys.
> I'm just not sure if it is already in use for security uploads? I
> believe it was used for uploads to the main archive already (not sure if
> it currently is?).
Indeed, it uses rsync over SSH through dupload. For security it uses
FTP. Interestingly an rsync-security dupload.conf entry exists, but it
doesn't seem to be used.
>> Maybe this is more of a question for DSA, but I don't know what the
>> current setup entails and if you wrote your own SSH daemon for uploads.
>> In that case we should be able to figure something out.
> It's the regular OpenSSH with forced command setup.
> Hmm, another issue comes to mind:
> If we care about encrypted buildd uploads, the buildds should probably
> also download from the (private) security-buildd archive over an
> encrypted connection, ideally with client authentication. Otherwise
> people could see the embargoed fixes in the source package.
Well, I thought this was already the case at this point. I suppose it
shouldn't be too hard to add https:// support at this point given that
apt supports it natively. But I think client auth should be a weak
requirement at this point.
> Maybe a local proxy that translates http to https requests and which
> provides a client certificate (so the chroot doesn't need it added)?
> The proxy could also filter out other network requests we don't want by
It's the kind of solution that I'd propose as well, if the preconditions
were different ones. Unless it's a pretty stock setup that can be run
with default packages I don't see that happening.
> We could also move the security buildd archive away from security-master
> at the same time (as we did for ftp-master). Then there should no
> longer be a reason for a httpd on security-master.
Whatever works for you, the script is now in puppet. (Assuming that
you'd be able to forward-port the current ACLing system.)
Kind regards and thanks