> - Daniel Bünzli, 11/03/2015 04:49 -
> 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.
An attacker could then divert the download attempts to any url; mostly
harmless, I can't imagine leveraging this for a DDos. But it can still prevent
you from updating, without knowing the reason.
Another attack mentionned by TUF is feeding an infinite datastream to the
download (blocking the update, possibly filling the disk and causing trouble) ;
so we should be sure to include the file size somewhere.
> > 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.
That sounds like a fair workflow. There could be automatic maintainer
notifications for such cases (by mail, and why not on github, but we shall not
depend on it)
> > But having opam-publish generate, and manage keys would be a definite gain
> > in usability IMO.
>
> Or opam itself.
Worth considering, but OPAM doesn't do anything related to packaging and
publishing at the moment (unless you count package pinning): it could be in the
same program but in clearly separated modules.
> > * 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.
Pinning allows you to specify any source of your choice for a package, and to
modify it. Adding signatures there sounds cumbersome -- we may put a warning on
pinning to a remote source ("you're leaving OPAM-secured territory") but
relying on the underlying security (e.g. git+ssh) sounds OK to me at the
moment. I don't grasp where exactly signed commits would articulate.
> > * 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).
>
Not sure if using the same key for signing and e.g. pushing to github over ssh
can be an issue or not. On the publication bureaucracy, that's very high in my
concerns indeed -- ssh-agent sounds handy indeed, but I'll let Hannes give
advice on that. I haven't heard of using the ssh rsa private key for signing,
so there might be a reason for that...
Cheers,
Louis
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
