[fossil-users] Help needed: fossil clone user authentication does not seem to work over ssh
Hi List, I am trying to clone a repository over ssh complete with all the private branches by means of $ fossil clone --private ssh://username:pass@hostname/path-to-Repo my.fossil Prior to doing that I set Private flag for username on the remote repo using the web interface. The clone operation fails with the message: Error: not authorized to sync private content However, when I enable Private flag on user nobody everything works as expected. It makes me think that somehow my clone session is always conducted as a nobody on remote server. Is there anyway to trace/debug fossil user credentials on the remote end, some sort of verbose/debug output? --Leo-- ___ 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] Help needed: fossil clone user authentication does not seem to work over ssh
Hi Leo and everybody else. I am not an avid poster online, (and English is not my native language) so please bear with me. I have also had a problem cloning over an ssh connection. Each time I've got the response: [...] Error: not authorized to clone [...] fossil: server returned an error - clone aborted I am 99.99% certain that I connected with the right username and password of a user with clone rights, as I am able to clone via http with the same user. On Mon, 06 Feb 2012 12:05:47 +0100, Leo Razoumov slonik...@gmail.com wrote: However, when I enable Private flag on user nobody everything works as expected. It makes me think that somehow my clone session is always conducted as a nobody on remote server. My problem also disappeared when I allowed clone-rights to 'Nobody'. This suggest that Leo Razoumov's observations are valid: ssh-connections only infer the 'nobody' rights. This is not the expected behavior, i think. I would expect, using a ssh-connection, that I might have the 'local-/super-user' rights, or at least the rights set for the username (eg. clone + some others). Have I (unwittingly) messed something up? I think this might be related to another issue with the cli-design. It is not obvious how to specify a username to clone with that is different from the username with which to make the ssh-connection. (I guess you could specify the username in 'fossil setting ssh-command'.) This is a design error, not at least because of the password requests. E.g. 2 password requests when only one username is given to the fossil clone command. The only difference is that the second request specifies the (remote) domain (which means this is the ssh password request). Kind regards, Sverre ___ 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] Derived code, not to be pushed public
On Feb 5, 2012, at 20:47 , Lluís Batlle i Rossell wrote: But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. A lot of care to only pull towards the derivatives? Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] BUG: clone/pull/push over SSH always use nobody privileges
Hi Richard, It seems that clone/push/pull over ssh ignore ssh://USER:PASSWORD settings and always connect to a remote fossil end as nobody. As a result * One cannot push anything to a remote repo (unless nobody is granted developer privileges) * clone/pull private branches does not work (unless nobody is granted Private privileges) These problems were recently reported to this mailing list by several people [1-4]. Is there a workaround or a bug fix? [1] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-January/007890.html [2] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008121.html [3] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008122.html [4] http://lists.fossil-scm.org:8080/pipermail/fossil-users/2012-February/008106.html Thanks, --Leo-- ___ 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] Derived code, not to be pushed public
On Sun, Feb 5, 2012 at 2:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sun, Feb 05, 2012 at 02:34:30PM -0500, Leo Razoumov wrote: IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. Well, even that alone would not be enough. I meant for cases where it is *very important* not to push the work. :) But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. Mark your branch private. Anything you want to push can then be merged into a non-private branch. ___ 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] Derived code, not to be pushed public
On Sun, Feb 5, 2012 at 2:34 PM, Leo Razoumov slonik...@gmail.com wrote: IMHO, a very important feature is still missing from fossil -- an ability to push or pull a single branch. A great variety of workflows could immediately become possible. Perhaps more useful would be the ability to pull a contributor's trunk into a branch in the receiving repository. ___ 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] Derived code, not to be pushed public
On Mon, Feb 06, 2012 at 01:07:30PM -0500, Ron Wilson wrote: On Sun, Feb 5, 2012 at 2:47 PM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sun, Feb 05, 2012 at 02:34:30PM -0500, Leo Razoumov wrote: Well, even that alone would not be enough. I meant for cases where it is *very important* not to push the work. :) But I suspect that there are people using fossil and having a reasonable workflow for those cases. I wonder what they use. Mark your branch private. Anything you want to push can then be merged into a non-private branch. Ah, well, that's fine for personal work. I meant a bit how to do private collaborative work over a public fossil base. Sorry that I did not state all I had in mind clear enough. Additionally, it looked to me that there have been some flaws in the code related to 'private' branches, so I'm understanding that this feature is not under much testing (as in broad usage). Thank you, Lluís. ___ 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] BUG: clone/pull/push over SSH always use nobody privileges
On Mon, Feb 6, 2012 at 09:24, Leo Razoumov slonik...@gmail.com wrote:
Hi Richard,
It seems that clone/push/pull over ssh ignore ssh://USER:PASSWORD
settings and always connect to a remote fossil end as nobody.
Richard,
Thank you very much for pushing a prompt fix to the trunk [a928c89cb18].
It solves SSH authentication problem very elegantly. If one has ssh
access to the repository then user privileges are mute anyway, for one
can simply copy the whole repository file from the remote to a local
host.
Along the same lines I should be able to clone private branches if my
source URL is a regular file. Unfortunately, as it stands now
clone_cmd function always calls delete_private_content() when the
source URL is a file.
Please, find below a simple patch which preserves private content if
clone is called with option --private.
%%%%
Index: src/clone.c
==
--- src/clone.c~0 2012-02-06 17:38:58.0 -0500
+++ src/clone.c 2012-02-06 17:19:49.0 -0500
@@ -119,11 +119,13 @@ void clone_cmd(void){
VALUES('server-code', lower(hex(randomblob(20))),now());
REPLACE INTO config(name,value,mtime)
VALUES('last-sync-url', '%q',now());,
g.urlCanonical
);
-delete_private_content();
+if( !bPrivate ){
+ delete_private_content();
+}
shun_artifacts();
db_create_default_users(1, zDefaultUser);
if( zDefaultUser ){
g.zLogin = zDefaultUser;
}else{
%%%%
--Leo--
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] In-line versus side-by-side diffs
A lot of people have been telling me that they prefer the unified or context style in-line diffs over side-by-side diffs. And I have to admit that sometimes an in-line diff is easier to read and understand. But side-by-side diffs, especially with the recent enhancements, sometime give a much clearer picture of what changed. The following is a dramatic example of this that I stumbled over while testing. First the in-line diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=0#chunk3 Can you tell what changed? Now look at the side-by-side diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=1#chunk3 Surely you will admit that, in this case at least, the side-by-side diff gives a much clearer picture of what happened -- 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] In-line versus side-by-side diffs
I think something like this would help the traditional diff format a lot: http://www.redmine.org/issues/7139 Bill On Mon, Feb 6, 2012 at 10:26 PM, Richard Hipp d...@sqlite.org wrote: A lot of people have been telling me that they prefer the unified or context style in-line diffs over side-by-side diffs. And I have to admit that sometimes an in-line diff is easier to read and understand. But side-by-side diffs, especially with the recent enhancements, sometime give a much clearer picture of what changed. The following is a dramatic example of this that I stumbled over while testing. First the in-line diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=0#chunk3 Can you tell what changed? Now look at the side-by-side diff: http://www.fossil-scm.org/fossil/fdiff?v1=25b66bf2fcbv2=1a6be6bad57sbs=1#chunk3 Surely you will admit that, in this case at least, the side-by-side diff gives a much clearer picture of what happened -- 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
