Re: [fossil-users] New command proposal?
Thus said David Mason on Thu, 25 Jul 2013 18:16:08 -0400: command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... where the name after gate defines the fossil user that this represents, and the ... are the public keys from the particular users. Should this instead represent/identify the remote SSH client? Cannot a remote SSH client have multiple Fossil usernames that might be spread out among the many potential fossils that will live in ~fossilcm/fossils? Also, do you consider it important for the ``fossil gate'' command to impose additional restrictions based upon the username listed? For example, given an entry: command=/home/fossilcm/bin/fossil gate otheruser ssh-rsa ... Would the gate prevent otheruser from even attempting to access a subset of all the possible fossils in ~fossilcm/fossil? (see below for an example) fossil clone ssh://fossilcm@fossilhost/one.fossil one.fossil and it would only validate against the public key that that user has. This way the remote user can't access any files other than the fossils in that directory. This part, at least, can be accomplished already using this branch: http://www.fossil-scm.org/index.html/timeline?r=ssh-shared-account And the following simple shell script: $ cat fossilgate.sh #!/bin/sh set -- $SSH_ORIGINAL_COMMAND while [ $# -gt 1 ]; do shift; done exec /usr/local/bin/fossil http ./fossils/$1 Of course key management is manual (as you suggested would be the case in the simple setup). There are no file level restrictions in place (as I asked above), only Fossil Privileges and Capabilities. Basically, this allows one to configure a command: command=./fossilgate.sh,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ... And then one can clone using: $ fossil clone -l amb ssh://fossilcm@remote/one.fossil one.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http one.fossil Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 536 bytes sent, 1154 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: f4e6229ef4d633a47de719d7bcea81704e746cc9 admin-user: amb (password is 9fdd1d) If one wanted to extend it further to do fossil name based checking: command=./fossilgate.sh otheruser,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa ... $ cat fossilgate.sh #!/bin/sh SSHUSER=$1 set -- $SSH_ORIGINAL_COMMAND while [ $# -gt 1 ]; do shift; done if grep ^$1\$ ./$SSHUSER.fossils /dev/null then exec /usr/local/bin/fossil http ./fossils/$1 fi echo INVALID FOSSIL $1 REQUESTED FOR $SSHUSER 2 And if I try to access something that is not in ./otheruser.fossils, I'll get an error: $ fossil clone -l amb ssh://fossilcm@remote/two.fossil two.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http two.fossil INVALID FOSSIL two.fossil REQUESTED FOR otheruser server did not reply And in the case where fossil name restrictions apply, and I request an allowed fossil, Fossil Privileges still apply: $ fossil clone -l amb ssh://guest@remote/three.fossil three.fossil password for amb: remember password (Y/n)? y Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T guest@remote fossil http three.fossil Round-trips: 2 Artifacts sent: 0 received: 1 Error: login failed missing or incorrect password for user amb How far is this from what you think would be useful at this point? Andy -- TAI64 timestamp: 400051f6065a ___ 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] New command proposal?
Thus said Alan Barrett on Mon, 29 Jul 2013 08:29:37 +0200: Regardless of whether this is a good idea or not, please do not call it fossil gate. Please give it a name that alerts the user to the fact that it's very closely tied to ssh. Understood. At this point, it is really just a concept (even though I have a working example). I'm not even sure that the tool should be part of fossil proper, since it really falls outside the realm of SCM and doesn't really need fossil to do its work. So it can be called whatever makes sense. I imagine, also, that there might be any number of similar tools that crop up doing similar things, but perhaps with different restrictions. Andy -- TAI64 timestamp: 400051f60fe0 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New precompiled-binary for Mac uploaded
I have recompiled the Mac binary for 1.26 on 10.5.8 with the --disable-lineedit option. Hopefully this new binary will work for everybody. Please write to this mailing list (not as a ticket!) if you encounter problems. -- D. Richard Hipp d...@sqlite.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] Unshun: CSRF attempt error
On 7/28/2013 13:47, Marc Simpson wrote: Output: Cross-site request forgery attempt. That's a browser-specific feature, not something Fossil does. It may be that Fossil could work differently to avoid triggering this browser security feature, but ultimately it's a false positive. What browser are you running, and what security-related plugins do you have loaded into it, if any? Have you tried a different browser? ___ 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] Unshun: CSRF attempt error
On Mon, Jul 29, 2013 at 4:03 PM, Warren Young war...@etr-usa.com wrote:
On 7/28/2013 13:47, Marc Simpson wrote:
Output: Cross-site request forgery attempt.
That's a browser-specific feature, not something Fossil does. It may
be that Fossil could work differently to avoid triggering this browser
security feature, but ultimately it's a false positive.
Please, don't mislead other people. CSRF is a Web vulnerability that
Browsers can't prevent yet. So it is normally handled on the server
side. Check Fossil's sources (src/login.c):
/*
** Before using the results of a form, first call this routine to verify
** that this Anti-CSRF token is present and is valid. If the
Anti-CSRF token
** is missing or is incorrect, that indicates a cross-site scripting attach
** so emits an error message and abort.
*/
void login_verify_csrf_secret(void){
if( g.okCsrf ) return;
if( fossil_strcmp(P(csrf), g.zCsrfToken)==0 ){
g.okCsrf = 1;
return;
}
fossil_fatal(Cross-site request forgery attempt);
}
Regards.
--
Isaac Jurado
The noblest pleasure is the joy of understanding
Leonardo da Vinci
___
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] Unshun: CSRF attempt error
On Mon, Jul 29, 2013 at 3:03 PM, Warren Young war...@etr-usa.com wrote: On 7/28/2013 13:47, Marc Simpson wrote: Output: Cross-site request forgery attempt. That's a browser-specific feature, not something Fossil does. It may be that Fossil could work differently to avoid triggering this browser security feature, but ultimately it's a false positive. No, it's not. What browser are you running, and what security-related plugins do you have loaded into it, if any? Have you tried a different browser? I originally ran into this problem on Firefox 22; reproducible in Chrome 28. A CSRF error shouldn't be generated at all when I'm running everything locally (via 'fossil ui'). ___ 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] Linux/Windows USB
On Sat, Jul 27, 2013 at 2:26 PM, henk harmsen h...@carbonmetrics.comwrote: Thanks! The solution that was easiest to implement was to keep just the repo on the USB and make checkins on each platform. i'm a bit late to the party here, and didn't realize that this had already been resolved, but i wanted to confirm what you have apparently already seen. Since you know that already, i'll just add an historical anecdote to it: if memory serves me correctly (it doesn't always do that), the relative path support was added explicitly for this particular use case when someone reported this same use case a couple years ago. -- - 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] Unshun: CSRF attempt error
On Sun, Jul 28, 2013 at 9:47 PM, Marc Simpson m...@0branch.com wrote:
It seems that unshunning is currently broken. To reproduce:
(1) Create a test repository,
$ fsl version
This is fossil version 1.26 [a60b008f1a] 2013-07-26 15:46:01 UTC
$ fsl new tmp.fsl
$ mkdir tmp; cd tmp
$ fsl open ../tmp.fsl
$ touch a
$ fsl add a; fsl commit -m a a
$ fsl ui
(2) Shun commit 'a' via [Admin Shunned] in the UI.
(3) Click on the newly shunned artifact and attempt to [Unshun].
Output: Cross-site request forgery attempt.
A bug indeed. Here's a possible fix:
Index: src/info.c
==
--- src/info.c
+++ src/info.c
@@ -1427,11 +1427,11 @@
if( !g.perm.Read ){ login_needed(); return; }
if( rid==0 ) fossil_redirect_home();
if( g.perm.Admin ){
const char *zUuid = db_text(, SELECT uuid FROM blob WHERE rid=%d, rid);
if( db_exists(SELECT 1 FROM shun WHERE uuid='%s', zUuid) ){
- style_submenu_element(Unshun,Unshun, %s/shun?uuid=%ssub=1,
+ style_submenu_element(Unshun,Unshun,
%s/shun?accept=%ssub=1#accshun,
g.zTop, zUuid);
}else{
style_submenu_element(Shun,Shun, %s/shun?shun=%s#addshun,
g.zTop, zUuid);
}
@@ -1577,11 +1577,11 @@
if( !g.perm.Read ){ login_needed(); return; }
if( rid==0 ) fossil_redirect_home();
if( g.perm.Admin ){
const char *zUuid = db_text(, SELECT uuid FROM blob WHERE rid=%d, rid);
if( db_exists(SELECT 1 FROM shun WHERE uuid='%s', zUuid) ){
- style_submenu_element(Unshun,Unshun, %s/shun?uuid=%ssub=1,
+ style_submenu_element(Unshun,Unshun,
%s/shun?accept=%ssub=1#accshun,
g.zTop, zUuid);
}else{
style_submenu_element(Shun,Shun, %s/shun?shun=%s#addshun,
g.zTop, zUuid);
}
@@ -1685,11 +1685,11 @@
rid = name_to_rid_www(name);
if( rid==0 ){ fossil_redirect_home(); }
zUuid = db_text(, SELECT uuid FROM blob WHERE rid=%d, rid);
if( g.perm.Admin ){
if( db_exists(SELECT 1 FROM shun WHERE uuid='%s', zUuid) ){
- style_submenu_element(Unshun,Unshun, %s/shun?uuid=%ssub=1,
+ style_submenu_element(Unshun,Unshun,
%s/shun?accept=%ssub=1#accshun,
g.zTop, zUuid);
}else{
style_submenu_element(Shun,Shun, %s/shun?shun=%s#addshun,
g.zTop, zUuid);
}
Index: src/shun.c
==
--- src/shun.c
+++ src/shun.c
@@ -133,20 +133,21 @@
@ input type=text name=uuid value=%h(PD(shun,)) size=50 /
@ input type=submit name=add value=Shun /
@ /div/form
@ /blockquote
@
+ @ a name=accshun/a
@ pEnter the UUID of a previous shunned artifact to cause it to be
@ accepted again in the repository. The artifact content is not
@ restored because the content is unknown. The only change is that
@ the formerly shunned artifact will be accepted on subsequent sync
@ operations./p
@
@ blockquote
@ form method=post action=%s(g.zTop)/%s(g.zPath)div
login_insert_csrf_secret();
- @ input type=text name=uuid size=50 /
+ @ input type=text name=uuid value=%h(PD(accept, )) size=50 /
@ input type=submit name=sub value=Accept /
@ /div/form
@ /blockquote
@
@ pPress the Rebuild button below to rebuild the repository. The
Regards.
--
Isaac Jurado
The noblest pleasure is the joy of understanding
Leonardo da Vinci
___
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 changes ready?
Hello, Many thanks to those who have provided feedback and suggestions for how to improve the SSH transport for ssh:// URLs. Is there anything else left to be done (specifically for what is required to be directly in Fossil) regarding the SSH transport changes? I've tested it with a few upgrade scenarios and here is a sample of what will be seen when using the new binary with an already open fossil. This fossil was opened using version-1.22 and then updated with the new SSH changes: $ f ver This is fossil version 1.26 [021e41014d] 2013-07-27 21:09:30 UTC $ f up Autosync: ssh://amb:*@remote//tmp/orig.fossil Round-trips: 1 Artifacts sent: 0 received: 0 ssh -e none -T amb@remote fossil http /tmp/orig.fossil Error: login failed password for amb: remember password (Y/n)? y Round-trips: 2 Artifacts sent: 0 received: 0 Pull finished with 695 bytes sent, 745 bytes received --- checkout: 51a93acd1a06a336554b6714f38d47d2a81c8f96 2013-07-30 03:54:39 UTC tags: trunk comment: four (user: amb) changes: None. Already up-to-date Notice that it prompted me for the Fossil user password because the one it had stored in the local settings DB is no longer correct. In cases where the password is the same as the SSH account, then this won't present a password prompt because it will succeed. I suspect that most SSH users probably did not set their Fossil user password because there was no need---given that the remote command was essentially fossil test-http. Are there any other areas that should be tested heavily? Someone want to spot check the code for glaring no-no's? Summary of changes: Changed default SSH remote command to ``fossil http /path/to/fossil'' which eliminates any dependency on shells on the server side. This also means that Fossil Privileges and Capabilities will now be imposed upon the account used to clone/sync the fossil. Added additional support for separate Fossil user vs SSH user to allow for more flexibility when using SSH as transport. This will enable shared accounts (useful when using SSH keys) so Fossils can be aggregated under a single account. Traditional shared access is still possible (this is the default behavior) as long as Unix groups and permissions allow read/write access to the fossil. Added additional support to fossil http to recognize the remote SSH client (via SSH_CONNECTION environment variable). This helps identify the source of changes in artifacts. Enhanced the parsing of SSH URLs by ignoring a missing port and not failing (thanks Rene). Made the sync output less verbose (thanks Martin Gagnon). Eliminated the -pw option on Windows (primarily a plink.exe option) since it doesn't really make sense anymore as SSH authentication is no longer handled by fossil. Eliminated the use of test-http for ssh:// URLs (inherent to first item). Eliminated the test-ssh-far-side command since it is really not needed now. Hopefully I haven't missed anything... To see all relevant changes: http://www.fossil-scm.org/index.html/vdiff?from=a60b008f1a01a383to=021e41014d69a67bsbs=1 Thanks, Andy -- TAI64 timestamp: 400051f749fb ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
