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

[Hannes Mehnert]

-----BEGIN PGP SIGNED MESSAGE-----
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.


hannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCQAGBQJVAC2fAAoJELyJZYjffCju1JcP/jJzvdxxFoTEvPBD1ippAzzN
+dsiabsF0MsWSiMWWBuRlDcyaNJJ02y0NVWeti2g26Ql+sV3g6/kp7vg4pz5iJNP
gbPE2FsyC/OTdL2HNAtvdOos1OsP5Gd6H8+K9fZBwQRWSvmYjrJPbgLA5chhmeTi
Mu+dnEz4Az2QTcEmfPqgLUGrGQuKLI2QzyWetbBLDpYitrOlAnLp5KP9Vulvecln
Wv2XJxWKjrpFATL/L2gh4pJFEI0G+LA/zC0FXzkEag2XhG9eU6le9VsT+KmvqlFD
xSMZA6xBAr9TBA5QUHo0Qhmko21MtK1QSqWHg97mbypic1AL06STQqdQ0Fu7t9Ro
fleZ1dAYH3PujmaQ8lm+M4Tg4YEAQL0gcIz3+e5qMlekH4gIZ7gsWKKv82iVaZrB
0Wc4leVkVwJ1gQ5Cxkcn2Wb4HwoYX8FZdgoeA5WO4Fs1qKzMxBXXlAwlNpNfcBR7
pKz/w6pE9K70cVXl4FBlMFTCuHhwxuL34eFXJKlrHPiVYbW1ln8sYbkGTUsX/ahR
M1Zle0JjGdc/6dTKENAS3nofC2kQhlUeeu+Dk8PVyf+OSqAybvvVOd3YK9dMEmVx
DJp4CL7FE5Ff+2P/lW6xvCIZFP+6CEQll6dEh5pvay3sINRwpI1e4047a179k1jA
LAJnewFlqZMmWflf0IB9
=VR1/
-----END PGP SIGNATURE-----