[fossil-users] setting hash-policy via web UI

[Eduard]

Hello,

Are there plans to expose the 'hash-policy' configuration option for
modification in the fossil web interface?

Best,
Eduard

[Richard Hipp]

Post by Eduard
Are there plans to expose the 'hash-policy' configuration option for
modification in the fossil web interface?

No. I was hoping to avoid yet another configuration option that
people have to think about when setting up a new Fossil instance.
hash-policy is suppose to be automatic for most users.

[Warren Young]

Post by Richard Hipp

Post by Eduard
Are there plans to expose the 'hash-policy' configuration option for
modification in the fossil web interface?

No. I was hoping to avoid yet another configuration option that
people have to think about when setting up a new Fossil instance.
hash-policy is suppose to be automatic for most users.

While I agree that the defaults are sensible and should rarely be changed, there are cases where a Fossil newbie would regret not finding this option until after commits have happened. Our newbie may be setting up a repo that they know needs to be accessible to Fossil 1.x clients, and they can’t force the upgrade.

Other settings can be hidden away in the command line because the consequences of changing them are low. This option, though, is (*ahem*) a one-way function.

(Thank you folks, I’ll be here all week. Try the veal.)

If that argument makes you reconsider putting this in the UI, I think this setting would fit in quite nicely with what’s already in Admin > Configuration. As with the other sensible defaults there, its presence isn’t so much because it needs to be changed often, it’s because you want to be sure the user has had a chance to agree that the default is sensible early on.

[Richard Hipp]

Post by Warren Young
Our newbie may be setting up a repo that
they know needs to be accessible to Fossil 1.x clients, and they can’t force
the upgrade.

Our newbie is going to need to know about the --sha1 option to "fossil
new". Otherwise, the initial check-in created will use a SHA3 hash
and the whole repository will be inaccessible to older clients.
Adding a method to change the hash-policy later won't help that.

[Warren Young]

Post by Richard Hipp

Post by Warren Young
Our newbie may be setting up a repo that
they know needs to be accessible to Fossil 1.x clients, and they can’t force
the upgrade.

Our newbie is going to need to know about the --sha1 option to "fossil
new".

You’re saying that if I init a repo in SHA3 mode, then open it and immediately go into Fossil UI, it’s already too late to change the hash policy?

I thought it wouldn’t be too late until the first commit happened.

Is it because of the initial empty commit?

[Richard Hipp]

Post by Warren Young

Post by Richard Hipp

Post by Warren Young
Our newbie may be setting up a repo that
they know needs to be accessible to Fossil 1.x clients, and they can’t force
the upgrade.

Our newbie is going to need to know about the --sha1 option to "fossil
new".

You’re saying that if I init a repo in SHA3 mode, then open it and
immediately go into Fossil UI, it’s already too late to change the hash
policy?
I thought it wouldn’t be too late until the first commit happened.
Is it because of the initial empty commit?

The "fossil new" command creates an initial, empty check-in which is
suppose to become the ancestor of all future check-ins. That check-in
will have a SHA3 hash, unless you use the --sha1 option on "fossil
new".

And once you get one SHA3 artifact in the repo, legacy clients cannot handle it.

[Warren Young]

Post by Richard Hipp
The "fossil new" command creates an initial, empty check-in which is
suppose to become the ancestor of all future check-ins. That check-in
will have a SHA3 hash, unless you use the --sha1 option on "fossil
new”.

Maybe then just a notice in Admin > Configuration or similar: “Hey, you know you’ve got a repo that Fossil 1.x can’t read, right? Just checking.”

[Warren Young]

Post by Warren Young
Maybe then just a notice in Admin > Configuration or similar: “Hey, you know you’ve got a repo that Fossil 1.x can’t read, right? Just checking.”

It could be conditional based on the repository age, disappearing after a week or a month. And the code to generate it can be removed once Fossil 2.x is old enough that the chances of running into Fossil 1.x is tiny.

[s***@gmail.com]

Confused a bit reading this...will Fossil 2.1 default to sha3 or sha1
hardened?http://www.fossil-scm.org/index.html/doc/trunk/www/hashpolicy.wiki"A
Pure SHA3 FutureAt some point in the future, years from now, after
everybody has finally upgraded to Fossil 2.0 or later, the default hash
policy will probably change to "sha3", or maybe even "shun-sha1". By the
time that happens, you will probably already be using SHA3 on all your
projects and so you are unlikely to notice."

I am asking since I would prefer to create new repo's with sha3 now using
fossil 2.1.
Then figure how to update/rebuild my older repo's using sha3?
Is that even possible?

Maybe then just a notice in Admin > Configuration or similar: “Hey, you

know you’ve got a repo that Fossil 1.x can’t read, right? Just checking.”
It could be conditional based on the repository age, disappearing after a
week or a month. And the code to generate it can be removed once Fossil
2.x is old enough that the chances of running into Fossil 1.x is tiny.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Richard Hipp]

Post by s***@gmail.com
Confused a bit reading this...will Fossil 2.1 default to sha3 or sha1
hardened?

The default hash-policy is "auto", which means use Hardened-SHA1 for
all repos that have only SHA1 artifacts, but promote to "sha3" in any
repository that contains one or more SHA3 artifacts.

So when working with legacy repositories, only Hardened-SHA1 artifacts
are generated.

But when you create a new repository using "fossil new" the initial
check-in is SHA3 (unless you use the --sha1 command-line option) which
causes the default "auto" to immediately promote to "sha3".

[Warren Young]

I am asking since I would prefer to create new repo's with sha3 now using fossil 2.1.

That’s what you will get by default. You have to go out of your way with Fossil 2.1+ to get a new SHA-1 based repo.

Then figure how to update/rebuild my older repo's using sha3?

Upgrade to Fossil 2.1+, then say “fossil set hash-policy sha3” in each repo where you want new content to be hashed with SHA-3.

If all your local repos either need to be converted or are clones of remote repos that will soon be shipping SHA-3 hashed artifacts (e.g. Fossil itself), you can say “fossil all set hash-policy sha3” instead, upgrading them all at once.

Fossil 2.1+ will purposely not rewrite all the old artifacts with SHA-3 hashes because that would break any intra-repository links, such as between checkin comments and tickets, wiki articles and mentioned checkins, etc. Only new content gets hashed with SHA-3 once its hash policy has been switched to SHA-3, whether explicitly or implicitly.

See the “firewall” thread if you’re worried about the consequences of leaving the old content hashed with SHA-1. (Executive summary: relax.)

Maybe someone will write a tool that rebuilds an old repo with all-SHA-3 for those who aren’t worried about the intra-repository links.

[s***@gmail.com]

Thanks for the detailed replies.
I will make the leap to v2.1 shortly.

Thanks for Fossils-ha!

Post by s***@gmail.com
I am asking since I would prefer to create new repo's with sha3 now

using fossil 2.1.
That’s what you will get by default. You have to go out of your way with
Fossil 2.1+ to get a new SHA-1 based repo.

Post by s***@gmail.com
Then figure how to update/rebuild my older repo's using sha3?

Upgrade to Fossil 2.1+, then say “fossil set hash-policy sha3” in each
repo where you want new content to be hashed with SHA-3.
If all your local repos either need to be converted or are clones of
remote repos that will soon be shipping SHA-3 hashed artifacts (e.g. Fossil
itself), you can say “fossil all set hash-policy sha3” instead, upgrading
them all at once.
Fossil 2.1+ will purposely not rewrite all the old artifacts with SHA-3
hashes because that would break any intra-repository links, such as between
checkin comments and tickets, wiki articles and mentioned checkins, etc.
Only new content gets hashed with SHA-3 once its hash policy has been
switched to SHA-3, whether explicitly or implicitly.
See the “firewall” thread if you’re worried about the consequences of
leaving the old content hashed with SHA-1. (Executive summary: relax.)
Maybe someone will write a tool that rebuilds an old repo with all-SHA-3
for those who aren’t worried about the intra-repository links.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users