Re: Official Debian digital 'branding' of debs
> Also, I'm afraid that I see autobuilders fundamentally at odds with
> signed packages. The only person who can take responsibility for the
> contents of a .deb is the developer, and if they aren't there while
> the package is being compiled then they can't honestly take
> responsibility for what goes into it. We could have an autobuilder
> signature (with all the accompanying key compromise risks), but it
> would have far less meaning than a human claiming that they had
> reviewed the package and believed it to be free of tampering.
The build daemons' results have to be signed already... the .changes
files! Just a note here how it currently works:
If the daemon has finished a package, it send the build log plus a
dump of the (unsigned) .changes to its admin. The admin's
responsibility is to review the log if everything went fine (some
build errors still can result in ok status!), and if so he will
extract the .changes from the mail, sign it, and send it back to the
daemon. (There's a handy elisp function for this process...) The
buildd then completely replaces the .changes it already has by the
signed version received in the answer and upload it together with the
.debs.
This procedure ensures that no private PGP key will have to reside on
the build machine. (The passphrase would be a problem for auto-signing
anyway.) And it's still a human who signs, not the machine.
Now seeing this together with your sign-the-.debs approach: With some
technical effort, this would work the same way. You have to either
transport the parts of the .deb that should be signed to the signing
machine, or somehow build that crypographic hash that will be signed
together with the build log. The first solution sounds like a huge
waste of bandwidth, the second would need special support from the
signing tool (separating the steps that build the hash and sign it
later.)
Roman
Reply to: