Mailman 3 August 2013 - Distutils-SIG

Who administers bugs.python.org, and can we get a notice on the setuptools tracker?
by PJ Eby 05 Aug '13

05 Aug '13

Hi. Not sure who this should go to, but it would be really good if we could get a prominent notice on the old setuptools tracker (at bugs.python.org), specifically on the issue creation screen, to inform people that this tracker is only for setuptools 0.6, and that issues for later versions should go to https://bitbucket.org/pypa/setuptools/issues instead (with a link, of course). Right now, what's happening is that, despite all the other prominent links to the correct tracker, there are still people going to the old tracker and posting issues for the newer versions of setuptools. This means they then have to wait for me to tell them they're in the wrong place, and then resubmit to the correct tracker. Setuptools 0.6 is still supported, so closing the tracker entirely isn't appropriate just yet, but putting up a prominent notice on the issue submission screen saying, "If you're reporting an issue for setuptools 0.7 or higher, please use....". Thanks in advance!

2 2

[issue157] setuptools installation instructions fail on OS X: no wget
by Ned Deily 05 Aug '13

05 Aug '13

New submission from Ned Deily: The current installation instructions for "Unix-based Systems including Mac OS X" do not work on vanilla OS X systems because OS X does not ship with "wget". It does, however, ship with "curl". (The Distribute web page had been updated a long time ago to use "curl" instead of "wget"; I guess that never happened for the "setuptools" page.) https://pypi.python.org/pypi/setuptools/0.9.8#unix-based-systems-including-… ---------- messages: 743 nosy: nad priority: bug status: unread title: setuptools installation instructions fail on OS X: no wget _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue157> _______________________________________________

1 0

Monthly Download Counts on PyPI
by Donald Stufft 02 Aug '13

02 Aug '13

Just a quick update that the monthly rolling download counts are now enabled on PyPI which means the download count rollout is now complete. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

2 1

Migrating Hashes from MD5 to SHA256
by Donald Stufft 02 Aug '13

02 Aug '13

PyPI has historically used MD5 in order to verify the downloads. However MD5 is severely broken and is generally regarded as something that should be migrated away from ASAP. From speaking with a number of cryptographers they've more or less said that the major reason they believe that MD5 hasn't had a published pre-image attack is just because it's so broken that most researchers have moved on to newer hashes. Since versions 1.2 pip has supported md5, sha1, and any of the sha2 family. Additionally it has only supported SSL verification since 1.3. This means there is no version of pip which both verifies SSL and only allows MD5. Since version 0.9 setuptools has supported md5, sha1, and any of the sha2 family and it has only supported SSL verification since 0.7. I propose we switch PyPI from using MD5 to using SHA256. There is no security lost from using a hash that pip prior to version 1.2 doesn't understand as it didn't verify SSL so an attacker could simply modify the hashes if they wanted. Additionally there is no security list from setuptools versions earlier than 0.7. However setuptools versions 0.7-0.8 will lose their hashes. I believe this is a ok thing to happen because the uptake on 0.7-0.8 is fairly low. Most people will use the setuptools bundled with virtualenv which has only ever bundled 0.6 or 0.9. So essentially moving from MD5 to SHA256 will only negatively affect the security of a handful of users while positively impacting the security of everyone else. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

16 81

Status report on PyPI+pip+TUF
by Trishank Karthik Kuppusamy 01 Aug '13

01 Aug '13

Hello Nick and the PyPI community, This is a brief status report on the integration of PyPI and pip with TUF. (A quick reminder: TUF is a general "plug-n-play" update framework designed to introduce usable security to community software repositories such as PyPI. If you think of PyPI as HTTP, then TUF is like adding SSL, and more, to HTTP. More information may be found at [https://www.updateframework.com/].) Firstly, thanks to the generous funding of the National Science Foundation, we are pleased to introduce the addition of a full-time developer, Vladimir Diaz, to our team. Vladimir has been instrumental to the development of TUF, and we are excited to have him join us full-time. (Now we do not just have one PhD student who works on TUF when he is not busy working on other projects!) We are also happy to have a few interns --- Zane Fisher, Tian Tian, John Ward, and Yuyu Zheng --- on board for the summer. Since the security attacks on the Python wiki infrastructure earlier this year, we have been closely following Distutils-SIG to see what we could do to help secure PyPI. We use Python heavily in all of our projects, and would love to help in any way we can. Here is what we have done: ========================== 1. At PyCon 2013, we showed that pip needs very little modification to work with a TUF-enabled PyPI mirror. 2. Soon after (during the spring break), we wrote automation to build a TUF-secured PyPI mirror (which is indistinguishable from any other PyPI mirror except that it has signed metadata about all of the files on PyPI). 3. At the same time, thanks to efforts of Konstantin Andrianov, we also wrote a lot of unit and integration tests to show the attacks that are possible without TUF and impossible with TUF. 4. After that, we started investigating the most efficient way to build TUF metadata for PyPI. We found that requiring a separate key for every package on PyPI may sound like a good idea, but besides generating too much metadata, this scheme also makes key management difficult. Here is what we are doing now: ============================== We are designing a usable key management scheme, coupled with efficient generation and download of metadata, which we think should make for a smooth integration of PyPI with TUF. We are actively working on this and think that we are almost there. As a conservative estimate, we do not believe that this should take longer than two weeks. Here is what we are going to do next: ===================================== In about a month, we will present to you a demonstration of a PyPI mirror and a pip client which are robust against entire classes of security attacks. We welcome you then to try our demo, be really critical of it and tell us what you think about what we could do better. Our goal with TUF is to provide a framework that works with as many software community repositories as possible and that secures as many users as possible. More details on our development are available at our mailing list: https://groups.google.com/forum/#!forum/theupdateframework We hope this gives you a good idea of the current status of integrating TUF with PyPI and pip. Let us know if you have questions. Thanks, The TUF team

2 4