Re: [fossil-users] manifest setting "l" flag

2017-09-28 Thread Scott Robison 
There is a winsymlink branch I created some time ago. Hasn't been kept up
to date (I didn't need it, just thought it might be useful for feature
parity) but I could take a look at it if you were interested. Or you could.

On Sep 28, 2017 7:08 PM, "Andy Goth"  wrote:

> http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8
>
> I added support for a new "l" flag to the "manifest" setting.  With this
> flag present, a new file "manifest.symlinks" is automatically created and
> maintained.  This file lists all symlinks (not their targets).
>
> I need this feature for a project that makes extensive use of symlinks and
> has to work on Windows even though the OS doesn't really have symlinks (at
> least not symlinks to files).  On this project, I currently have a symlink
> list file which I maintain by running a script on Linux and checking in the
> result.
>
> When I run on Windows, everything in the project that actually needs to
> use symlinks looks at the symlinks file to see if it should read the file
> to get its target before proceeding.
>
> This works pretty well for me but is kind of awkward.  I'd rather have the
> symlinks file be kept up to date, no fooling, without being a separately
> checked-in file.
>
> However, it's not 100% what I need.  When working on Windows, I'd like to
> also be able to edit manifest.symlinks to change which files are and are
> not considered to be symlinks.
>
> I believe the current Fossil logic for handling symlinks on Windows is to
> create them as ordinary files containing their targets (no trailing
> newline), then leave them as symlinks in the manifest until they are
> changed.  I'm thinking that when the "l" flag is set, the logic would
> instead be to reread the manifest.symlinks file when doing a commit and use
> it to decide what to mark as symlinks in the manifest.  Said logic would
> only apply in Windows.
>
> --
> Andy Goth | 
> ___
> 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

[fossil-users] manifest setting "l" flag

2017-09-28 Thread Andy Goth 

http://fossil-scm.org/index.html/info/8d6bdd1e00cf2cf8

I added support for a new "l" flag to the "manifest" setting.  With this 
flag present, a new file "manifest.symlinks" is automatically created 
and maintained.  This file lists all symlinks (not their targets).


I need this feature for a project that makes extensive use of symlinks 
and has to work on Windows even though the OS doesn't really have 
symlinks (at least not symlinks to files).  On this project, I currently 
have a symlink list file which I maintain by running a script on Linux 
and checking in the result.


When I run on Windows, everything in the project that actually needs to 
use symlinks looks at the symlinks file to see if it should read the 
file to get its target before proceeding.


This works pretty well for me but is kind of awkward.  I'd rather have 
the symlinks file be kept up to date, no fooling, without being a 
separately checked-in file.


However, it's not 100% what I need.  When working on Windows, I'd like 
to also be able to edit manifest.symlinks to change which files are and 
are not considered to be symlinks.


I believe the current Fossil logic for handling symlinks on Windows is 
to create them as ordinary files containing their targets (no trailing 
newline), then leave them as symlinks in the manifest until they are 
changed.  I'm thinking that when the "l" flag is set, the logic would 
instead be to reread the manifest.symlinks file when doing a commit and 
use it to decide what to mark as symlinks in the manifest.  Said logic 
would only apply in Windows.


--
Andy Goth | 
___
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] Using Fossil with Apache Proxy

2017-09-28 Thread Richard Hipp 
On 9/28/17, David Mason  wrote:
>
> Last question for a while: in clone.c line 104 it says to use %40, %2f and
> %3a for special characters in the userid and password (for obvious
> reasons). Are there any other restrictions on the repo name or other parts
> of the URL?

Note that I recall.  But there might be some that I've forgotten about.

As a security precaution in your system, I think you would do well to
restrict repo names to begin with an alphanumeric, end with ".fossil",
and contain no characters other than alphanumerics, '.', '_', and '-'.
Maybe also only allow a single '.', specifically the one that occurs
on the ".fossil" suffix.
-- 
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] Using Fossil with Apache Proxy

2017-09-28 Thread David Mason 
I seem to be thick as a brick today, but I found the --nocgi but can't seem
to use it...
a bit later after looking at the sources... Ahhh... it's only parsed if
GATEWAY_INTERFACE is in the environment!

I would argue that line 601 should use & instead of && - principle of least
surprise.

It appears that `unset GATEWAY_INTERFACE` is a more robust way to deal with
it in the meantime (and you have to unset it... not just set it to '').

Last question for a while: in clone.c line 104 it says to use %40, %2f and
%3a for special characters in the userid and password (for obvious
reasons). Are there any other restrictions on the repo name or other parts
of the URL?

Thanks  ../Dave



On 28 September 2017 at 09:53, Roy Keene  wrote:

> On Thu, 28 Sep 2017, Mark Janssen wrote:
>
>
>>
>> On 28 Sep 2017 13:37, "David Mason"  wrote:
>>
>>
>>> I have all the logic I need I just want fossil to behave like it
>>> would at a terminal prompt, rather than acting like a CGI... the
>>> complication is that I am calling it from a CGI!  But removing all the
>>> environment
>>> variable mostly solves the problem.
>>>
>>>
>> To get the commandline behavior of fossil in a CGI context use the
>> --nocgi flag.
>>
>>
>>
>>
> For what it's worth, this is how Flint (which powers ChiselApp.com) does
> it:
>
> http://chiselapp.com/user/rkeene/repository/flint/artifact?
> ln=33-37=1eb0582d234199bc
>
> ___
> 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

Re: [fossil-users] fossil-users Digest, Vol 116, Issue 32

2017-09-28 Thread Ron W 
On Thu, Sep 28, 2017 at 7:57 AM, 
wrote:

> Date: Thu, 28 Sep 2017 06:17:30 -0400
> From: David Mason 
> Subject: Re: [fossil-users] Using Fossil with Apache Proxy
>
> I'm running fossil from within a CGI of my own... I want to do things like
> `fossil new foo.fossil`
>

As Richard suggested, look at http://chiselapp.com/ . It is open source and
uses Fossil to the things you want to do, like creating new repositories.
___
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] Using Fossil with Apache Proxy

2017-09-28 Thread Roy Keene 

On Thu, 28 Sep 2017, Mark Janssen wrote:




On 28 Sep 2017 13:37, "David Mason"  wrote:



I have all the logic I need I just want fossil to behave like it would at a 
terminal prompt, rather than acting like a CGI... the complication is that I am 
calling it from a CGI!  But removing all the environment
variable mostly solves the problem.



To get the commandline behavior of fossil in a CGI context use the --nocgi flag.





For what it's worth, this is how Flint (which powers ChiselApp.com) does 
it:


http://chiselapp.com/user/rkeene/repository/flint/artifact?ln=33-37=1eb0582d234199bc
___
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] Using Fossil with Apache Proxy

2017-09-28 Thread Mark Janssen 
On 28 Sep 2017 13:37, "David Mason"  wrote:



I have all the logic I need I just want fossil to behave like it would
at a terminal prompt, rather than acting like a CGI... the complication is
that I am calling it from a CGI!  But removing all the environment variable
mostly solves the problem.


To get the commandline behavior of fossil in a CGI context use the --nocgi
flag.
___
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] Using Fossil with Apache Proxy

2017-09-28 Thread David Mason 
No, just setuid something other than www - an ordinary user.

I'm currently doing a workaround to not run fossil from within a CGI, but
it's not optimal (exposes some information I'd rather not expose).

Thanks

On 28 September 2017 at 09:26, Richard Hipp  wrote:

> On 9/28/17, David Mason  wrote:
> >
> > The CGI is also setuid,...
>
> Setuid root?  If so, remember that when Fossil sees that it running as
> root, it puts itself inside a chroot jail and drops all privileges (it
> reverts to the owner of the repository) prior to doing much of
> anything else.  Might the chroot() and/or setuid() be causing you some
> kind of grief?
>
> --
> 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

Re: [fossil-users] Using Fossil with Apache Proxy

2017-09-28 Thread Richard Hipp 
On 9/28/17, David Mason  wrote:
>
> The CGI is also setuid,...

Setuid root?  If so, remember that when Fossil sees that it running as
root, it puts itself inside a chroot jail and drops all privileges (it
reverts to the owner of the repository) prior to doing much of
anything else.  Might the chroot() and/or setuid() be causing you some
kind of grief?

-- 
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] Using Fossil with Apache Proxy

2017-09-28 Thread David Mason 
I thought I had it... but no...
I tried:

env - PATH=$PATH FOSSIL_HOME=. fossil new -A  foo.fossil
on a terminal and it worked perfectly... I use the same values in the CGI,
and it gives the read permission problem. It does create the foo.fossil
file, but it's junk.

Sigh  ../Dave

On 28 September 2017 at 07:37, David Mason  wrote:

> I wasn't clear! (I've been working all night on this so it's
> understandable.)
>
> I have all the logic I need I just want fossil to behave like it would
> at a terminal prompt, rather than acting like a CGI... the complication is
> that I am calling it from a CGI!  But removing all the environment variable
> mostly solves the problem.
>
> The CGI is also setuid, and I'm wondering if that could explain some of
> the permission problems I'm seeing... in particular fossil says:
>
> Fossil internal error: repository does not exist or is in an unreadable
> directory
> when it really isn't. So I changed the permissions on the directory to 777
> and now I get:
>
> Fossil internal error: read permission denied for repository
> Fossils/A.fossil
> which is equally mystifying!
> And there are no users defined.
>
> Obviously there is some heavy voodoo happening that I'm not tracking.  For
> the record this is Linux.
>
> Thanks  ../Dave
>
> On 28 September 2017 at 06:37, Richard Hipp  wrote:
>
>> On 9/28/17, David Mason  wrote:
>> >
>> > I need to create fossils on the fly [using CGI]
>>
>> Fossil does not (currently) have that capability.
>>
>> What you are really asking for is a "meta-fossil" that is a
>> server-side program that manages multiple fossil repositories.
>>
>> The closest thing we have to that right now is that in your CGI
>> script, you can use the "directory:" keyword in place of "repository:"
>> to specify a directory that contains multiple "*.fossil" files, and
>> then Fossil will give you a list of the files to choose from.  But
>> with that mechanism, there is no opportunity to customize the look &
>> feel of the screen, nor authenticate the user, nor do any of the other
>> kinds of things that a true meta-fossil would need to do.
>>
>> Perhaps a full-up "meta-fossil" capability should be a feature request.
>>
>> See also:  http://chiselapp.com/
>> --
>> 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

Re: [fossil-users] Using Fossil with Apache Proxy

2017-09-28 Thread David Mason 
I wasn't clear! (I've been working all night on this so it's
understandable.)

I have all the logic I need I just want fossil to behave like it would
at a terminal prompt, rather than acting like a CGI... the complication is
that I am calling it from a CGI!  But removing all the environment variable
mostly solves the problem.

The CGI is also setuid, and I'm wondering if that could explain some of the
permission problems I'm seeing... in particular fossil says:

Fossil internal error: repository does not exist or is in an unreadable
directory
when it really isn't. So I changed the permissions on the directory to 777
and now I get:

Fossil internal error: read permission denied for repository
Fossils/A.fossil
which is equally mystifying!
And there are no users defined.

Obviously there is some heavy voodoo happening that I'm not tracking.  For
the record this is Linux.

Thanks  ../Dave

On 28 September 2017 at 06:37, Richard Hipp  wrote:

> On 9/28/17, David Mason  wrote:
> >
> > I need to create fossils on the fly [using CGI]
>
> Fossil does not (currently) have that capability.
>
> What you are really asking for is a "meta-fossil" that is a
> server-side program that manages multiple fossil repositories.
>
> The closest thing we have to that right now is that in your CGI
> script, you can use the "directory:" keyword in place of "repository:"
> to specify a directory that contains multiple "*.fossil" files, and
> then Fossil will give you a list of the files to choose from.  But
> with that mechanism, there is no opportunity to customize the look &
> feel of the screen, nor authenticate the user, nor do any of the other
> kinds of things that a true meta-fossil would need to do.
>
> Perhaps a full-up "meta-fossil" capability should be a feature request.
>
> See also:  http://chiselapp.com/
> --
> 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

Re: [fossil-users] Using Fossil with Apache Proxy

2017-09-28 Thread Richard Hipp 
On 9/28/17, David Mason  wrote:
>
> I need to create fossils on the fly [using CGI]

Fossil does not (currently) have that capability.

What you are really asking for is a "meta-fossil" that is a
server-side program that manages multiple fossil repositories.

The closest thing we have to that right now is that in your CGI
script, you can use the "directory:" keyword in place of "repository:"
to specify a directory that contains multiple "*.fossil" files, and
then Fossil will give you a list of the files to choose from.  But
with that mechanism, there is no opportunity to customize the look &
feel of the screen, nor authenticate the user, nor do any of the other
kinds of things that a true meta-fossil would need to do.

Perhaps a full-up "meta-fossil" capability should be a feature request.

See also:  http://chiselapp.com/
-- 
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] Using Fossil with Apache Proxy

2017-09-28 Thread David Mason 
Another challenge!

I'm running fossil from within a CGI of my own... I want to do things like
`fossil new foo.fossil`

But fossil decides it is running as a CGI itself and doesn't do what I
ask.  Running it as `exec - /usr/local/bin/fossil new foo.fossil` kind of
works, but some things are still strange. I reset GATEWAY_INTERFACE and
PATH_INFO to '' but that didn't solve it.

The actual fossil name I'm using looks like: A+foo_bar.com+oth_re.ex.fossil
- would that be causing me strange problems? Also this CGI that's calling
fossil is running setuid... does fossil use the system to determine
permissions or does it use stat etc. to look at the files directly. I.e. do
I need to call seteuid?

I thought this was going to be easy to use it (in this very idiosyncratic
way), but it's been a pile of hassles.

The reason for this weirdness is that I need to create fossils on the fly
and change permissions/passwords, etc.

Thanks

On 26 September 2017 at 12:01, David Mason  wrote:

> This is proxy, not CGI, but the same appears to apply:
>
> fossil clone http://dmason%40ryerson.ca@localhost:8081/f2017/A-dmason_
> ryerson.ca x.fossil
>
> (talking directly to the server) also doesn't seem to want the .fossil
> extension, whereas ssh: and file: do.
>
> This seems inconsistent to me, though obviously you won't be changing it!!!
>
> Thanks again (both for the immediate help, and for fossil itself)!
>
> ../Dave
>
> On 26 September 2017 at 10:05, Richard Hipp  wrote:
>
>> On 9/26/17, David Mason  wrote:
>> > Indeed! Thanks... I already noted that in the web access, but the file
>> does
>> > end in .fossil and I've always used that before when cloning (using the
>> > ssh: access method). Is there a difference in how fossil names are
>> > recognized in ssh: vs http(s): ?
>>
>> When using http(s), you need to tell the web server the name of the
>> CGI script, not the name of the repository.  Apache doesn't know
>> anything about Fossil and has no idea how to deal with it.  But Apache
>> does know how to run CGI.
>>
>> When using the ssh: access method, the client uses the "ssh" command
>> to run "fossil server $repo" on the remote side, where $repo is the
>> name of the repository as specified in the URL.  In this case, the
>> command being run is "fossil" and it does know how to deal directly
>> with a repository.  Hence, ssh: is a little different from https: in
>> that ssh: wants the name of the repository whereas https: wants the
>> name of the CGI script.
>>
>> Note that it is usually undesirable to download the repository file
>> directly, as the repository contains additional information such as
>> usernames and password hashes and log files that should normally be
>> kept private.  If you ever do need to share a Fossil repository with
>> an untrusted third party, first make a copy of the repo, then run the
>> "fossil scrub" command on the copy in order to remove all sensitive
>> information.  Share the copy, not the original.
>>
>> --
>> 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