[Distutils] vetting, signing, verification of release files
Nick Coghlan
ncoghlan at gmail.com
Wed Jul 17 10:50:16 CEST 2013
On 17 Jul 2013 18:17, "holger krekel" <holger at merlinux.eu> wrote:
>
> On Wed, Jul 17, 2013 at 07:48 +0000, Vinay Sajip wrote:
> > holger krekel <holger <at> merlinux.eu> writes:
> >
> > > about existing schemes/efforts. I guess most Linux distros do it
already
> > > so if nothing comes up here PyPI-specific (what is the status of TUF,
btw?)
> > > i am going to look into the distro's working models.
> >
> > ISTM it works for distros because they're the central authority
guaranteeing
> > the provenance of the software in their repos. It's harder with PyPI
because
> > it's not a central authority curating the content. Perhaps something
like a
> > web of trust would be needed.
>
> I am thinking about curating release files _after_ publishing and
> then configuring install activities to require "signed-off" release files.
> Basically giving companies and devops the possibility to organise their
> vetting processes and collaborate, without requiring PyPI to change first.
> This certainly involves the question of trust but if nothing else an
entity
> can at least trust its own signatures :)
Note that Linux distros don't trust each other's keys and nor do app stores
trust other. Secure collaborative vetting of software is an Unsolved
Problem. The Update Framework provides a solid technical basis for such
collaboration, but even it doesn't solve the fundamental trust issues.
Those issues are why we still rely on the CA model for SSL, despite its
serious flaws: nobody has come up with anything else that scales
effectively.
The use of JSON for metadata 2.0 is enough to make it TUF friendly, but
there are significant key management issues to be addressed before TUF
could be used on PyPI itself. That's no reason to avoid experimenting with
private TUF enabled PyPI servers, though - a private server alleviates most
of the ugly key management problems.
Cheers,
Nick.
>
> best,
> holger
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJR5lLnAAoJEI47A6J5t3LWUkYIAJ1qqyAc185R7NrXqJyEpNo6
> erDSfCMROcMqxtkqLCeoaiKSSBnhyJJpcLJ9a5P2/z8hBsYVTKM54NdOpvJEcgb/
> s/sepYI3vTIXFtUyRTxXPmhUZoxgh+GdvatCWw+7EA8pcAPs3YvrdKPYqHOm3xup
> Z1KWAUrPWhVxoUY8laUBaHkHxX3WJ88Hj0buJfzsKEbQvytT8sRO9Nq03VE5EsjL
> 85boVh4UIA0KUMtEgzxgRGDjD9Cc47ukFrmN/ViYKdmV6gmIBV1h30dcRXhvof5W
> QSuuROqXjQ466Vm5aaE7rfLzIAOtxOvjBuZLygr2bMbZYY8WtHDJD7e0VYFJPCw=
> =vZ9n
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130717/bf016231/attachment.html>
More information about the Distutils-SIG
mailing list