Hi,

I updated our server's fossil version from 2.22 to 2.23 but now accounts do not validate for some reason -- passwords we know should work are not accepted. This applies both to the web interface and to fossil clients. The upgrade was a binary swap (compiled from source), so nothing else should have changed, but presumably I did something wrong. I notice that the old web config has been lost -- anon accounts can login and view the contents of the entire repository whereas this was prohibitted before. So apparently a binary upgrade is not entirely "in-place".

Please advise, Jesse

All of the upgrades to the SQLite website and to Fossil's self-hosting repository are done as you describe - but simply replacing the binary with a new one. And we haven't had any problems. So something else is going wrong, I suspect.

Is there a simple way to query the sqlite database directly and see what fossil thinks the passwords should be?

The repository does not store the passwords, but rather a SHA3 checksum of the passwords. You can query that checksum easily enough:

fossil sql -R repo.fossil

Then run SQL like this:

.mode qbox
SELECT * FROM user;

Thanks. Which instance of the SHA3 was used -- or rather -- how can I check the outcome myself? I see 40 characters stored in the 'pw' column. Knowing how that works I can then shoe-horn in a value as a temporary bandaid.

Do you have the repo on your local machine? If so, then you can just run:

fossil ui repo.fossil

And it will pop up the regular web interface automatically giving you full admin rights. Then just change the password.

40-character strings did you say? That sounds like SHA1 not SHA3. I might have mis-remembered which hash algorithm is used....

Great, thanks, this "fixed" the immediate problem. Note that the hash now is totally different from what was reportedly stored there prior. Looks like the system did an upgrade from FreeBSD 13 -> 14 before the fossil upgrade, so maybe a change in openssl altered how how hashed were generated or something?

My Fossil bisecting skills are weak but the least I can do for now is build from 2.22 and report back.

Deep gratitude for your assistence with this drh. Muchly appreciated!

You can build fossil from source with commits from 2.22 forward until it breaks.

My Fossil bisecting skills are weak

It's not difficult:

fossil clone https://fossil-scm.org
cd fossil-scm
fossil bisect bad         # implicitly, "trunk" is bad
fossil bisect good version-2.22

That will give you a version halfway between 2.22 and tip-of-trunk, at which point you can then say:

./configure --with-your-favored-options

Build and test as you normally would. If it's good, say "fossil bisect good" to get another version halfway again between that point and trunk. If it's bad, "fossil bisect bad" gets you a version halfway between that point and 2.22 instead.

The only tricky bit is that it's advisable to say "make clean reconfig" between each bisect update to ensure you're getting a complete rebuild of the new version, without any stale build artifacts from the prior test.

It only takes log₂(n) tests to find the breakage point this way, where n is the number of commits between 2.22 and tip-of-trunk. Currently, n=185, thus a maximum of 9 trials to find out where Fossil's behavior changed on your system.

Thanks for the guide. Easy indeed. I have an old copy of the repo on 2.22 at home that I'll try this on, but I'm on travel so it'll have to wait.

Are you 100% sure you didn't accidentally overwrite the repository file when you upgraded the binary?

Did you save the old binary? Can you swap it back in and see if that clears the problem?

How did you build? Have you tried using one of the pre-built binaries? Did you follow the same procedures we use to build the pre-build binaries (https://fossil-scm.org/home/wiki?name=Release+Build+How-To) or did you do something else. The build should have worked either way, but perhaps there is some quirk in the Makefile that we need to work out.

The repo.fossil file was, as far as I can tell, not changed. If I upload and replace that with a repo.fossil from the client, should that work all the same?

Old binary, sadly, nope. That's gone.

I'm on FreeBSD 14. Grabbed the source .tar from the website, .configure --static, then make. I've always done it this way and without issues previously. Followed https://fossil-scm.org/home/doc/trunk/www/build.wiki

Can you rebuild an older version and try that to see if it clears the problem?

2.22 works with the now-updated password completely seamlessly (the experience I had hoped for going from 2.22 to 2.23). Since the problem is no longer re-producible it may be a dead end. Spooky, though.