<div dir="ltr">We may have something unclear in the doc.   We definitely don't just worry about package names.   <div><br></div><div style>(In between meetings, will send a longer response in a bit.)</div><div style><br>

</div><div style>Thanks,</div><div style>Justin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 13, 2013 at 2:15 PM, Daniel Holth <span dir="ltr"><<a href="mailto:dholth@gmail.com" target="_blank">dholth@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Mar 13, 2013 at 5:13 AM, Trishank Karthik Kuppusamy<br>
<<a href="mailto:tk47@students.poly.edu">tk47@students.poly.edu</a>> wrote:<br>
> Hello Nick,<br>
><br>
><br>
> On 3/13/13 4:09 AM, Nick Coghlan wrote:<br>
>><br>
>><br>
>> - the PSF board generally stays out of the technical details of<br>
>> running the <a href="http://python.org" target="_blank">python.org</a> infrastructure, so it's likely that any root<br>
>> keys would be handled by the PSF infrastructure committee. A (2, 4) or<br>
>> (3, 5) trust configuration would likely be manageable at this level.<br>
><br>
><br>
> Understood. We think a higher (t, n) [where t out of n signatures are needed<br>
> to trust the metadata for a role] is better for the root role simply because<br>
> its crucial metadata (the authorized keys for top-level roles) should change<br>
> very rarely.<br>
><br>
><br>
>> - at the target delegation level, PyPI supports the registration of<br>
>> new projects through the web service (see<br>
>> <a href="http://docs.python.org/2/distutils/packageindex.html" target="_blank">http://docs.python.org/2/distutils/packageindex.html</a>). If my<br>
>> understanding of target delegation is correct, this means the "simple"<br>
>> and "packages/source/<letter>" delegations will need to be (1, 1) and<br>
>> online.<br>
>> - higher levels of the target delegation hierarchy could conceivably<br>
>> be kept offline, but there seems little value in doing so if they're<br>
>> trusting on online (1, 1) key<br>
><br>
><br>
> Fortunately, the "targets/simple" and "targets/packages/(version)/(letter)/"<br>
> roles should not require (1, 1) online keys, as their metadata (simply<br>
> target delegations and no actual target files) should also fluctuate fairly<br>
> rarely. I should make this clearer in our design document.<br>
><br>
><br>
>> - many PyPI packages are maintained by single developers, so (1, 1) or<br>
>> (1, n) is likely to be the only generally feasible level of signing at<br>
>> the project level.<br>
><br>
><br>
> Yes, the package developers themselves could choose any (t, n) they like. In<br>
> our design, we propose that PyPI could eventually delegate to "stable"<br>
> packages which need little change (and use more security with more offline<br>
> keys) and to "unstable" packages which need frequent change (and use less<br>
> security with more online keys).<br>
><br>
><br>
>> With the current focus being on getting an improvement from the status<br>
>> quo that we can successfully deploy in a reasonable period of time,<br>
>> the target delegation side of things probably needs to be<br>
>> substantially simpler in the initial iteration. Yes, it leaves us open<br>
>> to certain vulnerabilities we would like to remove in the long run,<br>
>> but we need to be very cautious in the additional demands we place on<br>
>> the users uploading to PyPI. It may even mean the initial iteration<br>
>> allows projects to rely on a PyPI provided signing key for their TUF<br>
>> metadata, using the existing upload mechanisms to add the files to<br>
>> PyPI.<br>
><br>
><br>
> I agree that there is a delicate problem of balancing security with<br>
> usability here, especially in the beginning.<br>
><br>
> You raised a very good issue there: on first migration, how would PyPI<br>
> accommodate packages which have not had their target files delegated to<br>
> their developers? We imagine that in this case, PyPI could assume initial<br>
> responsibility for these packages, and later PyPI would delegate those<br>
> packages to their respective developers.<br>
><br>
> Thanks for your input,<br>
> Trishank<br>
<br>
</div></div>With all the different kinds of metadata, It's interesting to note<br>
that currently TUF seems to only be concerned with the available file<br>
names and their integrity. (Some of us will think of PEP 426<br>
"PKG-INFO" first when we hear the word metadata.)<br>
<br>
It looks like the D metadata lists all the filenames for Django, and<br>
then Django lists them again with hashes and signatures. Why all the<br>
lists? Does every Django release re-assert all the versions of Django<br>
that are available on the index?<br>
<br>
How might I deal with producing the official source distribution<br>
myself and having a friend produce the official Windows build of a<br>
package?<br>
<br>
As an aside PyPI has been doubling in size every 1.5 - 2 years.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888"><br>
Daniel Holth<br>
</font></span></blockquote></div><br></div>