Add optional password_command .pypirc value
After doing some research last night on storing/accessing passwords in the OSX Keychain (http://asktherelic.com/2013/03/07/storing-command-line-passwords-in-keychain...), I was curious why the .pypirc doesn't support something like this when asking for the password during 'upload', to not have your pypi password in plaintext on your system. As far as I can see from the source, the password is read straight from the .pypirc config: https://bitbucket.org/tarek/distribute/src/188dcdb7f0873f1b382e8bde65377c5f4... and fails if the password value doesn't exist: https://bitbucket.org/tarek/distribute/issue/291/allow-password-to-be-omitte... I'm curious about implementing: 1. a password_command to support integration with external password tools (1password, keychain, keyring python lib) The implementation from the program I am trying to emulate, pianobar, is here: https://github.com/PromyLOPh/pianobar/blob/master/src/main.c#L135 just a /bin/sh for nix/osx. Could run cmd.exe for windows cross-platform compatibility. 2. better notification to the user about trying to upload with an empty password or using get_pass if empty password The only other reference to something like this is from several years ago here: http://bugs.python.org/issue4394 Does this seem like it's worth making a patch? -- Matt Behrens
On Fri, Mar 8, 2013 at 5:08 PM, Matt Behrens <askedrelic@gmail.com> wrote:
Does this seem like it's worth making a patch?
Personally I think it's better to the the ssh way and support uploading via ssh with uploaded ssh keys, and deprecate the password support for uploading. That way there is no problems with integrating a bunch of different platform specific keyring systems. That said, this is just me talking, and doing counts more. :-) //Lennart
On Mar 8, 2013, at 11:32 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Mar 8, 2013 at 5:08 PM, Matt Behrens <askedrelic@gmail.com> wrote:
Does this seem like it's worth making a patch?
Personally I think it's better to the the ssh way and support uploading via ssh with uploaded ssh keys, and deprecate the password support for uploading. That way there is no problems with integrating a bunch of different platform specific keyring systems.
I dislike hijacking SSH to tunnel a HTTP protocol over and adding more reliance on SSH keys means a lost SSH key becomes _even_ worse than it already is. I don't think the long term answer is key rings either.
That said, this is just me talking, and doing counts more. :-)
//Lennart _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Fri, Mar 8, 2013 at 6:01 PM, Donald Stufft <donald@stufft.io> wrote:
I dislike hijacking SSH to tunnel a HTTP protocol over
I'm not sure we have to hijack or tunnel anything. :-)
and adding more reliance on SSH keys means a lost SSH key becomes _even_ worse than it already is.
I don't follow that argument. You can have separate keys in separate places if you like. //Lennart
On Mar 8, 2013, at 12:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Mar 8, 2013 at 6:01 PM, Donald Stufft <donald@stufft.io> wrote:
I dislike hijacking SSH to tunnel a HTTP protocol over
I'm not sure we have to hijack or tunnel anything. :-)
If you're uploading via SSH you'll open a SSH tunnel and then POST to PyPI over that tunnel.
and adding more reliance on SSH keys means a lost SSH key becomes _even_ worse than it already is.
I don't follow that argument. You can have separate keys in separate places if you like.
Ideally you can sure. Security that only deals in ideal and doesn't pay attention to what people will actually do in the general case is a problem. The general case people will reuse their typical SSH keys, thus placing more reliance on a single secret across multiple services (Github, bitbucket, SSH, PyPI). Encouraging authentication token sharing is a bad practice. HTTP has a token that is functionally similar to SSH keys. Client side SSL certificates. They would function fine and enable similar uses as SSH keys.
//Lennart
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Fri, Mar 08, 2013 at 12:57:54PM -0500, Donald Stufft wrote:
On Mar 8, 2013, at 12:47 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Mar 8, 2013 at 6:01 PM, Donald Stufft <donald@stufft.io> wrote:
I dislike hijacking SSH to tunnel a HTTP protocol over
I'm not sure we have to hijack or tunnel anything. :-)
If you're uploading via SSH you'll open a SSH tunnel and then POST to PyPI over that tunnel.
and adding more reliance on SSH keys means a lost SSH key becomes _even_ worse than it already is.
I don't follow that argument. You can have separate keys in separate places if you like.
Ideally you can sure. Security that only deals in ideal and doesn't pay attention to what people will actually do in the general case is a problem. The general case people will reuse their typical SSH keys, thus placing more reliance on a single secret across multiple services (Github, bitbucket, SSH, PyPI). Encouraging authentication token sharing is a bad practice.
HTTP has a token that is functionally similar to SSH keys. Client side SSL certificates. They would function fine and enable similar uses as SSH keys.
If we're choosing between SSH keys and SSL certificates the client side tools for SSH are much more mature than the ones for SSL. The numerous ssh-agents, for instance, allow the ssh key to be encrypted on disk but the user is only prompted for a password when the agent has to read the key (which could be after a timeout or once when the ssh-agent starts up). SSL certificate use for comandline usage doesn't yet have that sort of tool so SSL certificates are often unencrypted on disk if they're being used for commandline access. -Toshio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2013 12:57 PM, Donald Stufft wrote:
If you're uploading via SSH you'll open a SSH tunnel and then POST to PyPI over that tunnel.
That isn't a hard requirment. The PyPI software could add a command-line script used for uploads which depended on the identity indicated by the SSH-authenticated session. 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.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlE6z+MACgkQ+gerLs4ltQ6DggCfZ62QIeUlx5A7A5cnuwU5jTqJ pN8AoN0T0P20qwo5r5p7aheyYi3cGL2L =SdYC -----END PGP SIGNATURE-----
On Fri, Mar 8, 2013 at 6:57 PM, Donald Stufft <donald@stufft.io> wrote:
If you're uploading via SSH you'll open a SSH tunnel and then POST to PyPI over that tunnel.
You are not required to use HTTP, there are several other protocols you can use such as SCP of SFTP. Not that I think it matters which protocol we use.
Ideally you can sure. Security that only deals in ideal and doesn't pay attention to what people will actually do in the general case is a problem. The general case people will reuse their typical SSH keys, thus placing more reliance on a single secret across multiple services (Github, bitbucket, SSH, PyPI).
Often they will reuse passwords too.
Encouraging authentication token sharing is a bad practice.
So don't do that. :-)
HTTP has a token that is functionally similar to SSH keys. Client side SSL certificates. They would function fine and enable similar uses as SSH keys.
Every time I've used that it has been very complicated and usually not worked well or cross-platform. Perhaps that situation has changed? //Lennart
On Sat, Mar 9, 2013 at 4:25 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Mar 8, 2013 at 6:57 PM, Donald Stufft <donald@stufft.io> wrote:
HTTP has a token that is functionally similar to SSH keys. Client side SSL certificates. They would function fine and enable similar uses as SSH keys.
Every time I've used that it has been very complicated and usually not worked well or cross-platform. Perhaps that situation has changed?
Pulp (http://pulpproject.org) handles it fairly well IMO - the CLI includes a "pulp-admin auth login" command which just uses Basic Auth over HTTPS. This returns a server-generated cert that is saved to disk and is valid for a week. After a week, you have to log in again to refresh your cert (this is to mitigate the problem Toshio noted: the cert is stored unencrypted on disk. Without the expiry date, this approach would be just as bad as storing the password itself in the clear). There's a bit of fiddling client side to use the cached cert, and server side to check it, but the user experience is pretty smooth. (Pulp is GPL, while PyPI is now BSD, so if we do go down this path, someone that hasn't read the Pulp code will need to implement it, or else I can talk to the Pulp team about getting those parts relicensed under a more permissive license) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Donald Stufft -
Lennart Regebro -
Matt Behrens -
Nick Coghlan -
Toshio Kuratomi -
Tres Seaver