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