Re: Bug#840104: Encrypted uploads to the security archive

[Ansgar Burchardt <ansgar@debian.org>]

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?).

> 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.

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
default.

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.

Ansgar