[distutils] make the storage of the password optional in .pypirc
Hello
I would like to make the storage of the password optional in .pypirc. If unstored, the register command would prompt for it.
More details here: http://bugs.python.org/issue4394
Any thaught or objection on this ?
Regards Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
I would like to make the storage of the password optional in .pypirc. If unstored, the register command would prompt for it.
More details here: http://bugs.python.org/issue4394
Any thaught or objection on this ?
+1. Storing plaintext passwords on disk is just wrong.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Sun, Jan 4, 2009 at 2:40 PM, Tres Seaver tseaver@palladion.com wrote:
Any thaught or objection on this ?
+1. Storing plaintext passwords on disk is just wrong.
Yes,
in a second phase, I was also wondering if a mechanism ala ssh-agent could be set to save the password in the user session.
Tarek
On Mon, Jan 5, 2009 at 6:00 AM, Tarek Ziadé ziade.tarek@gmail.com wrote:
On Sun, Jan 4, 2009 at 2:40 PM, Tres Seaver tseaver@palladion.com wrote:
Any thaught or objection on this ?
+1. Storing plaintext passwords on disk is just wrong.
This is done and available in trunk and 3.1,
I will also backport that feature in the collective.dist package, which provides distutils new features for Python 2.4->2.6
Tarek
Brilliant.
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
On Fri, Jan 9, 2009 at 8:32 AM, Tarek Ziadé ziade.tarek@gmail.com wrote:
On Mon, Jan 5, 2009 at 6:00 AM, Tarek Ziadé ziade.tarek@gmail.com wrote:
On Sun, Jan 4, 2009 at 2:40 PM, Tres Seaver tseaver@palladion.com wrote:
Any thaught or objection on this ?
+1. Storing plaintext passwords on disk is just wrong.
This is done and available in trunk and 3.1,
I will also backport that feature in the collective.dist package, which provides distutils new features for Python 2.4->2.6
Tarek
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
On Fri, Jan 9, 2009 at 4:08 PM, Stephen Emslie stephenemslie@gmail.com wrote:
Brilliant.
Thanks :)
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Not yet. I need to dig on how this could work properly, by studying ssh-agent
Regards Tarek
On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie stephenemslie@gmail.com wrote:
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
On Fri, Jan 09, 2009 at 10:17:50AM -0500, Benji York wrote:
On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie stephenemslie@gmail.com wrote:
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
Yes please. I'd rather have one agent running and reuse my SSH key for authentication.
Marius Gedminas
On Fri, Jan 9, 2009 at 4:45 PM, Marius Gedminas marius@pov.lt wrote:
On Fri, Jan 09, 2009 at 10:17:50AM -0500, Benji York wrote:
On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie stephenemslie@gmail.com wrote:
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
Yes please. I'd rather have one agent running and reuse my SSH key for authentication.
That would be awesome indeed. But that would involve quite some changes on server side, I'll forward this mail to catalog-sig for Richard, Martin and others's feedback
Regards Tarek
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
Yes please. I'd rather have one agent running and reuse my SSH key for authentication.
That would be awesome indeed. But that would involve quite some changes on server side, I'll forward this mail to catalog-sig for Richard, Martin and others's feedback
I'm fairly skeptical. First, the infrastructure is *not* yet in place. Nobody has uploaded SSH keys to PyPI, and in order to allow SSH access, we probably would need to create a Unix account, which then runs a fixed (Python) program on ssh login. That is much less secure than the current setup, in the sense that this program can probably tricked much easier than Apache can. So it opens a door for people hacking into the system; all they have to do is to create a fake PyPI account and upload an SSH key...
To improve password storage, I think it would be better to use the platform's secure password storage services where available (e.g. OSX Keychain, KDE KWallet, etc). Of course, such a library should be developed independently of distutils. For Keychain, there is already
http://muffinresearch.co.uk/archives/2008/02/05/python-keychainpy-access-to-...
Regards, Martin
On Jan 9, 2009, at 3:18 PM, Martin v. Löwis wrote:
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
Yes please. I'd rather have one agent running and reuse my SSH key for authentication.
That would be awesome indeed. But that would involve quite some changes on server side, I'll forward this mail to catalog-sig for Richard, Martin and others's feedback
I'm fairly skeptical. First, the infrastructure is *not* yet in place. Nobody has uploaded SSH keys to PyPI,
Right. PyPI would have to grow the ability to manage public keys for users.
and in order to allow SSH access, we probably would need to create a Unix account,
No, you would not.
which then runs a fixed (Python) program on ssh login. That is much less secure than the current setup, in the sense that this program can probably tricked much easier than Apache can. So it opens a door for people hacking into the system; all they have to do is to create a fake PyPI account and upload an SSH key...
No. You'd have a new server process, written in Python using Twisted or paramiko, that would would provide a small number of specialized commands and that would read public keys from the pypi database for authentication and update the database in response to commands,
Jim
-- Jim Fulton Zope Corporation
On Jan 9, 2009, at 3:57 PM, Jim Fulton wrote:
No. You'd have a new server process, written in Python using Twisted or paramiko, that would would provide a small number of specialized commands
Or better yet, supported scp. Then the upload/register process would be reduced to just scp-ing a distro to pypi. The server could read meta-data from the distro, register the release, if necessary, and put the distro in the right place.
Jim
-- Jim Fulton Zope Corporation
Or better yet, supported scp. Then the upload/register process would be reduced to just scp-ing a distro to pypi. The server could read meta-data from the distro, register the release, if necessary, and put the distro in the right place.
That wouldn't fit too well with the existing "register" and "upload" commands, I think.
Regards, Martin
On Fri, Jan 9, 2009 at 10:07 PM, "Martin v. Löwis" martin@v.loewis.de wrote:
Or better yet, supported scp. Then the upload/register process would be reduced to just scp-ing a distro to pypi. The server could read meta-data from the distro, register the release, if necessary, and put the distro in the right place.
That wouldn't fit too well with the existing "register" and "upload" commands, I think.
+1
and in any case those commands should stay compatible with the current mechanism and let people store the password in the pypirc file if they want to, and use https authentication.
Imho a scp/ssh protocol should be implemented in a new set of commands,
Regards Tarek
Regards, Martin
No. You'd have a new server process, written in Python using Twisted or paramiko, that would would provide a small number of specialized commands and that would read public keys from the pypi database for authentication and update the database in response to commands,
Ok. I guess "contributions are welcome".
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Martin v. Löwis wrote:
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
Yes please. I'd rather have one agent running and reuse my SSH key for authentication.
That would be awesome indeed. But that would involve quite some changes on server side, I'll forward this mail to catalog-sig for Richard, Martin and others's feedback
I'm fairly skeptical. First, the infrastructure is *not* yet in place. Nobody has uploaded SSH keys to PyPI, and in order to allow SSH access, we probably would need to create a Unix account, which then runs a fixed (Python) program on ssh login.
Right, a single account with multiple keys (each with 'command='do_pypi - -u <userid>').
That is much less secure than the current setup, in the sense that this program can probably tricked much easier than Apache can. So it opens a door for people hacking into the system; all they have to do is to create a fake PyPI account and upload an SSH key...
Zope has been using the 'command=' bit to do SSH-protected CVS / SVN access since 2000 with a lot of success; 370+ committers have keys on the system. The command being executed is actually a small shell script, which barfs if the program being run is not one of 'svn', 'cvs', or 'scp' (for uploading tarballs).
To improve password storage, I think it would be better to use the platform's secure password storage services where available (e.g. OSX Keychain, KDE KWallet, etc). Of course, such a library should be developed independently of distutils. For Keychain, there is already
http://muffinresearch.co.uk/archives/2008/02/05/python-keychainpy-access-to-...
Not only are PyPI passwords stored in the clear on user's hard drives, they are sent in the clear on every authenticated request to the web interface (basic auth over unencrypted HTTP): it seems to me we ought to worry about both those issues more.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Jan 9, 2009, at 10:17 AM, Benji York wrote:
On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie <stephenemslie@gmail.com
wrote: A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
+1 Note that paramiko or the Twisted ssh support should make this fairly straightforward to implement. (I have need to build a custom ssh server soon for a project, and I'll find out if this statement is correct. :)
Jim
-- Jim Fulton Zope Corporation
On Fri, 9 Jan 2009 11:46:25 -0500, Jim Fulton jim@zope.com wrote:
On Jan 9, 2009, at 10:17 AM, Benji York wrote:
On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie <stephenemslie@gmail.com > wrote:
A bit OT, but from your blog post on the subject:
I'd like to go further and to think about a ssh-agent like system, so there's no need to enter the pasword everytime you work with PyPI in the same session.
Have you had any feedback on this yet?
Here's some: how about instead of an ssh-like system, use ssh itself. Front PyPI with an ssh server that users connect to. That way it is both secure and the infrastructure (agent, etc.) is already in place.
+1 Note that paramiko or the Twisted ssh support should make this fairly straightforward to implement. (I have need to build a custom ssh server soon for a project, and I'll find out if this statement is correct. :)
I'd like to hear more about the details of how distutils/pypi would be using SSH, but this is potentially a project I'd be willing to volunteer some time to implement.
Jean-Paul
On Fri, Jan 9, 2009 at 6:00 PM, Jean-Paul Calderone exarkun@divmod.com wrote:
On Fri, 9 Jan 2009 11:46:25 -0500, Jim Fulton jim@zope.com wrote:
+1 Note that paramiko or the Twisted ssh support should make this fairly straightforward to implement. (I have need to build a custom ssh server soon for a project, and I'll find out if this statement is correct. :)
I'd like to hear more about the details of how distutils/pypi would be using SSH, but this is potentially a project I'd be willing to volunteer some time to implement.
Great !
I'd like to mention also, that there's a Python Language Summit right before Pycon in Chicago where such a topic can be presented (eg upcoming projects in distutils and pypi)
and that I have asked for a sprint slot for distutils and pypi matters,
Regards Tarek
participants (8)
-
"Martin v. Löwis" -
Benji York -
Jean-Paul Calderone -
Jim Fulton -
Marius Gedminas -
Stephen Emslie -
Tarek Ziadé -
Tres Seaver