[Haskell-cafe] Improvements to package hosting and security

[Michael Snoyman]

On Mon, Apr 13, 2015 at 3:21 PM Francesco Ariis <fa-ml at ariis.it> wrote:

> 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 at googlegroups.com.
> To post to this group, send email to commercialhaskell at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/commercialhaskell/20150413121848.GA3834%40x60s.casa
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150413/dd0dd89b/attachment.html>