On Mon, 2017-10-09 at 17:38 +0100, Steve McIntyre wrote: > On Mon, Oct 09, 2017 at 02:01:15PM +0100, Ben Hutchings wrote: [...] > > It also appears to mean that buildds can get anything signed on demand > > with no human intervention at all, without all the checks that dak does > > on uploads. This seems to be to substantially raise the risk of > > signing evil code and needing to revoke those signatures (or the > > signing key). > > We spoke about this too. Source packages uploaded and eventually built > on the buildds already go through dak and wanna-build, for one. We > have to trust that mechanism already. It's also audited - every upload is publicly logged, which makes it hard for an attacker to hide an evil upload. The archive is signed, rather than individual packages, and those signatures are valid for a limited period. So if an evil upload is successful, we can replace it, warn users, and then by the time it's forgotten the signature will be invalid. A signing service would have to implement a separate audit mechanism. And code signing can't be time limited so if we sign an evil upload we'll need to revoke it somehow. > What human intervention are you wanting here? A human decides when processing the BYHAND queue whether this binary upload looks reasonable. If it's built from an NMU, I would hope this gets extra scrutiny (perhaps including a query to the maintainer). (Ideally that would happen at the source upload stage for packages that get code-signed. I'm not sure if that's possible to do.) Also, dak checks that every binary upload corresponds to a source upload, so an evil upload will have to be either a source upload or a replacement of a binary upload. It seems like the proposed signing service would allow an attacker that compromises a buildd to get code signed at any time, independently of a source upload. > We're also looking at a whitelist of specific packages > that the buildd and signing service will allow to be signed, to reduce > the potential attack surface. This mechanism already exists in dak, of course. Ben. > > Plus the reliability issues you pointed out on the wiki. > > Right - we're trying to consider the issues as we go. > > > > I would like to know everyone's opinions about these approaches, if you > > > agree to go forward with the second approach described above and how do > > > we solve the NEW queue policy issue. > > > > So far as I can see, the second approach is difficult, risky, > > unreliable and leads to policy violations. > > > > On the other side... there is an FTP team objection with no documented > > explanation. > > -- Ben Hutchings Humour is the best antidote to reality.
Attachment:
signature.asc
Description: This is a digitally signed message part