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

Re: Official Debian digital 'branding' of debs

>>"Roman" == Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de> writes:

 >> 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.

 Roman> The build daemons' results have to be signed already... the .changes
 Roman> files! Just a note here how it currently works:

 Roman> If the daemon has finished a package, it send the build log plus a
 Roman> dump of the (unsigned) .changes to its admin. The admin's
 Roman> responsibility is to review the log if everything went fine (some
 Roman> build errors still can result in ok status!), and if so he will
 Roman> extract the .changes from the mail, sign it, and send it back to the
 Roman> daemon. (There's a handy elisp function for this process...) The
 Roman> buildd then completely replaces the .changes it already has by the
 Roman> signed version received in the answer and upload it together with the
 Roman> .debs.

        This process is then as insecure as the build machine is. You
 may as well have your secret key on that networked machine,
 for all the security you are getting.

        There should be a way to do what you are doing now, but that
 would involve manually getting in on the machine, verifying that the
 buildd daemon was not compromised, that the log files were not
 compromised (how do you do that?), that the extracted source tree was
 not conta=minated in the meanwhile, and that the daemon was the one
 sending you mail in the first place.

        I understand that the build daemons are convenient. Conveniece
 is the major enemy of security.

 Roman> This procedure ensures that no private PGP key will have to reside on
 Roman> the build machine. (The passphrase would be a problem for auto-signing
 Roman> anyway.) And it's still a human who signs, not the machine.

        But is just as insecure. All I have to do is hack the buidd
 daemon, or spoof a mail, and bingo, I can get the admin to sign stuff
 for me.

 Roman> Now seeing this together with your sign-the-.debs approach: With some
 Roman> technical effort, this would work the same way. You have to either
 Roman> transport the parts of the .deb that should be signed to the signing
 Roman> machine, or somehow build that crypographic hash that will be signed
 Roman> together with the build log. The first solution sounds like a huge
 Roman> waste of bandwidth, the second would need special support from the
 Roman> signing tool (separating the steps that build the hash and sign it
 Roman> later.)

 Always draw your curves, then plot your reading.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

Reply to: