[Catalog-sig] [Draft] Package signing and verification process

[Zygmunt Krynicki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 06.02.2013 11:57, Christian Heimes pisze:
> Am 05.02.2013 22:28, schrieb Zygmunt Krynicki:
>>> * If we are trusting the fingerprint someone is sending us we 
>>> can trust the public key they are sending us, * Adds an extra 
>>> step to go from zero to releasing * Expecting the user to
>>> decrypt the mail manually is kinda unfriendly
> 
>> It provides a guarantee that the user has access to the public
>> and private keys and completes the email cycle. Launchpad.net has
>> the same functionality built in.
> 
> Exactly! I modeled the workflow based on Launchpad's design. The
> extra cycle helps the user to verify her setup. This aids users
> that are new to GPG and signing, too.
> 
>> I get the feeling that we either put a lot of trust in the
>> central authority (pypi) or we must conclude that peer-to-peer
>> trust without automatic update methods is the only way that
>> prevents us from some attacks.
> 
> My design has the benefit of enabling both levels of trust at the
> same time:
> 
> 1) An overtrustful user just has to trust PyPI's key. She checks 
> PyPI's signature of the package metadata + maintainer's signature
> to verify that the maintainer was trusted by PyPI at the moment of
> the upload. After that she verifies the uploader's signature of the
> file WITHOUT verifying the uploader's key. The user doesn't trust
> the uploader's key explicitly but rather trusts PyPI's simple key
> check.
> 
> 2) A more paranoid user also needs to establish full trust of the 
> uploader's key (import and sign the key).

I don't think we ever need to do this part. Nobody will go and find
each developer to personally confirm their identity and get their key
fingerprint. We don't need that at all.

What we want is to allow the user to express trust in a particular
person, as identified by their key fingerprint, whoever that person
may be (that person may be dead for instance), to author a particular
package.

We never expect to meet the developer. Just review their code
(probably once) and keep accepting subsequent updates to that code (as
limited by the project name) for as long as we choose not to revoke
that trust. This ironically allows full anonymity for the upstream
developers if they so desire.

>> I agree. I think that pypi should not have to be trusted. Real 
>> people trust other (few, limited) real people. We don't normally 
>> trust large bodies (corporations, groups) as that trust cannot
>> be effective.
> 
> No, you have to trust PyPI on some degree. PyPI is *the* authority
> of the relationship between users and projects. PyPI is the only
> entity in process that can truly verify that a key holder was a
> project maintainer at some given point in the past.

But that information is worthless to me. Anyone can upload a new
project to pypi. What I want is to know if all the software that I
install via pip is from the trusted set of developers. If someone
introduces a new dependency I want to examine it and trust the
developer of the new dependency. This should never happen automatically.

All that I want pypi to do is to have non borked database where I can
register my software. With signed code and developer-project
association I don't care if pypi gets owned tomorrow, it hosts no
valuable data.

> 
> If you don't trust PyPI then you have to create and maintain your
> own mapping of key fingerprints to projects.

Yes, that is what I want to do. Otherwise we have no trust, just
signed malware coming from one site.

Thanks
ZK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREl13AAoJECiU6TooxntHmUAP/3/O9LFtk2vhi6bW1eoBwdj0
fPYZiDYGx84t0UNj4SnbFNwFakCgJeX57og5mNm2c4krMlzkPa3K3EK6K89UAnZ+
a15IQcMVkwp8XjvADixWaUczRwJa6J52Kw579s4OIiadauwN7Buk/mQu9BXQfsTw
raWRlFMa2A6MXFN+Is/0T9MpzKqpjEApQ5qfkprWTTgwpZkeyvwvT2NxGWy6oNob
Ncp9lsZRVu/4i0kdqe3IIg1N6l/P/xde3OAffA4JBjqgci8TIY9lkANBLlCE2GsP
V0CALJcuRWe2uWEu3EvAyzDSeInctIx5n7eObF3BXjsKLoyzd+d5j8qACyKIpbEf
YXADchMayoeNTf9IzzXQOf3z4pBaNfkmauaWf2fbbeYVVLxilvKh1Z03Mbr7Y0BZ
nT+Jm7k9G9eEClD7xLHXedoxcngCis9CX+bXrqHVdvjDnBndDIfCZErxameVxOj6
3DcDoFZFtlbbdrXqd1DhQKdxg+A0SV/jJxQSNKeSsg41ByoMdhjhJzu37+qCtGpW
T9aFf8GwLvxQDZD53iiF53yQOJQSDjm1JAyyxegKB5h9mJGy54nQbqS6TjisS/Nq
l+KXpKiwHAN0rvhphluB3n4pTFXbP/6weB66+7W4NsRpLuKbG3ckq03fRkPv2u0f
i6CtFEAr+LGwWmA5w6sg
=+0PT
-----END PGP SIGNATURE-----