On 30 Mar 2016, at 12:15, Hannes Mehnert <han...@mehnert.org> wrote: > > uhm, this is very much into dreamland right now (since the first step, > of signing integration isn't done yet)...
it's useful to figure out the workflow for people such that it'll actually get adoption... > > On 30/03/2016 13:03, Anil Madhavapeddy wrote: >> That actually sounds like the perfect workflow for signing... if there was >> some way to sign it (perhaps keybase.io via JavaScript) without a CLI, it >> would be much more widely adopted. > > does this propose that you want people to store their private keys > online on the internet (certainly password-protected)? I'm uneasy with > that (and would prefer to store the private keys on the people's > laptops, rather than online). not necessarily; the keybase model seems to support a pure JS workflow where the private keys are never "on the cloud" but on the local machine. In practise, having a mode that lets people do a single-click-or-two sign will make the difference between having to whip out out a CLI (much like the "merge" button in GitHub greatly accelerates the common case of pull request handling). > >>> On 30 Mar 2016, at 12:02, Louis Gesbert <louis.gesb...@ocamlpro.com> wrote: >>> More simply, the mechanism could do all the work, and poll the package >>> maintainer for a signature (assuming he wouldn't sign without actually >>> checking ?) . Something like a mail with instructions and archive + >>> cryptohash >>> to verify, then a command to run and it's done. > > this sounds good to me, a mail where the developer has to invoke some > command-line utility locally to generate a signature, and resubmit this > via mail (well, or git as a first step). A CLI utility to sign is fine, but submitting it via yet another communication mechanism seems unnecessary. -a _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
