Re: [fossil-users] SSH client updates.
On Fri, Jul 12, 2013 at 3:15 AM, Matt Welland estifo...@gmail.com wrote: My vote is to go with the new behaviour only. More options usually means more pain - albeit after getting though any transition troubles. +1 -- - 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] SSH client updates.
On 2013-07-12 01:49, Andy Bradford wrote: Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 I prefer the new way and do remove the old way -- 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] SSH client updates.
Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 ___ 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] SSH client updates.
My vote is to go with the new behaviour only. More options usually means more pain - albeit after getting though any transition troubles. I am biased in this. The old method seemed brittle. However I haven't yet tested your new code. Hopefully I'll get a chance to do that next week some time. On Thu, Jul 11, 2013 at 4:49 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Rene on Thu, 11 Jul 2013 22:31:48 +0200: I would prefer to not have that option. test-http is for testing a new transport method. If you give someone read acces to your ssh repo then test-http circumvents that. In fact test-htp makes you while connected setup user I agree with you on this sentiment. Does this also mean, however, that you would prefer to remove the original clone behavior entirely? Right now, the original behavior is preserved by default: fossil clone ssh://amb@remote//tmp/test.fossil test.fossil Will invoke a remote shell via SSH, go through the echo/reply probes, and then finally launch ``fossil test-http /tmp/test.fossil''. Should this option be removed entirely? Should it be changed instead to go through the same echo/reply probes, but then finally call ``fossil http /tmp/test.fossil'' instead? Or should the default behavior be replaced with simply issuing a remote ``fossil http /tmp/test.fossil'' as I now do using the -h http option? My vote would be to remove the original behavior, and replace it with simply running a remote ``fossil http /tmp/test.fossil'' and not worry about shell issues. But, that does introduce one difference in behavior on clones---because the ``fossil http'' command outputs a Connection: close header in the response, each interaction during the clone will invoke a new SSH command. This isn't necessarily a problem for people who are using SSH keys, but you will be prompted for a password each time if you aren't using a key. This may not be so bad, however, because I believe autosync already behaves this way, so really, it's only the cloning operation that would change in behavior. Perhaps a poll is in order. Thanks for the feedback. Andy -- TAI64 timestamp: 400051df44b5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] SSH client updates.
Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. Originally, fossil would fork an SSH connection and then communicate with the remote shell by issuing shell commands to test that it has a working shell. This was accomplished by a series of echo/reply tests. Once it was decided that the shell was working, it would issue ``fossil test-http /path/to/repo.fossil'' and things would proceed from there. Is there value in keeping this old method? I personally don't see any, but then I don't have the background to know why it was done this way. Removing it would simplify the code, but perhaps break unforseen things. For now, I think it would be alright to leave it in as the default behavior just to be safe, despite the fact that it introduces multiple code paths. With that said, I hope the changes I've introduced will allow for a more flexible interaction with SSH. All of the critical changes are client side, so they will even work against older fossil instances. I've also added some improved logging of SSH connections which will only be useful when running a fossil http server that has the newer code. For example, after a Fossil user ``guest'' clones the repo to a local account ``amb'', makes some changes, and then commits them, while non-admin accounts will only see that ``amb'' commited some changes, the admin privileged accounts will actually see the following in the timeline: [f78758bc9c] Leaf: test (user: amb [guest], tags: trunk) And in the detailed info for the commit: Received From:guest @ 10.2.5.9 on 2013-07-10 06:52:50 I'm still debating on the value of the timeline change, but I think the detailed info is definitely valuable, as it shows the remote client's IP address (instead of just 127.0.0.1). The changes are still against version-1.26 (I used it as BASIS when I branched). I did a test merge against trunk and there were no conflicts. I'm not certain the changes are implemented in the best way, but they do work and they also allow for more restricted control using SSH keys. Specifically, now that I can restrict an SSH key to a specific command, I can also take advantage of the fossil Privileges and Capabilities (even though the user has write access to the file), which seems to work correctly. In the following example, on remote, the guest user has rw access to the remote fossil file, but is only setup as a Reader in the fossil repo: remote$ ls -l test.fossil -rw-rw 1 amb guest 58368 Jul 10 00:19 test.fossil Now I clone from the local system: local$ fossil clone -h http ssh://guest@remote//tmp/test.fossil test.fossil password for guest: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil Round-trips: 2 Artifacts sent: 0 received: 9 ssh -e none -T guest@remote fossil http /tmp/test.fossil Round-trips: 2 Artifacts sent: 0 received: 12 Clone finished with 549 bytes sent, 2344 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 9ababc8b9a3e0b97d3da4467aa4effbad24d91c2 admin-user: amb (password is e0b973) Now I'll open and try to modify something but it will be rejected because guest does not have permissions (Reader only): local$ fossil commit -m test Autosync: ssh://guest:*@remote//tmp/test.fossil Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil Round-trips: 1 Artifacts sent: 0 received: 0 Pull finished with 350 bytes sent, 480 bytes received New_Version: 783a69e327649a5942c1bad7134986a3adb1704a Autosync: ssh://guest:*@remote//tmp/test.fossil Round-trips: 1 Artifacts sent: 2 received: 0 ssh -e none -T guest@remote fossil http /tmp/test.fossil Error: not authorized to write Round-trips: 1 Artifacts sent: 2 received: 0 Sync finished with 736 bytes sent, 512 bytes received Autosync failed ^^^ Guess it didn't work out. Let's try to delete the file: local$ ssh guest@remote rm /tmp/test.fossil HTTP/1.0 501 Not Implemented Date: Wed, 10 Jul 2013 06:44:06 GMT Connection: close X-Frame-Options: SAMEORIGIN Cache-control: no-cache Content-Type: text/html; charset=utf-8 Content-Length: 52 htmlbodyUnrecognized HTTP Request/body/html Nope, no go, key says I can only do fossil http /tmp/test.fossil. Anyway, that's where I'm at with the changes. Also, I'm not sure that where I setup the signal ignore for SIGPIPE was in the correct place, however, without it, fossil kept failing with SIGSEGV when the remote SSH connection closed the connection. Some guidance there would be of value. With that said, attached is an updated patch against version-1.26 for review if anyone is interested. Definitely needs more testing than I have been able to give it. Andy
Re: [fossil-users] SSH client updates.
On Wed, Jul 10, 2013 at 9:51 AM, Andy Bradford amb-fos...@bradfords.orgwrote: ... Is there value in keeping this old method? I personally don't see any, but then I don't have the background to know why it was done this way. If i'm not sorely mistaken, the current approach was done because it was quick and easy to add. ssh was added relatively late in Fossil's development (and i've never used it - the CGI interface gives me everything i need), and almost certainly piggybacked on as much connection-related code as it could. Removing it would simplify the code, but perhaps break unforseen things. For now, I think it would be alright to leave it in as the default behavior just to be safe, despite the fact that it introduces multiple code paths. i would have thought that it leads to fewer code paths (no ssh-specific server component, for example). ... The changes are still against version-1.26 (I used it as BASIS when I branched). I did a test merge against trunk and there were no conflicts. I'm not certain the changes are implemented in the best way, but they do work and they also allow for more restricted control using SSH keys. Very little has changed in the trunk since then, so i wouldn't expect any conflicts. -- - 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] SSH client updates.
On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. -- Martin G. ___ 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] SSH client updates.
On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Is nobody allowed to clone on your repo? -- 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] SSH client updates.
On Wed, Jul 10, 2013 at 10:32:26PM +0200, Rene wrote: On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Cloning the repo work with orignal fossil using http:// protocol, so nobody can clone it.. Here some experiments: - try 1: normal fossil, clone throught http: - me@myserver(~/test) $ fossil clone http://10.0.0.1/repo/common common1.fossil Round-trips: 12 Artifacts sent: 0 received: 3120 Clone finished with 2888 bytes sent, 75949538 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 6e3c63) - try 2: normal fossil, clone throught ssh: - me@myserver(~/test) $ fossil clone ssh://me@10.0.0.1//fossil/common.fossil common2.fossil ssh -e none -T me@10.0.0.1 me@10.0.0.1's password: Round-trips: 12 Artifacts sent: 0 received: 3157 Clone finished with 2994 bytes sent, 75953950 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 4ff602) - try 3: patched fossil, clone throught ssh: - (Notice on output that it ask password on same line as sync status output, but we can see that artifact received and sent are 0) $ fossil2 clone ssh://me@10.0.0.1//fossil/common.fossil common3.fossil ssh -e none -T me@10.0.0.1 fossil http /fossil/common.fossil me@10.0.0.1's password: nt: 0 received: 0 Now, if I list my 3 cloned repos: (common3.fossil have the journal file and is a lot smaller that it should be..) me@myserver(~/test) $ ls -ltrh total 336800 -rw-r--r-- 1 me me 79.7M Jul 10 17:11 common.fossil -rw-r--r-- 1 me me 79.7M Jul 10 17:13 common2.fossil -rw-r--r-- 1 me me 14.5K Jul 10 17:13 common3.fossil-journal -rw-r--r-- 1 me me 4.7M Jul 10 17:13 common3.fossil -- Martin G. ___ 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] SSH client updates.
On Wed, Jul 10, 2013 at 05:24:29PM -0400, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 10:32:26PM +0200, Rene wrote: On 2013-07-10 21:31, Martin Gagnon wrote: On Wed, Jul 10, 2013 at 01:51:05AM -0600, Andy Bradford wrote: Folks, As I mentioned before, I've been attempting some modifications to the fossil SSH URL handling. I'm at a point where I could use some feedback regarding the previous method for handling SSH. [snip] I like the idea to have new ssh implementation that don't depend on shell and to have capability to use ssh protocol without using accounts with shell access. But I think there's still have some work and test that need to be done on this implementation. I tried your patch, I don't know if I'm missing something but it doesn't work for me... I made a simple test in the same way I was using ssh:// protocol before, without using SSH keys restrictions and I got following results: 1- Some new line are missing when asking for password, so I'm typing password over the first line of sync status output. (I guess this is not a problem when using ssh keys but output should still be correct when using password) 2- Clone return with no warning or error right away with 0 artifact sent and 0 artifact received and I end up with a empty fossil file and a fossil-journal file.. (On OpenBSD 5.3 amd64) Exact same command with non-patched fossil work. On linux (arch) it works. Now if i lower my credentials i'm not allowed to write! I had no problem typing the password. even if i botch my first one! fossil clone ssh://renez@arch:22/src/fossil/myclone.fossil?fossil=bin/fssh new2.fsl ssh -e none -T renez@arch renez@arch's password: Permission denied, please try again. renez@arch's password: Round-trips: 6 Artifacts sent: 0 received: 21510 Clone finished with 1592 bytes sent, 28967314 bytes received Killed by signal 2. Rebuilding repository meta-data... 100.0% complete... project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333 admin-user: renez (password is 4b8994) Cloning the repo work with orignal fossil using http:// protocol, so nobody can clone it.. Here some experiments: - try 1: normal fossil, clone throught http: - me@myserver(~/test) $ fossil clone http://10.0.0.1/repo/common common1.fossil Round-trips: 12 Artifacts sent: 0 received: 3120 Clone finished with 2888 bytes sent, 75949538 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 6e3c63) - try 2: normal fossil, clone throught ssh: - me@myserver(~/test) $ fossil clone ssh://me@10.0.0.1//fossil/common.fossil common2.fossil ssh -e none -T me@10.0.0.1 me@10.0.0.1's password: Round-trips: 12 Artifacts sent: 0 received: 3157 Clone finished with 2994 bytes sent, 75953950 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: fae69cd7d6c31a88295fa9c9d984b9483faac0ac admin-user: me (password is 4ff602) - try 3: patched fossil, clone throught ssh: - (Notice on output that it ask password on same line as sync status output, but we can see that artifact received and sent are 0) $ fossil2 clone ssh://me@10.0.0.1//fossil/common.fossil common3.fossil ssh -e none -T me@10.0.0.1 fossil http /fossil/common.fossil me@10.0.0.1's password: nt: 0 received: 0 Now, if I list my 3 cloned repos: (common3.fossil have the journal file and is a lot smaller that it should be..) me@myserver(~/test) $ ls -ltrh total 336800 -rw-r--r-- 1 me me 79.7M Jul 10 17:11 common.fossil -rw-r--r-- 1 me me 79.7M Jul 10 17:13 common2.fossil -rw-r--r-- 1 me me 14.5K Jul 10 17:13 common3.fossil-journal -rw-r--r-- 1 me me 4.7M Jul 10 17:13 common3.fossil -- Martin G. Sorry, *my* mistake.. I didn't notice the new version of the patch on latest Andy Bradford email. My test was made with the previous patch. Work fine now.. sorry for the noise.. -- Martin G. ___ 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] SSH client updates.
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400: Sorry, *my* mistake.. I didn't notice the new version of the patch on latest Andy Bradford email. My test was made with the previous patch. Not a problem. I should probably setup a fossil clone that can be accessed, rather than sending patches (I'll get there eventually). I was about to respond mentioning that your output was consistent with the first version of the patch. Looks like you got it figured out. Andy -- TAI64 timestamp: 400051ddf557 ___ 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] SSH client updates.
Thus said Martin Gagnon on Wed, 10 Jul 2013 17:50:40 -0400: Work fine now.. sorry for the noise.. Speaking of noise, time to add a little more (because my original email wasn't quite long enough). The new options that I've added are not yet fully documented in the usage/help (not having settled on how to access the changes in client). At the moment, you can specify which type of HTTP access to use (test-http vs http): fossil clone -h http ssh://amb@remote//tmp/test.fossil test.fossil Or if you prefer the old method (this option may be redundant): fossil clone -h test-http ssh://amb@remote//tmp/test.fossil test.fossil Path to fossil can be made explicit: fossil clone -f /opt/bin/fossil -h http ssh://amb@remote//tmp/test.fossil test.fossil Of course, if force command SSH keys are in use, it doesn't really matter what is specified because that will be controlled by the remote SSH account, in which case you might want to explicitly set the ssh command (in the even that the SSH key is different from your default SSH key): fossil clone -s 'ssh -e none -T -i /home/amb/.ssh/fossil' ssh://amb@remote//tmp/test.fossil test.fossil I wasn't certain if this was the right location to do this; can a repository specific SSH command be configured prior to cloning the repository? All of these options are also exposed in sync/push/pull (in the event that it needs to be changed). Andy -- TAI64 timestamp: 400051ddf842 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
