Re: [fossil-users] http-proxy + https
Hi, I have a completely OT remark: Your certificate has expired a long time ago... 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
Re: [fossil-users] cgi on Mac problem
On Sun, 29 Sep 2013 17:51:56 +0200, Stephan Beal sgb...@googlemail.com wrote: On Sun, Sep 29, 2013 at 5:45 PM, j. van den hoff veedeeh...@googlemail.comwrote: htmlbodypBad Request: missing REQUEST_URI/p/body/html That's an indication that Apache is missing something. The env vars REQUEST_URI and SCRIPT_NAME, both specified by CGI, are required in the environment: http://www.cgi101.com/book/ch3/text.html (i mention SCRIPT_NAME b/c the check for those two vars is in the same place in the source code) i've never seen that happen on an Apache-based config, and i have never set up Fossil as a CGI under any different web server :/. i.e. i'm confused and don't have any suggestions at the moment. and I have no clue in these matters anyway. but it seems to work nevertheless. one remaining issue is the following: I've put the cgi-script in the standard location on the mac with is a directory only modifiable by root. now, if I access the server, most things work just fine (logging in as different users, looking at timeline and diffs etc.) but what does _not_ work is to download a tarball or zip-file, where the attempt to do this leads to the message: The requested URL /cgi-bin/repo.cgi/tarball/reponame-0253aa7c17e75b5a.tar.gz was not found on this server. from this I guess that `fossil' tries ot create a subdir tarball within the cgi-script directory (or does it?) which it is not able to do (since only writable by root, not by the cgi-user). if this is correct: what is the canonical solution to the problem? is it really necessary (and unproblematic) to make the cgi-script dir world writable? j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] cgi on Mac problem
On Mon, Sep 30, 2013 at 11:06 AM, j. van den hoff veedeeh...@googlemail.com wrote: The requested URL /cgi-bin/repo.cgi/tarball/** reponame-0253aa7c17e75b5a.tar.**gz was not found on this server. from this I guess that `fossil' tries ot create a subdir tarball within the cgi-script directory (or does it?) which it is not able to do (since only writable by root, not by the cgi-user). if this is correct: what is the canonical solution to the problem? is it really necessary (and unproblematic) to make the cgi-script dir world writable? No, Fossil generates the tarball on-the-fly and transmits it back over the wire without every writing to disk. I'm not sure what the problem might be. Are you sure you have the Download ZIP capability (which also covers tarballs) turned on? -- 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] cgi on Mac problem
On Mon, 30 Sep 2013 17:11:41 +0200, Richard Hipp d...@sqlite.org wrote: On Mon, Sep 30, 2013 at 11:06 AM, j. van den hoff veedeeh...@googlemail.com wrote: The requested URL /cgi-bin/repo.cgi/tarball/** reponame-0253aa7c17e75b5a.tar.**gz was not found on this server. from this I guess that `fossil' tries ot create a subdir tarball within the cgi-script directory (or does it?) which it is not able to do (since only writable by root, not by the cgi-user). if this is correct: what is the canonical solution to the problem? is it really necessary (and unproblematic) to make the cgi-script dir world writable? No, Fossil generates the tarball on-the-fly and transmits it back over the wire without every writing to disk. I'm not sure what the problem might be. I see. Are you sure you have the Download ZIP capability (which also covers tarballs) turned on? at least I did not intentionally switch it off... what I actually did, for testing purposes, is to set the permissions/capabilities as follows for anonymous and nobody: anonymous: hmncz nobody: j but the reported error occurs when I'm logged in as the Setup/Super-user (capabilities: s). I presume `s' implies everything else? but if not so: the download fails also if I explicitly add `z' for the setup user. if I can provide any more information please let me know. j. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] cgi on Mac problem
On Mon, Sep 30, 2013 at 5:25 PM, j. van den hoff veedeeh...@googlemail.comwrote: anonymous: hmncz nobody: j but the reported error occurs when I'm logged in as the Setup/Super-user (capabilities: s). I presume `s' implies everything else? but if not so: the download fails also if I explicitly add `z' for the setup user. setup is kind of a superuser, but the permissions are not additive there (at least, not IIRC). Setup users have a few rights which admins do not, e.g. editing the site's configuration info. Admins can add users, but cannot (e.g.) change the access rights of a user with Setup permissions. In my experience the owner of a repo, and perhaps one or two others, have s+a permissions, then perhaps a few others have admin permissions, so that they can set up users and do a few of the mundane admin tasks, but they cannot modify or lock out the Setup user(s). If you'll grep the sources for perm.Setup and perm.Admin the difference should become a bit clearer. It is possible to have Setup permission without Admin permissions, in which case you can set up the basic configuration but will be denied access to some other bits. e.g. an Admin can shun but a Setup user cannot (not sure why, but that's what the code tells me). if I can provide any more information please let me know. i'm still at a loss. -- - 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] cgi on Mac problem
I think I have found the reason for the problem: it is caused by the presence of a `/' in the project name. specifically in my case, the error message was: 8 The requested URL /cgi-bin/repo.cgi/zip/PET/MR+Bug+List-0253aa7c17e75b5a.zip was not found on this server. 8 and it's the `/' in `PET/MR' which obviously is interpreted as part of the path, since it is not quoted. if I change the project name by replacing PET/MR -- PET-MR I can download the tarball/zip file without problem. so I think either fossil should quote any occurence of `/' when constructing the URL (if possible -- I'm not sure if it is) or silently replace any `/' by something else (as it already does with any blanks which are replaced by `+'). a `-' actually might be the best choice for replacing the `/'. does this make sense? j. On Mon, 30 Sep 2013 17:11:41 +0200, Richard Hipp d...@sqlite.org wrote: On Mon, Sep 30, 2013 at 11:06 AM, j. van den hoff veedeeh...@googlemail.com wrote: The requested URL /cgi-bin/repo.cgi/tarball/** reponame-0253aa7c17e75b5a.tar.**gz was not found on this server. from this I guess that `fossil' tries ot create a subdir tarball within the cgi-script directory (or does it?) which it is not able to do (since only writable by root, not by the cgi-user). if this is correct: what is the canonical solution to the problem? is it really necessary (and unproblematic) to make the cgi-script dir world writable? No, Fossil generates the tarball on-the-fly and transmits it back over the wire without every writing to disk. I'm not sure what the problem might be. Are you sure you have the Download ZIP capability (which also covers tarballs) turned on? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] cgi on Mac problem
On Mon, Sep 30, 2013 at 9:07 PM, j. van den hoff veedeeh...@googlemail.comwrote: so I think either fossil should quote any occurence of `/' when constructing the URL (if possible -- I'm not sure if it is) or silently replace any `/' by something else (as it already does with any blanks which are replaced by `+'). a `-' actually might be the best choice for replacing the `/'. My personal preference would be to restrict the project name field to only characters which are legal in Fossil filenames (note that fossil disallows some which are legal in Unix but not on Windows, like :). -- - 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] cgi on Mac problem
On Mon, 30 Sep 2013 21:49:17 +0200, Stephan Beal sgb...@googlemail.com wrote: On Mon, Sep 30, 2013 at 9:07 PM, j. van den hoff veedeeh...@googlemail.comwrote: so I think either fossil should quote any occurence of `/' when constructing the URL (if possible -- I'm not sure if it is) or silently replace any `/' by something else (as it already does with any blanks which are replaced by `+'). a `-' actually might be the best choice for replacing the `/'. My personal preference would be to restrict the project name field to only characters which are legal in Fossil filenames (note that fossil disallows some which are legal in Unix but not on Windows, like :). yes, that would be possible. but still: at least blanks _are_ allowed in file names, but not in the URL and are therefore replaced by `+' and I think this is the more reasonable approach. I would argue that it's preferable to allow free text for the project name (including blank, slash, colon etc.) and just map all these to something valid (maybe all of them to `+' just like it is already done for blanks) when the tarball URL is constructed: after all, the project name is just the descriptive title at the top of the web-page and it feels not right to enforce that this title is also a valid file name. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] cgi on Mac problem
On Mon, Sep 30, 2013 at 9:57 PM, j. van den hoff veedeeh...@googlemail.comwrote: it is already done for blanks) when the tarball URL is constructed: after all, the project name is just the descriptive title at the top of the web-page and it feels not right to enforce that this title is also a valid file name. If i'm not mistaken, the project's name is used as the top-most directory name in the tar/zip file, which means you might not be able to unpack the such a zip/tar if it contains ':' or '/' in it. Encoding it for the URL is not a problem (in principal, at least), though there might be a corner case or three waiting for us there. Way back in the old days, the zip files (fossil didn't have tar back then) unpacked everything into the current directory. At some point we added an artificial subdir based off of the project's name and the version UUID. At the time it was assumed (my fault!) that project names would be simple in nature, but that was (in hindsight a poor assumption). In baseline_zip_cmd() the code can be found which replaces space with underscore, but that's just a very basic form of escaping. To handle /, :, \, *, and probably a few other potentially problematic ones, we'd need to expand that (and the corresponding tar counterpart) a bit (but it's almost bedtime here, so i'm not going to touch it tonight ;). Ah, here's a workaround which might work: pass a name=abcdef option and it will use that as the base name, but if it's longer than 10 bytes then it truncates it to 10 bytes (see zip.c:baseline_zip_page()). i haven't checked the corresponding tar code to see if it has a similar feature. -- - 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] http-proxy + https
Jan Danielsson wrote: Hello, This has been brought up before, and I've been meaning to look at it, but it suddenly became a little more urgent. Last week I found myself being in a situation of not being able to clone a https repository due to an evil http proxy, and soon afterwards someone I know ran into the same problem at his workplace. I was planning on adding support for https over http-proxy this past weekend, but other things got in the way. I did however take a quick look and noticed that the code currently makes certain assumptions which makes it a little less trivial than it could have been -- so slight rewiring is required. The usual check, to avoid duplicate work: Is anyone else working on this already? Is anyone planning on touching the ssl and/or http-proxy code in the very near future? I recall seeing this bug/patch a while back: http://fossil-scm.org/index.html/tktview?name=e854101c4f But it's really old, so it's probably not going to apply to the current version cleanly. -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
