Proposal: cabal-install: verify OpenPGP signatures
nikita at karetnikov.org
Thu May 22 20:43:01 UTC 2014
I’ve been extremely busy recently, so I only answer the questions for
now. Please speak up if you see a possibility for an attack, or if
something is not clear or not efficient.
> 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.
Each Hackage user should be able to upload their public key.
Each Hackage package must have a “signed?” flag or an equivalent (which
will be set automatically).
While uploading a package, a user should be able to choose whether to
sign it or not.
If a package is signed, the maintainers have the permission to sign. If
it’s necessary to add a maintainer, the uploader lists a username in a
file, signs it, and uploads. (Is there a better way to achieve the same
thing?) The server checks the signature, parses the file, and adds the
usernames to the maintainers group.
Since it’s important to sign the file locally, there should be a
convenience tool allowing to select the usernames. An error must be
raised if the file is not signed; the server must not allow such
uploads. Each user of the said list must have a public key on Hackage.
If not, the server must show an error message.
If a key is not known, the server must check whether it’s signed by a
previously known key corresponding to the 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).
When a user runs ‘cabal update’, it fetches a list of packages along
with the “signed?” flags and the keys corresponding to each package. If
the cache is empty, the information is written to disk. If not, it is
compared with the previous version. If a package that was signed
previously is not signed, an error must be raised.
People will be able to share such files (if they want) in order to
> * How to distribute the web of trust among end users (as opposed
> to authors) to minimise effort.
I’m not sure. Maybe we shouldn’t bother (at least for now). If someone
wants to check a fingerprint, for instance, they can ask on haskell-cafe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: not available
More information about the cabal-devel