do without .netrc

"git clone http://a:b@donatello.pri.univie.ac.at/repositories/0/Data/" 
is not working

also "git clone 
http://a@donatello.pri.univie.ac.at/repositories/0/Data/" is not asking 
for password. is it supposed to?

it is working without a:b@ part, but ~/.netrc instead

:-(, is it possible without .netrc

git version 1.5.4.3

thanks, regards

Jürgen

On Wed, Aug 06, 2008 at 01:00:54AM +0200, Jürgen Mangler [off-list ref] wrote:

it is working without a:b@ part, but ~/.netrc instead

:-(, is it possible without .netrc

I thought questions have question marks. ;-)

Anyway, what is the advantage of not using a ~/.netrc?

Miklos Vajna venit, vidit, dixit 06.08.2008 10:50:

On Wed, Aug 06, 2008 at 01:00:54AM +0200, Jürgen Mangler [off-list ref] wrote:

quoted

it is working without a:b@ part, but ~/.netrc instead

:-(, is it possible without .netrc

I thought questions have question marks. ;-)

Anyway, what is the advantage of not using a ~/.netrc?

Not having the password on disk[?!]

Michael

On Wed, Aug 06, 2008 at 11:17:48AM +0200, Michael J Gruber [off-list ref] wrote:

Not having the password on disk[?!]

I think you can't avoid so (we are talking about http).

There is no such thing as ssh-agent for http, and typing the password
for each pull or push is boring. (OK, this is subjective, but I think
nobody types his/her pass on every push/pull.)

You could have the password in the URL, but the it's in .git/config,
even worse.

Miklos Vajna wrote:

On Wed, Aug 06, 2008 at 01:00:54AM +0200, Jürgen Mangler [off-list ref] wrote:

quoted

it is working without a:b@ part, but ~/.netrc instead

:-(, is it possible without .netrc

I thought questions have question marks. ;-)

Explanation 1: I wrote it to IRC and then thought maybe crossposting to 
the list would be no bad idea. On IRC i was not using question marks, 
mail was just copying the lines, forgot to add question marks.

Explanation 2: its not questions but accusations! *fg*

Anyway, what is the advantage of not using a ~/.netrc?

It's mentioned on several occations that it is not necessary (e.g. 
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt)

The advantages for me would be:

a) I have multiple different passwords on the same server for different 
directories, it's not possible to put this to a netrc (AS FAR AS I 
KNOW). So i have to edit the netrc for every push, clone, ... -> very 
inconvenient
b) secondly (maybe not a super valid argument for you): netrc is not 
considered to be the most secure thing, isn't it? Our network is invaded 
every year "tested" by thousands of computer science students, so i 
always try to have as few plain-text passwords as possible lying around 
(one never knows - yes netrc has 0600).

i'd also prefer not to use the user:pass@server schema, but to be asked, 
to not show pass in the history and config file in .git although even 
user:pass@server would be an advantage because it solves a).

Jürgen

The advantages for me would be:

a) I have multiple different passwords on the same server for different 
directories, it's not possible to put this to a netrc (AS FAR AS I 
KNOW). So i have to edit the netrc for every push, clone, ... -> very 
inconvenient
b) secondly (maybe not a super valid argument for you): netrc is not 
considered to be the most secure thing, isn't it? Our network is invaded 
every year "tested" by thousands of computer science students, so i 
always try to have as few plain-text passwords as possible lying around 
(one never knows - yes netrc has 0600).

i'd also prefer not to use the user:pass@server schema, but to be asked, 
to not show pass in the history and config file in .git although even 
user:pass@server would be an advantage because it solves a).

Valid solutions would therefore include:

* allow http://user@server urls, and ask user for password (A-rated)
* provide for http.basic.user and http.basic.pass in .git/config file 
(B-rated, one has to take care about the security of his config file)
* allow http://user:pass@server urls (C-rated, the consequences have 
been discussed on this list several times)

Jürgen