{"id":439,"date":"2016-04-15T23:46:32","date_gmt":"2016-04-15T21:46:32","guid":{"rendered":"https:\/\/blogs.gentoo.org\/mgorny\/?p=439"},"modified":"2016-04-15T23:46:32","modified_gmt":"2016-04-15T21:46:32","slug":"why-automated-gentoo-mirror-commits-are-not-signed-and-how-to-verify-them-2","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/mgorny\/2016\/04\/15\/why-automated-gentoo-mirror-commits-are-not-signed-and-how-to-verify-them-2\/","title":{"rendered":"Why automated gentoo-mirror commits are not signed and\u00a0how to verify them"},"content":{"rendered":"

Those of you who use my Gentoo repository mirrors<\/a> may have noticed that the\u00a0repositories are constructed of original repository commits automatically merged with cache updates. While the\u00a0original commits are signed (at least in the\u00a0official Gentoo repository), the\u00a0automated cache updates and\u00a0merge commits are not. Why?<\/p>\n

Actually, I was wondering about signing them more than once, even discussed it a\u00a0bit with Kristian. However, each time I decided against it. I was seriously concerned that those automatic signatures would not be able to provide sufficient security level \u2014 and\u00a0could cause the\u00a0users to believe the\u00a0commits are authentic even if they were not. I think it would be useful to explain why.<\/p>\n

<\/p>\n

Verifying the\u00a0original commits<\/h2>\n

While this may not be entirely clear, by\u00a0signing the\u00a0merge commits I would implicitly approve the\u00a0original commits as\u00a0well. While this might be worked-around via some kind of\u00a0policy requesting the\u00a0developer to perform additional verification, such a\u00a0policy would be impractical and\u00a0confusing. Therefore, it only seems reasonable to verify the\u00a0original commits before signing merges.<\/p>\n

The\u00a0problem with that is that we still do not have an\u00a0official verification tool<\/em> for repository commits. There’s the\u00a0whole Gentoo-keys<\/a> project that aims to eventually solve the\u00a0problem but it’s not there yet. Maybe this year’s Summer of Code will change that\u2026<\/p>\n

Not having an\u00a0official verification routines, I would have to implement my own. I’m not saying it would be that hard \u2014 but it would always be semi-official, at\u00a0best. Of course, I could spend a\u00a0day or two in\u00a0contributing needed code to Gentoo-keys and\u00a0preventing some student from getting the\u00a0$5500 of Google money\u2026 but that would be the\u00a0non-enterprise way of\u00a0solving the\u00a0urgent problem.<\/p>\n

Protecting the\u00a0signing key<\/h2>\n

The\u00a0other important point is the\u00a0security of\u00a0key used to sign commits. For the\u00a0whole effort to make any sense, it needs to be strongly protected against being compromised. Keeping the\u00a0key (or even a\u00a0subkey) unencrypted on the\u00a0server really diminishes the\u00a0whole effort (I’m not<\/em> pointing fingers here!)<\/p>\n

Basic rules first. The\u00a0primary key kept off-line, used to generate signing subkey only. Signing subkey stored encrypted on the\u00a0server and\u00a0used via gpg-agent, so that it won’t be kept unencrypted outside the\u00a0memory. All nice and\u00a0shiny.<\/p>\n

The\u00a0problem is \u2014 this means someone needs to type the\u00a0password in. Which means there needs to be an\u00a0interactive bootstrap process. Which means every time server reboots for some reason, or\u00a0gpg-agent dies, or\u00a0whatever, the\u00a0mirrors stop and\u00a0wait for me to come and\u00a0type the\u00a0password in. Hopefully when I’m around some semi-secure device.<\/p>\n

Protecting the\u00a0software<\/h2>\n

Even all those points considered and\u00a0solved satisfiably, there’s one more issue: the\u00a0software. I won’t be running all those scripts in\u00a0my home. So it’s not just me you have to trust \u2014 you have to trust all other people with administrative access to the\u00a0machine that’s running the\u00a0scripts, you have to trust the\u00a0employees of the\u00a0hosting company that have physical access to the\u00a0machine.<\/p>\n

I mean, any one of\u00a0them can go and\u00a0attempt to alter the\u00a0data somehow. Even if I tried hard, I won’t be able to protect my scripts from this. In the\u00a0worst case, they are going to add a\u00a0valid, verified signature to the\u00a0data that has been altered externally. What’s the\u00a0value of this signature then?<\/p>\n

And\u00a0this is the\u00a0exact reason why I don’t do automatic signatures.<\/p>\n

How to verify the\u00a0mirrors then?<\/h2>\n

So if automatic signatures are not the\u00a0way, how can you verify the\u00a0commits on repository mirrors? The\u00a0answer is not that complex.<\/p>\n

As I’ve mentioned, the\u00a0mirrors use merge commits to combine metadata updates with original repository commits. What’s important is that this preserves<\/em> the\u00a0original commits, along with their valid signatures and\u00a0therefore provides a\u00a0way to verify them. What’s the\u00a0use of\u00a0that?<\/p>\n

Well, you can look for the\u00a0last merge commit to find the\u00a0matching upstream commit. Then you can use the\u00a0usual procedure to verify the\u00a0upstream commit. And\u00a0then, you can diff it against the\u00a0mirror HEAD to see that only caches and\u00a0other metadata have been altered. While this doesn’t guarantee that the\u00a0alterations are genuine, the\u00a0danger coming from them is rather small (if any).<\/p>\n","protected":false},"excerpt":{"rendered":"

Those of you who use my Gentoo repository mirrors may have noticed that the\u00a0repositories are constructed of original repository commits automatically merged with cache updates. While the\u00a0original commits are signed (at least in the\u00a0official Gentoo repository), the\u00a0automated cache updates and\u00a0merge commits are not. Why? Actually, I was wondering about signing them more than once, even … Continue reading “Why automated gentoo-mirror commits are not signed and\u00a0how to verify them”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/439"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=439"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/439\/revisions"}],"predecessor-version":[{"id":440,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/439\/revisions\/440"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=439"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=439"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=439"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}