[Distutils] PEP 458: Surviving a Compromise of PyPI: Round 1

[anatoly techtonik]

On Sun, Nov 17, 2013 at 7:22 AM, Trishank Karthik Kuppusamy
<tk47 at students.poly.edu> wrote:
> Hello everyone,
>
> Donald, Justin and I have co-authored a PEP that recommends a
> comprehensive security solution to allow PyPI to secure its users
> against a wide array of compromises.
>
> The gist of the PEP is that the changes to PyPI are essentially
> invisible to users and developers unless an attack is underway.
>
> The key design ideas are as follows:
> ...

These are not design - these are implementation details. What's the idea
about that metadata? I don't get it. I already spent 15 minutes reading
here and there and still can't see any short concept description. Only
vague "end-to-end" "security best practices" buzzwords.


> * Developers do not have to opt-in to secure their projects with their
> own TUF metadata. In that case, PyPI will sign these "unclaimed"
> projects on their behalf. However, unclaimed projects will not be secure
> against a PyPI compromise.

So PyPI will sign malicious packages from compromised developer
account who still uses Python 2 for his enterprise application and was not
careful enough to pay attention to http://bugs.python.org/issue12226
and uploaded his package through unsecure PyCon WiFi network.

Until bugs like this exists, any complication and will lead to "safe
security" feeling, which is much worse than being aware of poor state.

> * To protect against a PyPI compromise, developers may choose to
> register their public keys with Warehouse and upload their own signed
> TUF metadata about their projects.

If developer account is hacked, there is no protection. The real protection
is only known hashsize of the known package of specific version.
Protection against change of package version contents, not against new
malicious release / upload. If PyPI is a central repository, and hashsizes
are not distributed, it is easy to hack PyPI, alter hashsizes, serve
malicious package to few target recipients and return everything back. If
hashsizes are distributed, you can't go unnoticed.

Is it that TUF provides? If yes, what is the distribution mechanism?

> * Therefore, developers do not have to concern themselves with key
> management in case they leave their projects as "unclaimed". When they
> do claim their projects, they simply have to register their keys once
> with Warehouse. After that, they may delegate signing for distributions
> as they wish without depending on Warehouse.

Use case explanation needed. I'd split in two:
1. developers who don't care don't need to care
2. developers who care need to "claim project" by registering keys, and
    then delegate signing without depending on WH to who?

"unclaimed" project. What's this? What is the process of "claiming a
project"? Is there a better terminology? This reads like picking abandoned
project or project without authorship.


> * Clients will be instructed to first search for a project in the more
> secure claimed metadata (protected by offline keys) before looking for
> it in the less secure unclaimed metadata (protected by online keys).

What are the main points that makes offline signatures more secure
once more?

> The official PEP is here:
>
> http://www.python.org/dev/peps/pep-0458/

Too wordy. Complicated. Picture is good, but didn't help. The document
should be readable to ordinary corporate Joe, who knows that he got PGP,
but doesn't know what root keys are signed for. And it should be concise
enough for people with knowledge. I don't know if it is possible to do both.

> We welcome your feedback and suggestions.