I've been using basic auth over https for quite a while now. In my deployment it's undesirable to use fossil's built in password storage mechanism because I have other services running behind the http server and on the server side it's convenient to have 1 password back-end for ssh / http / various other things. I rely on the remote user option when creating fossil repositories and delegate the credential checking to the http server.
On the client side I don't like specifying the username and password on the command line. I brought up using gnome-keyring / osx-keychain support not long ago on this list and based on feedback I convinced myself I wanted fossil to do things that was probably not realistic to support on all the various platforms fossil runs on. I think this thread is just re-asking the same question I had. That is, "How do I better handle user credentials on the client when the server is configured to use the HTTP basic auth protocol?" Maybe supporting gnome/mate keyring or the osx keychain isn't so unrealistic. In my hacked up version of fossil if I get a 401 response and the protocol is https it prompts me for a username + password then stores them in the system keychain using the full URL as the index. In the global fossil settings DB I save the URL and add a key to the effect of "go grab credentials from the keychain and send them as a basic auth header from now on if the requested url is https" The next time I run fossil and the "use keychain" flag is set it looks stuff up in the keychain and just works. And, I don't need to have any funny characters in the password or specify extra command line args. It'd be really nice to have an officially supported compile time option of "--use-keychain" to enable some very basic platform integration. It's nice that fossil is so "stand alone" but it's also not nice at times. Regards, Dave On Mon, Feb 3, 2014 at 1:21 PM, Ron Wilson <ronw.m...@gmail.com> wrote: > On Sat, Feb 1, 2014 at 1:29 PM, Andy Bradford <amb-fos...@bradfords.org>wrote: > >> Thus said "Andy Bradford" on 01 Feb 2014 10:04:23 -0700: >> >> > Thus said Kevin Martin on Sat, 01 Feb 2014 09:14:20 +0000: >> > >> > > How does fossil authenticate with a server, does it send the >> > > password plaintext? HTTP Basic Auth does! >> > >> > It's not encrypted, no, only base64 encoded. >> >> It seems I misunderstood what Mr. Martin was asking here. Fossil uses a >> nonce and the password and sends only the SHA1 hash across the wire: >> >> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki >> > > There are some caveats mentioned in the documentAndy linked to, that you > should pay attention to: > > 1. When a user logs into Fossil using the web interface, the login name > and password are sent in the clear to the server. > > 2. If the USER.PW on the server holds a cleartext password, then the > server will also accept a login-card signature that is constructed using > either the cleartext password .... > > The second item relates to compatability with older clients. Although it > is unlikely anyone is still using Fossil versions that old (older than > 010-01-11<http://www.fossil-scm.org/index.html/timeline?c=2010-01-10+20:56:30>), > an old enough repository could possibly have cleartext passwords, so I > would recomend converting the passwords as described in the document. > > Also, from reading the description of the sync protocol, I'm not sure how > safe the nounce is. The calculation appears to not make use of the current > time nor other value reasonably unique to the session. > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
