Re: Bug#840104: Encrypted uploads to the security archive
Philipp Kern writes:
> On 01.02.2018 10:30, Ansgar Burchardt wrote:
[...]
>> 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].
Hmm, maybe we should try if it does the right thing? The wrapper script
should ignore the `chmod` call I mentioned in #876900, so the uploaded
files shouldn't even be readable by other DDs.
Please watch file permissions of the files on the upload host during
upload and after upload (before debianqueued processes them) if you try.
>> 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.
If someone can read from the buildd <-> security-master connection, he
probably can also sent packages with the buildd's IP. So just https://
doesn't bring much IMHO. (It doesn't hurt either.)
>> 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.
I think squid can do that:
tls_outgoing_options cert= key=: for client certificate
url_rewrite_*: for http:// -> https:// rewrite
`url_rewrite_program` would need a simple script doing the rewriting.
Of course that still leaves managing the client certificates themselves.
For limiting network access (for programs respecting *_proxy environment
variables), one would need to know which URLs are okay. That should
pretty much be the list of mirrors any chroot might end up using. This
needs to be generated automatically as buildds use different mirrors.
I use squid for limiting network access for GitLab CI runners which
works quite nice. I haven't used client certificates or URL rewriting
with squid so far. Maybe I should try if it works as expected.
Ansgar
Reply to: