Ah, it says so when I create the repository on Chisel. Alright less concerned about that now, though still confused why it thinks that is necessary.

Please fill out the form below to upload an existing repository. A new super-user will be created that matches your chisel username and the password you provide below. Limit 8M in size. If your repository is larger than this, create a new empty project and push to it instead.

Why did Chisel add an account?

Note that Chisel is a 3rd-party service not directly associated with or supported by this project.

Lastly, I tried adding an admin user (while signed in as Y) and syncing it. Proceeding to clone the remote repository as the new user fails, citing that the user doesn't exist.

Sync itself does not copy the users. You need to pull those separately:

fossil config pull user

But see below...

Why does only X see the full userlist?

You'll need to show us that Y is not also getting that list on a fresh clone. To the best of my recollection, "s" users ("s" is for "setup", not "superuser") can all clone the complete user list. That said...

Cloning the user list is in no way necessary for normal repo operations. It's "just a list" and is in no way tied to those same user names in checkins. Also, the login data for those users is invalid in any clone because the password is, in part, hashed against random bytes which are specific to each clone. Thus a hash from one repository clone won't work in another.

FWIW, i've been using fossil since 2007 and have never once had a genuine need to clone the user list. It serves literally no function in a local clone. In a local clone, the only truly relevant user is the one who performed the clone (the name under which checkins and whatnot will be made).

So it turns out Y wasn't actually a setup user, it just reported being one when I cloned as that user. I still consider this all baffling but at least that explains some discrepancies. I hope syncing will give some error if I try to sync something I don't actually have permissions for.

Also, the login data for those users is invalid in any clone because the password is, in part, hashed against random bytes which are specific to each clone. Thus a hash from one repository clone won't work in another.

Ooohh so the userlist info is... fake? As far as clones are concerned? Okay so the bottom line here is that I have to interact directly with the remote repository for some actions. Namely, creating users and modifying their privileges. I can't exclusively use clones as an interface like I'd assumed. Are users and editing users the only thing that is not cloned & synced or are there other details I must keep in mind? Is the issue tracker synced? The chatroom? The forum? Etcetera?

Note that Chisel is a 3rd-party service not directly associated with or supported by this project.

That's fair. I asked on the off chance it was some builtin feature of remote fossils that Chisel has a convenience UI for. Well, that and to be thorough.

("s" is for "setup", not "superuser")

Oh sorry I mistook the mnemonic to mean they're interchangeable. Unsure whether to consider that a documentation bug or my fault for putting stock in a mnemonic.

---

PS. Fossil neither transfers user lists nor indicates that the local repository's userlist is uncorrelated with the remote userlist. Is this behavior considered a bug that just isn't worth fixing or is it somehow a feature? That is to say, do I ever have a reason to run fossil user ls now that I know it's uncorrelated with remote?

Ooohh so the userlist info is... fake? As far as clones are concerned?

It's not fake, except for the passwords, but it is 100% irrelevant for all SCM-related features. None of the actual SCM features rely on that list for local usage. When running in local mode, the user automatically has all privileges (because it's their copy they're working on).

Okay so the bottom line here is that I have to interact directly with the remote repository for some actions. Namely, creating users and modifying their privileges.

You need to set up users on any copies of the repositories in which those users will interact. If that's the Chisel copy then that's where they need to be set up. They can do all the interacting they want with their local copies, but the permission on the Chisel copy will be the one which determines what exactly those users are permitted to do on that copy.

Are users and editing users the only thing that is not cloned & synced or are there other details I must keep in mind? Is the issue tracker synced? The chatroom? The forum? Etcetera?

• Users can be synced with the config option, but administering users in clones is unnecessary and ineffective because copying a user "breaks" the password on that clone.

• Tickets, wiki, and forum state are transparently synced via all push/pull/sync operations.

• Chatroom is 100% transient and not synced. We have no builtin mechanism for porting the /chat content from one clone to another. It can be done using the right sequence of db commands and SSH access, but it's not (by design) a feature of /chat itself.

In short, all SCM-relevant data is synced as needed and non-SCM-relevant data is either not synchable or requires specific command invocations to sync (see (fossil help config) for examples).

In practice, all you have to do is the usual push/pull/sync, which are automatically performed if autosync is on (which it is by default). Don't worry about cloning users or some such: do all user management on the "central" copy. There are other config-related things which can be synched but rarely, if ever, need to be. The example which comes readily to mind as something i've ever synched from my clone to a central repo is the site skin. Sometimes it's useful to do site skin management locally and then push it to a remote using (fossil config push skin).

Oh sorry I mistook the mnemonic to mean they're interchangeable. Unsure whether to consider that a documentation bug or my fault for putting stock in a mnemonic.

FWIW, you're not the only person to have tripped over that and certainly won't be the last!

PS. Fossil neither transfers user lists nor indicates that the local repository's userlist is uncorrelated with the remote userlist. Is this behavior considered a bug that just isn't worth fixing or is it somehow a feature?

That is by design. The user list controls only access to a given clone and is not SCM-relevant. If the complete and functional user list, permissions, and password hashes were to be copied to any given clone, it would effectively get other users access to your copy, which is definitely not something fossil will enable by itself. It would also give you, a remote user, enough information with which to brute-force decrypt those passwords, whereas fossil makes part of the hashing equation private to each clone of a repo so that leaked hashes are effectively useless for such purposes.

That is to say, do I ever have a reason to run fossil user ls now that I know it's uncorrelated with remote?

Nope. None whatsoever unless, perhaps, you are operating directly on the repository copy which other users access. (That is never the case when using Chisel.) The user list only comes into play when accessing your clone via (fossil server) or similar. When using (fossil ui), which is a variant of fossil server, it will log in automatically as the same user under whose name checkins and such are performed.

As a long-time fossil developer, literally the only time i have to manipulate a given clone's user list is when hacking on the /chat page and needing a few dummy user accounts to test it with.

Alright I believe I've got this down now. Thanks for all the info! You're a much appreciated resource.

Are you saying that if I make modifications in the local clone that it "breaks" the user?

No, i meant basically that doing a clone copies over user accounts which cannot be logged in to unless their password is reset because the password hashes are "broken" (will no longer hash the same for the clone as for the original). "Break" was too strong a word on my part.

That said...

At any rate, my point is, after clone (using a setup user), all the users in the remote copy are also now in my local copy and I can login with them. So they don't appear to be broken.

What am I missing?

It might be me that's missing something. i was under the recollection (apparently wrong) that the "secret" bytes used for hashing those never leave that repo except via the "backup" command. (Writing from bed, though, so i'm not going to dig through the sources to straighten out my understanding at the moment!)

Or more completely…

Fossil makes a distinction between universal content that is shared with all repositories for the same project, and local content. The universal content includes things like the check-ins and wiki pages and forum posts. Local content is skin configuration, display preferences, email notification setup, and the users and passwords.

The "fossil sync" command only synchronizes the universal content. This is intentional. Separate repositories might be run by different people, who have difference display and configuration preferences. Also, things like email addresses might be considered PII, and you don't necessarily want to make that kind of thing available to every random passer-by on the internet.

The local content can be synced, if you have sufficient privilege, using the "fossil config pull/push/sync" command. Typically you need admin privilege on the remote repository for this to work fully. Low-privilege users can often do "fossil config pull skin" to bring down the skin setup of a server. But higher privileges are needed to bring down other configuration settings or to push configuration settings.