use .netrc

[Martin Pool]

We should perhaps look in .netrc for passwords for http and (especially) ftp servers. It's probably not appropriate for sftp.

http://docs.python.org/lib/module-netrc.html

[Jelmer Vernooij (jelmer)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  status confirmed

Agreed, this would be a nice feature to have.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRhZQ4gy0JeEGD2blAQK7wwP+J7oUfkINpfB1IlyNiflddFL45vs2CfS1
CKj2FBRxErJpIUaTJvxW9SGhg3mPtU/pQvWucz10+zOCsPGYHt07ft/XwLFUEjBp
DQcyy4X5aIcdBEcsTBmjVlxU6y4jDdKFelnlwxGVXcjTSufk6GrYIu1JzkicLX3D
VvCw3Y4x9Xs=
=RmY2
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

Patch from Chris Niekel

[Martin Pool (mbp)]

On 4/7/07, Chris Niekel <email address hidden> wrote:
> On Thu, Apr 05, 2007 at 06:02:45AM +1000, Martin Pool wrote:
> > I don't think there is a way to do it at present. There is Python
> > support for a netrc file, so we could use that to get it pretty
> > easily, I would think.
>
> It was indeed very easy. The hardest part was figuring out how to use bzr,
> because I'm not used to it yet. Here's my patch, hopefully someone can
> integrate it.

https://bugs.launchpad.net/bzr/+bug/103029

Thanks Chris,

Could you please try to write a test for it too to make sure it
doesn't regress? In tests that subclass TestCaseInTempDir we set
$HOME to a temporary directory. We also have the capability to run up
an ftp server in testing, which is done in the code at the bottom of
transport/ftp.py. I think you'll need to add a new
blackbox/test_ftp.py, create a netrc file, run the server, then try to
connect.

--
Martin

[John A Meinel (jameinel)]

Martin Pool wrote:
> On 4/7/07, Chris Niekel <email address hidden> wrote:
>> On Thu, Apr 05, 2007 at 06:02:45AM +1000, Martin Pool wrote:
>> > I don't think there is a way to do it at present. There is Python
>> > support for a netrc file, so we could use that to get it pretty
>> > easily, I would think.
>>
>> It was indeed very easy. The hardest part was figuring out how to use
>> bzr,
>> because I'm not used to it yet. Here's my patch, hopefully someone can
>> integrate it.
>
> https://bugs.launchpad.net/bzr/+bug/103029
>
> Thanks Chris,
>
> Could you please try to write a test for it too to make sure it
> doesn't regress? In tests that subclass TestCaseInTempDir we set
> $HOME to a temporary directory. We also have the capability to run up
> an ftp server in testing, which is done in the code at the bottom of
> transport/ftp.py. I think you'll need to add a new
> blackbox/test_ftp.py, create a netrc file, run the server, then try to
> connect.

It would be good to have a few test cases.

Also, if I read it closely, it seems you have to supply a username (and
then it matches based on username).

It might be nice to look up by host, and if there is only one username +
password, to just use it. That allows different people to use
"ftp://foo/bar" and have it Just Work, just like sftp urls.

I would even consider adding netrc processing for http urls.

I know at one point we added a spec for using "~/.authinfo":
https://blueprints.launchpad.net/bzr/+spec/authinfo

I'm curious how '.authinfo' compares with .netrc. Does anyone know?

(If we decide to go this route, we could just say call the spec
implemented, using netrc instead of authinfo)

John
=:->

[Vincent Ladeuil (vila)]

>>>>> "john" == John A Meinel <email address hidden> writes:

    john> It would be good to have a few test cases.

    john> Also, if I read it closely, it seems you have to supply
    john> a username (and then it matches based on username).

    john> It might be nice to look up by host, and if there is
    john> only one username + password, to just use it. That
    john> allows different people to use "ftp://foo/bar" and have
    john> it Just Work, just like sftp urls.

    john> I would even consider adding netrc processing for http urls.

Can of worms...

For ssh and [s]ftp authentication is done with (user,
password), (user, password, account) even.

For http, most of the time (user, password) will be enough, but
webdav (for one) requires (user, password, realm).

And via .htaccess you can provide different (user, password)
specific to any tree (inside which you can, of course, use other
.htaccess files).

    john> I know at one point we added a spec for using "~/.authinfo":
    john> https://blueprints.launchpad.net/bzr/+spec/authinfo

    john> I'm curious how '.authinfo' compares with .netrc. Does anyone know?

AIUI, netrc is for ftp (host, user, password [, account]),
authinfo is for pop3/nntp (host, user, pass).

The most complete solution will be to allow: (scheme, host, path,
user, password).

- scheme can be empty (meaning the rest of the tuple can be used
  for any scheme),

- host can be empty (to act as a default for any host),

- path can be empty (ssh or sftp will never user it),

- user is mandatory (hey, if you don't want to provide a user,
  don't provide a file ;)

- password can be empty (for security reasons, a user may use the
  definitions but want to be prompted).

The first matching tuple wins (empty fields match everything,
path match if included in the requested url, scheme should match
even if decorators are used in the requested url).

    john> (If we decide to go this route, we could just say call the spec
    john> implemented, using netrc instead of authinfo)

Neither one will do for http.

But implementing .netrc handling will be a step in the right
direction.

IMHO, we should define a plan to also address the following points
in the long term:

- define priorities when several sources exist ([.authinfo]?,
  .netrc, .bzr-auth ?, .bazaar/bazaar.conf ? /bzr/branch/branch.conf ?),

- decide if we want a bzr specific source (and avoid putting
  passwords in bazaar.conf, etc),

- define a policy regarding what access rights we allow for
  sources (unix 600 ? 400 ?),

- define a format to store the passwords (John mentioned base64
  in the past as a convenient way to lightly hide passwords from
  accidental readers (admins)).

Or it may be possible to use the key rings provided by Ubuntu or
Mac OS X and surely windows have a way to store passwords
securely...

        Vila

[Vincent Ladeuil (vila)]

I forgot to mention that we also need a way to identify https self-certified hosts so that user can flag them on a case-by-case basis.

[Martin Pool (mbp)]

vila, I think doing those things would be very good, can you register a spec or another bug for them?

[Chris (chris-niekel)]

I worked on the .netrc a little more (thanks to jam on irc). The netrc is old, ftp-only, and 1 user per machine. But it's easy to support, because it's only a "import netrc" away!

I added tests, fixed some bugs, and probably introduced others. It's work in progress, I'm going to try to setup tests against a test-server later this week.

[Vincent Ladeuil (vila)]

>>>>> "Martin" == Martin Pool <email address hidden> writes:

    Martin> vila, I think doing those things would be very good,
    Martin> can you register a spec or another bug for them?

Done: https://blueprints.launchpad.net/bzr/+spec/authentication-ring

This a draft, comments are not only welcomed but strongly
encouraged.

      Vincent

[Vincent Ladeuil (vila)]

The associated branch provides a way to use .netrc passwords as long as the relevant sections are added to the authentication.conf file.