Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread Jan Danielsson
On 03/01/17 17:06, sky5w...@gmail.com wrote: [---] > 3. Fossil 2.0+ delivered as dll. >I use the exe for remote repo server, but automate my check-in/out's. >That would be more fluid without parsing CLI text. This has brought up a few times before, and there are no such plans (not for

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread Richard Hipp
On 3/1/17, Sean Woods wrote: > Do you keep updating Fossil 1.x? Will changes to the Fossil 1.x line be > ported to 2.x? No. Fossil 2.0 is a drop-in replace for Fossil 1.x. If you find a problem in historical Fossil 1.x, then the solution is to upgrade to Fossil 2.0. --

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread Sean Woods
Do you keep updating Fossil 1.x? Will changes to the Fossil 1.x line be ported to 2.x? On Wed, Mar 1, 2017, at 11:36 AM, Richard Hipp wrote: > On 3/1/17, sky5w...@gmail.com wrote: > > More 2.0+ requests... > > Fossil 2.0 will say focused on one thing: SHA3 > > -- > D.

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread Richard Hipp
On 3/1/17, sky5w...@gmail.com wrote: > More 2.0+ requests... Fossil 2.0 will say focused on one thing: SHA3 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread sky5walk
Sorry for double post, I got spammed between reply and lost track of what I deleted. :( On Wed, Mar 1, 2017 at 11:14 AM, wrote: > Cool! > More 2.0+ requests... > 1. 'Prune' repo to deliver a branch or whatever as a new repo. >Ideally, history preserved from point of

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread sky5walk
Cool! More 2.0+ requests... 1. 'Prune' repo to deliver a branch or whatever as a new repo. Ideally, history preserved from point of prune forward. 2. Unversioned files supported with check in/out. Current approach is confusing(that may be intentional?). 3. Fossil 2.0+ delivered as dll. I

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread sky5walk
All sha's aside: 1. 'Prune' repo to deliver a branch or whatever as a new repo. Ideally, history preserved from point of prune forward. 2. Unversioned files supported with check in/out. Current approach is confusing(that may be intentional?). 3. Fossil 2.0+ delivered as dll. I use the exe

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-03-01 Thread Richard Hipp
On 2/26/17, Richard Hipp wrote: > I propose that the next release of Fossil be called "Fossil 2.0" An alpha version of Fossil 2.0 is now live on the main fossil website: https://www.fossil-scm.org/ That same Fossil instance also runs SQLite:

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-28 Thread Warren Young
On Feb 27, 2017, at 6:28 PM, Tony Papadimitriou wrote: > > On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote: > >>> how is it possible for someone to inject a 'bad' file with the same SHA1 as >>> a 'good' file already in the repo? >> Your attacker could be

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-27 Thread Tony Papadimitriou
-Original Message- From: Warren Young On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote: how is it possible for someone to inject a 'bad' file with the same SHA1 as a 'good' file already in the repo? Your attacker could be MITM’d into the sync stream. I gave an

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-27 Thread Warren Young
On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote: > > how is it possible for someone to inject a 'bad' file with the same SHA1 as a > 'good' file already in the repo? Your attacker could be MITM’d into the sync stream. I gave an example requiring only the current SHA-1

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-27 Thread Ron Aaron
On 27/02/2017 16:14, Richard Hipp wrote: On 2/26/17, Ron Aaron wrote: >From a performance standpoint, I would rather see Fossil adopt the BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has adjustable

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-27 Thread Richard Hipp
On 2/26/17, Ron Aaron wrote: > > From a performance standpoint, I would rather see Fossil adopt the > BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has > adjustable output hash size. > Please write and check-in code (on the "fossil-2.0" branch) that

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-26 Thread Ron Aaron
I'm happy to see you thinking along those lines. >From a performance standpoint, I would rather see Fossil adopt the BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has adjustable output hash size. On 27/02/2017 3:48, Richard Hipp wrote: > On 2/26/17, Tony Papadimitriou

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-26 Thread Richard Hipp
On 2/26/17, Tony Papadimitriou wrote: > > how urgent is the need to > transition away from SHA1? > From a technical standpoint, it is not very urgent, in my assessment. However, from a PR standpoint, I think it needs to happen quickly. It can also be a big PR win if we are able

Re: [fossil-users] Proposed roadmap for Fossil 2.0

2017-02-26 Thread Tony Papadimitriou
Leaving aside for a moment the consequences in general of the presumed imminent SHA1 collapse (and some of the valid points already made by Linus regarding Git): If FOSSIL will refuse (and I actually tried it with those two same SHA1 PDFs) to accept a file (commit, push, pull) with the same

[fossil-users] Proposed roadmap for Fossil 2.0

2017-02-26 Thread Richard Hipp
This message is cross-posted to fossil-users and fossil-dev. Follow-ups should go to fossil-dev only, please. Thanks. I propose that the next release of Fossil be called "Fossil 2.0", that it occur before Easter (2017-04-16), and that it have the following features: (1) Fossil 2.0 is backwards