[Distutils] GnuPG signatures on PyPI: why so few?

[Daniel Holth]

Or they could be printed as QR codes.

An interesting secure time service:
https://roughtime.googlesource.com/roughtime

On Wed, Mar 15, 2017 at 1:49 AM Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

> The big problem here, of course, is "key management"; what happens when
> someone throws their laptop in a river.
>
> https://github.com/ahf/teneo indicates to me that it may be possible to
> use a KDF to get an Ed25519 key from a passphrase that the user remembers,
> minilock-style, largely mitigating that problem, assuming we can get users
> to remember stuff :-).
>
> -g
>
> On Mar 14, 2017, at 7:35 AM, Daniel Holth <dholth at gmail.com> wrote:
>
> The wheel command implements but never fully realized the commands 'wheel
> keygen', 'wheel sign' for a bundled signature scheme (where the signature
> is inside the signed file) inspired by JAR signing and based on Ed25519
> primitives + JSON web signature / JSON web key. The idea was to have wheel
> automatically generate a signing key and always generate signed wheels,
> since it's impossible to verify signatures if there are none. Successive
> releases from the same author would tend to use the same keys; a TOFU
> (trust on first use) model, a-la ssh, would warn you if the key changed.
> The public keys would be distributed over a separate https:// server
> (perhaps the publisher's personal web page, or an application could publish
> a list of public keys for its dependencies as-tested). Instead of checking
> the hash of an exact release artifact, you could use a similar syntax to
> check against a particular public key and cover yourself for future
> releases. Instead of key revocation, you could let the only valid signing
> keys be the ones currently available at the key URL, like oauth2
> https://www.googleapis.com/oauth2/v3/certs
>
> The goal you'd want to shoot for is not 'is this package good' but 'am I
> being targeted'. A log of timestamp signatures for everything uploaded to
> PyPI could be very powerful here and might even be useful without publisher
> signatures, so that you could at least know that you are downloading the
> same reasonably old version of package X that everyone else is using. If
> there was a publisher signature, the timestamp server would sign the
> publisher's signature asserting 'this signature was valid at time X'.
>
> On Tue, Mar 14, 2017 at 2:52 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 14 March 2017 at 15:48, Glyph Lefkowitz <glyph at twistedmatrix.com>
> wrote:
>
>
> 2. Except, as stated - i.e. hashes without signatures - this just means we
> all trust Github rather than PyPI :).
>
>
> Yeah, HTTPS would still be a common point of compromise - that kind of
> simple scheme would just let the repo hosting and PyPI serve as
> cross-checks on each other, such that you had to compromise both (or the
> original publisher's system) in order to corrupt both the published
> artifact *and* the publisher's record of the expected artifact hash.
>
> It would also be enough to let publishers check that the artifacts that
> PyPI is serving match what they originally uploaded - treating it as a QA
> problem as much as a security one.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170315/8403daa6/attachment.html>