I currently have two repositories that are part of the same login group. I want to create a new repository and make it part of that login group. I want to add the users that currently exist in the login group to the new repository while maintaining the existing passwords. I'm asking because I'm concerned I might accidentally change the passwords in the login group when I add the new user(s) if I do things incorrectly.

What is the best way to do this? How do I safely migrate the users and passwords from the login group to the new repository?

mike

The passwords do not need to be the same. If you have three repos, AAA, BBB, and CCC, that are all part of the same login group, if you log into one then you are automatically logged into the all the others for which you have a user id. The password does not need to be the same.

You use the password for whichever repo you log into first. Then you are automatically logged into all the others, regardless of what the password is on the others.

If you change your password on any one of the three repos, then passwords are automatically updated on all of the others. That means, for example, if you have 50 repos in the same login group and you change the password on one of those repos, then you end up doing a write transaction on all 50 repositories.

(Caveat: At least, that's the way I remember coding it. It has been ages since I wrote that code, though, so maybe my memory is wrong.)

Thanks for the reply, Richard.

I think I understand that (knock on wood). Let me rephrase my question. How do I add users to the new repository such that they inherit the existing passwords? I'd like the password to be the same across all repositories, including the new one, and I want it to be the existing password.

I don't want to accidentally change the password on the existing repositories just because adding a user on the new repository comes up with a different default password.

mike

How do I add users to the new repository such that they inherit the existing passwords?

You cannot, because there is per-repository information that gets mixed into the hashed passwords. Copying them over would invalidate the passwords.

Thus point #4 here: if you want the passwords to sync, you have to apply them to all repos intentionally. This results in a different password hash in each repo which matches as the "same" password at login time.

That doc distills a long session of careful experimentation, which I can save you needlessly replicating if you will but read it carefully. Hint. :)

I started with that document before I hit the forum. I think I understand why this is tricky, I'm trying to figure a course of action besides "can't do it".

What is the best way to achieve my goal? I want to create a new repository, add users and have them be able to login using the same passwords they use on the other repositories. Without making the users change their password and without accidentally changing the existing passwords when I add the users to the new repository. Having separate pre-repository hashes is great. I just want them to be able to login using the same credentials.

Would this work?

1. Create the new repository
2. Add it to the existing login group
3. Add users, making sure the scope is set to 'this repository only'
4. Use the UI interface on one of the other repositories and change something trivia for one of the users (like an access privilege - basically anything except the password itself), being sure the scope is set to the login group
5. Revert the trivial change, again saving with scope set to the login group
6. Repeat for each user

I guess I'm most worried about step 3, making sure adding a new user doesn't push a new password to the rest of the group.

As a feature request, an 'update all users across entire group' command would greatly simplify steps 4-6.

How do other people handle this situation? While it might not be a common action, it doesn't strike me as something that has never happened before.

Would this work?

I think so, but I'm not interested enough to try the experiment for you. Give it a shot. What happens?

What I can tell you isn't going to happen is for all of the passwords to come into sync short of forcing them across all other repos in the group. This is not an SSO system, as commonly understood. If that's what you want, you should look into the several historical threads on integrating Fossil with LDAP, OAUTH, AD-FS, etc.

No such integration exists, mind. I'm just telling you that you're going down a path that lots of people have trodden before, and I'd rather we don't repeat all that in this thread.

The whole purpose of my initial post was to ask how others, with more fossil knowledge than I have, how to handle this situation so I don’t have to experiment and potentially mess things up. If that person is not you, if this is not a situation you’ve dealt with, that is fine and I thank you for your feedback. Perhaps someone else will know.

Perhaps I wasn’t clear, but I do want the same passwords used across all other repos in the group, so “forcing” that situation is okay. What I want to be careful about, and why I am asking and not experimenting, is making sure the passwords that are forced across all other repos are the ones that currently exist, not the autogenerated ones created when adding new users.

If this really is a situation that no one has encountered in their own usage, and no one has any helpful advice on how I should do things, then I will experiment and see what happens, but I’d prefer to err on the side of caution, if possible.

So I did some testing. Short story, it didn't work. Long story, lots of weird things occurred. I don't know why, but after trying to push the password from one repository in the group to the other, not only did it not work, but the second repository ended up with an unknown password. I could log in as the test user using its password from either repository. There were also situation where I can to type values into to last field in a form before filling in the other fields. When I worked top-to-bottom, the last field wouldn't accept input. I hadn't noticed that before. Perhaps it is an artifact of the particular version of fossil I have installed.

So, I guess I am stuck with making the users change their password each time I add a new repository. Unless someone has a clever idea on how to manage this situation.

I took notes. Here's what I did and what I saw:

fossil version
	This is fossil version 2.23 [47362306a7] 2023-11-01 18:56:47 UTC


fossil init -A master a.fossil
	password is MV8bEhFzUA
fossil init -A master b.fossil
	password is tk4bdPvFyr

fossil server -P 8080 a.fossil
fossil server -P 8081 b.fossil	# in another terminal

Using safari in tab #1 - localhost:8080
# For the following I have to enter the password first.
# If I enter the login name first I cannot type into the
# password field.  Once it gets stuck like this,
# I need to change to another page (like Wiki) and then
# go back to the Login tab.
Login
	User ID: master
	Password: MV8bEhFzUA


In tab #2 - localhost:8081
Login
	User ID: master
	Password: tk4bdPvFyr


Tab #1
Admin -> Users -> Add
	Login: test
	Password: aFZDzmneUkVq
	Capabilities: uv
	# hit return in the password field to create new user
	#    (Apply Changes doesn't do anything)

Admin -> Login-Group
	# Must enter name of login-group first.  If I
	# fill in the top fields first, I cannot type
	# into 'Name of login-group'
	Name of login-group: test
	Repository name in group to join: b.fossil
	Login: master
	Password: tk4bdPvFyr
	Join

	# Config.Name		Config.Value
	# login-group-code	6219524cb75da67f
	# login-group-name	test
	# peer-repo-5ec85bc444491489	/path/to/b.fossil
	# project-code		94544e2fc5ee4b14d21043333fa08bd4a01e8f2f

Logout

Login
	User ID: test
	Password: aFZDzmneUkVq
	# success
Logout


Tab #2
Admin
# forces a login

User ID: master
Password: tk4bdPvFyr
# now in admin tab

# Below, I'm using the suggested password since in a real
# situation, I wouldn't know what password had been used
# in the a.fossil repo.
Users -> Add
Login: test
Capabilities: uv
Password: qdNAWDRtvrVe
Apply change to this repository only
# Unlike previously, the Apply Changes button did add the user
# this time.

Logout

Login
	User ID: test
	Password: qdNAWDRtvrVe
	# success

Logout


In tab #1
	# Notice that I did not complete the Logout confirmation
	# when I previously tried to logout 'test'.  Complete
	# that now.
	Login
		User ID: master
		Password: MV8bEhFzUA

Admin -> Users
	Select test user
	Add Clone Capabilities
	Apply change to all repositories in "test" group
	Apply Changes

	Select test user
	Remove Clone cap
	Apply change to all repositories
	Apply changes

Logout


In tab #2
	# Notice that test didn't complete the logout confirmation.
	# I could have sworn I did it, but I guess not.
	Logout

Login
	User ID: test
	Password: tk4bdPvFyr # test's password from a.fossil
	# fail

	User ID: test
	Password: qdNAWDRtvrVe # initial password from b.fossil
	# fail

	User ID: master
	Password: tk4bdPvFyr
	# success

	Admin -> Users
	# verify that test is still listed as a user, but
	# now with an unknown password.

	Logout
	# full confirmation this time


In tab #1
	Login
		User ID: test
		Password: aFZDzmneUkVq
		# success

So, I guess I am stuck with making the users change their password each time I add a new repository.

With the use case that you have described, what I can confirm is that you will indeed have to either get the user to change their password each time you add a new repository, or you will have to keep a list of the users' plain text passwords.

Note that the second option is a horrendous idea, but these are your only two options.

Very deliberately, a password cannot be "injected" into a repository from a pre-existing repository. The password itself is never stored, and the inputs to the hashing function are different for every repo, very deliberately.

So you must have access to the actual plain text password to set up the new repository.

This can be either the user themselves entering it (ideally by changing their password, possibly to the same one) or by you knowing their password.

But these are your two options. While you may find this frustrating, I hope it is at least clear?

The password itself is never stored, and the inputs to the hashing function are different for every repo, very deliberately.

Not only for every repo, but for every distinct clone of a given repo. That is, my clone of fossil-scm.org's main repo creates different hashes than yours does.

This can be either the user themselves entering it (ideally by changing their password, possibly to the same one) or by you knowing their password.

In some projects, an admin will pass out an initial password to users and then request that they change after logging in. If my vague recollection is correct, that changing of the password will update the password in any repos within that login group.

One last question before I move on. When a user changes their password, does it matter which repo they use?

I'd think it would be any, but when setting up the login group, I only add the syncing credentials on one repository. Is the resulting group bi-directional? If I link a repo 'a' to repo 'b' by providing 'a' with login information for 'b', can a user change their password on 'b' and have it synced on 'a'?

When a user changes their password, does it matter which repo they use?

To the best of my recollection, no, but i've not poked around in that code in ages.

If I link a repo 'a' to repo 'b' by providing 'a' with login information for 'b', can a user change their password on 'b' and have it synced on 'a'?

Both my recollection and a cursory scan of the source code suggest that the login group connection is omni-directional. Every peer in the group is made aware of every other peer, so that a password modification on one knows which other databases have to be updated.

Edit: if any given member repo of a login group is every deleted or moved, all of its former peers will silently delete its entry when they're next updated. i.e. it won't cause a "repo not found" error across the whole login group.

Thanks

Yes. I understand. I guess it was just wishful thinking on my part. It seems like what I’m trying to do would be a common enough need that there would be a solution. Login groups are a quasi step in this direction and indicate others need something sort of like what I want, but it’s not a full solution.

I guess what I’d really need is a configurable back-end for password management. Some sort of shared database (maybe even a fossil repository) that would hold user information that could then be used across multiple repositories.

Yes, the closest you will come to this is fossil's CGI interface, which sets login variables in the CGI process' environment.

But you can't use this to allow credential control in fossil itself.

It's not a fully fledged SSO solution, it's just meant to help with a network of fixed, linked repositories.

It's your dynamic adding of new repositories that breaks the assumptions, and that is itself such a niche case that I don't think it is likely to be accommodated (but we have all said such things and been wrong before!).

You also can't restrict access to the CGI function with user caps (just in case you were wondering!).

I still think your easiest option, should you really wish to pursue your model (which I can see being useful) is to ask users to update their passwords whenever you add a repository. It really doesn't take long, and it would update all linked repos in one go, even if they hadn't logged in for a while. You could use the central "coordination repo" for this.

Thanks

Edit: I'm almost certain I'll end up doing this a few times, as we start using fossil for other projects that require separate repositories.

Please do repost then, when you either:

1. Can tell us how this "get everyone to change their password (to the same one potentially) each time you add a repository to the login group" strategy
2. Find an alternative workflow

I'd be very interested to hear your findings.

I'm sure it'll be #1. If it annoys me or the users too much (thankfully there aren't many) and if I have time (huge if), then I'll start looking at the fossil code and see what it would take to add some sort of shared password database.

As you and others have pointed out, there really isn't a solution. Either I record everyone's password so I can reset it for them, which is a bad idea in general and won't even work if they change the password on their own, or I make them jump through the reset password hoop when we add new repositories. So either I suck it up or I come up to speed on fossil internals and write some code. It'll probably be suck it up.

Well, I guess there's a third option - switch to a different SCM, but I like fossil. I prefer it to git. I'm definitely not going to go back to my roots with SCCS, RCS and CVS. My favorite is probably still Perforce, but they haven't supported FreeBSD as a server in a long time and I haven't used it in many years now.

My apologies, I guess I have more thoughts, after all. With an eye towards the future, what about the following as a work around.

I create a number of extra, unassigned repos now. Say, dummy1.fossil, dummy2.fossil, etc. and have them join the login group along with the new one I need now. Then I ask people to change their passwords. Then the extra ones, even thought they have no purpose would be synced up and ready to go.

Are there any pitfalls involved in later renaming and repurposing the dummy repositories? Would it be as easy as renaming the file, or would there always be something "dummy" inside them?

No, I think that would work, though it feels a little ugly.

Users wouldn't even need to know about the dummy repos waiting to be brought in at a later date. As long as they were all in the same login group and existent, it's probably a solution worth trying.

Not just existent, but available. You need to ask what happens if a user tries to change their password and one of the repositories is offline.

If they are all hosted in the same place and therefore that isn't an issue - perhaps Andy's idea is a good one, look at policing access a different way entirely.

Regarding the multiple dummy repositories idea, I suspect you either end up with a ridiculous number of spares, or you don't create enough and eventually end up with the same problem all over again. A design rule I used to have to work under said design for at least 20 times the current know worst case requirement.

Not just existent, but available. You need to ask what happens if a user tries to change their password and one of the repositories is offline.

Login groups require that all of the repos are reachable via local filesystem paths (they may be on a mount point, but must be accessible via a /conventional/path). Remote sync of passwords for a login group isn't an option.

It is hypothetically possible that one of them throws a locking error while a login group password is being updated, but locking errors are rare in fossil, even for moderately active repos like sqlite's forum.

I think locking errors would be even less common for unused repos!

I hope everybody had a nice weekend.

I was going to ask a follow-up question regarding renaming a dummy repository: If the process of maintaining login group membership is a simple as deleting the repo using the old name and then re-adding it using the new name. Then I figure I might as well just test it myself. That's when I noticed a problem.

Changing the user's password is not always propagating across repos. I have repos a, b and c in the same group. All have a user 'test'. When I change the password on repo a, I cannot use the new password to login in repo c. The new password works with repos an and b, but not c. All repos list the other two as being part of the same login group, though some of the implementation details are different, as shown below.

Repo a

Repo b

Repo c

My testing was split between 2.23 and the snapshot as of 2024-02-24. This is on a Mac using Safari. I would use either 'fossil ui' or 'fossil server' to do the testing depending on who I was logging in with.

Unrelated to the password problem, I'm seeing a problem I mentioned previously. If I'm filling in the values on a form, I often cannot type into the last entry field if I'm filling them in top-to-bottom. I think it is related to moving from one entry to the entry immediately below it using the mouse to change focus. If I tab between the entries, it work. Also, if I skip an entry (go from entry 1 to entry 3 without clicking in entry 2) it works.

Not just existent, but available

They just have to be on the filesystem where fossil can access them. They don't need to be served or hosted. They can be squirrelled away somewhere, just waiting to be populated.

Regarding the multiple dummy repositories idea, I suspect you either end up with a ridiculous number of spares

There isn't really any cost to having "a ridiculous number of spares".

But this isn't really a situation where a hot spare is needed instantly.

The OP will have some decent idea of how frequently a new repo will be needed.

If this turns out to be insufficient, then the "change a password" route is needed, but this would only need to be done one more time to bring any number of spares online (where "any number" is now informed by experience of how quickly new repositories were needed).

I think your concerns actually make me like this proposed solution more.

Then I ask people to change their passwords. Then the extra ones, even thought they have no purpose would be synced up and ready to go.

What if (just spitballing here): you set up a repo which has no other purpose but to act as a gateway to all other repos by providing links to them on its homepage. Require all users to change their passwords through that one and it becomes (IMO) easier to reason about than telling them that they can change their password on any member of the repo group.

An example of a "gateway" repo can be seen at https://fossil.wanderinghorse.net. That repo's only purpose is to gateway access to my own repo collection. It does not use a login group, but... perhaps it should.

This is an interesting idea. Do you have any advice regarding how you set up your gateway?

Do you have any advice regarding how you set up your gateway?

The given example is just a "thin repo" - all it has is a few doc pages and a single user account. One of the menu entries ("Repos") points to a subdir which holds (A) a single CGI script per repo and (B) an shell-script-generated index.html to list those repos. Far simpler is probably to use fossil's "directory mode" but the idea of having fossil open up dozens of repositories just to show me a listing of them makes me queasy, so a CGI script per repo is my strong personal preference.

Sidebar: that particular site is believed (by me, anyway!) to be the oldest fossil-dedicated site aside from fossil's own source repo. According to the /stat page of the gateway repo:

Repository Size:	232,448 bytes
Number Of Artifacts:	114 (19 fulltext and 95 deltas) Details
Uncompressed Artifact Size:	4,479 bytes average, 22,410 bytes max, 510,648 total
Compression Ratio:	21:10
Number Of Check-ins:	14
Number Of Files:	3
Number Of Wiki Pages:	3
Project Age:	15 years, 5 months, 9 days
...

We can see that, even though it's ancient and still active, it doesn't hold much content.