Re: [fossil-users] How to embed image in project home page or wiki pages?

[The Tick]

On 9/15/2015 6:09 PM, Ron W wrote:

On Tue, Sep 15, 2015 at 6:18 PM, The Tick > wrote:

However, if I do that, then the image would be included in the
project download, right? I guess one small image would not be that
big a deal, but it would be good to not foist unnecessary files on
users.


What about your project's "user manual"? Screenshots are often included,
so would be reasonable to include in the source "tarball".


First of all, thanks for your reply.

The app is a Tcl script and associated image files. There is no "User 
Manual". It also requires Tcl with the Tk Img package be installed. If 
someone does not know how to unpack a ZIP and double-click a file, 
well... Adding a windows installer (even NullSoft) would add more 
complexity than I am willing to handle, especially trying to determine 
if Tcl is already installed, downloading ActiveState's version if not, 
etc. I am also assuming Unix users know how to unpack a tarball.


There's an 'INSTALL.txt' that should provide enough information. After 
that I will assume that most people know how to click a mouse.


If the 'INSTALL.txt' is unclear or there are bugs, I'd like the bug 
tracking system to be easy to use. Since there's no "Users Manual", I do 
not need nor want a public "wiki".




FYI, Fossil can automatically create "tarballs" of the files in the
repository for a specified version, which defaults to the latest.


That is one of the features that I was looking for. How to get the URL 
for that to put on the 'home' page is one of my next tasks. I doubt that 
most windows users would explore fossil's interface (and understand it 
enough) to click 'files' then click the weird check-in id to get to the 
ZIP download button. At this point I'm assuming I can just copy that URL 
and duplicate it on my home page.




I suppose a work-around would be to add the image(s) to a specific
version of your project, commit that version, then remove (rm) the
image(s) from the next version and commit that. Then your pages can link
to the image(s) at that specific version of your project, while the
automatically made tarballs would not have it/them.


I'll have to explore that. It's just one image to get an idea of the 
app's GUI.




Also, besides Fossil created tarballs, your project's build procedure
can, possibly should, create release packages. Such packages would
contain only what you choose to put in them. (But, see below.) The
specific version "trick" I described would work for these, as well as
images.


Since there is no build procedure, I want whatever source control system 
or host to supply the simple download Zip/Tar button. Again, thanks for 
your help.

___
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] Why Hash

[Stephan Beal]

On Wed, Sep 16, 2015 at 3:01 AM, Scott Robison 
wrote:

> cryptographic security, it was designed to take a blob of data and create
> a pseudo-random looking string of 40 hex digits that would be highly
> unlikely to collide with anything being done by anyone else.
>

To add to that - a collision is not a problem so long as it doesn't happen
in the same context. If 2 independent repos end up with the same hash for 2
distinct blobs, _no big deal_. Nothing evil happens there. Even if one were
to try to feed "that other" blob into "the other" repo, the R-card
calculation (done using md5) would then change, invalidating any checkins.

I do see your points about interested parties trying to create a collision,
> but even if they managed that, simply gaining commit access to the master
> repository as mentioned the other day would not be adequate; the
> maliciously modified artifact would be rejected by fossil (as I understand
> it) as a duplicate / already received artifact.
>

Even if they locally inject it, the R-card calculation would see it, as it
is (i will naively assert) "impossible" that both the sha1 and md5 could
both be made to match in a collision of a non-empty blob. (The empty-blob
case is an interesting one, though, if only intellectually.)


> Again, I concede your point about bad actors trying to create deliberate
> collisions, but even in so doing there is far more to do than just "push an
> update".
>

+1.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Admin->Configuration suggests '/home' as index page. How do I create '/home'?

[Stephan Beal]

In the admin pages you can change that to use your "home" wiki page (i do
that so that my repos all have the same home path).

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
On Sep 16, 2015 12:09 AM, "The Tick"  wrote:

> On 9/15/2015 4:00 PM, Ron W wrote:
>
>> On Tue, Sep 15, 2015 at 3:54 PM, The Tick > > wrote:
>>
>> After starting 'fossil ui', I go Admin->Configuration
>>
>> The Index page value has the suggestion to use '/home'. I did that.
>> Now, how do I create this '/home' page?
>>
>>
>>  From the instructions on that set up page:
>>
>> The default "/home" page displays a Wiki page with the same name as the
>> Project Name specified above. Some sites prefer to redirect to a
>> documentation page (ex: "/doc/tip/index.wiki") or to "/timeline".
>>
>> So, if your project's name is "Fossil", then create a wiki page named
>> "Fossil".
>>
>>
> Ah, so there's a mapping: /home ==> wiki page named 
> Thank you
> ___
> 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] Why Hash

[Stephan Beal]

On Wed, Sep 16, 2015 at 1:05 AM, Warren Young  wrote:

> On Sep 14, 2015, at 11:53 PM, Stephan Beal  wrote:
> >
> > it is not possible to change the hash without a near-complete overhaul
> of fossil (and its docs)
>
> I’ve already addressed the documentation/UI issue repeatedly above: The
> fact that Fossil uses SHA-1 should be a hidden implementation detail,
> unimportant to anyone but those working on the lowest-level parts of Fossil.
>

There are lots of assumptions in many places about which hashes are being
used, and their properties (e.g. length and being made up solely of
lowercase hex).


> (Plus those working on compatible software such as libfossil and FUEL.)
>

And i can say from my work on libfossil that this is so ;).


> > Supporting two hash variants in one fossil binary would likely prove to
> be problematic (and would require a major overhaul).
>
> Why can’t an artifact’s or checkin’s hash be tagged in MCF fashion, so
> that when Fossil checks the hashes, it knows which algorithm to use at each
> step?
>

It "could" be done, but it would essentially require duplicate code paths
for much of the existing code and would not be directly compatible with
existing repos (which would have to keep using sha1).


> Many other systems support multiple encryption and digest algorithms, and
> many of those can switch mid-stream to a different algorithm.  This is
> known tech.
>

Sure, it's conceivable, but it's more trouble than it's worth. There's no
use case for fossil where such a move would simplify its usage in any way.


> then the prior discussion was all about accidental collision.  I’m talking
> instead about motivated, well-trained, intelligent, well-funded attackers
> purposely attempting to engineer a collision.  Not the same thing at all.
>

Wake me up when that happens. It hasn't happened yet and there is little
reason to suspect that it ever will.


> The Chinese attack from 2005 reduces the attack complexity to about 2^69
> operations.  The Stevens attack from 2011 reduces the attack complexity
> even further, to between 2^60.3 and 2^65.3 operations.  Add to that the
> improvement from Moore’s Law and you’re talking about 5 to 7 orders of
> magnitude improvement.
>

Again - a hypothetical problem. (A) nobody has anything to gain by
maliciously injecting content into a fossil repo and (B) i would have to
see it happen to believe it.


> Obviously the world’s HTTPS traffic is a far bigger target than
> public-facing Fossil repos, so Fossil’s urgency to get off SHA-1 should be
> lower.  That said, attacks only get better, and Moore’s Law still has steam
> in it, at least for embarrassingly-parallel applications like hashing.\


Show me one such successful attack on fossil and i'll be _all ears_.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Why Hash

[Warren Young]

On Sep 15, 2015, at 7:01 PM, Scott Robison  wrote:
> 
> I think calling it a non sequitur is not completely fair

Stephan stated that Fossil isn’t doing cryptography, therefore SHA-1 doesn’t 
have to be replaced.  Cryptography and message authentication are not the same 
thing.

It’s like pointing out that the bald tires on the car do not need to be 
replaced because we don’t require that the car be able to climb trees.

> It wasn't intended to provide cryptographic security

I’m probably just being pedantic, but now you’re doing it, too.

“Cryptographic security” implies encryption, which is not being done here.

The proper phrasing is “cyptographically-strong message digest algorithm.”  The 
reference to cryptography is only an indicator that the use of a given MD 
algorithm can be used with some given cryptosystem without compromising its 
integrity.

> It is more likely to detect accidental corruption than deliberate corruption.

I thought that’s what the MD5 bits were for.

My sense from reading the file format wiki page is that the SHA-1 bits ensure 
that blob B, which is intended to appear in the timeline between blobs A and C, 
was almost certainly inserted into the database at time T_b, where T_a <= T_b 
<= T_c.  That is, it is primarily a guarantor of checkin ordering.

That’s why I’ve been framing the risk as one of potential insertion of a 
timeline item way in the past.

That may be a bogus risk for other reasons, though, since you’d also have to 
work out how to change all the deltas.

It’s also occurred to me since my previous post that all the work needed to 
generate a bogus SHA-1 hash for an HTTPS cert only has to be done once, at 
which point you now have a reusable cert good for months or years.  The work 
needed to attack a single timeline entry in Fossil is a one-shot deal: to 
attack two different nodes in the timeline, you need to do 2x the work.

> simply gaining commit access to the master repository as mentioned the other 
> day would not be adequate; the maliciously modified artifact would be 
> rejected by fossil

I’m no expert in Fossil’s inner workings, and I have no interest in trying to 
attack it.

I’m just aware that Bruce Schneier and Google’s crypto geeks know things I do 
not, and I use that awareness to guide my own design decisions.  The last 
hash-based system I designed used SHA-256. :)

> I find it far more likely that someone would fork the repo and contaminate it 
> that way, rebuilding it from scratch, and finding ways to induce parties to 
> use *that* version of the library instead of the blessed repo.

Clearly so.

Always attack the weakest link first, if possible.

> * ethernet uses a 32 bit CRC; how much internet traffic goes through 
> ethernet? Can't really change that because of backward compatibility.
> * rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I remember 
> correctly). Can't really change that because of backward compatibility.

That’s why TLS exists.

TLS doesn’t solve any weaknesses with Fossil’s use of SHA-1, though.  It just 
prevents you from MITM-ing an existing TCP connection.  Once you’ve got a TCP 
connection to the Fossil server, well, *then* what?  That’s the purpose of this 
sub-thread.

> Given the widespread use of SHA-1 in DVCS systems, and the use of GPG 
> signatures to authenticate commits, I think it would be reasonable to enhance 
> the cryptographic security in a future version of fossil.

Indeed, perhaps Fossil should just wait and see what Git does, if anything.  
Github is a much bigger target for this sort of thing, if there is a “thing” 
here at all.
___
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] Why Hash

[Warren Young]

On Sep 15, 2015, at 8:18 PM, Richard Hipp  wrote:
> 
> what problem would you solve by changing Fossil
> to use the latest wizbang cryptographic hash function?

All I’m pointing out here is that we will shortly get to the time where it is 
economically feasible to forge arbitrary SHA-1 authenticated messages.

As for what you can do with that, that’s obviously something for you to say, as 
well as those of your associates who also know the internal structure of the 
system.

I am not going to go off and craft some kind of exploit just to be able to win 
this argument.  If you aren’t worried after learning about the known weaknesses 
of SHA-1, then you aren’t worried.  End of thread. :)
___
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] Why Hash

[Warren Young]

On Sep 14, 2015, at 11:53 PM, Stephan Beal  wrote:
> 
> it is not possible to change the hash without a near-complete overhaul of 
> fossil (and its docs)

I’ve already addressed the documentation/UI issue repeatedly above: The fact 
that Fossil uses SHA-1 should be a hidden implementation detail, unimportant to 
anyone but those working on the lowest-level parts of Fossil.

(Plus those working on compatible software such as libfossil and FUEL.)

> Supporting two hash variants in one fossil binary would likely prove to be 
> problematic (and would require a major overhaul).

Why can’t an artifact’s or checkin’s hash be tagged in MCF fashion, so that 
when Fossil checks the hashes, it knows which algorithm to use at each step?

Many other systems support multiple encryption and digest algorithms, and many 
of those can switch mid-stream to a different algorithm.  This is known tech.

> Fossil does not use it in a cryptographic context

That’s a true non sequitur.  Fossil uses SHA-1 as a kind of message 
authentication, the very sort of thing that HTTPS certificates use it for.

Therefore, either Fossil’s use of SHA-1 is not like HTTPS certs in some respect 
I do not understand, or Google is wrong to be trying to push the web world off 
SHA-1 authenticated HTTPS certs.

> There are long threads somewhere in the list archives about the changes of 
> hash collision. Management summary: not likely to happen for many human 
> generations.

If you mean posts like this one

  http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg05979.html

then the prior discussion was all about accidental collision.  I’m talking 
instead about motivated, well-trained, intelligent, well-funded attackers 
purposely attempting to engineer a collision.  Not the same thing at all.

If you were going to point me instead to a different thread with the value 2^80 
or (heaven forfend, 2^160) in it anywhere, you’d be pointing to something 
almost certainly not written by a cryptographer.  That complexity only applied 
when SHA-1 had no known weaknesses.

The Chinese attack from 2005 reduces the attack complexity to about 2^69 
operations.  The Stevens attack from 2011 reduces the attack complexity even 
further, to between 2^60.3 and 2^65.3 operations.  Add to that the improvement 
from Moore’s Law and you’re talking about 5 to 7 orders of magnitude 
improvement.

Obviously the world’s HTTPS traffic is a far bigger target than public-facing 
Fossil repos, so Fossil’s urgency to get off SHA-1 should be lower.  That said, 
attacks only get better, and Moore’s Law still has steam in it, at least for 
embarrassingly-parallel applications like hashing.
___
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] Why Hash

[Scott Robison]

On Tue, Sep 15, 2015 at 5:05 PM, Warren Young  wrote:

> On Sep 14, 2015, at 11:53 PM, Stephan Beal  wrote:
> >
> > it is not possible to change the hash without a near-complete overhaul
> of fossil (and its docs)
>
> I’ve already addressed the documentation/UI issue repeatedly above: The
> fact that Fossil uses SHA-1 should be a hidden implementation detail,
> unimportant to anyone but those working on the lowest-level parts of Fossil.
>
> (Plus those working on compatible software such as libfossil and FUEL.)
>

I don't dispute the "implementation detail" of SHA-1 isn't needed in the
interface / user docs. I don't think it is nearly as big a problem as you
do though, but I could be wrong.


> > Supporting two hash variants in one fossil binary would likely prove to
> be problematic (and would require a major overhaul).
>
> Why can’t an artifact’s or checkin’s hash be tagged in MCF fashion, so
> that when Fossil checks the hashes, it knows which algorithm to use at each
> step?
>
> Many other systems support multiple encryption and digest algorithms, and
> many of those can switch mid-stream to a different algorithm.  This is
> known tech.
>

I see the problem less as "can it be done" as "what would existing fossil
implementations do with the data format changes that would be required"? I
certainly think a fossil 2.0 spec should probably accommodate such changes.


> > Fossil does not use it in a cryptographic context
>
> That’s a true non sequitur.  Fossil uses SHA-1 as a kind of message
> authentication, the very sort of thing that HTTPS certificates use it for.
>
> Therefore, either Fossil’s use of SHA-1 is not like HTTPS certs in some
> respect I do not understand, or Google is wrong to be trying to push the
> web world off SHA-1 authenticated HTTPS certs.
>

I think calling it a non sequitur is not completely fair, though admittedly
it depends on your point of view. SHA-1 was a convenient algorithm, already
in use by git & mercurial at least, for this very same sort of computation.
It wasn't intended to provide cryptographic security, it was designed to
take a blob of data and create a pseudo-random looking string of 40 hex
digits that would be highly unlikely to collide with anything being done by
anyone else. The fact that it can be used to detect errors in the original
data is more akin to the CRC in an ethernet frame than cryptographic
security. It is more likely to detect accidental corruption than deliberate
corruption. Perhaps better signing / validation of artifacts should be
added to the fossil 2.0 list.

I do see your points about interested parties trying to create a collision,
but even if they managed that, simply gaining commit access to the master
repository as mentioned the other day would not be adequate; the
maliciously modified artifact would be rejected by fossil (as I understand
it) as a duplicate / already received artifact. In order to impact the
official / master / canonical repository, someone would have to gain access
to the file so that it could be modified and presented to the world. I find
it far more likely that someone would fork the repo and contaminate it that
way, rebuilding it from scratch, and finding ways to induce parties to use
*that* version of the library instead of the blessed repo.


> > There are long threads somewhere in the list archives about the changes
> of hash collision. Management summary: not likely to happen for many human
> generations.
>
> If you mean posts like this one
>
>
> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg05979.html
>
> then the prior discussion was all about accidental collision.  I’m talking
> instead about motivated, well-trained, intelligent, well-funded attackers
> purposely attempting to engineer a collision.  Not the same thing at all.
>

And avoiding accidental collision was the initial intent. The fact that it
can be used as "a kind of message authentication" does not mean that was
how it was intended to be used.

If the fact that some algorithm is cryptographically weak means that it
should be replaced, then we have a lot of work to do:

* ethernet uses a 32 bit CRC; how much internet traffic goes through
ethernet? Can't really change that because of backward compatibility.
* rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I remember
correctly). Can't really change that because of backward compatibility.

There are many more examples, these are the first two that came to mind.
And they are admittedly not fair examples, given they are used as part of a
protocol vs part of a durable long lasting repository structure, but they
are examples of "cryptographically insecure" algorithms being used
effectively to detect accidental corruption vs deliberate shenanigans.

Again, I concede your point about bad actors trying to create deliberate
collisions, but even in so doing there is far more to do than just "push an
update". Given the widespread use of 

Re: [fossil-users] Why Hash

[Richard Hipp]

On 9/15/15, Warren Young  wrote:
>
>> It is more likely to detect accidental corruption than deliberate
>> corruption.
>
> I thought that’s what the MD5 bits were for.
>

MD5 is 128 bytes versus 160 for SHA1.  That's why I picked SHA1.

Tell me: suppose tomorrow somebody publishes a trivial preimage attack
against SHA1 - a program that will generate a file that has any SHA1
you want.  (That's unlikely.  No such program exists for even things
like MD4.  But suppose.)

What attacks could you mount against Fossil using such a tool?

To put it another way, what problem would you solve by changing Fossil
to use the latest wizbang cryptographic hash function?
-- 
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] How to embed image in project home page or wiki pages?

[Ron W]

On Tue, Sep 15, 2015 at 6:18 PM, The Tick  wrote:
>
> I did run across a way to embed an image that is checked in as part of a
> project:
> http://stackoverflow.com/questions/3982999/fossil-how-to-display-checked-in-image-files-on-wiki-pages
>
> However, if I do that, then the image would be included in the project
> download, right? I guess one small image would not be that big a deal, but
> it would be good to not foist unnecessary files on users.
>

What about your project's "user manual"? Screenshots are often included, so
would be reasonable to include in the source "tarball".

FYI, Fossil can automatically create "tarballs" of the files in the
repository for a specified version, which defaults to the latest.

I suppose a work-around would be to add the image(s) to a specific version
of your project, commit that version, then remove (rm) the image(s) from
the next version and commit that. Then your pages can link to the image(s)
at that specific version of your project, while the automatically made
tarballs would not have it/them.

Also, besides Fossil created tarballs, your project's build procedure can,
possibly should, create release packages. Such packages would contain only
what you choose to put in them. (But, see below.) The specific version
"trick" I described would work for these, as well as images.


> I'd like to put a small screenshot image to illustrate the project's GUI.
> Eventually, I will use Chisel to host this project, so perhaps there's a
> way to host an image file outside of a project's repository? (And, of
> course, to reference the image with an  tag.)
>

As best I can tell, ChiselApp.com doesn't provide for hosting files outside
of a Fossil repository. So, if you need to host files (images, release
packages, other) outside of a Fossil repository, you will need some other
arrangement. Unfortunately, I don't have any recommendations for "general
purpose" image /file hosting. Although photo sharing sites like photobucket
would *technically* work, using one that way might be against the terms of
service.
___
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] Why Hash

[Scott Robison]

On Tue, Sep 15, 2015 at 7:46 PM, Warren Young  wrote:

> On Sep 15, 2015, at 7:01 PM, Scott Robison 
> wrote:
> >
> > I think calling it a non sequitur is not completely fair
>
> Stephan stated that Fossil isn’t doing cryptography, therefore SHA-1
> doesn’t have to be replaced.  Cryptography and message authentication are
> not the same thing.
>
> It’s like pointing out that the bald tires on the car do not need to be
> replaced because we don’t require that the car be able to climb trees.
>
> > It wasn't intended to provide cryptographic security
>
> I’m probably just being pedantic, but now you’re doing it, too.
>
> “Cryptographic security” implies encryption, which is not being done here.
>
> The proper phrasing is “cyptographically-strong message digest
> algorithm.”  The reference to cryptography is only an indicator that the
> use of a given MD algorithm can be used with some given cryptosystem
> without compromising its integrity.
>

As I understand "cryptography" to be defined it means "the practice and
study of techniques for secure communication in the presence of third
parties". If that is correct, message authentication is most assuredly a
use of "cryptography to securely identify authenticity". If I'm using a
term incorrectly, my apologies.


> > It is more likely to detect accidental corruption than deliberate
> corruption.
>
> I thought that’s what the MD5 bits were for.
>
> My sense from reading the file format wiki page is that the SHA-1 bits
> ensure that blob B, which is intended to appear in the timeline between
> blobs A and C, was almost certainly inserted into the database at time T_b,
> where T_a <= T_b <= T_c.  That is, it is primarily a guarantor of checkin
> ordering.
>
> That’s why I’ve been framing the risk as one of potential insertion of a
> timeline item way in the past.
>
> That may be a bogus risk for other reasons, though, since you’d also have
> to work out how to change all the deltas.
>

The SHA-1 bits ensure (virtually guarantee) that blob B has a unique
identity so that two contributors don't allocate ID 42 at the same time
creating a collision in commit IDs. Artifacts are unordered and can
originally come into a repository from any source in any order. It is
primarily a guarantor of checkin identity, and the individual cards in the
manifest control timeline order, date, time, author, etc.


> It’s also occurred to me since my previous post that all the work needed
> to generate a bogus SHA-1 hash for an HTTPS cert only has to be done once,
> at which point you now have a reusable cert good for months or years.  The
> work needed to attack a single timeline entry in Fossil is a one-shot deal:
> to attack two different nodes in the timeline, you need to do 2x the work.
>

Given that the commit ID is a hash of the manifest, and most of the cards
in the manifest are F cards, in theory all you have to do is find a useful
collision with the SHA-1 hash of any file artifact. If you could modify one
file without changing its SHA-1 hash, everything else in the database would
still match its hash. Of course, if it is too far back in the history
(probably even a single merge behind tip) it may never be noticed because
the project has moved on. And the difficulty still exists of getting it
into the master repository.


> > simply gaining commit access to the master repository as mentioned the
> other day would not be adequate; the maliciously modified artifact would be
> rejected by fossil
>
> I’m no expert in Fossil’s inner workings, and I have no interest in trying
> to attack it.
>
> I’m just aware that Bruce Schneier and Google’s crypto geeks know things I
> do not, and I use that awareness to guide my own design decisions.  The
> last hash-based system I designed used SHA-256. :)
>

I have a lot of respect for Schneier. I would not consider using SHA-1 in a
security sensitive environment today. This use is less about security and
more about non-cryptographic hashing, where an (at one time) cryptographic
strength hash happened to be satisfactory for the needs at hand.


> > I find it far more likely that someone would fork the repo and
> contaminate it that way, rebuilding it from scratch, and finding ways to
> induce parties to use *that* version of the library instead of the blessed
> repo.
>
> Clearly so.
>
> Always attack the weakest link first, if possible.
>
> > * ethernet uses a 32 bit CRC; how much internet traffic goes through
> ethernet? Can't really change that because of backward compatibility.
> > * rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I
> remember correctly). Can't really change that because of backward
> compatibility.
>
> That’s why TLS exists.
>
> TLS doesn’t solve any weaknesses with Fossil’s use of SHA-1, though.  It
> just prevents you from MITM-ing an existing TCP connection.  Once you’ve
> got a TCP connection to the Fossil server, well, *then* what?  That’s the
> purpose of this 

Re: [fossil-users] Admin->Configuration suggests '/home' as index page. How do I create '/home'?

[The Tick]

On 9/15/2015 4:00 PM, Ron W wrote:

On Tue, Sep 15, 2015 at 3:54 PM, The Tick > wrote:

After starting 'fossil ui', I go Admin->Configuration

The Index page value has the suggestion to use '/home'. I did that.
Now, how do I create this '/home' page?


 From the instructions on that set up page:

The default "/home" page displays a Wiki page with the same name as the
Project Name specified above. Some sites prefer to redirect to a
documentation page (ex: "/doc/tip/index.wiki") or to "/timeline".

So, if your project's name is "Fossil", then create a wiki page named
"Fossil".



Ah, so there's a mapping: /home ==> wiki page named 
Thank you
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to embed image in project home page or wiki pages?

[The Tick]

This is my first open source project... I think fossil is the easiest 
source control for me to use, but I've got a lot to learn.


I've not found a way to put an image in the home page for a project.

I did run across a way to embed an image that is checked in as part of a 
project: 
http://stackoverflow.com/questions/3982999/fossil-how-to-display-checked-in-image-files-on-wiki-pages


However, if I do that, then the image would be included in the project 
download, right? I guess one small image would not be that big a deal, 
but it would be good to not foist unnecessary files on users.


I'd like to put a small screenshot image to illustrate the project's 
GUI. Eventually, I will use Chisel to host this project, so perhaps 
there's a way to host an image file outside of a project's repository? 
(And, of course, to reference the image with an  tag.)



___
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] merge after cherrypick plus edit does not identify GCA as I would like

[Steve Stefanovich]

‎Don't know if related, but I've also got unexpected results when subsequently 
merging cherrypick merges:

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg21107.html‎

(I need to come up with reproducible fossil example like you, but perhaps the 
description of the problem as is can still point someone‎ in the right 
direction.)

From: Eric Rubin-Smith‎
Sent: Tuesday, 15 September 2015 01:38
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] merge after cherrypick plus edit does not identify GCA 
as I would like


See the transcript below for gory details.  The summary is:

1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so 
cherrypick it (assume in this example that other stuff is happening on the beta 
branch that we don't want in trunk at the moment, so a normal merge is not 
appropriate).
4. edit the same file on trunk and check it in
5. the "beta" branch now wants to merge the latest from trunk to continue work

==> It's noted as a merge conflict

This is because the GCA calculation does not seem to incorporate the cherrypick 
info (at least in this case).

Perhaps there is some deeper reason for this that I'm unaware of, but for this 
case the behavior is suboptimal.

Transcript illustrating the above:

eas@little:~$ fossil version
This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC
eas@little:~$ mkdir /tmp/fossil
eas@little:~$ cd !$
cd /tmp/fossil
eas@little:/tmp/fossil$ fossil new test.db
project-id: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
server-id:  ba2bb96bf830fa680389b425fa09c5dcfd5370c2
admin-user: eas (initial password is "dc73fc")
eas@little:/tmp/fossil$ mkdir sandbox
eas@little:/tmp/fossil$ cd !$
cd sandbox
eas@little:/tmp/fossil/sandbox$ fossil open /tmp/fossil/test.db
project-name: 
repository:   /tmp/fossil/test.db
local-root:   /tmp/fossil/sandbox/
config-db:/home/eas/.fossil
project-code: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
checkout: 6bb0b6577411bd798631d137bf5b2d7d8fc3ac12 2015-09-14 15:28:16 UTC
tags: trunk
comment:  initial empty check-in (user: eas)
check-ins:1
eas@little:/tmp/fossil/sandbox$ echo 1.0 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil add VERSION
ADDED  VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Add version file"
New_Version: b6f302b927b0289feae9831c80f8b066f6e87d70
eas@little:/tmp/fossil/sandbox$ echo 1.1 > h^CRSION
eas@little:/tmp/fossil/sandbox$ set -o vi
eas@little:/tmp/fossil/sandbox$ echo 1.1b1 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit --branch beta -m "Start beta 
branch."
New_Version: ac64ec791f7be8601848e4c50a87dc54262cc659
eas@little:/tmp/fossil/sandbox$ fossil update trunk
UPDATE VERSION
---
updated-to:   b6f302b927b0289feae9831c80f8b066f6e87d70 2015-09-14 15:28:52 UTC
tags: trunk
comment:  Add version file (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge --cherrypick 
ac64ec791f7be8601848e4c50a87dc54262cc659
UPDATE VERSION
 "fossil undo" is available to undo changes to the working checkout.

eas@little:/tmp/fossil/sandbox$
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Cherrypick version number 
change."
New_Version: 8a4693e6ce2faa5cf3cd1e5a839b33ba7c590d02
eas@little:/tmp/fossil/sandbox$ echo 1.1b1.01 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "More work on the trunk."
New_Version: cee15c31915298ecce84eb0b5aa9b7520e3c8b61
eas@little:/tmp/fossil/sandbox$ fossil update beta
UPDATE VERSION
---
updated-to:   ac64ec791f7be8601848e4c50a87dc54262cc659 2015-09-14 15:29:19 UTC
tags: beta
comment:  Start beta branch. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge trunk
MERGE VERSION
* 1 merge conflicts in VERSION
WARNING: 1 merge conflicts
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ cat VERSION
<<< BEGIN MERGE CONFLICT: local copy shown first <<<
1.1b1
=== COMMON ANCESTOR content follows 
1.0
=== MERGED IN content follows ==
1.1b1.01
>>> END MERGE CONFLICT >
eas@little:/tmp/fossil/sandbox$ exit




___
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] Why Hash

[Scott Doctor]

What are the items that are used to calculate the hash? Is the 
hash salted?



Scott Doctor
sc...@scottdoctor.com
--

On 9/14/2015 10:53 PM, Stephan Beal wrote:
On Mon, Sep 14, 2015 at 7:46 PM, Warren Young 
> wrote:


output, and Fossil would be free to switch to a different
algorithm later if that seemed like a good idea.


Indeed, fossil's model allows any hash to be used, but it is 
not possible to change the hash without a near-complete 
overhaul of fossil (and its docs), nor without invalidating 
every repo in existence, so it's highly unlikely to ever 
happen. Supporting two hash variants in one fossil binary 
would likely prove to be problematic (and would require a 
major overhaul).


And indeed, maybe it is a good idea, since SHA-1 is
nearing its EOL for cryptographic use:

https://www.google.com/?q=sha-1%20end%20of%20life


Fossil does not use it in a cryptographic context, so i would 
argue that that's not relevant for fossil's continued use. 
Fossil only uses sha-1 to define/determine content identity. 
(There are long threads somewhere in the list archives about 
the changes of hash collision. Management summary: not likely 
to happen for many human generations.)


--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed 
byproduct of those who insist on a perfect world, freedom will 
have to do." -- Bigby Wolf



___
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] Why Hash

[Stephan Beal]

On Tue, Sep 15, 2015 at 8:28 AM, Scott Doctor  wrote:

>
> What are the items that are used to calculate the hash? Is the hash salted?


For files/blobs, only their content is hashed (their name/timestamp/etc.,
if any, is not used). No salt is used. If i'm not mistaken (but might be),
a salt is irrelevant (or unnecessary) in a non-cryptographic context.

For passwords a combination of inputs is used: the project code (random hex
bytes), user name, and plain-text password.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Broken repo leads to bad free and SIGSEGV when editing checkin comments

[Jonathan Hankins]

Hello,

TL;DR: One-line patch seems to fix it:

--- db.c.orig   2015-09-14 20:14:25.324662150 -0500
+++ db.c2015-09-14 20:17:01.742666003 -0500
@@ -2015,7 +2015,7 @@
 if( zDefault==0 && pSetting && pSetting->def[0] ){
   z = fossil_strdup(pSetting->def);
 }else{
-  z = zDefault;
+  z = mprintf("%s", zDefault);
 }
   }
   return z;



Not sure how my original repo got into this state, but I was able to
reproduce my issue.

Symptom was, I could not edit the existing comments on several checkins on
my trunk.  As soon as I clicked the "edit" link on the checkin page, I got
an empty browser page that says "ERR_EMPTY_RESPONSE" (Chrome).  Other
operations seem to be OK, and I was able to create a new branch and keep
working there.

Started digging, and the child process is getting SIGSEGV at info.c:2703

[This is fossil version 1.33 [f6c13632bb] 2015-09-12 19:18:28 UTC]

[ci_edit_page()]

2703   if( zBranchName ) fossil_free(zBranchName);

Here's what's happening: for some reason, several of the checkins in trunk
are missing the record in the tagxref table with tagid = 8 (TAG_BRANCH),
 This results in an empty response in from db_text() at info.c:2620

[ci_edit_page()]

2620   zBranchName = db_text(0, "SELECT value FROM tagxref, tag"
2621  " WHERE tagxref.rid=%d AND tagtype>0 AND tagxref.tagid=tag.tagid"
2622  " AND tagxref.tagid=%d", rid, TAG_BRANCH);

Then at info.c:2662:

2662   if( !zBranchName ){
2663 zBranchName = db_get("main-branch", "trunk"); /* 2nd arg "trunk"
is value for zDefault, see below */
2664   }

In my config table (fresh repo) there is no value for "main-branch" even
though the settings GUI has "trunk" in the text box (presumably as a
default, when there is no main-branch setting in the db, but I haven't
looked.)  So, at db.c:2018, it falls back to using "zDefault":

[db_get()]

2014   if( z==0 ){
2015 if( zDefault==0 && pSetting && pSetting->def[0] ){
2016   z = fossil_strdup(pSetting->def);
2017 }else{
2018   z = zDefault;
2019 }
2020   }
2021   return z;
2022 }

Resulting in an attempted free() on a the const string "trunk" passed as
zDefault in the call to db_get.

This crashes the child of the "server" process with SIGSEGV.

To duplicate, create a new repo and make some checkins.  Run sqlite on the
db, and:

delete from tagxref where tagid = 8 order by rid desc limit 1;

This will break the most recent checkin -- try clicking the "edit" link to
verify.

-Jonathan Hankins
___
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] Broken repo leads to bad free and SIGSEGV when editing checkin comments

[Richard Hipp]

On 9/15/15, Jonathan Hankins  wrote:
> Hello,
>
> TL;DR: One-line patch seems to fix it:

Thanks.  I checked in a slightly different change.
https://www.fossil-scm.org/fossil/info/868404c0a3adc017

>
> --- db.c.orig   2015-09-14 20:14:25.324662150 -0500
> +++ db.c2015-09-14 20:17:01.742666003 -0500
> @@ -2015,7 +2015,7 @@
>  if( zDefault==0 && pSetting && pSetting->def[0] ){
>z = fossil_strdup(pSetting->def);
>  }else{
> -  z = zDefault;
> +  z = mprintf("%s", zDefault);
>  }
>}
>return z;
>
> 
>
> Not sure how my original repo got into this state, but I was able to
> reproduce my issue.
>
> Symptom was, I could not edit the existing comments on several checkins on
> my trunk.  As soon as I clicked the "edit" link on the checkin page, I got
> an empty browser page that says "ERR_EMPTY_RESPONSE" (Chrome).  Other
> operations seem to be OK, and I was able to create a new branch and keep
> working there.
>
> Started digging, and the child process is getting SIGSEGV at info.c:2703
>
> [This is fossil version 1.33 [f6c13632bb] 2015-09-12 19:18:28 UTC]
>
> [ci_edit_page()]
>
> 2703   if( zBranchName ) fossil_free(zBranchName);
>
> Here's what's happening: for some reason, several of the checkins in trunk
> are missing the record in the tagxref table with tagid = 8 (TAG_BRANCH),
>  This results in an empty response in from db_text() at info.c:2620
>
> [ci_edit_page()]
>
> 2620   zBranchName = db_text(0, "SELECT value FROM tagxref, tag"
> 2621  " WHERE tagxref.rid=%d AND tagtype>0 AND tagxref.tagid=tag.tagid"
> 2622  " AND tagxref.tagid=%d", rid, TAG_BRANCH);
>
> Then at info.c:2662:
>
> 2662   if( !zBranchName ){
> 2663 zBranchName = db_get("main-branch", "trunk"); /* 2nd arg "trunk"
> is value for zDefault, see below */
> 2664   }
>
> In my config table (fresh repo) there is no value for "main-branch" even
> though the settings GUI has "trunk" in the text box (presumably as a
> default, when there is no main-branch setting in the db, but I haven't
> looked.)  So, at db.c:2018, it falls back to using "zDefault":
>
> [db_get()]
>
> 2014   if( z==0 ){
> 2015 if( zDefault==0 && pSetting && pSetting->def[0] ){
> 2016   z = fossil_strdup(pSetting->def);
> 2017 }else{
> 2018   z = zDefault;
> 2019 }
> 2020   }
> 2021   return z;
> 2022 }
>
> Resulting in an attempted free() on a the const string "trunk" passed as
> zDefault in the call to db_get.
>
> This crashes the child of the "server" process with SIGSEGV.
>
> To duplicate, create a new repo and make some checkins.  Run sqlite on the
> db, and:
>
> delete from tagxref where tagid = 8 order by rid desc limit 1;
>
> This will break the most recent checkin -- try clicking the "edit" link to
> verify.
>
> -Jonathan Hankins
>


-- 
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] merge after cherrypick plus edit does not identify GCA as I would like

[Eric Rubin-Smith]

> The merge algorithm does *not* consider cherry-picks.  It looks for
> the most recent common ancestor without taking cherry-picks into
> account.

Another popular version control tool whose name I won't mention (hint: rhymes 
with "zit") behaves identically to fossil in this scenario. Is there some 
deeper reason for not using the cherry pick "arrow", or is it simply that yall 
haven't had a need to improve the behavior here yet so haven't bothered?

> On the other hand, the merge algorithm will usually recognize when the
> same edit is applied twice, and do the right thing.
> -- 
> 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] merge after cherrypick plus edit does not identify GCA as I would like

[Richard Hipp]

On 9/15/15, Eric Rubin-Smith  wrote:
>
>> The merge algorithm does *not* consider cherry-picks.  It looks for
>> the most recent common ancestor without taking cherry-picks into
>> account.
>
> Another popular version control tool whose name I won't mention (hint:
> rhymes with "zit") behaves identically to fossil in this scenario. Is there
> some deeper reason for not using the cherry pick "arrow", or is it simply
> that yall haven't had a need to improve the behavior here yet so haven't
> bothered?
>

Merge is done by a classic 3-way diff.  It looks at all the changes
that occurred on the path from A to B and applies those same changes
to C.  (A in this case would be the most recent common ancestor of B
and C).

How would cherry-picks factor into this?

-- 
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] merge after cherrypick plus edit does not identify GCA as I would like

[Scott Doctor]

a sideways question on this topic. Assume in my C editor I run 
the code formatter operation which indents and parses certain 
tokens for cosmetic, but not functional, changes in the file. By 
parsing I mean operations such as adding/removing linefeeds 
before/after a token such as a bracket or semicolon, and 
removing/adding blanks lines and spaces.


Will the merge and diff operations see the file as completely 
changed?




Scott Doctor
sc...@scottdoctor.com
--

On 9/15/2015 5:13 AM, Richard Hipp wrote:

On 9/15/15, Eric Rubin-Smith  wrote:

The merge algorithm does *not* consider cherry-picks.  It looks for
the most recent common ancestor without taking cherry-picks into
account.

Another popular version control tool whose name I won't mention (hint:
rhymes with "zit") behaves identically to fossil in this scenario. Is there
some deeper reason for not using the cherry pick "arrow", or is it simply
that yall haven't had a need to improve the behavior here yet so haven't
bothered?


Merge is done by a classic 3-way diff.  It looks at all the changes
that occurred on the path from A to B and applies those same changes
to C.  (A in this case would be the most recent common ancestor of B
and C).

How would cherry-picks factor into this?



___
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] Why Hash

[Ron W]

On Tue, Sep 15, 2015 at 2:34 AM, Stephan Beal  wrote:
>
> For files/blobs, only their content is hashed (their name/timestamp/etc.,
> if any, is not used). No salt is used. If i'm not mistaken (but might be),
> a salt is irrelevant (or unnecessary) in a non-cryptographic context.
>

 FYI, salts are mainly used for hashing passwords and authentication
tokens. This is to make the hashes different each time.

When using hashes to identify and/or check the integrity of documents,
salting doesn't really add to the security of either the hash or the
document.

Fossil, by using hashes as identifiers, also provides some integrity
checking of the stored documents. While Fossil is *not* generally
considered a cryptographic tool, the integrity checking it implicitly
provides could be considered a cryptographic feature.

Also, as I pointed in an earlier post, the description of how Fossil uses
GPG, PGP or similar tool, implies only the manifest gets signed. Therefor,
the signature might rely on hashes generated by Fossil.

Because of the way signatures work, if GPG were using SHA1, it would give
the same result as encrypting the manifest ID with the user's private key.
Of course, GPG can use newer, presumably better, algorithms.
___
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] Why Hash

[Ron W]

On Tue, Sep 15, 2015 at 1:53 AM, Stephan Beal  wrote:

> Indeed, fossil's model allows any hash to be used, but it is not possible
> to change the hash without a near-complete overhaul of fossil (and its
> docs), nor without invalidating every repo in existence, so it's highly
> unlikely to ever happen. Supporting two hash variants in one fossil binary
> would likely prove to be problematic (and would require a major overhaul).
>

What parts of Fossil's source I have looked at seem to be well structure. I
would be surprised if changing the hash algorithm required changing the
internals of 1, maybe 2 functions.

As for repo compatibility, if nothing else, a build option to select the
hash algorithm to use.

It would also be a good idea that repos using other than SHA1 have a new
card in their manifests to indicate (and identify) use of a different has
algorithm.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Admin->Configuration suggests '/home' as index page. How do I create '/home'?

[The Tick]

Following a recommendation to use fossil and Chisel for my very first 
open source project, my impression of fossil is very favorable. I've 
downloaded fossil to my win7x64 PC, created a repository and am now 
trying to set it up as I eventually will on Chisel (I assume).


After starting 'fossil ui', I go Admin->Configuration

The Index page value has the suggestion to use '/home'. I did that. Now, 
how do I create this '/home' page?


I clicked on 'Wiki' and it let me create a 'new' page. I called it 
'home' and put some content there.


Where is it? Why does it not show up when I click 'Home'?

I found a discussion in the archives that had some suggestions as to 
various options. I don't yet understand what's being suggested. So, I 
just want to keep things really, really simple to start with.


How do I create this '/home' page so that I don't get 'Empty page' when 
I click on 'Home'?


[As an aside, when I click on 'Home' I see 'Project name / project name' 
as the heading. Is there any way to remove the redundancy?]


___
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] Admin->Configuration suggests '/home' as index page. How do I create '/home'?

[Ron W]

On Tue, Sep 15, 2015 at 3:54 PM, The Tick  wrote:
>
> After starting 'fossil ui', I go Admin->Configuration
>
> The Index page value has the suggestion to use '/home'. I did that. Now,
> how do I create this '/home' page?
>

>From the instructions on that set up page:

The default "/home" page displays a Wiki page with the same name as the
Project Name specified above. Some sites prefer to redirect to a
documentation page (ex: "/doc/tip/index.wiki") or to "/timeline".

So, if your project's name is "Fossil", then create a wiki page named
"Fossil".
___
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] merge after cherrypick plus edit does not identify GCA as I would like

[Richard Hipp]

On 9/14/15, Eric Rubin-Smith  wrote:
> See the transcript below for gory details.  The summary is:
>
> 1. create a new file on trunk and check it in.
> 2. edit the file and check in on a branch (let's call it "beta")
> 3. trunk decides it wants that particular change set from step (2), so
> cherrypick it (assume in this example that other stuff is happening on the
> beta branch that we don't want in trunk at the moment, so a normal merge is
> not appropriate).
> 4. edit the same file on trunk and check it in
> 5. the "beta" branch now wants to merge the latest from trunk to continue
> work
>

The merge algorithm does *not* consider cherry-picks.  It looks for
the most recent common ancestor without taking cherry-picks into
account.

On the other hand, the merge algorithm will usually recognize when the
same edit is applied twice, and do the right thing.
-- 
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] merge after cherrypick plus edit does not identify GCA as I would like

[Eric Rubin-Smith]

> Merge is done by a classic 3-way diff.  It looks at all the changes
> that occurred on the path from A to B and applies those same changes
> to C.  (A in this case would be the most recent common ancestor of B
> and C).
>
> How would cherry-picks factor into this?
>

Sorry, maybe I'm confused.  I'm not at the moment talking about the 3-way
diff algorithm, but the step before that in which the GCA (your 'A') is
determined.  You said that the GCA calculation does not consider
cherry-pick merges.  I'm wondering whether there is a deep reason for that,
or if it's just because no one has yet had a need for it.

Perhaps it is because if cherry-picks are considered, then you'd have to
determine a GCA for every file rather than for the check-ins as a whole,
and you believe this will be too slow?  Or maybe there is some deeper
logical problem that I haven't considered.

In my initial example, if the cherry-picks were considered then the 'beta'
leaf would be the GCA for my test file, so the merge would be a trivial one
(simply take the current 'trunk' leaf as the new file data).

Eric
___
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] merge after cherrypick plus edit does not identify GCA as I would like

[Stephan Beal]

Fossil knows nothing about syntax of any sort, so a merge must consider any
change as significant. Try reindenting a python script, where whitespace is
part of the syntax. Diff can be told to ignore changes in spacing, iirc. If
you switch from unix EOL to Windows EOL fossil will see the whole file
(well, the EOL bytes) as changed.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
On Sep 15, 2015 2:24 PM, "Scott Doctor"  wrote:

>
> a sideways question on this topic. Assume in my C editor I run the code
> formatter operation which indents and parses certain tokens for cosmetic,
> but not functional, changes in the file. By parsing I mean operations such
> as adding/removing linefeeds before/after a token such as a bracket or
> semicolon, and removing/adding blanks lines and spaces.
>
> Will the merge and diff operations see the file as completely changed?
>
>
> 
> Scott Doctor
> sc...@scottdoctor.com
> --
>
> On 9/15/2015 5:13 AM, Richard Hipp wrote:
>
>> On 9/15/15, Eric Rubin-Smith  wrote:
>>
>>> The merge algorithm does *not* consider cherry-picks.  It looks for
 the most recent common ancestor without taking cherry-picks into
 account.

>>> Another popular version control tool whose name I won't mention (hint:
>>> rhymes with "zit") behaves identically to fossil in this scenario. Is
>>> there
>>> some deeper reason for not using the cherry pick "arrow", or is it simply
>>> that yall haven't had a need to improve the behavior here yet so haven't
>>> bothered?
>>>
>>> Merge is done by a classic 3-way diff.  It looks at all the changes
>> that occurred on the path from A to B and applies those same changes
>> to C.  (A in this case would be the most recent common ancestor of B
>> and C).
>>
>> How would cherry-picks factor into this?
>>
>>
> ___
> 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] Multiple Projects in one Repo

[David Mason]

On 14 September 2015 at 13:58, Warren Young  wrote:

> On Sep 12, 2015, at 9:54 AM, Oliver Friedrich <
> redtalonof+mailingl...@gmail.com> wrote:
> >
> > with nested repositories my administration overhead would exceed even
> the single repository solution, right?
>
> The alternative to managing just one .fossil file is managing just one
> directly full of .fossil files.  Is that really such a big difference?
>
> Note that “fossil serve” works the same when pointed to a directory full
> of fossils as it does when pointed at a single fossil, with the exception
> that the URLs are all one directory deeper.


I use nested checkouts and I have many .fossil files in my ~/Fossils
directory.  One of them, Admin, has a wiki page that points to pages in the
others so I can access them easily.  I keep the url
http://localhost:8080/Admin/wiki?name=Admin open in one of my browser tabs
(actually the first one) so I can easily get at any of the repos in one
click.  I have sections in that wiki page like:

Direct Links
  *  Courses Links
  *  CPS313 Links

Administrative links
  *  Courses
  *  Research

along with other generally useful links.

Yes, I have to use --nested when I open a new directory on a repo, but I do
that only a few times a year (in fact, I usually forget, but fossil tells
me there's a problem, so I re-issue the open with --nested).

../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users