[Distutils] vetting, signing, verification of release files

[Daniel Holth]

Wheel provides a "wheel keygen" and "wheel sign" command and if you
set WHEEL_TOOL=/path/to/wheel then bdist_wheel will automatically sign
all the packages you create. Ideally wheel would sign every package,
reducing the problem from "how do we force people to use PGP" to "how
do we derive value from existing signatures." It also allows multiple
signers per package.

Readers of this list mostly use pypi for library management during development.

Zooko's use case is different and appropriate for an application
publisher. You trust the application publisher and want to get
versions of dependencies they trust/tested or that are signed by
people that they trust. As an end user you do not want parties unknown
to "fix" dependencies.

In any case it wasn't ever expected that people would embed keys in
setup.py's abstract dependencies, rather they would go into
requirements.txt used to install complete applications. You would also
have had the option to trust any number of signing keys (n signers out
of m possible signers, likely at a minimum both the publisher's and
your own signing key would be accepted for any particular package).

There has been a focus on deciding whether a package is malicious. I
think that's wrong / too hard. It's better to focus on making sure
everyone at least gets the same packages so targeted attacks via the
pypi system don't work. I also feel it's much more important to make
signatures widespread than to make them individually as secure as
possible.


On Wed, Jul 17, 2013 at 4:14 PM, Donald Stufft <donald at stufft.io> wrote:
>
> On Jul 17, 2013, at 3:58 PM, zooko <zooko at zooko.com> wrote:
>
> In my opinion it is a good idea to embed, not just the *name* of the package
> that your package depends on, but also the public key or public keys that
> your
> package requires the depended-upon package to be signed by.
>
>
> The problem with this is it makes it more difficult to replace a library
> with a patched copy.
>
> Example:
> I want to install the library Foo, Foo depends on Bar, and Bar depends on
> Broken. Broken
>         is well, broken and I want to use a patched version of it locally.
> So I fix Broken, upload
>         it to my private index server and I pip install from that.
>
>         If public keys are encoded as part of the dependency chain, not only
> do I need to patch Broken
>         but I also need to patch Foo and Bar _and_ anything else that
> depends on Foo, Bar, or Broken
>         _and_ anything else that depends on those, so on until we reach the
> leaves.
>
>
> Packages should have signatures. Dependency should be by name. End tooling
> should provide a method to make a set of requirements with certain
> signatures or hashes for a specific instance of this installation. (E.g.
> Awesome, Inc could have a set of requirements that contain Foo, Bar and
> their own patched version of Broken along with the keys used to sign all of
> them).
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>