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.
> 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.
> Anyway, the signing process will be open and should be reproducible by hand,
> with minimum hassle.
Yes.
> But having opam-publish generate, and manage keys would be a definite gain in
> usability IMO.
Or opam itself.
> * 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.
> * Last, I'd like your advice and opinion on the algorithms and signing to
> use. Small elliptic-curve based signature (ed25519) seem to be all the hype
> now with stuff like signify or minilock. What is the state of what we
> currently have in native OCaml, and what would you recommend ?
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).
Best,
Daniel
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
