<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Apr 13, 2015 at 3:21 PM Francesco Ariis <<a href="mailto:fa-ml@ariis.it">fa-ml@ariis.it</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Apr 13, 2015 at 10:02:45AM +0000, Michael Snoyman wrote:<br>
> I wrote up a strawman proposal last week[5] which clearly needs work to be<br>
> a realistic option. My question is: are people interested in moving forward<br>
> on this? If there's no interest, and everyone is satisfied with continuing<br>
> with the current Hackage-central-authority, then we can proceed with having<br>
> reliable and secure services built around Hackage. But if others- like me-<br>
> would like to see a more secure system built from the ground up, please say<br>
> so and let's continue that conversation.<br>
<br>
I finished reading the proposal, the only minor remark I have is on this<br>
sentence:<br>
<br>
    " Each signature may be revoked using standard GPG revokation.<br>
<br>
It is the /key/ being revoked really, not the single signature (in our case<br>
it would mean revoking every-package-version-or-revision-signed-by-that-key).<br>
This in turn highlights the need for a well defined process on how to<br>
handle "key transitions" (task left to the single implementators).<br>
<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The downside to this is that it redoes the basic GPG keysigning mechanism to some extent, but it does address key transitions more easily.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A distributed and secure hackage sounds like a dream, I really hope this<br>
comes to life!<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups "Commercial Haskell" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:commercialhaskell%2Bunsubscribe@googlegroups.com" target="_blank">commercialhaskell+unsubscribe@googlegroups.com</a>.<br>
To post to this group, send email to <a href="mailto:commercialhaskell@googlegroups.com" target="_blank">commercialhaskell@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/commercialhaskell/20150413121848.GA3834%40x60s.casa" target="_blank">https://groups.google.com/d/msgid/commercialhaskell/20150413121848.GA3834%40x60s.casa</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</blockquote></div></div>