Re: [fossil-users] ssl implementation
On 11/08/2013, at 10:49 PM, Chad Perrin wrote: Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the thanks is my general response for everything to which I do not specifically respond below. Specific comments follow. On Sun, Aug 11, 2013 at 01:21:37PM +0200, Rene wrote: On 2013-08-10 04:21, Chad Perrin wrote: On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: The reason I choose axTLS . . . snip . . . If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? No there isn't. I used the information from http://axTLS.sf.net to create the fossil interface. I hadn't been able to find any. I'm glad it's not just me who couldn't find them, but at the same time bummed that it means you can't suggest any for me. Bit of a quandary, there. Having read your question about team setup on freebsd, My recommendation is to go with ssh keys. That's my plan. My interest in axTLS is actually mostly unrelated to Fossil, though I support there being options other than OpenSSL or GnuTLS. In fact, both OpenSSL and (especially) GnutTLS have license compatibility problems that frankly annoy the crap out of me, and axTLS licensing neatly solves that if it also solves the technical needs of a project. I'll just chime in that we use axTLS as the SSL implementation for our embedded web server with great success. Much smaller and simpler than openssl. I can highly recommend it. Also, the author, Cameron Rich lives here in Brisbane, Australia! Cheers, Steve -- Embedded Systems Specialists - http://workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 02:58:56PM -0600, Andy Bradford wrote: Hopefully that clarifies. Yeah . . . especially considering I thought he was referring to problems with the approach I am using right now, rather than the approach you're developing, when he started talking about logging issues. I'm pretty clear on how things work with regard to logging now, for both SSH scenarios, at any rate. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On 2013-08-10 04:21, Chad Perrin wrote: On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: The reason I choose axTLS . . . snip . . . If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? No there isn't. I used the information from http://axTLS.sf.net to create the fossil interface. on unix you can do make menuconfig and everything it provide can be selected. The writer Cameron Rich is responsive when asked questions. As to the protocol (http://en.wikipedia.org/wiki/Transport_Layer_Security) looking at ths table: Protocol version Website support Security SSL 2.0 27.4% Insecure SSL 3.0 99.7% Depends on cipher and depends on patching with RFC 5746 TLS 1.0 99.3% Depends on cipher TLS 1.1 14.5% Depends on cipher TLS 1.2 17.0% Depends on cipher It seems not to be a problem In testing I used fossil clone https://fossil-scm.org/ and I cloned via my own internal Apache web server I checked yesterday and you can build on windows with msc and cygwin. The documentation states that you always needs GnuMake (also under windows, The cygwin environment is used to build a config executable (make config or menuconfig But then you need the curses library). After that the config is started and you have your choice of build environment. As I stated before my frustration came from setting up openss[hl] on windows and Solaris. Therefore I looked at this option. Having read your question about team setup on freebsd, My recommendation is to go with ssh keys. Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. I have been looking at abusing the current ssh where users are elevated to the highest user level within fossil. I found it surprisingly difficult to get the tunnels to setup and talk to the fossil process I thought of socat but that is not something you pick of the net and use :-(. If your ssh package is flawed (You have a much bigger problem) or an unauthorized person got a hold of a ssh key or you have a rogue user (in al 3 cases they have access to test-http) I assume(BUT CAN NOT PROVE) that it is possible to look at the fossil source and craft a package that could rearrange your setup over ssh. Why someone would want that is beyond me! (AGAIN it is very possible that I'm completely wrong here!) Andy's patch will mean that you have to login into ssh and fossil. It means you have to administrate the users in fossil also. While in the standard the ssh key is enough. If you have a separation of jobs with different capabilities in fossil and you want to enforce them you need andy's patch -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the thanks is my general response for everything to which I do not specifically respond below. Specific comments follow. On Sun, Aug 11, 2013 at 01:21:37PM +0200, Rene wrote: On 2013-08-10 04:21, Chad Perrin wrote: On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote: The reason I choose axTLS . . . snip . . . If this is of interest I can add it on a branch. I find it pretty interesting. The biggest problem I see with axTLS is the protocol support limitation you identified. Are there good howtos for using axTLS out there on the web somewhere? No there isn't. I used the information from http://axTLS.sf.net to create the fossil interface. I hadn't been able to find any. I'm glad it's not just me who couldn't find them, but at the same time bummed that it means you can't suggest any for me. Bit of a quandary, there. Having read your question about team setup on freebsd, My recommendation is to go with ssh keys. That's my plan. My interest in axTLS is actually mostly unrelated to Fossil, though I support there being options other than OpenSSL or GnuTLS. In fact, both OpenSSL and (especially) GnutTLS have license compatibility problems that frankly annoy the crap out of me, and axTLS licensing neatly solves that if it also solves the technical needs of a project. Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On 2013-08-11 14:49, Chad Perrin wrote: Thanks for all your information about issues related to axTLS. Not everything you said warrants a specific response from me, but the thanks is my general response for everything to which I do not [snip] Much simpler provided that all you need/want is cmdline access. With the standard ssh functionality you can get by. The only minor thing in that setup is that the log is not recording the user that did clone/sync/pull/push but the fossil owner. I quess that is easy enough to fix. But do use forced commands otherwise people can gain access to the fossil account. If you so wish to prevent logins. Or prevent logins by using the shell /bin/nologin. Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. And in a single user setup that makes sense. In most cases a ssh key has a 1 on 1 relation with the unix account. In which case having the ssh key is OK and login in to fossil is redundant. And since you are the owner of that account. You already have the highest level of capabilities. Logging the owner makes perfect sense because of this 1 on 1 relationship However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 3:24 PM, Rene renew...@xs4all.nl wrote: However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. One of the devs (Andy?) has been working on integrating ssh forced commands with fossil so that ssh connections can use fossil's authentication. i'm not sure what the status of that is, but from what i've read it sounds like a promising solution. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On 2013-08-11 15:26, Stephan Beal wrote: On Sun, Aug 11, 2013 at 3:24 PM, Rene renew...@xs4all.nl wrote: However If your going to break that relation by having n keys on 1 account then, I presume, your doing something with fossil which wasn't designed. One of the devs (Andy?) has been working on integrating ssh forced commands with fossil so that ssh connections can use fossil's authentication. i'm not sure what the status of that is, but from what i've read it sounds like a promising solution. -- - stephan beal http://wanderinghorse.net/home/stephan/ [1] http://gplus.to/sgbeal [2] Links: -- [1] http://wanderinghorse.net/home/stephan/ [2] http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users It is. I have been testing it. As I said if you have a multi user project with different job responsibilities and you want to maintain that in fossil then you need andy's patch! -- Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote: On 2013-08-11 14:49, Chad Perrin wrote: Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. Ah, okay. I thought you meant the Fossil user account for a moment there. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ] ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ssl implementation
Thus said Chad Perrin on Sun, 11 Aug 2013 10:10:40 -0600: On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote: On 2013-08-11 14:49, Chad Perrin wrote: Err . . . wait. Is it not logging the *user*, or just the IP address? What would it log in place of the actual authenticated Fossil user account that initiated the sync? The user in the current ssh functionality is not authenticated against fossil. Ah, okay. I thought you meant the Fossil user account for a moment there. What he meant was this..., when you do the following: fossil clone ssh://chad@freebsdhost/fossils/project.fossil project.fossil There is no Fossil authentication that happens in this interaction. It is presumed that because you have SSH access to the file, that you also have Fossil access to the file. So the only entry that will show up in the log for chad is chad. This is fine, and it will probably even work if you want to give out an SSH account for each user that you want to access the fossil as long as the permissions on the fossils are correctly setup for Unix groups. But if you want to have a single SSH account under which to aggregate the fossils, then you won't be able to do it yet, because all access to the fossils would appear to be logged in from the exact same user. All that being said, this is not how you are currently planning on setting up. There, you are simply using SSH as a tunnel/proxy to get you to the Fossil daemon listening on port . Then you do: fossil clone http://chad@localhost:/project project.fossil And it will prompt you for Fossil user chad's credentials because it is not using SSH as the transport per se. Hopefully that clarifies. Andy -- TAI64 timestamp: 40005207fb33 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ssl implementation
I have been running fossil on 3 platforms windows, linux and solaris.
Setting up openssl can be a major hassle.
I have used axTLS (http://axtls.sf.net) to create an interface
compatible src/http_ssl.c. (I still struggle with X509 certificates).
The reason I choose axTLS
1) BSD style licensing
2) Size the source tree is 3.2M. Which is the same size as zlib.
3) It has, an optional, https Server axhttps include in the source tree
4) It support out of the box Windows(cygwin, Microsoft), BSD, linux and
Solaris
5) No dependencies on other libraries, only needs a c compiler to build.
Possible downsides are:
1) it only support TLSv1.0/1.1
2) Mingw is not supported. But you can do cygwin with option -mno_cygwin
(I have been told :-).
3) I'm not sure if this is a downside
axTLS has language bindings to a number of scripting languages but not
TCL.
I have not (yet) integrated it in the build tools.
Although I have been mucking around with http_${SSL_LIBRARY}.c.
That gave me the impression that adding this to the build system is
fairly easy.
If this is of interest I can add it on a branch.
--
Rene
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
