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[1].
>> 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
> default.
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[2]. (Assuming that
you'd be able to forward-port the current ACLing system.)
Kind regards and thanks
Philipp Kern
[1]
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/buildd/files/dupload.conf
[2]
https://salsa.debian.org/dsa-team/mirror/dsa-puppet/blob/master/modules/schroot/files/schroot-setup.d/99builddsourceslist
Reply to: