Re: [Distutils] Comments on PEP 426
On 04.09.2013 01:51, Nick Coghlan wrote: On 4 Sep 2013 07:20, M.-A. Lemburg m...@egenix.com wrote: On 31.08.2013 17:56, Nick Coghlan wrote: setuptools definitely has its issues, but it's still substantially superior to distutils, and has the critical virtue of behaving the *same* in all currently supported versions of Python. Consistency across platform versions is something you really want in a build tool, and is something a standard library module like distutils can never provide. As one of the most conservative Linux vendors, even Red Hat has acknowledged this key point by creating the Red Hat Developer Toolset to provide a more consistent build experience across different RHEL versions. Microsoft (with Visual Studio) and Apple (with XCode) have long worked the same way. I think you're overestimating the usefulness of setuptools here. setuptools only extends distutils in various ways, it doesn't replace it. And it doesn't do a good job at extending it, since it monkey patches distutils in areas where monkey patching is not necessary (*). distutils does provide a pretty straight forward way to extend it, adding new commands to it and new options to existing commands. I've been extending distutils for many many years in mxSetup.py (which is part of egenix-mx-base). It's been working great and I only rarely had to revert to monkey patching in order to get something implemented. IMO, a much better way forward would be to integrate useful setuptools changes right back into distutils, so that the monkey patching no longer happens and python-dev can officially bless those set of changes. BTW: I'm not sure where you get the idea from that setuptools behaves the same across Python versions or platforms. It simply inherits the distutils changes in each version and thus exhibits the same problems (if any) that you see with distutils itself. (*) Monkey patching is necessary in a few places, but most of those could be fixed by splitting out method code into new methods which can then be overridden to provide the new functionality. Note that this is a classical problem with OO code, there's nothing special here w/r to distutils. Sure, it's *possible* someone could publish a better setuptools that avoids unnecessary monkey patching, leaves out easy_install and separates pkg_resources out into its own distribution. However, setuptools, for all its flaws, already clears the good enough bar in most cases, at least as far back as 2.6 (and likely earlier). Any new standards are going to have to be supported in setuptools *anyway* due to the number of projects that rely on it explicitly for the opt-in features like dependency declarations and entry points, so it seems expedient to me to avoid duplicating that effort. There are also existing projects like bento with a setup.py that can cope with vanilla distutils *and* with setuptools, but may not cope with a new setuptools replacement that does things a bit differently again. The recommendation to use setuptools and the requirement for all distributions to at least *tolerate* setuptools being imported into the same process as their setup.py is an entirely pragmatic one in order to bootstrap the migration to the next generation dependency management system by using the *current* dependency declaration system. The idea is to integrate setuptools extensions to distutils back into vanilla distutils, so that you don't need to do monkey patching and change distutils in wasy that break the regular distutils extension mechanisms. This may break a few extensions for Python 3.4, but not many. Most distributions use plain distutils or plain setuptools without any changes. Of the ones that use setuptools the most dominantly used features are being able to build eggs and requirement tracking. The ones extending distutils (with or without setuptools monkey patching enabled) will most likely already support most of the setuptools hacks, simply because it's been difficult to ignore setuptools for at least the last 5 years. The few that don't will have to get updated after such a change. We need to get rid off hacks like setuptools if we ever want to see light at the end of the packaging tunnel. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
Re: [Distutils] Comments on PEP 426
Hi, Paul Moore p.f.moore at gmail.com writes: On 3 September 2013 22:20, M.-A. Lemburg mal at egenix.com wrote: IMO, a much better way forward would be to integrate useful setuptools changes right back into distutils, so that the monkey patching no longer happens and python-dev can officially bless those set of changes. I'm curious about this possibility. It seems everyone has the memory of a goldfish here? Reintegrating useful third-party features, and generally improving distutils, was Tarek's original work on distutils, then distutils2 / packaging. (Yes, it's a pity it was shot down, since all we are left now are pie-in-the sky improvements that may happen 5 years down the road for the average user) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 03.09.2013 23:57, Paul Moore wrote: On 3 September 2013 22:20, M.-A. Lemburg m...@egenix.com wrote: IMO, a much better way forward would be to integrate useful setuptools changes right back into distutils, so that the monkey patching no longer happens and python-dev can officially bless those set of changes. I'm curious about this possibility. One thing that would ease experimentation in this area, and which has certainly been discussed elsewhere in this thread, would be if there was a clearly defined set of setuptools facilities that are missing from distutils, and which the modern infrastructure relies on. Off the top of my head, the following items would definitely be needed: 1. An extension to the install command to supply a list of the installed files (the --record feature of setuptools) This already exists in distutils' install command. 2. A bdist_wheel command This is not part of setuptools, but yes, this should be added as well. 3. Updates to the install (or maybe bdist_egg) commands to emit Metadata 2.0 and dist-info metadata Should be easy to do (mostly copypaste). 4. An install_scripts command that created script wrappers from metadata (may not be needed if the only supported route to install is via wheels) Adding new commands is really easy in distutils, so that's not much of a problem either: distutils has a cmdclass mechanism which allows to easily register new commands or override existing command classes. We've been using this in mxSetup.py to customize distutils commands and add new commands such as an autoconf mechanism in the build process, a C library build process (implementing the ./configure; make dance), bdist_prebuilt or uninstall. To be honest, these extensions do seem relatively achievable. But I don't know if they are complete - can the advocates of setuptools clarify what facilities of setuptools are needed beyond these (with an indication of where they are used in the build toolchain). There are other features of setuptools that I can see would be relevant (for instance, version parsing and requirement checking) but these seem to me to be more in the nature of utility library features than distutils enhancements per se. I'd fully expect that such code could easily be extracted from setuptools (indeed, it may be that all of that code is isolated in pkg_resources already) without needing any of the distutils monkeypatching/extensions. It may be that such an approach is reinventing the existing wheel that is setuptools, and indeed it may never go anywhere - but it is an interesting alternative train of thought. It's not about reinventing the wheel, it's taking the good bits from setuptools and moving them into distutils to make them standard for Python 3.4+, allowing setuptools to stop monkey patching distutils and extensions to stop relying on a setuptools patched distutils. I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 08:13, M.-A. Lemburg m...@egenix.com wrote: It's not about reinventing the wheel, it's taking the good bits from setuptools and moving them into distutils to make them standard for Python 3.4+, allowing setuptools to stop monkey patching distutils and extensions to stop relying on a setuptools patched distutils. Personally, I was thinking about externally packaged extensions to distutils - a sort of setuptools lite if you like. I think Antoine has a point in that people do tend to keep suggesting updating distutils forgetting that there is no way that is ever going to happen. To my knowledge, no core committer is willing to apply patches to distutils[1] and the track record of someone external getting core privs and trying to apply distutils changes consists of Tarek, who despite all his efforts didn't manage to get anywhere. I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. To my mind the biggest issue (and again, I'm with Antoine here - people keep forgetting this) is that there are no defined API specs to work to. You can't implement just the important bits of setuptools without knowing what those bits are, and what the interface to them is. I do suspect that the issue is not so much forgetfulness as optimism - people keep hoping that we can find a clean and simple solution, in spite of the overwhelming evidence that it'll never happen. But maybe that's just me being optimistic as well :-) Paul [1] For what are probably very good reasons - it seems like it's a sure-fire route to instant burnout :-( ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 04.09.2013 09:27, Paul Moore wrote: On 4 September 2013 08:13, M.-A. Lemburg m...@egenix.com wrote: It's not about reinventing the wheel, it's taking the good bits from setuptools and moving them into distutils to make them standard for Python 3.4+, allowing setuptools to stop monkey patching distutils and extensions to stop relying on a setuptools patched distutils. Personally, I was thinking about externally packaged extensions to distutils - a sort of setuptools lite if you like. I think Antoine has a point in that people do tend to keep suggesting updating distutils forgetting that there is no way that is ever going to happen. To my knowledge, no core committer is willing to apply patches to distutils[1] and the track record of someone external getting core privs and trying to apply distutils changes consists of Tarek, who despite all his efforts didn't manage to get anywhere. The reason for this is not that no one wants to apply such patches, it's that distutils has been put on a moratorium for quite some time now - mostly due to the distutils2/packaging efforts and the concerns about backwards compatibility. We can lift that moratorium and start to move forward again. Note that just moving features from setuptools into distutils will not cause major breakage. If we are serious about this, we do have to accept some breakage, but it will be minimal. Related to the suggestion to have distutils extensions, we could also add a mechanism to make the cmdclass feature in distutils, I mentioned, easier to use and provide a way which allows distutils extensions to easily register themselves. I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. To my mind the biggest issue (and again, I'm with Antoine here - people keep forgetting this) is that there are no defined API specs to work to. You can't implement just the important bits of setuptools without knowing what those bits are, and what the interface to them is. I don't quite follow you there. setuptools does come with documentation and the code is available to be read and reused. The situation is similar for distutils itself. Most of the details are laid out in the code. You just need to take a bit of time and learn the concepts - which is not all that hard. I do suspect that the issue is not so much forgetfulness as optimism - people keep hoping that we can find a clean and simple solution, in spite of the overwhelming evidence that it'll never happen. But maybe that's just me being optimistic as well :-) I think we've walked down too many dead ends by now to keep thinking that someone somewhere will come up with the one and only solution to it all. distutils itself was an effort in that direction. Before distutils, the only mechanism we had was Makefile.pre.in. distutils isn't prefect, but it works mostly and has been working for quite some time now. Given that its in the standard library it's hard to evolve - just like any code that makes it into the stdlib. I think it's about time that we allow some minimal breakage to get rid off hacks like setuptools and first class some, or even all, new commands and features setuptools adds to distutils. [1] For what are probably very good reasons - it seems like it's a sure-fire route to instant burnout :-( True. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] OpenID login - Login failed:NotAuthenticated('Replay attack detected', 9)
Hi,
I'm getting the following error when I try to login using OpenID
on PyPI:
Login failed:NotAuthenticated('Replay attack detected', 9)
Is there any known cause for it?
Regards
Antoine.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Please use a mix of different-case letters and numbers in your password
Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
Antoine Pitrou solipsis at pitrou.net writes: Hi, Paul Moore p.f.moore at gmail.com writes: On 3 September 2013 22:20, M.-A. Lemburg mal at egenix.com wrote: IMO, a much better way forward would be to integrate useful setuptools changes right back into distutils, so that the monkey patching no longer happens and python-dev can officially bless those set of changes. I'm curious about this possibility. It seems everyone has the memory of a goldfish here? Reintegrating useful third-party features, and generally improving distutils, was Tarek's original work on distutils, then distutils2 / packaging. (Yes, it's a pity it was shot down, since all we are left now are pie-in-the sky improvements that may happen 5 years down the road for the average user) Note I'm not *criticizing* those pie-in-the-sky improvements. There's no false dilemma here. But the interim solution of gradual improvements would have been very beneficial everyone (including the developers of long-term changes, since that would spare them the complaints about the lack of short-term improvements :-)). Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 08:51, M.-A. Lemburg m...@egenix.com wrote: On 04.09.2013 09:27, Paul Moore wrote: On 4 September 2013 08:13, M.-A. Lemburg m...@egenix.com wrote: I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. To my mind the biggest issue (and again, I'm with Antoine here - people keep forgetting this) is that there are no defined API specs to work to. You can't implement just the important bits of setuptools without knowing what those bits are, and what the interface to them is. I don't quite follow you there. setuptools does come with documentation and the code is available to be read and reused. The situation is similar for distutils itself. Most of the details are laid out in the code. You just need to take a bit of time and learn the concepts - which is not all that hard. An implementation is not a defined API spec even if it does come with some documentation. Tools like pip will need to install projects whose setup.py uses distutils, or setuptools, or monkey-patched versions of distutils/setuptools or a reimplementation of some version of distutils, or with a setup.py that uses neither distutils nor setuptools. What is needed is an independent specification of the minimal command-line interface that a setup.py should provide that is consistent with how things work now for each of those types of setup.py and sufficient for the needs of past, present and future packaging tools. There is documentation for e.g. the egg_info command: https://pythonhosted.org/setuptools/setuptools.html#egg-info-create-egg-metadata-and-set-build-tags However this is really just a description of how to use the command rather than a specification of what expectations can be made of it by other tools and libraries. The problem with implementation defined specifications is that there's no way to reasonably fix or improve the implementation. It is never possible to say that an implementation conforms or contravenes a standard if the implementation *is* the standard. When pip fails to install a project X from PyPI it is not possible to say which of X or pip (or distutils/setuptools if used) is buggy since there is no explicitly documented required behaviour anywhere apart from the general expectation that 'pip install X' should work. As a case in point 'pip install bento' does not work (fails to find the egg info directory). I haven't discovered the reason for this yet but I wouldn't be surprised if the reason is that bento's setup.py differs in its behaviour in some way that isn't specified in any API docs. If the answer is that the bento authors should read the whole of the setuptools codebase and ensure that what they produce is exactly the same then they may as well use setuptools and there's basically no way for anyone to distribute sdists that don't use distutils/setuptools. If the expected minimal behaviour of setup.py including the relevant parts that currently *need* to come from setuptools (i.e. the reasons for pip to monkeypatch distutils with setuptools) were independently specified in a PEP then those features could be incorporated into future versions of distutils without propagating the implementation-defined problems of the past. It would be possible for pip and other tools to make assumptions in a backward- and forward-compatible way and to fix bugs in all tools and libraries since it would be clear what is a bug and what is not. Oscar ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 4:27 AM, Antoine Pitrou anto...@python.org wrote: Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig Use a better password, unless I misunderstand and you're getting this error trying to login? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 04.09.2013 11:49, Oscar Benjamin wrote: On 4 September 2013 08:51, M.-A. Lemburg m...@egenix.com wrote: On 04.09.2013 09:27, Paul Moore wrote: On 4 September 2013 08:13, M.-A. Lemburg m...@egenix.com wrote: I guess that's what the suggestion is all about: avoiding reinventing the wheel, endless discussions and instead going for standard software refactoring techniques. To my mind the biggest issue (and again, I'm with Antoine here - people keep forgetting this) is that there are no defined API specs to work to. You can't implement just the important bits of setuptools without knowing what those bits are, and what the interface to them is. I don't quite follow you there. setuptools does come with documentation and the code is available to be read and reused. The situation is similar for distutils itself. Most of the details are laid out in the code. You just need to take a bit of time and learn the concepts - which is not all that hard. An implementation is not a defined API spec even if it does come with some documentation. Tools like pip will need to install projects whose setup.py uses distutils, or setuptools, or monkey-patched versions of distutils/setuptools or a reimplementation of some version of distutils, or with a setup.py that uses neither distutils nor setuptools. What is needed is an independent specification of the minimal command-line interface that a setup.py should provide that is consistent with how things work now for each of those types of setup.py and sufficient for the needs of past, present and future packaging tools. There is documentation for e.g. the egg_info command: https://pythonhosted.org/setuptools/setuptools.html#egg-info-create-egg-metadata-and-set-build-tags However this is really just a description of how to use the command rather than a specification of what expectations can be made of it by other tools and libraries. The problem with implementation defined specifications is that there's no way to reasonably fix or improve the implementation. It is never possible to say that an implementation conforms or contravenes a standard if the implementation *is* the standard. When pip fails to install a project X from PyPI it is not possible to say which of X or pip (or distutils/setuptools if used) is buggy since there is no explicitly documented required behaviour anywhere apart from the general expectation that 'pip install X' should work. As a case in point 'pip install bento' does not work (fails to find the egg info directory). I haven't discovered the reason for this yet but I wouldn't be surprised if the reason is that bento's setup.py differs in its behaviour in some way that isn't specified in any API docs. If the answer is that the bento authors should read the whole of the setuptools codebase and ensure that what they produce is exactly the same then they may as well use setuptools and there's basically no way for anyone to distribute sdists that don't use distutils/setuptools. If the expected minimal behaviour of setup.py including the relevant parts that currently *need* to come from setuptools (i.e. the reasons for pip to monkeypatch distutils with setuptools) were independently specified in a PEP then those features could be incorporated into future versions of distutils without propagating the implementation-defined problems of the past. It would be possible for pip and other tools to make assumptions in a backward- and forward-compatible way and to fix bugs in all tools and libraries since it would be clear what is a bug and what is not. It would certainly be a good idea to document a minimal standard setup.py command line interface as PEP. I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into the setup.py code (and whether it uses setuptools, bento, custom code, etc.). Package authors could then make sure that they adhere to this interface spec to avoid breakage such as the one you are describing. Could the pip developer perhaps come up with such a minimal set of requirements they have for the setup.py interface ? That said, it does, of course, make sense to also document the distutils internals some more. I was just pointing out that in order to work on or extend distutils you currently have to look at the code, since there is only very little developer documentation available for extending distutils. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 04 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com
Re: [Distutils] Comments on PEP 426
On Sep 4, 2013, at 6:21 AM, M.-A. Lemburg m...@egenix.com wrote: I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into the setup.py code (and whether it uses setuptools, bento, custom code, etc.). I like it as a temporary solution that is backwards compatible with the old tooling but I don't think it should be the interface going into the future. If I recall correctly Tarek started out trying to improve distutils and ended up inadvertently breaking things which ended up getting his changes backed out and the block on changes to distutils was placed and the distutils2/packaging effort was started. All of this completely skirts the fact that any change to distutils would only be available in 3.4+ or 3.5+ which makes it's value practically zero. It's not like other modules in the library where you can reasonably expect someone to have a backport installed if you need to use the new features. Setuptools has already gone through the long process of getting everyone to get it installed, why would we want to go through that again for a system that should eventually be deprecated entirely? - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 4:27 AM, Antoine Pitrou antoine at python.org wrote: Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG at python.org https://mail.python.org/mailman/listinfo/distutils-sig Use a better password, Ok, let me try to explain this, despite the fact that I would have preferred not to lose time with this: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). Mandating that users choose hard-to-remember passwords only leads to them writing down those passwords on post-it stickers (or send themselves clear-text reminder e-mais, etc.). It's counter-productive in addition to being an annoyance when trying to do real work. I think it would be beneficial if you changed your attitude a bit here. Caring about security is good. Mandating that other people follow *your* security principles when dealing with *their* data is obnoxious (and here the accent is really on mandating; it's fine to give advice). Thanks Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 6:33 AM, Antoine Pitrou anto...@python.org wrote: Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 4:27 AM, Antoine Pitrou antoine at python.org wrote: Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG at python.org https://mail.python.org/mailman/listinfo/distutils-sig Use a better password, Ok, let me try to explain this, despite the fact that I would have preferred not to lose time with this: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). Mandating that users choose hard-to-remember passwords only leads to them writing down those passwords on post-it stickers (or send themselves clear-text reminder e-mais, etc.). It's counter-productive in addition to being an annoyance when trying to do real work. I think it would be beneficial if you changed your attitude a bit here. Caring about security is good. Mandating that other people follow *your* security principles when dealing with *their* data is obnoxious (and here the accent is really on mandating; it's fine to give advice). The hard to remember restrictions only kick in if your password is less than 16 characters. If you don't want to include symbols make it longer. Requiring a decent password for a system that if your account gets compromised can often times be daisy chained to attacking lots of developer machines is a reasonable thing to do. As to the assumption that writing down passwords is bad I'll just defer to the experts where Bruce Schneier and Jesper Johansson urge people to write down their passwords. In the words of Schneier: We're all good at securing small pieces of paper. I recommend that people write their passwords down on a small piece of paper, and keep it with their other valuable small pieces of paper: in their wallet. That all being said I wasn't the person who added the restrictions I merely agree with them. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Wed, Sep 4, 2013 at 6:33 AM, Antoine Pitrou anto...@python.org wrote: Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 4:27 AM, Antoine Pitrou antoine at python.org wrote: Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG at python.org https://mail.python.org/mailman/listinfo/distutils-sig Use a better password, Ok, let me try to explain this, despite the fact that I would have preferred not to lose time with this: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). Mandating that users choose hard-to-remember passwords only leads to them writing down those passwords on post-it stickers (or send themselves clear-text reminder e-mais, etc.). It's counter-productive in addition to being an annoyance when trying to do real work. I think it would be beneficial if you changed your attitude a bit here. Caring about security is good. Mandating that other people follow *your* security principles when dealing with *their* data is obnoxious (and here the accent is really on mandating; it's fine to give advice). People (at least technical people) should use password managers. What annoys me is when a 40-character random password is rejected because it doesn't contain a number (or a capitalized character letter or whatever), when the same system would accept a 7-character password. (It's easy enough to add the missing bits to the password, which makes it merely annoying, but It also makes me think the system is sorta stupid.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 6:50 AM, Jim Fulton j...@zope.com wrote: On Wed, Sep 4, 2013 at 6:33 AM, Antoine Pitrou anto...@python.org wrote: Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 4:27 AM, Antoine Pitrou antoine at python.org wrote: Hi, On PyPI: Please use a mix of different-case letters and numbers in your password Ok... has anyone decided to play BOFH on this one? Displaying recommendations is fine (and, why not, some kind of entropy meter), enforcing stupid rules like that is not. Regards Antoine, trying to access his PyPI account... ___ Distutils-SIG maillist - Distutils-SIG at python.org https://mail.python.org/mailman/listinfo/distutils-sig Use a better password, Ok, let me try to explain this, despite the fact that I would have preferred not to lose time with this: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). Mandating that users choose hard-to-remember passwords only leads to them writing down those passwords on post-it stickers (or send themselves clear-text reminder e-mais, etc.). It's counter-productive in addition to being an annoyance when trying to do real work. I think it would be beneficial if you changed your attitude a bit here. Caring about security is good. Mandating that other people follow *your* security principles when dealing with *their* data is obnoxious (and here the accent is really on mandating; it's fine to give advice). People (at least technical people) should use password managers. What annoys me is when a 40-character random password is rejected because it doesn't contain a number (or a capitalized character letter or whatever), when the same system would accept a 7-character password. (It's easy enough to add the missing bits to the password, which makes it merely annoying, but It also makes me think the system is sorta stupir.) That should be fine for PyPI's restrictions! Length is the best way to introduce more entropy anyways. Requiring longer passwords is far better than requiring symbols or numbers. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP453 - Explicit bootstrapping of pip in Pythoninstallations
On 4 September 2013 09:55, Justin Cappos jcap...@poly.edu wrote: We have integrated PyCrypto into TUF and are planning to distribute binaries for it along with TUF so that TUF will work smoothly on Windows, Linux, Mac, etc. We will have a demo that shows TUF integration into pip later this week. It will have a bunch of example tests you can run that show how pip can be hacked (some of which will work even if GPG signature verification was implemented), but that TUF blocks. Great to hear! (uh, well, sort of... this whole everything is broken, but we have ways to possibly make it less broken in the future thing really needs some more appropriate adjectives...) More to come! Justin P.S. Should we make the unofficial TUF motto more secure than it used to be? :) Heh, it's certainly one of the best ways I know to remind myself there needs to be an appropriate balance between security, backwards compatibility and usability :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 11:30, Donald Stufft don...@stufft.io wrote: On Sep 4, 2013, at 6:21 AM, M.-A. Lemburg m...@egenix.com wrote: I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into the setup.py code (and whether it uses setuptools, bento, custom code, etc.). I like it as a temporary solution that is backwards compatible with the old tooling but I don't think it should be the interface going into the future. It shouldn't be the recommended interface for new packages but it will need to be supported at least as a backward compatibility mode for a *long* time. If I recall correctly Tarek started out trying to improve distutils and ended up inadvertently breaking things which ended up getting his changes backed out and the block on changes to distutils was placed and the distutils2/packaging effort was started. As I remember it, the problem Tarek had was that a __private function/method somewhere in distutils was being used by setuptools. Tarek changed the behaviour of the private function which resulted in breakage for setuptools so the changes were backed out. It was then decided that if even modifying private interfaces could not be done in a backward-compatible way then there could basically be no changes to distutils unless absolutely required for the purposes of building CPython itself. You could argue that this was perhaps something of an over-reaction. For example the changes proposed here are to add new code/commands rather than modify existing ones. The potential for breakage is a lot lower in this case. Also Tarek's problems were IIRC confounded by setuptools being unmaintained at the time so that the onus was entirely on Tarek not to make any change that could break anything for setuptools. At the time it seemed to be considered that there could be no expectation that setuptools itself could make reasonable adjustments in preparation for or after any change in distutils. I think most projects would understand if their setup.py breaks in a new Python version because they were accessing private methods. The problem with setuptools was that a lot of projects who only used the documented setuptools APIs would have experienced breakage and then been rightly upset about the situation. All of this completely skirts the fact that any change to distutils would only be available in 3.4+ or 3.5+ which makes it's value practically zero. It's not like other modules in the library where you can reasonably expect someone to have a backport installed if you need to use the new features. Setuptools has already gone through the long process of getting everyone to get it installed, why would we want to go through that again for a system that should eventually be deprecated entirely? If there is a minimal interface that setup.py should support then I think it's very reasonable to say that a simple distutils setup.py script should export that interface. Specifically it should be possible to do 'python setup.py bdist_wheel' and 'python setup.py egg_info'. Projects with a distutils-based setup.py will be around for many future Python versions. Also would this be sufficient to decouple pip and setuptools (a reasonable goal in itself)? Or does pip depend on setuptools in more ways than the distutils monkey-patching? Oscar ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 11:30, Donald Stufft don...@stufft.io wrote: On Sep 4, 2013, at 6:21 AM, M.-A. Lemburg m...@egenix.com wrote: I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into the setup.py code (and whether it uses setuptools, bento, custom code, etc.). I like it as a temporary solution that is backwards compatible with the old tooling but I don't think it should be the interface going into the future. I don't think anyone has even begun to discuss what such an interface for the future should be. In principle that would be nice, but on a pure practicality point of view documenting current practice makes a lot of sense. It also offers the option of having a spec that backward compatibility adapters could use to allow current tools to work with the interface for the future when that arrives. All of this completely skirts the fact that any change to distutils would only be available in 3.4+ or 3.5+ which makes it's value practically zero. It's not like other modules in the library where you can reasonably expect someone to have a backport installed if you need to use the new features. Setuptools has already gone through the long process of getting everyone to get it installed, why would we want to go through that again for a system that should eventually be deprecated entirely? I think you misunderstand at least what I am suggesting. You can, right now, write code in your setup.py that provides a bdist_wheel command, using pure distutils. (That's the cmdclass interface that MAL has mentioned). That would work on any version of Python with distutils, no matter how old. It's quite a lot of code, so you may want to split it out into a separate module, and you may then want to make that module available independently for other projects to use, but that's not actually relevant. It's essentially what setuptools already does, the only real difference is that setuptools actually modifies the extensibility methods of distutils rather than just using them. There may be some more complex areas where actual changes to distutils are required. That's precisely what I'd like to see established - if we knew what that minimal API was that setup.py had to provide, we'd be able to experiment to find out if we could provide it without distutils changes or not. [BTW, this is *precisely* the sort of debate that is non-productive if the mandate is to use setuptools. It's why I keep asking for clarity on the status of setuptools - do projects have the option of trying this sort of thing out and therefore asking for explanations of what they need to provide to support packaging tools, or is that option explicitly rejected and those projects need to import setup from setuptools and stop trying to implement their own version? Mandating setuptools would cut off the drain on time that is threads like this - at the cost of potentially alienating those people who still want to explore such options.] Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 12:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote: Also would this be sufficient to decouple pip and setuptools (a reasonable goal in itself)? Or does pip depend on setuptools in more ways than the distutils monkey-patching? I've not got round to reviewing the code (it's on my list) but I think it would be sufficient. There is a fair amount of internal pip use of *pkg_resources* (for versions, requirements parsing, and such like) but that's a somewhat different matter - it would be trivial to extract and vendor pkg_resources if we so wished. We may still need the inject setuptools hack in certain cases, simply because pure-distutils packages simply don't provide that interface out of the box. And that may be a major issue because there's no obvious way to detect when a project needs that hack without the project saying so, or us making an assumption. But it's much less of a technical issue at that point. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On 4 September 2013 11:33, Antoine Pitrou anto...@python.org wrote: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). +1. I will not spend time explaining my situation to people, but please assume that there are people in the world for whom using a password manager is not convenient, and having passwords on paper in a wallet is *also* not convenient. Unique, high-entropy passwords conforming to a constantly-changing set of arbitrary restrictions may be ideal in some sense, but people protect their bank cards with a four digit PIN number, and the world hasn't yet fallen apart. (Note by the way that the PyPI restrictions would not accept the complete text of the above paragraph as a valid password. I bet it has pretty high entropy, though...) climbs down off the hobby horse Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On 4 September 2013 12:28, Paul Moore p.f.mo...@gmail.com wrote: (Note by the way that the PyPI restrictions would not accept the complete text of the above paragraph as a valid password. I bet it has pretty high entropy, though...) Whoops, missed the 16-character comment. Teach me to be sarcastic :-) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 12:20, Paul Moore p.f.mo...@gmail.com wrote:
On 4 September 2013 12:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
Also would this be sufficient to decouple pip and setuptools (a
reasonable goal in itself)? Or does pip depend on setuptools in more
ways than the distutils monkey-patching?
I've not got round to reviewing the code (it's on my list) but I think
it would be sufficient. There is a fair amount of internal pip use of
*pkg_resources* (for versions, requirements parsing, and such like)
but that's a somewhat different matter - it would be trivial to
extract and vendor pkg_resources if we so wished.
We may still need the inject setuptools hack in certain cases,
simply because pure-distutils packages simply don't provide that
interface out of the box. And that may be a major issue because
there's no obvious way to detect when a project needs that hack
without the project saying so, or us making an assumption. But it's
much less of a technical issue at that point.
What I meant was: If distutils gained the minimal missing setuptools
commands then would that be sufficient to decouple setuptools and pip.
I guess you've answered that above as probably.
I don't know what commands pip requires but for the sake of argument
let's imagine that it's bdist_wheel and egg_info. Then if distutils as
of Python 3.4 (more realistically 3.5...) gained those commands then
pip would be able to know very easily whether it needed to inject
setuptools:
if sys.version_info (3, 4):
inject_setuptools()
Or perhaps
from distutils.somewhere import cmdclasses
if not ('bdist_wheel' in cmdclasses and 'egg_info' in cmdclasses):
inject_setuptools()
Oscar
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 12:37, Oscar Benjamin oscar.j.benja...@gmail.comwrote: What I meant was: If distutils gained the minimal missing setuptools commands then would that be sufficient to decouple setuptools and pip. I guess you've answered that above as probably. OK. But I regard vthat as a case of if false then anything. I do think that we should explicitly abandon any solution that requires a change to distutils. That's never going to happen. (If one of the core commiters wants to prove me wrong, then go for it - but I think it's a waste of time for anyone else to bother speculating about it). Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 16:44, M.-A. Lemburg m...@egenix.com wrote: We need to get rid off hacks like setuptools if we ever want to see light at the end of the packaging tunnel. Yes, the whole point of formally defining the requirements for the setup.py CLI (along with a hook system for metadata 2.0 to make providing setup.py itself completely optional) is to make it so that projects don't need to use distutils *or* setuptools. They just need to provide a setup.py that follows the spec or the appropriate static metadata to tell automated build tools how to run Python code from the source distribution to do the build. With the assumption that pip (or an equivalent tool) will be available to retrieve dependencies, developers can just declare the appropriate dependency metadata for their chosen build system (using install_requires in current setuptools defined metadata, or build_requires in metadata 2.0), and the build system will sort it out based on the dependency declarations. However, the lack of a viable *transition plan* is one of the big things that crippled the ultimate effectiveness of the distutils2 effort. The two most popular build systems for Python at this point are vanilla distutils and setuptools. setuptools is the one that people that actually need the dependency management and entry point features are using. Our feelings about its implementation details are completely irrelevant: those projects *have* to be able to migrate easily, or the transition to metadata 2.0 isn't going to work. Fortunately, Jason and PJE are both on-board with the current metadata 2.0 efforts, and metadata 2.0 has been redesigned so it can be shipped in parallel with metadata 1.1 and the supporting setuptools-defined metadata formats. This means it is likely that setuptools will gain the ability to emit those formats once they're standardised. So, the projects that explicitly use setuptools shouldn't be a problem. That then leaves the projects that use plain distutils. How do we get *them* into the shiny metadata 2.0 future, given that we have five legacy versions of distutils in widespread use that we need to get to support the new metadata 2.0 standards, when those standards *haven't even been defined yet*, and definitely won't be defined in time for Python 3.4 feature freeze in November (adding a *sixth* legacy version to support). Note that the distutils freeze has *already been lifted*. The problem that originally led to the freeze was a change to an internal API breaking setuptools in a CPython *maintenance* release. PJE has since indicated that he would have accepted that breakage as requiring a setuptools upgrade in a *feature* release - it was the fact it happened in a maintenance release that he had a problem with. So, no distutils freeze, but still a problem with supporting new metadata standards in previously released versions of Python. Once that was clarified, the freeze was lifted, but there was also the realisation around that time that any proposed changes to the packaging ecosystem are irrelevant if they aren't supported at least as far back as Python 2.6 (so they work with the system Python on RHEL/CentOS/ScientificLinux and other long term support Linux versions of similar vintage). Given where we are now, the *ideal* solution would be for Python 3.4 distutils to be brought up to feature parity with current setuptools and a backports.distutils module published on PyPI. When the metadata 2.0 standards are defined, support would be added to the Python 3.5 distutils, and published immediately on PyPI as backports.distutils. One potential problem with that approach is that distutils in trunk is currently Python 3 only, while a backport would need to be 2/3 compatible. That's likely more feasible now than it was when packaging/distutils2 were being worked on, but the initial set of changes to make it 2/3 compatible will probably still involve some pain. However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant implementation that could be used to replace distutils in Python 3.4 library *doesn't exist*, and I have no desire to wait around in the (likely vain) hope of somebody stepping up to create it. Instead, I think the far more pragmatic option at this point is to just tell people your setup.py must run correctly with setuptools imported in that process. If it doesn't, it is your setup.py is broken, not the build tool that imported setuptools, or setuptools itself for monkey-patching distutils. Most projects don't need to do anything special to handle that situation, and for the few that do 'setuptools' in sys.modules is a reliable way to check for its presence. This approach is a useful hack until somebody actually *produces* a setuptools-lite which does everything important that setuptools does without monkey-patching distutils, or until we have successfully made the transition to a metadata 2.0
Re: [Distutils] Comments on PEP 426
On Sep 4, 2013, at 7:13 AM, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 11:30, Donald Stufft don...@stufft.io wrote: On Sep 4, 2013, at 6:21 AM, M.-A. Lemburg m...@egenix.com wrote: I quite like the idea of using setup.py as high level interface to a package for installers to use, since that avoids having to dig into the details built into the setup.py code (and whether it uses setuptools, bento, custom code, etc.). I like it as a temporary solution that is backwards compatible with the old tooling but I don't think it should be the interface going into the future. I don't think anyone has even begun to discuss what such an interface for the future should be. In principle that would be nice, but on a pure practicality point of view documenting current practice makes a lot of sense. Wheel - Doesn't need it Sdist 2.0 - MEB system w/ discovery baked into pydist.json Source Checkout - ??? Probably some easy to edit file that tells pip which MEB system to use It also offers the option of having a spec that backward compatibility adapters could use to allow current tools to work with the interface for the future when that arrives. Of course, i'm not against documenting what a setup.py interface should look like. All of this completely skirts the fact that any change to distutils would only be available in 3.4+ or 3.5+ which makes it's value practically zero. It's not like other modules in the library where you can reasonably expect someone to have a backport installed if you need to use the new features. Setuptools has already gone through the long process of getting everyone to get it installed, why would we want to go through that again for a system that should eventually be deprecated entirely? I think you misunderstand at least what I am suggesting. You can, right now, write code in your setup.py that provides a bdist_wheel command, using pure distutils. (That's the cmdclass interface that MAL has mentioned). That would work on any version of Python with distutils, no matter how old. It's quite a lot of code, so you may want to split it out into a separate module, and you may then want to make that module available independently for other projects to use, but that's not actually relevant. It's essentially what setuptools already does, the only real difference is that setuptools actually modifies the extensibility methods of distutils rather than just using them. There may be some more complex areas where actual changes to distutils are required. That's precisely what I'd like to see established - if we knew what that minimal API was that setup.py had to provide, we'd be able to experiment to find out if we could provide it without distutils changes or not. [BTW, this is *precisely* the sort of debate that is non-productive if the mandate is to use setuptools. It's why I keep asking for clarity on the status of setuptools - do projects have the option of trying this sort of thing out and therefore asking for explanations of what they need to provide to support packaging tools, or is that option explicitly rejected and those projects need to import setup from setuptools and stop trying to implement their own version? Mandating setuptools would cut off the drain on time that is threads like this - at the cost of potentially alienating those people who still want to explore such options.] I think updating distutils is a dead end. Even if we do it in a completely backwards compatible way it will still only be available in 3.4+ or 3.5+. We've just recently gotten some confusing advice nullified by the distribute/setuptools merger so re-adding back in some new confusing advice seems to be user hostile. Use setuptools.. unless you're (and every user who might possibly install your thing) using Python 3.4+ and you're only using this list of features from setuptools we deemed important, well then you can use distutils. One of the fundamental problems with setup.py i it's used for both install and for building. This means that anything that is required to run the setup.py needs to be available to end users. If you use the proposed new distutils features (only available in 3.4+) then anyone trying to install your package on an older version of Python it will not work. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 7:28 AM, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 11:33, Antoine Pitrou anto...@python.org wrote: Users don't want their security concerns to be dictated by a service provider. Programmatically refusing passwords which are deemed too weak is the kind of policy that I thought had disappeared since the 1990s (yes, it's been tried before, like other stupid requirements such as having to change passwords every month). +1. I will not spend time explaining my situation to people, but please assume that there are people in the world for whom using a password manager is not convenient, and having passwords on paper in a wallet is *also* not convenient. Unique, high-entropy passwords conforming to a constantly-changing set of arbitrary restrictions may be ideal in some sense, but people protect their bank cards with a four digit PIN number, and the world hasn't yet fallen apart. This is a false equivalency. Sure people protect their bank card with a four digit pin but it also typically requires having the physical card itself (attacks such as skimming aside). I'd be ok with relaxing the restrictions if we can also mandate a physical factor but that is more onerous than the simple restriction that exists already. If you can't maintain a basic level of security on your account maybe you shouldn't be releasing code for other people to use? If you're releasing code a compromise of your account exposes *other* people to risk (which is also unlike your bank card example). I don't think it's that hard to remember a 16+ character password that has no other restrictions besides being 16+ characters. Hell repeat your original password twice and there you go (passwords also must be at least 8 characters). - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Jim Fulton jim at zope.com writes: People (at least technical people) should use password managers. I will gladly use a password manager on my personal computer, just *not* on a computer which other people may access. In these cases it is important to be able to choose a rememberable enough password, precisely because I don't want the computer to store it. What annoys me is when a 40-character random password is rejected because it doesn't contain a number (or a capitalized character letter or whatever), when the same system would accept a 7-character password. Yep, again: giving recommendations is good, but rejecting certain passwords is just a pointless nuisance. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 12:58, Nick Coghlan ncogh...@gmail.com wrote: However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant implementation that could be used to replace distutils in Python 3.4 library *doesn't exist*, and I have no desire to wait around in the (likely vain) hope of somebody stepping up to create it. The problem with not even defining an interface is that there is no upgrade path. Users use setuptools/pip or wait for the new solution. Nobody can write their own replacement for setuptools (bento, for example) and be sure it will integrate with pip. It's a longer term issue for certain, but it *is* important. If we don't get away from the implementation defining the behaviour, we'll just perpetuate the problem of nobody being able to innovate because everything needs to implement most of setuptools. Instead, I think the far more pragmatic option at this point is to just tell people your setup.py must run correctly with setuptools imported in that process. If it doesn't, it is your setup.py is broken, not the build tool that imported setuptools, or setuptools itself for monkey-patching distutils. The big question here, I suppose is do any such projects exist? There's a lot of nervousness (I hesitate to use the term FUD) about how will projects that don't work with setuptools react? but no actual evidence of such projects existing. I believe that cx_Oracle had an issue in the past. I must try to test that out again and report it to them if so. Maybe MAL's projects are another potential test case. And maybe numpy. It's hard to be sure, because projects in this category are likely the more complex ones, and as a result are probably also pretty hard to build (and consequently to test...) Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Donald Stufft donald at stufft.io writes: If you can't maintain a basic level of security on your account maybe you shouldn't be releasing code for other people to use? Hey, can you get off your high horses now? I don't think it's that hard to remember a 16+ character password that has no other restrictions besides being 16+ characters. You know, I think people could care less about what *someone else* thinks is hard to remember *for them*. They just want to use the service, not be patronized by some external entity who insists on rectifying their behaviour. Also, the talk about how a broken password can threaten other developers completely misses the big picture. Because even a strong password could be obtained in completely different ways, such as e.g. compromising the developers' personal computer. (obligatory reference: http://xkcd.com/538/ ) You seem to be misunderstanding the difference between *providing* security (e.g. HTTPS, better hashes, etc., which is good) and *requiring* security-minded practices (e.g. requiring strong passwords), which is a nuisance in many situations. Hell repeat your original password twice and there you go (passwords also must be at least 8 characters). Well, can I use too or do I have to use aAaAaAaAaAaAaAaAaAaAaAaAaAaAaAaA? If that works, you could disable the restriction right now because it is not securing anything, it's just a feel-good restriction for security nerds. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Wed, Sep 4, 2013 at 8:11 AM, Antoine Pitrou anto...@python.org wrote: Jim Fulton jim at zope.com writes: People (at least technical people) should use password managers. I will gladly use a password manager on my personal computer, just *not* on a computer which other people may access. In these cases it is important to be able to choose a rememberable enough password, precisely because I don't want the computer to store it. Some password managers (including both that I've used) let you access your passwords via the web, so they aren't stored locally. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Wed, Sep 4, 2013 at 9:08 AM, Antoine Pitrou anto...@python.org wrote: Jim Fulton jim at zope.com writes: Some password managers (including both that I've used) let you access your passwords via the web, so they aren't stored locally. Will they work with setup.py too (e.g. the register command)? They will work with anything that requires typing, as you can copy and paste (or even view and transcribe) a password from a web interface. Jim ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Jim Fulton jim at zope.com writes: Some password managers (including both that I've used) let you access your passwords via the web, so they aren't stored locally. Will they work with setup.py too (e.g. the register command)? As far as the Web interface is concerned, I would be glad to switch to OpenID *if* the current bug (see other thread) was resolved... Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 22:51, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 12:58, Nick Coghlan ncogh...@gmail.com wrote: However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant implementation that could be used to replace distutils in Python 3.4 library *doesn't exist*, and I have no desire to wait around in the (likely vain) hope of somebody stepping up to create it. The problem with not even defining an interface is that there is no upgrade path. Users use setuptools/pip or wait for the new solution. Nobody can write their own replacement for setuptools (bento, for example) and be sure it will integrate with pip. It's a longer term issue for certain, but it *is* important. If we don't get away from the implementation defining the behaviour, we'll just perpetuate the problem of nobody being able to innovate because everything needs to implement most of setuptools. Instead, I think the far more pragmatic option at this point is to just tell people your setup.py must run correctly with setuptools imported in that process. If it doesn't, it is your setup.py is broken, not the build tool that imported setuptools, or setuptools itself for monkey-patching distutils. The big question here, I suppose is do any such projects exist? There's a lot of nervousness (I hesitate to use the term FUD) about how will projects that don't work with setuptools react? but no actual evidence of such projects existing. I believe that cx_Oracle had an issue in the past. I must try to test that out again and report it to them if so. Maybe MAL's projects are another potential test case. And maybe numpy. It's hard to be sure, because projects in this category are likely the more complex ones, and as a result are probably also pretty hard to build (and consequently to test...) If such projects publish wheel files (modulo us getting the Linux file naming problem sorted), then the only people the build issues are likely to hit are those that force builds from source (like zc.buildout and Linux distributions). Even then, projects that encounter problems are likely to be hard to build *anyway* (since projects with simple build needs usually aren't so dependent on specific distutils details that they conflict with setuptools), so I think the risk of making things any worse is minimal. Just use setuptools is far from a perfect solution, but it's a heck of a lot better than leaving vanilla distutils projects in the dark ages of Python 2.6. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On 4 September 2013 22:53, Antoine Pitrou anto...@python.org wrote: Well, can I use too or do I have to use aAaAaAaAaAaAaAaAaAaAaAaAaAaAaAaA? If that works, you could disable the restriction right now because it is not securing anything, it's just a feel-good restriction for security nerds. It's about increasing the search space for attackers. I've submitted a patch to mention the 16 character threshold where all other checks no longer apply in the error message, but running basic security checks against new passwords is normal, and not something we're going to stop doing. It's quite possible that at some point in the future we'll start implementing stricter checks like those used for the Fedora Account System (this is especially likely if accounts start being linked across the python.org infrastructure, such that the consquences of a password compromise become even more significant). If the PyPI password restrictions ever feel too onerous, then OpenID is another alternative (albeit not one that works with the command line tools). However, you should be able to use pypissh for CLI access in that case. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Jim Fulton jim at zope.com writes: On Wed, Sep 4, 2013 at 9:08 AM, Antoine Pitrou antoine at python.org wrote: Jim Fulton jim at zope.com writes: Some password managers (including both that I've used) let you access your passwords via the web, so they aren't stored locally. Will they work with setup.py too (e.g. the register command)? They will work with anything that requires typing, as you can copy and paste (or even view and transcribe) a password from a web interface. Does that mean the password in stored in clear text by some third-party provider? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 23:25, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 14:18, Nick Coghlan ncogh...@gmail.com wrote: If such projects publish wheel files (modulo us getting the Linux file naming problem sorted), then the only people the build issues are likely to hit are those that force builds from source (like zc.buildout and Linux distributions). Personally, I don't expect to see published wheels for some time yet. So building from source (even if only once to make a locally published wheel) will remain an important issue, and if we need setuptools-compatibility to build wheels, that will mean projects getting told your project's setup.py fails when I try to do pip wheel. But as I say, this is all based on if such projects exist... I was under the impression pip *already* forced the use of setuptools (to ensure --record is available), so why would pip wheel provoke any more bug reports than pip install? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 14:18, Nick Coghlan ncogh...@gmail.com wrote: If such projects publish wheel files (modulo us getting the Linux file naming problem sorted), then the only people the build issues are likely to hit are those that force builds from source (like zc.buildout and Linux distributions). Personally, I don't expect to see published wheels for some time yet. So building from source (even if only once to make a locally published wheel) will remain an important issue, and if we need setuptools-compatibility to build wheels, that will mean projects getting told your project's setup.py fails when I try to do pip wheel. But as I say, this is all based on if such projects exist... Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On Sep 4, 2013, at 9:27 AM, Nick Coghlan ncogh...@gmail.com wrote: On 4 September 2013 23:25, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 14:18, Nick Coghlan ncogh...@gmail.com wrote: If such projects publish wheel files (modulo us getting the Linux file naming problem sorted), then the only people the build issues are likely to hit are those that force builds from source (like zc.buildout and Linux distributions). Personally, I don't expect to see published wheels for some time yet. So building from source (even if only once to make a locally published wheel) will remain an important issue, and if we need setuptools-compatibility to build wheels, that will mean projects getting told your project's setup.py fails when I try to do pip wheel. But as I say, this is all based on if such projects exist... I was under the impression pip *already* forced the use of setuptools (to ensure --record is available), so why would pip wheel provoke any more bug reports than pip install? Because people do weird things in their setup.py that isn't compatible with Wheel. Often times minor tweaks makes it work though. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 14:27, Nick Coghlan ncogh...@gmail.com wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available), so why would pip wheel provoke any more bug reports than pip install? It won't, but at the moment the reports are likely to be that *pip* is where the error lies. We're saying that such reports will in future be redirected at the project. That is the change. (It may be that it's simply changing can't fix to won't fix - I don't know how traditionally pip deals with such reports, if indeed it has ever had any). There's no point in worrying though until we have evidence of such a project actually existing. If no-one wants to try to check likely candidates in advance, let's just wait for the bug reports if any. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 9:27 AM, Antoine Pitrou anto...@python.org wrote: Jim Fulton jim at zope.com writes: On Wed, Sep 4, 2013 at 9:08 AM, Antoine Pitrou antoine at python.org wrote: Jim Fulton jim at zope.com writes: Some password managers (including both that I've used) let you access your passwords via the web, so they aren't stored locally. Will they work with setup.py too (e.g. the register command)? They will work with anything that requires typing, as you can copy and paste (or even view and transcribe) a password from a web interface. Does that mean the password in stored in clear text by some third-party provider? No, browser side crypto, not a perfect solution but better than the alternatives. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 9:10 AM, Nick Coghlan ncogh...@gmail.com wrote: I've submitted a patch to mention the 16 character threshold where all other checks no longer apply in the error message This is merged and deployed. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Nick Coghlan ncoghlan at gmail.com writes: On 4 September 2013 22:53, Antoine Pitrou antoine at python.org wrote: Well, can I use too or do I have to use aAaAaAaAaAaAaAaAaAaAaAaAaAaAaAaA? If that works, you could disable the restriction right now because it is not securing anything, it's just a feel-good restriction for security nerds. It's about increasing the search space for attackers. I've submitted a patch to mention the 16 character threshold where all other checks no longer apply in the error message, but running basic security checks against new passwords is normal, and not something we're going to stop doing. Well, I'll say it once more: presenting checks and recommandations to the user is fine. That doesn't mean weak passwords should be *rejected*, though. PyPI is not a project like Fedora is. It is a community service for thousands of different people, with wildly different processes and constraints. You can't just order anyone use your passwords like Nick and DOnald do. If the PyPI password restrictions ever feel too onerous, then OpenID is another alternative (albeit not one that works with the command line tools). However, you should be able to use pypissh for CLI access in that case. Thanks for reminding me about pypissh, I'll try it. As for OpenID, it doesn't work for me right now (see other thread). Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On Sep 4, 2013, at 9:25 AM, Paul Moore p.f.mo...@gmail.com wrote: Personally, I don't expect to see published wheels for some time yet. Just to add numbers to this, there are currently 162 published Wheels on PyPI which I think is pretty good given the relative newness of a pip that supports Wheel, the fact that people are unlikely to go back and create Wheels for old releases, and the window of time for new releases in that time period. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On Sep 4, 2013, at 9:39 AM, Antoine Pitrou anto...@python.org wrote: PyPI is not a project like Fedora is. It is a community service for thousands of different people, with wildly different processes and constraints. You can't just order anyone use your passwords like Nick and DOnald do. And Richard, since he's the one who added the constraints. I feel pretty confident saying this won't change. So argue if you want but I won't be committing anything to remove it so if you feel strongly about it your best bet is to ask Richard to remove the code he committed. I don't think this thread is going to go anywhere further so i'm bowing out of it. You've made your viewpoint known, i've made mine. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 9:46 AM, Antoine Pitrou anto...@python.org wrote: Nick Coghlan ncoghlan at gmail.com writes: If the PyPI password restrictions ever feel too onerous, then OpenID is another alternative (albeit not one that works with the command line tools). However, you should be able to use pypissh for CLI access in that case. For the record, it seems pypissh doesn't work with Python 3: $ sudo pip3 install pypissh Downloading/unpacking pypissh Running setup.py egg_info for package pypissh Installing collected packages: pypissh Running setup.py install for pypissh File /usr/local/lib/python3.3/dist-packages/pypissh.py, line 186 except socket.error, e: ^ SyntaxError: invalid syntax Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig I believe MvL owns PyPISSH and it has an issue tracker under his account on bitbucket.org. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 23:32, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 14:27, Nick Coghlan ncogh...@gmail.com wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available), so why would pip wheel provoke any more bug reports than pip install? It won't, but at the moment the reports are likely to be that *pip* is where the error lies. We're saying that such reports will in future be redirected at the project. That is the change. (It may be that it's simply changing can't fix to won't fix - I don't know how traditionally pip deals with such reports, if indeed it has ever had any). There's no point in worrying though until we have evidence of such a project actually existing. If no-one wants to try to check likely candidates in advance, let's just wait for the bug reports if any. More accurately, the response will still be let's investigate and see exactly what's going wrong. The only real change is that the project should change its setup.py to cope with the setuptools monkey-patching will be a more likely resolution from the distribution tools side. Bugs in pip and setuptools are still a possibility, and modifying pip to not *need* the setuptools monkey-patching is still highly desirable. It's just not a blocker for anything else :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] pypissh
Nick Coghlan ncoghlan at gmail.com writes: If the PyPI password restrictions ever feel too onerous, then OpenID is another alternative (albeit not one that works with the command line tools). However, you should be able to use pypissh for CLI access in that case. For the record, it seems pypissh doesn't work with Python 3: $ sudo pip3 install pypissh Downloading/unpacking pypissh Running setup.py egg_info for package pypissh Installing collected packages: pypissh Running setup.py install for pypissh File /usr/local/lib/python3.3/dist-packages/pypissh.py, line 186 except socket.error, e: ^ SyntaxError: invalid syntax Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] tox-1.6.1 / detox-0.9.3: some fixes
I just pushed tox-1.6.1 to PyPI which fixes a number of issues
Also detox-0.9.3, the parallelizing tox runner, is out.
tox aims to automate and standardize testing in Python, see docs:
http://tox.testrun.org
If you want to support tox development other than through contributions
or feedback, you may send gifts to my gittip account:
https://www.gittip.com/hpk42/
Oh, and a NOTE on Python2.5 support: support for running tox/detox
themselves on python2.5 will be dropped anytime now while _creating_
python2.5 environments (through tox.ini) will remain supported still
for some time (but not indefinitely).
have fun,
holger krekel
tox 1.6.1
---
- fix issue119: {envsitepackagesdir} is now correctly computed and has
a better test to prevent regression.
- fix issue116: make 1.6 introduced behaviour of changing to a
per-env HOME directory during install activities dependent
on --set-home for now. Should re-establish the old behaviour
when no option is given.
- fix issue118: correctly have two tests use realpath(). Thanks Barry
Warsaw.
- fix test runs on environments without a home directory
(in this case we use toxinidir as the homedir)
- fix issue117: python2.5 fix: don't use ``--insecure`` option because
its very existence depends on presence of ssl. If you
want to support python2.5/pip1.3.1 based test environments you need
to install ssl and/or use PIP_INSECURE=1 through ``setenv``. section.
- fix issue102: change to {toxinidir} when installing dependencies.
this allows to use relative path like in -rrequirements.txt.
detox-0.9.3
---
- fix issue6: quickly make detox work with tox-1.6 again (although not
all 1.6 features supported, e.g. --develop does not work)
- fix issue3: don't claim a TROVE identifier of python3 because detox
itself depends on eventlet which does not work on py3 yet. (Nevertheless
detox will create py3 environments through tox of course)
- fix issue1: support python2.5 again (although we might drop it in the
future -- it's enough of tox/detox can _create_ and handle py25 environments,
they don't neccessarily need to support running themselv on py25)
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On 4 September 2013 23:39, Antoine Pitrou anto...@python.org wrote: PyPI is not a project like Fedora is. It is a community service for thousands of different people, with wildly different processes and constraints. You can't just order anyone use your passwords like Nick and DOnald do. Sure - dealing with security issues for PyPI is always a complex balancing acting between security, backwards compatibility and avoiding raising barriers to entry. With the error message fixed, the current password rules are pretty simple, and easy to satisfy by typing a few more letters, pressing shift once or hitting a number key. Ramping things up to the level Fedora do is unlikely to happen any time soon, if it ever happens at all (especially since the shift to properly salted hashes likely added more security than tougher password rules ever will). On the other hand, pre-emptively filtering out passwords that are known to be picked up by the initial quick-and-dirty heuristics used by common password crackers (before they settle in to the more time consuming brute force searches) is a well established defence in depth strategy for password security, since it doesn't cost defenders much time to prevent them, and it doesn't save attackers much time to skip them. However, PyPI users need to recognise that it isn't the integrity of *their* accounts that we're primarily worried about when attempting to minimise login vulnerabilities. Our primary concern (after the integrity of PyPI itself), is the integrity of end users' machines. So when we place restrictions on uploaders, it's guided by a desire to be worthy of the exceptional levels of trust placed in the service by anyone that types pip install distribution or easy_install distribution or just downloads a file directly from the site. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] (no subject)
Nick Coghlan ncoghlan at gmail.com writes: That's the whole reason the content restrictions turn themselves off once the password hits 16 characters: passphrases are easy to remember, and generally quite secure. So, no, it's easy to remember is not an adequate excuse for choosing a poor password for a service that has a lot of other people depending on its integrity. Then please add helpful guidelines as to how people can choose a safe and easy to remember password /or passphrase/. Most people aren't password experts, and the current one-line message isn't useful. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
On 5 September 2013 00:31, Antoine Pitrou anto...@python.org wrote: Nick Coghlan ncoghlan at gmail.com writes: On 4 September 2013 23:39, Antoine Pitrou antoine at python.org wrote: PyPI is not a project like Fedora is. It is a community service for thousands of different people, with wildly different processes and constraints. You can't just order anyone use your passwords like Nick and DOnald do. Sure - dealing with security issues for PyPI is always a complex balancing acting between security, backwards compatibility and avoiding raising barriers to entry. With the error message fixed, the current password rules are pretty simple, and easy to satisfy by typing a few more letters, pressing shift once or hitting a number key. Once again, the problem is *not* to create a strong enough password (a one-liner using os.urandom() and the base64 module works for that), it's to remember it without having to note it down or whatever the current fashionable form of self-reminder is. This is the whole reason people choose weak passwords, because they are those they're able to remember easily. That's the whole reason the content restrictions turn themselves off once the password hits 16 characters: passphrases are easy to remember, and generally quite secure. So, no, it's easy to remember is not an adequate excuse for choosing a poor password for a service that has a lot of other people depending on its integrity. Yes, there are *many* points of vulnerability for PyPI, and we've hardened the password system enough at this point that it's not currently the easiest attack vector (probably, anyway). But a security system is only as strong as its weakest link, and there's no way we're going to deliberately weaken this one, and a definite chance that at some (distant) point in the future we'll strengthen it further. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 13:51, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 12:58, Nick Coghlan ncogh...@gmail.com wrote: However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant implementation that could be used to replace distutils in Python 3.4 library *doesn't exist*, and I have no desire to wait around in the (likely vain) hope of somebody stepping up to create it. The problem with not even defining an interface is that there is no upgrade path. Users use setuptools/pip or wait for the new solution. Nobody can write their own replacement for setuptools (bento, for example) and be sure it will integrate with pip. It's a longer term issue for certain, but it *is* important. If we don't get away from the implementation defining the behaviour, we'll just perpetuate the problem of nobody being able to innovate because everything needs to implement most of setuptools. It doesn't need to be just like setuptools. Distutils could be made to be just like distutils but with the addition of the *minimum* that is required to make it work in the new packaging system. Then a vanilla distutils setup.py can gain the relevant new commands without the package author needing to put setuptools in the setup.py and without the user needing to install setuptools and wheel. Distutils is already just like setuptools for a subset of what setuptools does. It could be made just like setuptools for a slightly larger subset that also includes the features deemed to be necessary in the future. Then pip's setuptools monkey-patching could just phase out along with the older Python versions where it is necessary. Projects using Cython often use Cython's distutils extension which isn't directly compatible with many setuptools commands (although setuptools-cython apparently tries to address this). These projects could really benefit from wheel support but they won't get it from setuptools. It could be added to Cython's distutils extension but then that doesn't help the packages with non-Cython C extensions which often don't use setuptools. I think a lot of projects would benefit from bdist_wheel being added to distutils even if it's only there for future Python versions. Until the minimum that is required of setup.py and the setup function has been identified I don't see how you can rule out the possibility of bringing distutils up to that specification. Instead, I think the far more pragmatic option at this point is to just tell people your setup.py must run correctly with setuptools imported in that process. If it doesn't, it is your setup.py is broken, not the build tool that imported setuptools, or setuptools itself for monkey-patching distutils. The big question here, I suppose is do any such projects exist? There's a lot of nervousness (I hesitate to use the term FUD) about how will projects that don't work with setuptools react? but no actual evidence of such projects existing. I believe that cx_Oracle had an issue in the past. I must try to test that out again and report it to them if so. Maybe MAL's projects are another potential test case. And maybe numpy. It's hard to be sure, because projects in this category are likely the more complex ones, and as a result are probably also pretty hard to build (and consequently to test...) Numpy already has logic to try and do the right thing with or without setuptools and with different versions of setuptools. If you look here: https://github.com/numpy/numpy/blob/master/numpy/distutils/core.py#L6 At the moment it looks like: if 'setuptools' in sys.modules: have_setuptools = True from setuptools import setup as old_setup # easy_install imports math, it may be picked up from cwd from setuptools.command import easy_install try: # very old versions of setuptools don't have this from setuptools.command import bdist_egg except ImportError: have_setuptools = False else: from distutils.core import setup as old_setup have_setuptools = False Presumably the next step is to add: try: from wheel.bdist_wheel import bdist_wheel except ImportError: have_wheel = False else: have_wheel = True followed by: if have_wheel: numpy_cmdclass['bdist_wheel'] = bdist_wheel It looks a bit of a mess but it's worth bearing in mind that the numpy folks will basically do whatever is required to make all of this stuff work (not that it's okay to antagonise them with arbitrary changes). The more relevant concern is how any of this affects smaller and less well-maintained projects. Setuptools addresses various problems in distutils for pure Python projects but AFAIK it doesn't make it any easier to build extension modules. Numpy has all the logic above precisely because they're trying to emulate the monkey-patching behaviour of setuptools. However smaller projects will often just use distutils (perhaps with
[Distutils] Password security
On 5 September 2013 00:59, Antoine Pitrou anto...@python.org wrote: Nick Coghlan ncoghlan at gmail.com writes: That's the whole reason the content restrictions turn themselves off once the password hits 16 characters: passphrases are easy to remember, and generally quite secure. So, no, it's easy to remember is not an adequate excuse for choosing a poor password for a service that has a lot of other people depending on its integrity. Then please add helpful guidelines as to how people can choose a safe and easy to remember password /or passphrase/. Most people aren't password experts, and the current one-line message isn't useful. It's a complex topic, hence it takes long articles like http://arstechnica.com/information-technology/2013/06/the-secret-to-online-safety-lies-random-characters-and-a-password-manager/ to do it justice. The *best* answer is for a service to use 2-factor authentication instead of relying entirely on passwords (the physical object Donald mentioned earlier), but we don't have the resources to set that up, and certainly can't require it for all PyPI users (since you either need a physical token or a phone capable of running an app like Google Authenticator). Second best is to use a password manager, either to help remember complex manually generated passwords, letting it generate the passwords for you, or a combination of the two. The Ars article linked above goes through some of the available options. Third is to encourage or require people to use better passwords. The third page of the Ars password management article (http://arstechnica.com/information-technology/2013/06/the-secret-to-online-safety-lies-random-characters-and-a-password-manager/3/) gives some example techniques for generating good pass phrases. There's also the XKCD method (https://xkcd.com/936/) and the Scheier method (see towards the end of https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html). A better password metering system than the current binary allowed/disallowed would definitely be desirable (see http://arstechnica.com/security/2013/05/its-official-password-strength-meters-arent-security-theater/), but isn't going to happen in the current PyPI web application. It might be possible after the migration to Warehouse is complete, though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On Sep 4, 2013, at 10:30 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: On 4 September 2013 13:51, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 12:58, Nick Coghlan ncogh...@gmail.com wrote: However, a more significant problem is that the whole idea is based on pure vapourware. That ideal it's just like setuptools, but with a more elegant implementation that could be used to replace distutils in Python 3.4 library *doesn't exist*, and I have no desire to wait around in the (likely vain) hope of somebody stepping up to create it. The problem with not even defining an interface is that there is no upgrade path. Users use setuptools/pip or wait for the new solution. Nobody can write their own replacement for setuptools (bento, for example) and be sure it will integrate with pip. It's a longer term issue for certain, but it *is* important. If we don't get away from the implementation defining the behaviour, we'll just perpetuate the problem of nobody being able to innovate because everything needs to implement most of setuptools. It doesn't need to be just like setuptools. Distutils could be made to be just like distutils but with the addition of the *minimum* that is required to make it work in the new packaging system. Then a vanilla distutils setup.py can gain the relevant new commands without the package author needing to put setuptools in the setup.py and without the user needing to install setuptools and wheel. Distutils is already just like setuptools for a subset of what setuptools does. It could be made just like setuptools for a slightly larger subset that also includes the features deemed to be necessary in the future. Then pip's setuptools monkey-patching could just phase out along with the older Python versions where it is necessary. Projects using Cython often use Cython's distutils extension which isn't directly compatible with many setuptools commands (although setuptools-cython apparently tries to address this). These projects could really benefit from wheel support but they won't get it from setuptools. It could be added to Cython's distutils extension but then that doesn't help the packages with non-Cython C extensions which often don't use setuptools. I think a lot of projects would benefit from bdist_wheel being added to distutils even if it's only there for future Python versions. Until the minimum that is required of setup.py and the setup function has been identified I don't see how you can rule out the possibility of bringing distutils up to that specification. Even if distutils is up to that specification there are 5 (likely 6) legacy versions that are not. If users want to use distutils they have to completely restrict themselves (and all of their users) to only versions of python 3.4 (likely 3.5) or higher. That's unreasonable for most projects. Instead, I think the far more pragmatic option at this point is to just tell people your setup.py must run correctly with setuptools imported in that process. If it doesn't, it is your setup.py is broken, not the build tool that imported setuptools, or setuptools itself for monkey-patching distutils. The big question here, I suppose is do any such projects exist? There's a lot of nervousness (I hesitate to use the term FUD) about how will projects that don't work with setuptools react? but no actual evidence of such projects existing. I believe that cx_Oracle had an issue in the past. I must try to test that out again and report it to them if so. Maybe MAL's projects are another potential test case. And maybe numpy. It's hard to be sure, because projects in this category are likely the more complex ones, and as a result are probably also pretty hard to build (and consequently to test...) Numpy already has logic to try and do the right thing with or without setuptools and with different versions of setuptools. If you look here: https://github.com/numpy/numpy/blob/master/numpy/distutils/core.py#L6 At the moment it looks like: if 'setuptools' in sys.modules: have_setuptools = True from setuptools import setup as old_setup # easy_install imports math, it may be picked up from cwd from setuptools.command import easy_install try: # very old versions of setuptools don't have this from setuptools.command import bdist_egg except ImportError: have_setuptools = False else: from distutils.core import setup as old_setup have_setuptools = False Presumably the next step is to add: try: from wheel.bdist_wheel import bdist_wheel except ImportError: have_wheel = False else: have_wheel = True followed by: if have_wheel: numpy_cmdclass['bdist_wheel'] = bdist_wheel It looks a bit of a mess but it's worth bearing in mind that the numpy folks will basically do whatever is required to make all of this stuff work (not that it's okay to antagonise them with arbitrary
Re: [Distutils] Password security
On Sep 4, 2013, at 11:28 AM, Nick Coghlan ncogh...@gmail.com wrote: The *best* answer is for a service to use 2-factor authentication instead of relying entirely on passwords (the physical object Donald mentioned earlier), but we don't have the resources to set that up, and certainly can't require it for all PyPI users (since you either need a physical token or a phone capable of running an app like Google Authenticator). PyPI will gain 2 Factor Auth support in Warehouse. It's something I feel strongly about and am going to make it work. It obviously won't be required for the reasons you listed it but if folks turn it on then it'll be required for their account. Likely also projects will be able to require that their projects themselves get modified only by an account with 2FA enabled as well. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Please use a mix of different-case letters and numbers in your password
Nick Coghlan ncoghlan at gmail.com writes: On 4 September 2013 23:39, Antoine Pitrou antoine at python.org wrote: PyPI is not a project like Fedora is. It is a community service for thousands of different people, with wildly different processes and constraints. You can't just order anyone use your passwords like Nick and DOnald do. Sure - dealing with security issues for PyPI is always a complex balancing acting between security, backwards compatibility and avoiding raising barriers to entry. With the error message fixed, the current password rules are pretty simple, and easy to satisfy by typing a few more letters, pressing shift once or hitting a number key. Once again, the problem is *not* to create a strong enough password (a one-liner using os.urandom() and the base64 module works for that), it's to remember it without having to note it down or whatever the current fashionable form of self-reminder is. This is the whole reason people choose weak passwords, because they are those they're able to remember easily. However, PyPI users need to recognise that it isn't the integrity of *their* accounts that we're primarily worried about when attempting to minimise login vulnerabilities. Our primary concern (after the integrity of PyPI itself), is the integrity of end users' machines. So when we place restrictions on uploaders, it's guided by a desire to be worthy of the exceptional levels of trust placed in the service by anyone that types pip install distribution or easy_install distribution or just downloads a file directly from the site. But there are many other ways to compromise a developers' account than to brute-force their PyPI password. Since most of the package production process is out of reach of PyPI administrators, it is a hopeless endeavour to try to provide security *in PyPI* in this regard. Similarly, someone signing a package using GPG doesn't say anything about the strength of their passphrase, or whether the private key was leaked somewhere. Again, provide the tools that allows users to make their authentication stronger and less easily breakable, but don't try to *enforce* it. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Password security
On 5 September 2013 01:31, Donald Stufft don...@stufft.io wrote: On Sep 4, 2013, at 11:28 AM, Nick Coghlan ncogh...@gmail.com wrote: The *best* answer is for a service to use 2-factor authentication instead of relying entirely on passwords (the physical object Donald mentioned earlier), but we don't have the resources to set that up, and certainly can't require it for all PyPI users (since you either need a physical token or a phone capable of running an app like Google Authenticator). PyPI will gain 2 Factor Auth support in Warehouse. It's something I feel strongly about and am going to make it work. It obviously won't be required for the reasons you listed it but if folks turn it on then it'll be required for their account. Likely also projects will be able to require that their projects themselves get modified only by an account with 2FA enabled as well. Yay, that's great news! :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Password security
Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 11:28 AM, Nick Coghlan ncoghlan at gmail.com wrote: The *best* answer is for a service to use 2-factor authentication instead of relying entirely on passwords (the physical object Donald mentioned earlier), but we don't have the resources to set that up, and certainly can't require it for all PyPI users (since you either need a physical token or a phone capable of running an app like Google Authenticator). PyPI will gain 2 Factor Auth support in Warehouse. It's something I feel strongly about and am going to make it work. It obviously won't be required for the reasons you listed it but if folks turn it on then it'll be required for their account. Likely also projects will be able to require that their projects themselves get modified only by an account with 2FA enabled as well. What would the second factor be in this case? (besides the usual password-based or OpenID-based auth factor?) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On Wed, Sep 4, 2013 at 9:44 AM, Nick Coghlan ncogh...@gmail.com wrote: On 4 September 2013 23:32, Paul Moore p.f.mo...@gmail.com wrote: On 4 September 2013 14:27, Nick Coghlan ncogh...@gmail.com wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available), so why would pip wheel provoke any more bug reports than pip install? It won't, but at the moment the reports are likely to be that *pip* is where the error lies. We're saying that such reports will in future be redirected at the project. That is the change. (It may be that it's simply changing can't fix to won't fix - I don't know how traditionally pip deals with such reports, if indeed it has ever had any). There's no point in worrying though until we have evidence of such a project actually existing. If no-one wants to try to check likely candidates in advance, let's just wait for the bug reports if any. More accurately, the response will still be let's investigate and see exactly what's going wrong. The only real change is that the project should change its setup.py to cope with the setuptools monkey-patching will be a more likely resolution from the distribution tools side. Bugs in pip and setuptools are still a possibility, and modifying pip to not *need* the setuptools monkey-patching is still highly desirable. It's just not a blocker for anything else :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig Let's review the proposed MEBS meta build system design which would provide a way for sdists to declare their build system and produce something that can be installed. I haven't implemented it yet mainly because packaging is not my only hobby: - each installed build system registers a .detect(path) method that determines whether it can build a particular unpacked sdist - the build+installer unpacks an sdist - the first build system where .detect() returns True is instantiated. (A configuration file can determine the precedence of installed build systems.) - the build object has a .metadata() method returning a dict of the sdist's metadata 2.0 - the build object has a .build() method that produces a wheel - todo development/in-place builds - todo how is the requested build system declared when no installed build system recognizes the package - todo plenty - the installer installs the new wheel Critically setup.py install is no longer needed as a feature of new build systems. The build system can focus on building and the installer on installing, simplifying both. A second important feature of this design is that MEBS does not always respect the package's declared build system, for example providing a way for setuptools to be used for distutils packages as it is today, or perhaps for distil to be used but only for those packages for which it is known to work. The current pip always import setuptools build process would be the first MEBS plugin. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 09/04/2013 07:27 AM, Nick Coghlan wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available) Sidenote, and already mentioned by MAL upthread, but --record is a distutils feature, not a setuptools feature, so this is not the reason pip forces setuptools. I think the actual reason is so that pip can have a uniform way to access metadata (including dependency metadata that only setuptools has) by running setup.py egg-info, which is setuptools-only. (It also means pip can install everything with the same installed format, including the .egg-info metadata directory). Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 6:47 AM, Donald Stufft wrote: On Sep 4, 2013, at 9:46 AM, Antoine Pitrou anto...@python.org wrote: Nick Coghlan ncoghlan at gmail.com writes: If the PyPI password restrictions ever feel too onerous, then OpenID is another alternative (albeit not one that works with the command line tools). However, you should be able to use pypissh for CLI access in that case. For the record, it seems pypissh doesn't work with Python 3: $ sudo pip3 install pypissh Downloading/unpacking pypissh Running setup.py egg_info for package pypissh Installing collected packages: pypissh Running setup.py install for pypissh File /usr/local/lib/python3.3/dist-packages/pypissh.py, line 186 except socket.error, e: ^ SyntaxError: invalid syntax Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig I believe MvL owns PyPISSH and it has an issue tracker under his account on bitbucket.org. Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Password security
On Sep 4, 2013, at 11:53 AM, Antoine Pitrou anto...@python.org wrote: Donald Stufft donald at stufft.io writes: On Sep 4, 2013, at 11:28 AM, Nick Coghlan ncoghlan at gmail.com wrote: The *best* answer is for a service to use 2-factor authentication instead of relying entirely on passwords (the physical object Donald mentioned earlier), but we don't have the resources to set that up, and certainly can't require it for all PyPI users (since you either need a physical token or a phone capable of running an app like Google Authenticator). PyPI will gain 2 Factor Auth support in Warehouse. It's something I feel strongly about and am going to make it work. It obviously won't be required for the reasons you listed it but if folks turn it on then it'll be required for their account. Likely also projects will be able to require that their projects themselves get modified only by an account with 2FA enabled as well. What would the second factor be in this case? (besides the usual password-based or OpenID-based auth factor?) Something that implements the standard TOTP algorithm. There are a number of apps for phones that enable it as well as desktop apps. Possibly support for users to buy a yubikey or an RSA token as well. A lot of the details are really sketchy because I haven't actually done it yet but I know that A) It'll be supported and b) At a minimum TOTP will be supported. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
On 4 September 2013 17:20, Carl Meyer c...@oddbird.net wrote: On 09/04/2013 07:27 AM, Nick Coghlan wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available) Sidenote, and already mentioned by MAL upthread, but --record is a distutils feature, not a setuptools feature, so this is not the reason pip forces setuptools. My apologies. That was me spreading that misinformation. I have no idea where I got it from, but I've just checked and distutils at least back to Python 2.5 has this features. And to compound my error, I have certainly said this on multiple occasions :-( Next time I'll check my facts more carefully. I think the actual reason is so that pip can have a uniform way to access metadata (including dependency metadata that only setuptools has) by running setup.py egg-info, which is setuptools-only. (It also means pip can install everything with the same installed format, including the .egg-info metadata directory). Actually, there is an install_egg_info command available in distutils, also back to at least Python 2.5. For some reason, it's not displayed by setup.py --help-commands, but it is there nevertheless. Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on PEP 426
Le 30/08/2013 03:23, Paul Moore a écrit : On 30 August 2013 00:08, Nick Coghlan ncogh...@gmail.com wrote: We also need to officially bless pip's trick of forcing the use of setuptools for distutils based setup.py files. Do we? What does official blessing imply? We've managed for years without the trick being official... The main reason it is currently used is to allow setup.py install to specify --record, so that we can get the list of installed files. If distutils added a --record flag, for example, I don't believe we'd need the hack at all. (Obviously, we'd still need setuptools so we could use wheel to build wheels, but that's somewhat different as it's a new feature). Maybe a small distutils patch is better than blessing setuptools here? distutils’ install command provides --record. Regards ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
Noah Kantrowitz noah at coderanger.net writes: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. Really? So what will be the options to upload files easily without stuffing a password in .pypirc? ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. What *is* the Era of Warehouse, exactly? Is there any documentation which defines standards, interfaces etc., or a rough time frame/road map for such documentation? What are the deliverables? Is it expected that there could be multiple implementations of a standard, or just a single blessed implementation that everyone has to use? Does all or most of the discussion about Warehouse happen on this list, or does substantive discussion take place on some other list somewhere? Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 11:33 AM, Antoine Pitrou wrote: Noah Kantrowitz noah at coderanger.net writes: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. Really? So what will be the options to upload files easily without stuffing a password in .pypirc I think Donald intends to support SSL Client Certs for those that want to use them, though OAuth-style access tokens is another possibility (no idea how Donald feels about those). --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
Noah Kantrowitz noah at coderanger.net writes: On Sep 4, 2013, at 11:33 AM, Antoine Pitrou wrote: Noah Kantrowitz noah at coderanger.net writes: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. Really? So what will be the options to upload files easily without stuffing a password in .pypirc I think Donald intends to support SSL Client Certs for those that want to use them, though OAuth-style access tokens is another possibility (no idea how Donald feels about those). Well, sounds nice but... will discussions about feature changes and possible compatibility breakage happen on the list beforehand, or will Warehouse be some kind of fait accompli? (I'm actually not even sure what Warehouse is, although from the discussions I gather that it's gonna be a PyPI replacemenent... a new codebase? a new hosting?) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 2:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. What *is* the Era of Warehouse, exactly? Is there any documentation which defines standards, interfaces etc., or a rough time frame/road map for such documentation? What are the deliverables? Is it expected that there could be multiple implementations of a standard, or just a single blessed implementation that everyone has to use? Does all or most of the discussion about Warehouse happen on this list, or does substantive discussion take place on some other list somewhere? Regards, Vinay Sajip Rolling up answers to multiple questions in here. 1) Warehouse is the name of the software that will power PyPI 2.0. 2) Nothing about the future of Warehouse is set in stone and API breakages and the like will be discussed before hand. 3) The way the migration was going to work was posted to this list already (https://mail.python.org/pipermail/distutils-sig/2013-July/022096.html). 4) In regards to the PyPISSH I don't know exactly what tooling I want to replace it with, it might simply be a saner implementation of SSH Authentication, it might be TLS Client Certs, or OAuth Tokens. Personally I'm leaning towards TLS Client Certs and possibly OAuth tokens but that will be decided down the road. 5) There are no real discussions about Warehouse yet, there is a github repo with issues and I sound future ideas off a few folks as I process ideas I want to implement but that doesn't preclude eventual discussion about them. Warehouse right now (which it's stalled waiting on some DB maintenance) is focused primarily on reimplementing the API of PyPI 1.0 and then adding a UX ontop of that. New features and new APIs and the like will come later and will be standards based and discussed. I expect there can (and will) be multiple implementations of the standard but there is not going to be much getting around the fact that the code that powers PyPI is going to be the standard implementation. This does not mean that there won't be a defined standard and hopefully the good folks making alternate implementations like Holger's devpi will keep me to task for defining and documenting everything. Also important to note that I do not consider the UX to be something that requires discussion to change. This is somewhat harder with PyPI which doesn't separate UX and API but that will be replicated for API usage but not for UX usage in Warehouse. If I missed anything just reask it or I can clarify points as well. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 12:14 PM, Donald Stufft wrote: On Sep 4, 2013, at 2:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. What *is* the Era of Warehouse, exactly? Is there any documentation which defines standards, interfaces etc., or a rough time frame/road map for such documentation? What are the deliverables? Is it expected that there could be multiple implementations of a standard, or just a single blessed implementation that everyone has to use? Does all or most of the discussion about Warehouse happen on this list, or does substantive discussion take place on some other list somewhere? Regards, Vinay Sajip Rolling up answers to multiple questions in here. 1) Warehouse is the name of the software that will power PyPI 2.0. 2) Nothing about the future of Warehouse is set in stone and API breakages and the like will be discussed before hand. 3) The way the migration was going to work was posted to this list already (https://mail.python.org/pipermail/distutils-sig/2013-July/022096.html). 4) In regards to the PyPISSH I don't know exactly what tooling I want to replace it with, it might simply be a saner implementation of SSH Authentication, it might be TLS Client Certs, or OAuth Tokens. Personally I'm leaning towards TLS Client Certs and possibly OAuth tokens but that will be decided down the road. To refine my statement, the current server implementation of using opensshd with some authorized_keys trickery is what the infra team is declining to support long term. Something built around Twisted's SSH server impl (for example) could be a suitable replacement since that would be secure by default as opposed to the current system where any failure on our part gives you shell access to the PyPI server. I know of no current issues, but long-term it isn't a position we want to be in in terms of support. --Noah signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypissh
On Sep 4, 2013, at 3:19 PM, Noah Kantrowitz n...@coderanger.net wrote: On Sep 4, 2013, at 12:14 PM, Donald Stufft wrote: On Sep 4, 2013, at 2:36 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Obligatory reminder that we (I) have no intention of supporting pypissh as we move into the Era of Warehouse. What *is* the Era of Warehouse, exactly? Is there any documentation which defines standards, interfaces etc., or a rough time frame/road map for such documentation? What are the deliverables? Is it expected that there could be multiple implementations of a standard, or just a single blessed implementation that everyone has to use? Does all or most of the discussion about Warehouse happen on this list, or does substantive discussion take place on some other list somewhere? Regards, Vinay Sajip Rolling up answers to multiple questions in here. 1) Warehouse is the name of the software that will power PyPI 2.0. 2) Nothing about the future of Warehouse is set in stone and API breakages and the like will be discussed before hand. 3) The way the migration was going to work was posted to this list already (https://mail.python.org/pipermail/distutils-sig/2013-July/022096.html). 4) In regards to the PyPISSH I don't know exactly what tooling I want to replace it with, it might simply be a saner implementation of SSH Authentication, it might be TLS Client Certs, or OAuth Tokens. Personally I'm leaning towards TLS Client Certs and possibly OAuth tokens but that will be decided down the road. To refine my statement, the current server implementation of using opensshd with some authorized_keys trickery is what the infra team is declining to support long term. Something built around Twisted's SSH server impl (for example) could be a suitable replacement since that would be secure by default as opposed to the current system where any failure on our part gives you shell access to the PyPI server. I know of no current issues, but long-term it isn't a position we want to be in in terms of support. --Noah Yes, if SSH Authentication is kept long term it will likely be replaced by an implementation using Twisted on the server side and I dunno what but something that doesn't involve shelling out to a command named ``ssh`` on the client side so that it can work out of the box on more OSs. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] (no subject)
On 09/04/2013 04:59 PM, Antoine Pitrou wrote: Nick Coghlan ncoghlan at gmail.com writes: That's the whole reason the content restrictions turn themselves off once the password hits 16 characters: passphrases are easy to remember, and generally quite secure. So, no, it's easy to remember is not an adequate excuse for choosing a poor password for a service that has a lot of other people depending on its integrity. Then please add helpful guidelines as to how people can choose a safe and easy to remember password /or passphrase/. Most people aren't password experts, and the current one-line message isn't useful. A link here should do the trick (which succinctly sums up this entire thread): https://xkcd.com/936/ (Apologies if I missed another reference to it.) Dag Sverre ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] (no subject)
On Sep 4, 2013, at 3:20 PM, Dag Sverre Seljebotn d.s.seljeb...@astro.uio.no wrote: On 09/04/2013 04:59 PM, Antoine Pitrou wrote: Nick Coghlan ncoghlan at gmail.com writes: That's the whole reason the content restrictions turn themselves off once the password hits 16 characters: passphrases are easy to remember, and generally quite secure. So, no, it's easy to remember is not an adequate excuse for choosing a poor password for a service that has a lot of other people depending on its integrity. Then please add helpful guidelines as to how people can choose a safe and easy to remember password /or passphrase/. Most people aren't password experts, and the current one-line message isn't useful. A link here should do the trick (which succinctly sums up this entire thread): https://xkcd.com/936/ (Apologies if I missed another reference to it.) Dag Sverre ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig I hate that comic :| - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
