On Fri, Mar 08, 2013 at 12:57:54PM -0500, Donald Stufft wrote: > On Mar 8, 2013, at 12:47 PM, Lennart Regebro <rege...@gmail.com> wrote: > > > On Fri, Mar 8, 2013 at 6:01 PM, Donald Stufft <don...@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
pgp4__BWB6HKx.pgp
Description: PGP signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
