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
