[opam-devel] Package signing (was Re: OPAM 1.3 roadmap)

Hannes Mehnert hannes at mehnert.org
Wed Mar 11 11:57:19 GMT 2015

Hash: SHA384

On 03/11/2015 03:49, Daniel Bünzli wrote:
> Le mercredi, 11 mars 2015 à 03:39, Louis Gesbert a écrit :
>> * the upstream package archive (and possibly its url and mirrors
>> ?)
> If we trust the hash function (i.e. not md5) signing the hash of
> the archive seems sufficient no ? We don't really care where it
> comes from, we care about the content.

yes. hash and size should be signed!

>> No better solution than letting the modified package get signed
>> by a general repository maintainer, maybe with a time window for
>> the rightful owner to sign it ? I'll think some more about it.
> This seems ok to me and rather an UI issue. E.g. as a repo end-user
> I'd like to be informed of the fact ("the meta data has been
> modified by the repo maintainer X") on installs/upgrades. As a
> package maintainer I'd like to be notified of the change and be
> able to agree to the change by signing the change after having
> authenticated it (through a single command line invocation !) at
> which point the end-user warning should disappear for him on
> further repo updates.

if we use email as identification, opam can notify the package
maintainer via email, including instructions what to do if
agree/disagree with the change.

>> * We should require maintainers to sign their packages -> the
>> clients shouldn't accept unsigned packages by default, but there
>> could be "unclaimed" (repository maintainer handled) signatures
>> on the repo to begin with.
> What about pins ? This is where git signed commit could be
> interesting.

I'd leave pins to git+ssh for now alone.. using signed commits open
another whole can of worms.

> One note about that, I'm personally not very cryptographically
> advanced and don't use the gpg stuff but with the years one thing I
> got to know a bit the ssh key-based authentication infrastructure.
> I don't know if that's a good idea or not but maybe we could try to
> hook in that infrastructure as I suspect a lot of devs are familiar
> with it and it would avoid creating one more of these "be careful"
> directories. Besides it could provide OS level ssh-agent
> integration which is quite handy from an UI point view (which is
> one of my fear in all this, there's already so much publication
> bureaucracy).

I'm currently eager to propose unencrypted private keys (valid for
maybe a year, thus we get key rollovers) and having revocation baked
in, thus a compromise of a key can be mitigated easily (and no need
for *-agent). Using the same key for encryption and signing is a bad idea.

Version: GnuPG v2


More information about the opam-devel mailing list