Re: [fossil-users] Why Hash

[Michal Suchanek]

On 16 September 2015 at 05:16, Scott Robison  wrote:
> 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 

Re: [fossil-users] Why Hash

[Noam Postavsky]

On Wed, Sep 16, 2015 at 1:38 AM, Stephan Beal  wrote:
> (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.

This might be too optimistic. According to Antoine Joux in
"Multicollisions in Iterated Hash Functions. Application to Cascaded
Constructions" [1]

A natural construction to build large hash values is to
concatenate several smaller
hashes. For example, given two hash functions F and G, it seems
reasonable given
a message M to form the large hash value (F(M)||G(M)). In this construction,
F and G can either be two completely different hash functions or
two slightly
different instances of the same hash function. If F and G are good
iterated hash
functions with no attack better than the generic birthday paradox attack, we
claim that the hash function F||G obtained by concatenating F and G is not
really more secure that F or G by itself. Moreover, this result
applies both to
collision resistance, preimage resistance and second preimage resistance.
[...]
Another generalization of the above attack is also worth noting. In [14],
B. Schneier described a different way of building a long hash from
a hash function
F. In this method, F(M) is concatenated with G(F(M)||M) (or G(M||F(M))).
At first view, this is more complicated than the F||G
construction. However, the
very same attack can be applied.
[...]
One can also study a related question, how does the security of
the concatenated
hash F||G behaves, when F and G have non-generic attacks better than
the birthday paradox collision search? In that case, can F||G be
significantly
more secure than the best of F and G?
[...] if G also admits a shortcut attack (as in section 3), it is
unclear whether
the two shortcut attacks may be used together to improve the composed attack
against F||G. Yet, some other type of attacks against G can be
integrated into a
better composed attack on F||G. ... Thus, it is safer to assume that F||G is
essentially as secure as the best of F and G, no more.

[1] http://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19
___
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

[Richard Hipp]

On 9/16/15, Noam Postavsky  wrote:
> On Wed, Sep 16, 2015 at 1:38 AM, Stephan Beal 
> wrote:
>> (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.
>
> This might be too optimistic. According to Antoine Joux in
> "Multicollisions in Iterated Hash Functions. Application to Cascaded
> Constructions" [1]
>
>
> [1] http://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19

Fascinating.  Thanks for the link!

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

[Scott Robison]

On Sep 16, 2015 3:24 AM, "Michal Suchanek"  wrote:
>
> On 16 September 2015 at 05:16, Scott Robison 
wrote:
> > But GPG could solve any weaknesses with Fossil's use of SHA-1, though.
It
> > won't prevent a determined party from deconstructing a repo, making
whatever
> > changes are desired, and rebuilding a believable facsimile that unwary
> > parties might trust. The rebuilt repo could even have fraudulent GPG
> > signatures attached just to make it feel more legit to people who don't
> > really check such things.
>
> It has been pointed out that when using GPG to sign checking only the
> manifests are signed and what links the manifests to the rest of the
> content like actual file blobs or previous checkins are the weak SHA-1
> hashes.

Right, I didn't mean "GPG can fix this today with the current
implementation in fossil". Just that it could be used to authenticate the
source of global repo state.

If we accept that sha1 is used for nothing more than identification and a
way to validate an artifact as having not been accidentally modified, then
clearly another means of authentication is necessary if it is a required
feature. I accept that all artifacts should be signed for such a feature
and that it is not happening at this time.

>
> So while it is possible to use PGP with fossil it gives only a false
> sense of security until fossil itself uses crypto grade hash to link
> its internal articact structure.
>
> Using a stronger or configurable hash for the internal linking of
> artifacts would result in ability to verify the authenticity of a copy
> of a signed repo even from unknown source so long as the signatures
> are valid.
>
> As actual signed repos are rare this is not really strong use case. On
> the other hand, they may be rare because there is no real point.

I think they are rare because signing and verifying is a pain and we trust
the official versions of repos. Arguably we should not. Even if GPG were
being used completely and effectively, how can we be sure someone's private
keys weren't compromised?

We've talked on list before about how (with regard to computers) nothing is
perfect, everything is statistically flawed in some way making it less than
100% guaranteed to work properly. I think fossil's (and other dvcs) use of
sha1 fits in this category. It isn't perfect, but it is close enough for
the use case.

>
> Thanks
>
> Michal
> ___
> 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] How to embed image in project home page or wiki pages?

[Ron W]

On Tue, Sep 15, 2015 at 9:24 PM, The Tick  wrote:
>
>
> 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.


Yes, you can simply copy that URL to the home page. You will need to update
it each time you make a release.

In theory, it is also possible to craft an URL that would also provide a
zip of the latest with a particular tag, such as "release". Not sure if
this is a good idea, but it would eliminate the need to update the home
page for each release. (Personally, I prefer to
explicitly update my download page for each release.)


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


To have a file appear in only one version in the repository:
fossil add path/to/file
fossil commit -m 'comment about file being added' # the ID of this
commit is the version containing the file.
fossil rm path/to/file
fossil commit -m 'Make it so this file only appears in the previous
commit'

You can add more than one file this way. To access the file, it will be
necessary to refer to it using the commit ID of the version containing the
file. (Alternately, you can use the artifact ID of the file.)


> Again, thanks for your help.


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

[fossil-users] Stash-cat

[bch]

Hi. I pushed http://fossil-scm.org/index.html/info/533f8b6aeacb554f on its
own branch for review (philosophical/ui, or errors/updates); otherwise,
it's ready for integration.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Interesting video on Google repository

[Scott Robison]

https://www.youtube.com/watch?v=W71BTkUbdqE

-- 
Scott Robison
___
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

[Steve Stefanovich]

‎Isn't the main annoyance the need to commit two times, one in nested checkout 
and one in the 'root' repo, and to try to keep timeline order in both?

How do you guys manage that - prevent committing/cloning to root and always use 
sub-repos?


  Original Message
From: Warren Young
Sent: Tuesday, 15 September 2015 03:58
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Multiple Projects in one Repo


On Sep 12, 2015, at 9:54 AM, Oliver Friedrich 
 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.

There are two annoyances currently involved in managing nested repositories, 
which could in principle go away: the need to explicitly open the 
sub-repositories every time you open the primary, and the need to pass --nested 
to bypass the checks Fossil does for a parent containing .fslckout (a.k.a. 
_FOSSIL_).

Git solves this problem more elegantly with the submodule:

  https://git-scm.com/book/en/v2/Git-Tools-Submodules

In short, the main project simply declares that it needs other projects by URL. 
When you clone the main project, Git also clones the submodules into the 
correct place within the parent’s tree.

I use nested checkouts myself, though probably for a different reason than 
you’re proposing.  I have a top-level repository with many branches for older 
versions of the software, and all versions need to share a single set of 
Fossil-managed resource files.  These shared resource files must be versioned 
separately from the main repository files, but the current version must always 
be present underneath the main repository branches.  If I have three branches 
checked out, I need three additional nested checkouts of the shared repository.

It would be very nice if I could just open each branch, and have the 
subproject’s repo opened in its correct place, automatically.
___
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] Interesting video on Google repository

[Warren Young]

On Sep 16, 2015, at 12:13 PM, Scott Robison  wrote:
> 
> https://www.youtube.com/watch?v=W71BTkUbdqE

The point I took from that that seems most applicable to Fossil is the idea 
that “workspaces” (i.e. local clones) are not complete copies of the entire 
repo’s history. 

In Google’s case, it’s because it would simply be unfeasible, at 86 TB, yet 
would include millions of old files that don’t even exist at the tip of the 
trunk any more.

While there probably isn’t anyone on this list with a Fossil repo anywhere near 
this size, the lesson remains: you probably don’t actually need the entire repo 
history in your local clone.

Some months ago, the thread “Fossil 2.1: Scaling” thread touched on this:

  http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/019952.html

In that thread, I proposed that the default mode of “fossil clone” be to 
include only the last N weeks of work on each open branch.  The idea being, you 
rarely need more than that except for archaeology work, at which point Fossil 
could go back to the repo it cloned from and import more of the history.

The amount of history per branch should be configurable, and of course it 
should be possible to disable the limit, so that you get a complete clone, 
which is nice for distributed backups.  (I’m reminded of a Linus Torvalds 
quote, where he said he never did backups, because his code is already 
distributed all over the world.)

Has there been any movement on that front?
___
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

[Andy Bradford]

Thus said Oliver Friedrich on Sat, 12 Sep 2015 12:34:21 -:

> What I  really would  like to  have is to  gather multiple  such small
> projects in  one repo file,  so instead  of having one  ROOT check-in,
> having one  ROOT for each project.  I know that would  make developing
> fossil a bit harder, but I think  it would be a great feature and that
> not I'm the only one who would use this.

You  mean like  this: assume  you  have two  Fossils, master.fossil  and
project.fossil. You  want to combine  the projects into a  single Fossil
but retain an independent timeline for each:

$ echo "SELECT 'UPDATE config SET value = ''' || value || ''' WHERE name = 
''project-code'';' FROM config WHERE name = 'project-code';" | fossil sql -R 
master.fossil | fossil sql -R project.fossil
$ fossil pull --once -R master.fossil project.fossil

Now, master will have two independent timelines, one from each project.

You'll then  want to  rename one  of the  trunks (and  maybe give  it an
intentional color  too) in  one of  the timelines  to something  else or
you'll get a warning about there being  two open leaves with the name of
trunk (even though technically there really isn't a fork in this case).

> But I  guess that implementing  this could be much  harder, especially
> visualizations in the web-frontend.

The web-frontend can handle visualizing this just fine I think. What may
take some getting used  to is that the files and  checkins will not have
common ancestors.

Also,  if  you   have  the  same  exact  filename  (and   path)  in  one
``sub-project''  that exists  in another,  the Files  display in  Fossil
might be tricky to navigate. But otherwise, it will probably work well.

Here's an example:

http://fossil.bradfords.org:8080/timeline

But, the same filename exists in  all three timelines, but has different
content. Files only shows the last (due to tip):

http://fossil.bradfords.org:8080/dir?ci=tip

You could  certainly change  the Header  to have  multiple links  to the
various files of a given ``sub-project'' like:

Trunk Files: http://fossil.bradfords.org:8080/dir?ci=trunk
Project1 Files: http://fossil.bradfords.org:8080/dir?ci=project1
Project2 Files: http://fossil.bradfords.org:8080/dir?ci=project2

What if you need  files from different projects at the  same time in the
same tree?  Well, you'll  have to  resort to  multiple opens  (and maybe
--nested) for that.

Andy
-- 
TAI64 timestamp: 400055fa4bb3


___
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 16 September 2015 at 21:56, Steve Stefanovich  wrote:

> ‎Isn't the main annoyance the need to commit two times, one in nested
> checkout and one in the 'root' repo, and to try to keep timeline order in
> both?
>
> How do you guys manage that - prevent committing/cloning to root and
> always use sub-repos?


There's only one commit, in the sub-repo, unless I change something in the
root repo, but that's pretty rare for me.

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