> Since sending the previous, I've reconsidered and would now like to
> release Fossil 2.0 and Fossil 2.1 simultaneously. The only
> difference between these two version will be that Fossil 2.0 still
> always generates SHA1 hashes on new content whereas Fossil 2.1
> generates only SHA3 hashes. B
> On 2/28/17, Richard Hipp wrote:
> >
> > (4) There are no hash options. You cannot choose to use any hash
> > algorithm other than SHA3-256 for new content.
> >
> > (6) The only complication to upgrading is that you need to update all
> > of your fossil (or fossil.exe) binaries to version 2.0 at
On Feb 28, 2017, at 6:50 PM, Warren Young wrote:
>
> ...for those who run their terminals at > 80 columns
If you go with that, you might want to call isatty(stdout) in case fossil is
being run in a pipeline, so code that tries to parse a hash out of the command
gets the full length.
I say “mi
On Feb 28, 2017, at 6:49 PM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp wrote:
>>
>> Should the SHA3 hashes be SHA3-224 or
>> SHA3-256? In my view, the extra computation and storage overhead for
>> SHA3-256 is minimal and should not present a barrier. However, the
>> extra 8 characters
On 2/28/17, Richard Hipp wrote:
>
> Should the SHA3 hashes be SHA3-224 or
> SHA3-256? In my view, the extra computation and storage overhead for
> SHA3-256 is minimal and should not present a barrier. However, the
> extra 8 characters of hash from SHA3-256 do seem to introduce UI
> challenges.
It would constitute a collision because it would mean that two clients had
different ideas of the contents of a file prior to the USHI request. If
you wanted to maintain a repository that tracks SHA1 PDFs that collide you
would have to issue an USHI first to something other than SHA1, or start
Thus said Roy Keene on Tue, 28 Feb 2017 11:13:01 -0600:
>e. If a collision is submitted (e.g., same SHA1, different SHA256)
>the artifact (by SHA1) is considered compromised and shunned from
>the repository (or something)
Why would this constitute a collision? Wouldn't a collision
On Feb 28, 2017, at 2:08 PM, Richard Hipp wrote:
>
> On 2/28/17, Warren Young wrote:
>>
>>> Then after a month or so we can release Fossil 2.1, in which all new
>>> content is always SHA3.
>>
>> If there’s going to be a transition time, I think it would need to be
>> something like a year or t
On Tue, Feb 28, 2017 at 2:11 PM, Richard Hipp wrote:
> On 2/28/17, Scott Robison wrote:
> >
> > The SQLite database storing the repository is UTF-8, or blobs in the
> > database are using UTF-8 encoded data that won't be transparently
> > transcoded by SQLite?
> >
>
> Neither. The problem is th
On 2/28/17, Warren Young wrote:
>
> I wonder if you’d share what you plan to do with the SQLite repository? Are
> you just going to roll to 2.0 immediately after release, and tell people who
> want to check out the sources via Fossil to upgrade to Fossil 2.0?
The plan is to convert SQLite and Fo
On Feb 28, 2017, at 9:17 AM, Richard Hipp wrote:
>
> This morning I was thinking of using SHA3-256. But after looking at a
> bunch of hashes on-screen, and seeing how long they are, I'm inclined
> now to go with the shorter SHA3-224.
Can you just look at $COLUMNS, $(tput cols), or getmaxyx(3)?
On 2/28/17, Scott Robison wrote:
>
> The SQLite database storing the repository is UTF-8, or blobs in the
> database are using UTF-8 encoded data that won't be transparently
> transcoded by SQLite?
>
Neither. The problem is that the Fossil implementation sometimes
accesses string values using sq
On 2/28/17, Warren Young wrote:
>
>> Then after a month or so we can release Fossil 2.1, in which all new
>> content is always SHA3.
>
> If there’s going to be a transition time, I think it would need to be
> something like a year or two, during which both Fossil 1 and Fossil 2 are
> actively main
On Tue, Feb 28, 2017 at 1:33 PM, Richard Hipp wrote:
> As I have been working through the Fossil code this week, I have
> spotted several places where the code assumes that the respository
> database uses a UTF8 encoding for text. In other words, if you
> convert a Fossil repository to use UTF16
On Feb 28, 2017, at 8:19 AM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp wrote:
>>
>> (4) There are no hash options. You cannot choose to use any hash
>> algorithm other than SHA3-256 for new content.
>>
>> (6) The only complication to upgrading is that you need to update all
>> of your
On Feb 28, 2017, at 8:11 AM, Richard Hipp wrote:
>
> (3) All new content added to the repository (for example by "fossil
> commit") uses a SHA3-256 hash.
That is a brave step, one I resisted suggesting, but it’s probably for the
best. Defaults matter. If the default is SHA-1, we’ll still be l
As I have been working through the Fossil code this week, I have
spotted several places where the code assumes that the respository
database uses a UTF8 encoding for text. In other words, if you
convert a Fossil repository to use UTF16, it will not work.
I suppose that is ok. But we should proba
> Those extra 8 bytes of hash on 256 versus 224 are starting to push the
> limits of what you can display with an 80-column tty window.
You're already at 80 columns on the checkout and parent lines.
Current SHA1 - Max line length 79
13:12:09 $ fo stat
repository: c:\fossil\fossil-scm.fossil
loc
On 2/28/17, Dillon, Eric W - Norman, OK - Contractor
wrote:
>
> Consider that you're primarily only going to be displaying / typing the
> first several hex values anyway.
If it were just the case of showing prefixes, I agree that we might as
well go with 256. But there are situations where the f
Proposed change:
1. A new control artifact ("Upgrade Security Hash Identifier");
a. U cards which identify an existing SHA1 (or other hash)
and the same hash in a different hasing algorith, e.g.:
U SHA1 3301ac54c1e6072db792352f5a7
I think going with the shorter hash for now is the best move, especially with
regards to possible future enhancements.
Sent from my iPhone
https://urn.to/r/mistachkin
> On Feb 28, 2017, at 11:17 AM, Richard Hipp wrote:
>
> Need your input: Should the new default hash algorithm be SHA3-224 or
Need your input: Should the new default hash algorithm be SHA3-224 or SHA3-256?
Remember, the desire is that there be no options. Fossil should just
do the right thing. VCS users should not have to worry with piddly
details like hashing algorithms. So "make it an option that the user
has to ch
On 2/28/17, Richard Hipp wrote:
>
> (4) There are no hash options. You cannot choose to use any hash
> algorithm other than SHA3-256 for new content.
>
> (6) The only complication to upgrading is that you need to update all
> of your fossil (or fossil.exe) binaries to version 2.0 at the same
> ti
Work is ongoing and subject to change. But the way this is playing
out is as follows:
(1) When you upgrade to Fossil 2.0, you can immediately start using it
on your existing repositories. There is no need to run "fossil
rebuild" or anything like that. It just works.
(2) All legacy SHA1 hash na
On 2/27/17, Andy Bradford wrote:
> Thus said Richard Hipp on Mon, 27 Feb 2017 21:50:43 -0500:
>
>> (9) There are no changes to the file formats, other than relaxing the
>> size constraint on artifact hashes - allowing hash to be greater than
>> or equal to 40 characters rather than requiring i
25 matches
Mail list logo
