"hg archive" with remote URL

[Martin Geisler]

Mutlu Dogruel <mutludogruel at gmail.com> writes:

> On 9 Aug 2013, at 16:02, "Kastner Masilko, Friedrich" <kastner-masilko at at.festo.com> wrote:
>> 
>> Ah, I think I see your point now: you already have an SSH key on your
>> machine (for Chef to work), and you want to re-use that.
>> 
>> In this case the logs containing the password is not so big of a
>> problem if they have the same viewing rights as the .ssh files. The
>> key to get to the repo is already on the machine, so I think in terms
>> of security you are on par with the password method. IMHO there is no
>> difference between getting the password from a log and having the key
>> right there in the .ssh directory. But I can understand that you are
>> concerned about having them transmitted over the wire in first place.
>> 
>> That said, wget offers the possibility to use a file for
>> user/password settings. If you have to pre-install SSH keys on the
>> remote machine for Chef to work, how about pre-installing a
>> user/password file along with them? You could e.g. create a .wgetrc
>> like so:
>> 
>> user = CompanyChef
>> password = <Lets_just_use_some_hash_here>
>> 
>> and then issue this in the script:
>> 
>> wget https://bitbucket.org/company/secretrepo/get/tip.zip
>> 
>> I just tried that and it works like a charm. Maybe you can forward
>> such ideas to the BB team, who knows what clever solution they could
>> work out with them?
>> 
>> Regards,
>> Fritz
>
> Hiding the password is a good practice but eventually if you use this
> basic authentication, wget still sends the password in plain. In
> practice, there is no difference between supplying your password on
> the URL or wget reading it and sending it along the URL, apart from
> the fact that the command line history will not have any line with
> your password. Thus, you need to encrypt the password sent, otherwise
> any person sniffing your network will get hold of it.

That is not correct when you connect to a HTTPS URL. The client will
establish a secure connection before sending the username and password
to authenticate itself. It is correct that the password is sent in
cleartext inside the encrypted channel, but outside observers sniffing
the network cannot see it.

> The solution is to use a "digest access authentication" which is
> theoretically supported both by wget and curl.

Digest authentification helps you when you're connecting to HTTP
addreses. Basic auth sends the username and password in cleartext to the
server -- with digest auth the client sends a hashed version of the
password.

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130809/6d4d5719/attachment.asc>