[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: