On Sun, Jan 4, 2009 at 2:40 PM, Tres Seaver 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

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é wrote:

On Mon, Jan 5, 2009 at 6:00 AM, Tarek Ziadé wrote:

...

On Sun, Jan 4, 2009 at 2:40 PM, Tres Seaver 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 10:08 AM, Stephen Emslie 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. -- Benji York Senior Software Engineer Zope Corporation

On Fri, Jan 9, 2009 at 4:45 PM, Marius Gedminas 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 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 -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

On Fri, 9 Jan 2009 11:46:25 -0500, Jim Fulton wrote:

On Jan 9, 2009, at 10:17 AM, Benji York wrote:

...

On Fri, Jan 9, 2009 at 10:08 AM, Stephen Emslie 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

...

...

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: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

-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJaUAW+gerLs4ltQ4RAhFXAJ47WOzMAe12m+YD5BNu22BzTU+QRQCeLTbX DSaVk1I96K5mzaZro98HUTU= =8sRs -----END PGP SIGNATURE-----