On Mon, Apr 13, 2015 at 3:21 PM Francesco Ariis
On Mon, Apr 13, 2015 at 10:02:45AM +0000, Michael Snoyman wrote:
I wrote up a strawman proposal last week[5] which clearly needs work to be a realistic option. My question is: are people interested in moving forward on this? If there's no interest, and everyone is satisfied with continuing with the current Hackage-central-authority, then we can proceed with having reliable and secure services built around Hackage. But if others- like me- would like to see a more secure system built from the ground up, please say so and let's continue that conversation.
I finished reading the proposal, the only minor remark I have is on this sentence:
" Each signature may be revoked using standard GPG revokation.
It is the /key/ being revoked really, not the single signature (in our case it would mean revoking every-package-version-or-revision-signed-by-that-key). This in turn highlights the need for a well defined process on how to handle "key transitions" (task left to the single implementators).
I think I was just wrong at that part of the proposal; it wouldn't be "standard GPG revokation" since, as you point out, that's for revoking a key. We'd need a custom revokation mechanism to make this work. But as to your more general point: there was an added layer of indirection that I considered but didn't write up, but I happen to like. The idea would be that all of the authorization lists would work based off of an identifier (e.g., an email address). We would then have a separate mapping between email addresses and GPG public keys, which would follow the same signature scheme that all of the other files in the repo follow. The downside to this is that it redoes the basic GPG keysigning mechanism to some extent, but it does address key transitions more easily. Another possibility would be to encode the release date of a package/version and package/version/revision and use that date for checking validity of keys. That way, old signatures remain valid for perpetuity. I'll admit to my relative lack of experience with GPG, so there's probably some built-in mechanism for addressing this kind of situation which would be better to follow.
A distributed and secure hackage sounds like a dream, I really hope this comes to life!
-- You received this message because you are subscribed to the Google Groups "Commercial Haskell" group. To unsubscribe from this group and stop receiving emails from it, send an email to commercialhaskell+unsubscribe@googlegroups.com. To post to this group, send email to commercialhaskell@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/commercialhaskell/20150413121848.GA3834%40... . For more options, visit https://groups.google.com/d/optout.