Re: [fossil-users] Why Hash

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 reb

Re: [fossil-users] Why Hash

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 > "Multic

Re: [fossil-users] Why Hash

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. Applicat

Re: [fossil-users] Why Hash

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, ther

Re: [fossil-users] Why Hash

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 i

Re: [fossil-users] Why Hash

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 th

Re: [fossil-users] Why Hash

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 me

Re: [fossil-users] Why Hash

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 authenticate

Re: [fossil-users] Why Hash

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 preimag

Re: [fossil-users] Why Hash

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

Re: [fossil-users] Why Hash

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 th

Re: [fossil-users] Why Hash

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,

Re: [fossil-users] Why Hash

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 ha

Re: [fossil-users] Why Hash

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

Re: [fossil-users] Why Hash

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 irr

Re: [fossil-users] Why Hash

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 mailto:w...@etr-usa.com>> wrote: output, and Fossil wo

Re: [fossil-users] Why Hash

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 f

Re: [fossil-users] Why Hash

On Sep 14, 2015, at 4:40 PM, Warren Young wrote: > > glibc-based Linux systems cope with this problem in /etc/shadow by tagging > the hash I just learned that this isn’t a Linux-specific thing, that it is in fact a pseudostandard also used on the BSDs and in various other places: http://pyt

Re: [fossil-users] Why Hash

On Sep 14, 2015, at 4:24 PM, Ron W wrote: > > On Mon, Sep 14, 2015 at 1:46 PM, Warren Young wrote: > > > What would be gained is that people wouldn’t be trying to work out how to > > match sha1sum commands to Fossil output, > > fossil artifact id | sha1sum - > sha1sum path/to/file See, that

Re: [fossil-users] Why Hash

On Mon, Sep 14, 2015 at 1:46 PM, Warren Young wrote: > The question is, “Why does this UI web page have to *say* that it is a > SHA-1 hash?” > > If this page just said “checkin ID,” what would be lost? > As far as VCS functionality, nothing. On the other hand, many projects publish the hashes f

Re: [fossil-users] Why Hash

On Mon, Sep 14, 2015 at 3:10 PM, Scott Robison wrote: > > I wasn't really thinking of who might want to do it, just that sha1 isn't > being used for cryptographic security and that would be covered by other > means (GPG for example). > The hashes can be important for verifying the integrity of th

Re: [fossil-users] Why Hash

On Mon, Sep 14, 2015 at 1:01 PM, Warren Young wrote: > On Sep 14, 2015, at 12:11 PM, Scott Robison > wrote: > > > > > Fossil would be free to switch to a different algorithm later if that > seemed like a good idea. > > > > Is this really a problem? Given that the checkin ID is generated from a >

Re: [fossil-users] Why Hash

On Sep 14, 2015, at 12:11 PM, Scott Robison wrote: > > > Fossil would be free to switch to a different algorithm later if that > > seemed like a good idea. > > Is this really a problem? Given that the checkin ID is generated from a > structured manifest file which is generated in part from sha

Re: [fossil-users] Why Hash

On Mon, Sep 14, 2015 at 11:46 AM, Warren Young wrote: > On Sep 12, 2015, at 2:26 AM, Stephan Beal wrote: > > > > On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote: > > For instance, why even mention “SHA1 Hash” on the checkin details page > in fossil ui, from src/info.c? Why not something m

Re: [fossil-users] Why Hash

On Sep 12, 2015, at 2:26 AM, Stephan Beal wrote: > > On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote: > For instance, why even mention “SHA1 Hash” on the checkin details page in > fossil ui, from src/info.c? Why not something more generic, like “checkin > ID”? > > The checkin ID is the

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 04:57:46PM -0600, Warren Young wrote: > I wonder if this is an implementation detail leaking through into the > UI, though. Under what conditions, except for Noam’s contrived example > with hardcoded dates, is there a useful distinction between “hash” — > implying a number

Re: [fossil-users] Why Hash

On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote: > For instance, why even mention “SHA1 Hash” on the checkin details page in > fossil ui, from src/info.c? Why not something more generic, like “checkin > ID”? > The checkin ID is the hash of the manifest for the checkin. e.g. try: [stephan@

Re: [fossil-users] Why Hash

On Sep 11, 2015, at 5:27 PM, Ron W wrote: > > They will ask why isn't it a small number like, for example, SVN uses. Solution: use tags. :) > Then they ask how do we know it's really unique? By telling them (in > simplified terms) how it is computed, they more readily accept the need for > su

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 6:57 PM, Warren Young wrote: > > I wonder if this is an implementation detail leaking through into the UI, > though. Under what conditions, except for Noam’s contrived example with > hardcoded dates, is there a useful distinction between “hash” — implying a > number that y

Re: [fossil-users] Why Hash

On Sep 11, 2015, at 4:46 PM, Ron W wrote: > > The commit ID really is a hash. It is the hash of the manifest artifact. The > manifest's 'D Card' has the date/time stamp of the commit. Also, the > manifest's 'P card' refers to the parent commit(s). Therefore, the commit IDs > of otherwise ident

Re: [fossil-users] Why Hash

On Sep 11, 2015, at 4:40 PM, Noam Postavsky wrote: > > On Fri, Sep 11, 2015 at 5:28 PM, Warren Young wrote: >> On Sep 11, 2015, at 2:34 PM, Noam Postavsky >> wrote: >>> >>> Okay, if you define branch that way… >> >> It isn’t a question of philosophical semantics. Stephan is telling you a

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 5:28 PM, Warren Young wrote: > It isn’t really a hash since it isn’t computed from the contents of the > artifact. It’s just a random number, expressed as a long hex string. It > *looks* like a hash, but it isn’t. Proof: > > cd ~/tmp > f new ../x.fossil > f new ..

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 5:28 PM, Warren Young wrote: > On Sep 11, 2015, at 2:34 PM, Noam Postavsky > wrote: >> >> Okay, if you define branch that way… > > It isn’t a question of philosophical semantics. Stephan is telling you a > fact about how Fossil behaves, not offering a fuzzy definition.

Re: [fossil-users] Why Hash

On Sep 11, 2015, at 2:34 PM, Noam Postavsky wrote: > > Okay, if you define branch that way… It isn’t a question of philosophical semantics. Stephan is telling you a fact about how Fossil behaves, not offering a fuzzy definition. Maybe I’m being overly sensitive about your choice of words, bu

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 4:04 PM, Michal Suchanek wrote: > On 11 September 2015 at 17:13, Noam Postavsky > wrote: >> On Fri, Sep 11, 2015 at 3:57 AM, Michal Suchanek wrote: >>> On 10 September 2015 at 19:23, Noam Postavsky >>> wrote: For example see figure 3 of http://fossil-scm.org/xf

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 10:15 PM, Scott Doctor wrote: > > I am getting confuzzled. Could someone explain the difference between a > leaf, branch, and fork. > In fossil a branch and fork are technically the same thing, the terms are just used in different contexts (branch = intentional, fork = un

Re: [fossil-users] Why Hash

I am getting confuzzled. Could someone explain the difference between a leaf, branch, and fork. Scott Doctor sc...@scottdoctor.com -- On 9/11/2015 1:04 PM, Michal Suchanek wrote: On 11 September 2015 at 17

Re: [fossil-users] Why Hash

On 11 September 2015 at 17:13, Noam Postavsky wrote: > On Fri, Sep 11, 2015 at 3:57 AM, Michal Suchanek wrote: >> On 10 September 2015 at 19:23, Noam Postavsky >> wrote: >>> For example see figure 3 of >>> http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki >>> >>> Both check-ins 3 and 4 are

Re: [fossil-users] Why Hash

On Fri, Sep 11, 2015 at 3:57 AM, Michal Suchanek wrote: > On 10 September 2015 at 19:23, Noam Postavsky > wrote: >> For example see figure 3 of >> http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki >> >> Both check-ins 3 and 4 are equidistant from the root. > > And each is on a differnt bran

Re: [fossil-users] Why Hash

On 10 September 2015 at 19:23, Noam Postavsky wrote: > On Thu, Sep 10, 2015 at 9:29 AM, Michal Suchanek wrote: >> Given that fossil does not support history rewriting by design the >> commit number on a particular branch counting from root is unique and >> stable per branch across all repos. >> >

Re: [fossil-users] Why Hash

On 9/10/2015 1:03 PM, Ron W wrote: On Thu, Sep 10, 2015 at 2:30 PM, Ross Berteig mailto:r...@cheshireeng.com>> wrote: (Rant: Just when will IDE authors learn to prominently document their project databases to make interoperation with any VCS easier?) You mean so you more easily ignore or m

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 2:30 PM, Ross Berteig wrote: > > I realized mid change the other day that the repo I was in had a bunch of > IDE private project data files that had been checked in. (Rant: Just when > will IDE authors learn to prominently document their project databases to > make interope

Re: [fossil-users] Why Hash

On 9/10/2015 3:44 AM, Jacek Cała wrote: Long time ago I was trying to propose and (almost) implemented numbering for changes, so you could do selective commit with range of files like 1-5,7. There was little interest in that feature, so I gave up. All in all, I think it would be nice to ad

Re: [fossil-users] Why Hash

On Thu, 10 Sep 2015 20:16:52 +0200, Martin Gagnon wrote: On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote: On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff <[1]veedeeh...@googlemail.com> wrote: and it really is just irrelevant for the simple envisaged convenience

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 08:39:49PM +0300, Baruch Burstein wrote: >On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff ><[1]veedeeh...@googlemail.com> wrote: > > and it really is just irrelevant for the simple envisaged convenience > measure: being able to use the ranks instead of th

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 8:03 PM, j. van den hoff wrote: > > and it really is just irrelevant for the simple envisaged convenience > measure: being able to use the ranks instead of the hashes for identifying > checkins in _my_ clone when interacting with fossil. I am starting to agree. When I use

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 9:29 AM, Michal Suchanek wrote: > Given that fossil does not support history rewriting by design the > commit number on a particular branch counting from root is unique and > stable per branch across all repos. > > If you release from a single master branch you have a monot

Re: [fossil-users] Why Hash

On Thu, 10 Sep 2015 16:54:30 +0200, Martin Gagnon wrote: On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote: On 10 September 2015 at 15:17, j. van den hoff wrote: > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal > wrote: > >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein

Re: [fossil-users] Why Hash

On Thu, 10 Sep 2015 11:29:15 -0400 Ron W wrote: [...] > Personally, I would find some kind of relative specification more > useful. For example, if I could say "fossil gdiff --from cur-3" and > get a diff between the current check out and the revision 3 commits > before the revision the check out

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 9:17 AM, j. van den hoff wrote: > > well, I'm only talking about the ordinal numbers chronologically > enumerating the timeline checkin(!) entries. this enumeration will not > change as a consequence of rebuild, right? it might change after a sync > against some remote repo

Re: [fossil-users] Why Hash

On 10 September 2015 at 16:54, Martin Gagnon wrote: > On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote: >> On 10 September 2015 at 15:17, j. van den hoff >> wrote: >> > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal >> > wrote: >> > >> >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote: > On 10 September 2015 at 15:17, j. van den hoff > wrote: > > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal > > wrote: > > > >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein > >> wrote: > >> > >>> On Wed, Sep 9, 2015 at 10:12

Re: [fossil-users] Why Hash

On 10/09/15 14:56, Baruch Burstein wrote: On Thu, Sep 10, 2015 at 1:44 PM, Jacek Cała > wrote: All in all, I think it would be nice to add these little things to the console client, so the need for the GUI is only for those who really hate console. So

Re: [fossil-users] Why Hash

On Thu, Sep 10, 2015 at 1:44 PM, Jacek Cała wrote: > All in all, I think it would be nice to add these little things to the > console client, so the need for the GUI is only for those who really hate > console. Some of us (yes, even some programmers) think of it the other way round... -- ˙uʍ

Re: [fossil-users] Why Hash

On 10 September 2015 at 15:17, j. van den hoff wrote: > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal > wrote: > >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein >> wrote: >> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff < >>> veedeeh...@googlemail.com> wrote: >>> in a breach o

Re: [fossil-users] Why Hash

On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal wrote: On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein wrote: On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff < veedeeh...@googlemail.com> wrote: in a breach of promise to myself to never again argue in favour of this functionality on th

Re: [fossil-users] Why Hash

2015-09-09 22:03 GMT+01:00 paul : > On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari > wrote: > >> Assuming I am remembering correctly, if Fossil had this feature, you >>> could >>> do something like: >>> >>> $ fossil timeline -N -n 3 >>> 0 [d28be5063a] *CURRENT* Fix linker parameter fi

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein wrote: > On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff < > veedeeh...@googlemail.com> wrote: > >> in a breach of promise to myself to never again argue in favour of this >> functionality on the fossil mailing list (it came up a few times over th

Re: [fossil-users] Why Hash

The latest Fuel 2.0 is also quite usable now. https://fuel-scm.org/fossil/home On 10 September 2015 at 05:03, paul wrote: > On 09/09/15 20:12, j. van den hoff wrote: > >> On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote: >> >> On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari >>> wrote: >>> >>>

Re: [fossil-users] Why Hash

On 09/09/15 20:12, j. van den hoff wrote: On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote: On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari wrote: Some DVCS, like hg, use both an hash and a sequential number. As I recall (been a few years since I last used hg), the numbers were "relative" to

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff wrote: > in a breach of promise to myself to never again argue in favour of this > functionality on the fossil mailing list (it came up a few times over the > last years): > > having simple chronological checkin numbers as an alternative way of > s

Re: [fossil-users] Why Hash

On Wed, 09 Sep 2015 20:19:04 +0200, Ron W wrote: On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari wrote: Some DVCS, like hg, use both an hash and a sequential number. As I recall (been a few years since I last used hg), the numbers were "relative" to the output of hg's equivalent to "timelin

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 7:19 AM, Luca Ferrari wrote: > > Some DVCS, like hg, use both an hash and a sequential number. As I recall (been a few years since I last used hg), the numbers were "relative" to the output of hg's equivalent to "timeline". Assuming I am remembering correctly, if Fossil h

Re: [fossil-users] Why Hash

On 9/9/15, Stephan Beal wrote: > On Wed, Sep 9, 2015 at 1:24 PM, Richard Hipp wrote: >> >> https://www.fossil-scm.org/fossil/timeline?y=ci&showid > > > But be warned that they are not incremented in steps of 1. Any and all blob > data in to the db gets its own number, so commits are normally

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 1:24 PM, Richard Hipp wrote: > Fossil also uses both the SHA1 hash and a sequential number. But only > the hash is guaranteed to be stable (unchanged over the life of the > project) and the same across all clones of the repo. So only the hash > is shown and used. > > You

Re: [fossil-users] Why Hash

On 9/9/15, Luca Ferrari wrote: > On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor > wrote: >> >> Why does Fossil use a hash for an entries identity instead of sequential >> numbering? Seems simply using the rowid of the associated database table >> would be more meaningful and practical than those l

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor wrote: > > Why does Fossil use a hash for an entries identity instead of sequential > numbering? Seems simply using the rowid of the associated database table > would be more meaningful and practical than those long strings of arbitrary > numbers. > S

Re: [fossil-users] Why Hash

On Wed, Sep 9, 2015 at 10:16 AM, Scott Doctor wrote: > > Why does Fossil use a hash for an entries identity instead of sequential > numbering? Seems simply using the rowid of the associated database table > would be more meaningful and practical than those long strings of arbitrary > numbers. A

Re: [fossil-users] Why Hash

Because it is distributed. If sequential numbering is used two disconnected clients can happen to use the same number for different artifacts. Regards, Stan Stanislav Paskalev On Wed, Sep 9, 2015 at 11:16 AM, Scott Doctor wrote: > > Why does Fossil use a hash for an entries identity instead of

[fossil-users] Why Hash

Why does Fossil use a hash for an entries identity instead of sequential numbering? Seems simply using the rowid of the associated database table would be more meaningful and practical than those long strings of arbitrary numbers. -- Scott Doctor sc...@scottdoctor.com --