Mark Knecht posted on Thu, 07 Aug 2014 11:16:23 -0700 as excerpted: > So that's all looking pretty good, as a first step. If it's a matter of > 3 1/2 minutes instead of 1-2 minutes then I can live with that part. > However that's just (I think) the portage tree and not signed source > code, correct?
[I just posted a reply to the gpg specific stuff.] Technically correct, but not really so in implementation. See below... > Now, is the idea that I have a validated portage snapshot at this point > and stiff have to actually get the code using the regular emerge which > will do the checking because I have: > > FEATURES="buildpkg strict webrsync-gpg" No... It doesn't work that way. > I don't see any evidence that emerge checked what it downloaded, but > maybe those checks are only done when I really build the code? Here's what happens. FEATURES=webrsync-gpg simply tells the webrsync stuff to gpg-verify the snapshot-tarball that webrsync downloads. Without that, it'd still download it the same, but it wouldn't verify the signature. This allows people who use the webrsync only because they're behind a firewall that wouldn't allow normal rsync, but who don't care about the gpg signing security stuff, to use the same tool as the people who actually use webrsync for the security aspect, regardless of whether they could use normal rsync or not. So that gets you a signed and verified tree. Correct so far. But as part of that tree, there are digest files for each package that verify the integrity of the ebuild as well as of the sources tarballs (distfiles). Now it's important to grasp the difference between gpg signing and simple hash digests, here. Anybody with the appropriate tools (md5sum, for example, does md5 hashes, but there's sha and other hashes as well, and the portage tree uses several hash algorithms in case one is broken) can take a hash of a file, and provided it's exactly the same bit-for-bit file they should get exactly the same hash. In fact, that's how portage checks the hashes of both the ebuild files and the distfiles it uses, regardless of this webrsync-gpg stuff. The tree ships the hash values that the gentoo package maintainer took of the files in its digest files, and portage takes its own hash of the files and compares it to the hash value stored in the digest files. If they match, portage is happy. If they don't, depending on how strict you have portage set to be (FEATURES=strict), it will either warn about (without strict) or entirely refuse to merge that package (with strict), until either the digest is updated, or a new file matching the old digest is downloaded. So far so good, but while the hashes protect against accidental damage as the file was being downloaded, because anyone can take a hash of the file, without something stronger, if say one of the mirror operators was a bad guy, they could replace the files with hacked files and as long as they replaced the digest files with the new ones they created for the hacked files at the same time, portage wouldn't know. So while hashes/digests alone protect quite well from accidental damage, they can't protect, by themselves, from deliberate replacement of those files with malware infested copies. Which is where the gpg signed tree snapshots come in. But before we can understand how they help, we need to understand how gpg signing differs from simple hashes. PGP, gpg, and various other public/private-pair key signing (and encryption) take advantage of a particular mathematical relationship property between the public and private keys. I'm not a cryptographer nor a mathematician, so I'm content to leave it at that rather handwavy assertion and not get into the details, but enough people I trust say the same thing about the details, and enough of our modern Internet banking and the like, depends upon the same idea, that I'm relatively confident in the general principle, at least. It works like this. People keep the private key from the pair private -- if it gets out, they've lost the secret. But people publish the public half of the key. The relationship of the keys is such that people can't figure out the private key from the public key, but if you have the private key, you can sign stuff with it, and people with the public key can verify the signature and thus trust that it really was the person with that key that signed the content. Similarly, people can use the public key to encrypt something, and only the person with the private key will be able to decrypt it -- having the public key doesn't help. Actually, as I understand it signing is simply a combination of hashing and encryption, such that a hash of the content to be signed is taken, and then that hash is encrypted with the private key. Now anyone with the public key can "decrypt" the hash and verify the content with it, thereby verifying that the private key used to sign the content by encrypting the hash was the one used. If some other key had been used, attempting to decrypt the hash with an unmatched public key would simply produce gibberish, and the supposedly "decrypted" hash wouldn't be the hash produced when checking the content, thereby failing to verify that the signed content actually came from the person that it was claimed to have come from. OK, we've now established that hashes simply verify that the content didn't get modified in transit, but they do NOT by themselves verify who SENT that content, so indeed, a man-in-the-middle could have replaced BOTH the content and the hash, and someone relying on just hashes couldn't tell the difference. And we've also established that a signature verifies that the content actually came from the person who had the private key matching the public key used to verify it, by mechanism of encrypting the hash of that content with the private key, so only by "decrypting" it with the matching public key, does the hash of the content match the one taken at the other end and encrypted with the private key. *NOW* we're equipped to see how the portage tree snapshot signing method actually allows us to verify distfiles as well. Because the tree includes digests that we can now verify came from our trusted source, gentoo, NOW those digests can be used to verify the distfiles, because the digests were part of the signed tree and nobody could tamper with that signed tree including those digests without detection. If our nefarious gentoo mirror operator tried to switch out the source tarballs AND the digests, he could do so for normal rsync users, and for webrsync users not doing gpg verification, without detection. But should he try that with someone that's using webrsync-gpg, he has no way to sign the tampered with tarball with the correct private key since he doesn't have it, and those using webrsync with FEATURES=webrsync-gpg would detect the tampered tarball as portage (via webrsync, via eix in your case) would reject that tarball as unverified. So the hash-digest method used to protect ordinary rsync users (and webrsync users without webrsync-gpg turned on) from ACCIDENTAL damage, now protects webrsync-gpg users from DELIBERATE man-in-the-middle attacks as well, not because the digests themselves are different, but because we can now trust and verify that they came from a legitimate source. Tho it should be noted that "legitimate source" is defined as anyone having access to that that private signing key. So should someone breakin to the snapshotting server and steal that private key doing the signing, they now become a "legitimate source" as far as webrsync-gpg is concerned. So where does that leave us in practice? Basically here: You're now verifying that the snapshot tarballs are coming from a source with the private signing key, and we're assuming that gentoo security hasn't been broken and thus that only gentoo's snapshot signing servers (and their admins, of course) have access to the private signing key, which in turn means we're assuming the machine with that signing key must be gentoo, and thus that the snapshotted tarballs are legit. But it's actually webrsync in combination with FEATURES=webrsync-gpg that's doing that verification. Once the verified tarball is actually unpacked on our system, portage operate just as it normally does, simply verifying the usual hash digests against the ebuilds and the distfiles /exactly/ as it normally would. Repeating in different words to hopefully ensure it's understood: It's *ONLY* the fact that we have actually gpg-verified that snapshot tarball and thus the digests within it, that gives us any more security than an ordinary rsync user. After that's downloaded, verified and unpacked, portage operates exactly as it normally does. Meanwhile, part of that normal operation includes FEATURES=strict, if you've set it, which causes portage to refuse to merge the package if those digests don't match. But that part of things is just normal portage operation. Rsync users get it too -- they just don't have the additional assurance that those digest files actually came from gentoo (or at least from someone with gentoo's private signing key), that webrsync with FEATURES=webrsync-gpg provides. (Meanwhile, one further personal note FWIW. You may think that all these long explanations take quite some time to type up, and you'd be correct. But don't make the mistake of thinking that I don't get a benefit from it myself. My dad was a teacher, and one of the things he used to say that I've found to be truer than true, is that the best way to /learn/ something is to try to teach it to someone. That's exactly what I'm doing, and all the unexpected questions and corner cases that I'd have never thought about on my own, that people bring up and force me to think about in ordered to answer them, help me improve my own previously more handwavy and fuzzy "general concept" understanding as well. I'm much more confident in my own understanding of the general public/private key concepts, how gpg actually uses them and how its web-of-trust works, and more specifically, how portage can use that via webrsync-gpg to actually improve the gentooer's own security, than I ever was before. And it has been quite some time since I worked with gpg and saw it in interactive mode like that, too, and it turns out that in the intervening years, I've actually understood quite a bit more about how it all works than I did back then, thus my ability to dig that all up and present it here, while back a few years ago, I was just as clueless about how all that web-of-trust stuff worked, and make exactly the same mistake of "ultimately trusting" the distro's package-signing key, for exactly the same reasons. Turns out I absorbed rather more from all those security and encryption articles I've read over the years than I realized, but it actually took my replies right here in this thread to lay it all out logically so I too realized how much more I understand what's going on now, than I did back then.) So... Thanks for the thread! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
