On Wed, 2014-04-30 at 03:15 +0400, Nikita Karetnikov wrote:
> Following up on the “cabal-install: Replacing HTTP with HTTPS” thread.
> I think we can do better. I want to make sure that people will notice
> if someone compromises the packages on hackage.haskell.org.
>
> Here’s a rough plan:
>
> 1. Patch ‘hackage-server’ to allow uploading of OpenPGP signatures.
>
> 2. Patch ‘cabal-install’ to use GPG for verification. (GPG trust levels
> could be useful here.) ‘cabal install’ should also support
> ‘--skip-verification’ or some such to avoid disaster during the
> adoption stage.
>
> In addition, ‘cabal update’ would fetch the list of fingerprints from
> Hackage and cache each revision. A warning would be raised if a
> fignerprint cannot be found in the cache.
>
> If a maintainer wants to use a new key, it must be signed with the
> previously used one. If a maintainer loses their private key, for
> instance, this should be resolved by the admins. For example, an
> admin (admins?) could sign the new key.
>
> After a while, a web of trust would be formed. The fingerprints of
> active maintainers would be well-known.
>
> I’ve been thinking about this for quite a while and don’t see other ways
> to achive the same level of trust while allowing arbitrary uploads. The
> proposal also doesn’t require much manual intervention.
>
> What do you think? I’m willing to work on this but want to make sure
> that my time won’t be wasted. Will you accept such a patch?
I think optional GPG signatures is a good idea, and I think in principle
we would accept the patch. However it does have to be opt-in only: both
opt-in for authors signing, and opt-in for clients checking.
The idea of GPG signing is complementary to another package signing idea
that we have been considering (Mikhail's reference to Austin's plan).
GPG signing can provide a higher level of security because it can be end
to end. However it's much harder with GPG signing to provide broad
coverage of packages and users. It's hard because not all users have GPG
(e.g. Windows), not all authors have GPG or can be bothered to sign
anything. The web of trust is tricky, especially if we want to minimise
the effort on the part of end users.
Because of these issues with GPG signing, we thought a better use of our
time was to work on this complementary plan where we have the server
sign all the packages and the client automatically check. This is less
secure because it is not end-to-end, but we can cover every package and
we should be able to do it on all platforms, and without any knowledge
or action needed on the part of authors or users.
However, as I've said, these two security measures are complementary, we
can have both. I can imagine a situation in which all packages are
signed by the server, but some important ones are also signed by the
authors, giving us a higher level of assurance of authenticity and
integrity for those packages.
So yes, you're welcome to help with either GPG signing or this
alternative scheme, whichever you'd prefer to hack on.
If you go for GPG, here's some issues to consider:
* Who is allowed to sign for each package? Do we place any
restriction or is any sufficiently trusted user allowed to
upload any package? (I know the server will try to prevent this,
but I'm talking about crypto level assurance here, not just
server permission checks). If we do try to restrict it then we
need some equivalent of the maintainer groups so I can allow
other certain people to upload "my" package.
* How to require some packages to be signed while not requiring
all packages to be signed. In particular, once we opt-in to
signing a particular package, we want to make sure it's signed
from then on, and not allow a non-signed version of the package
(which would otherwise be an obvious attack).
* How to distribute the web of trust among end users (as opposed
to authors) to minimise effort.
Good luck!
Duncan
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
