dear forum,

I just stuck on issue... and I can't help my self :(.

We quite large public hospital, running all onpremise (cybersecurity req.) We try to use fossil SCM as internal dev platform.

So at this moment we have this:

• docker-compose(d) fossil 2.18, running as UI behind reverse proxy (RPX)
• RPX exposes TLS w/ our internal authority cert and also forces client cert on request (fossil is plain http behind RPX w/ just --baseurl specified)
• we have one main repository named bootcamp.fossil where I have defined some 5 users (team members)
• I've setup devTeam@kzcr.eu login-group and there are aprox 5 repos in this group

now, I have test repository (lets say RnD.fossil), that is also member of devTeam@kzcr.eu login group w/

fossil config pull -R RnD.fossil user bootcamp.fossil

I can even see my user account (lets say adam) listed in RnD.fossil repo having setup,admin roles (over fossil UI), but I can't login into RnD.fossil repo using adam account. Login as adam is possible only through bootcamp repo and then I can navigate to RnD UI, being also in RnD.fossil adam & admin normally (confusing).

this command

fossil clone https://adam@devserver/RnD/team-repos/RnD --ssl-identity "adam.pem"

and also fossil pull/push

failes with Error: login failed

clonning anonymously is possible, but no way to push back changes (Error: login failed)

I also tried to anonymously clone bootcamp.fossil and after update remote-url, I was somehow randomly able to push back mini-change using:

fossil pull -B 'adam:[my pwd]' --ssl-identity "adam.pem"

but just once,... not being able to repeat again from scratch.

is there way to debug efficiently my setup to determine what causes login failed problem ? Do I miss something in users setup that I can't login using logon-group devTeam@kzcr.eu user account ?

w/ kind regards

A.W.

If you add the "--httptrace" option to your "clone" command, Fossil will create files named:

• http-request-N.txt
• http-reply-N.txt

These files will contain the complete, uncompressed HTTP requests and replies for each over the various round-trips to the server that took place during the clone attempt. The "N" is an integer that increments with each round-trip.

If it were me, I think I would start by looking at the requests and replies in order to try to understand what is going on.

hello Richard,

thank you very much for quick response. Unfortunatelly there was nothing suspicious in these log files :(, looks same when success and no sucess

I believe that my issue has nothing to do with cli commands (clone/push) as I can't login directly over UI to my RnD.fossil repo using any login-group account.

I also tried to run another fossil UI aside of main (same repository folder, no --pathprefix, no RPX before it) with same result :( I'll try to revert to 2.17

if I use repository start account "fossil" in clone command:

fossil clone https://fossil@myfosilserver/tls/sso-kerb/RnD/team-repos/RnD --ssl-identity "C:\trusted.pem"

is succesfull , but when I try:

fossil login-group join ../bootcamp.fossil --name "devTeam@kzcr.eu" -R ../RnD.fossil

fossil config pull -R ../RnD.fossil user ../bootcamp.fossil

fossil clone https://adam.user@myfosilserver/tls/sso-kerb/RnD/team-repos/RnD --ssl-identity "C:\trusted.pem"

ends with Error login failed

plus no way to login to RnD.fossil directly

:(

AW.

Is the "clone" command prompting you for a password?

Are you sure that the "adam.user" user exists and has "Clone" and "Check-out" capabilities (letters "g" and "i", respectively)?

yes, clone prompts me for password:

fossil clone https://adam.user@myserver/tls/sso-kerb/RnD/team-repos/RnD --ssl-identity "user.pem"
password for https://adam.user@myserver/tls/sso-kerb/RnD/team-repos/RnD: **************
remember password (Y/n)? n
Round-trips: 2   Artifacts sent: 0  received: 51
Error: login failed
Round-trips: 2   Artifacts sent: 0  received: 51
Clone done, wire bytes sent: 660  received: 20639  ip: 172.xx.xx.xx
server returned an error - clone aborted

same command but with "fossil" account ends ok.

actually, it is quite crazy to rename all to make it publicable :), my real accountname and servername is different, but yes

adam.user exists in bootcamp.fossil and also appear as setup,admin,developer in RnD.fossil UI after join login-group

I didnt set any other specific capabilities to adam.user except setup,admin,developer in bootcamp.fossil repo

actually, I just noted now that when I try

https://myserver/tls/sso-kerb/RnD/team-repos/bootcamp/setup_uedit?id=8

https://myserver/tls/sso-kerb/RnD/team-repos/RnD/setup_uedit?id=8

it shows different user accounts

I'm sorry, I don't know what is going wrong for you. You seem to have a complex setup. Something, somewhere, is probably misconfigured. But without being on-site and spending time trying to track down the problem, I don't know what that might be.

The way login-groups work is that passwords are shared across the repositories of a login-group, but usernames are not. This is by design. So, for example, if you have:

1. Repository One

   • User Alice
   • User Bob

2. Repository Two

   • User Bob
   • User Cindy

Then Bob can log into (or clone from) either One or Two using the same password. But Alice can only log into One and Cindy can only log into Two.

confused :(

what is wrong with my script and why I can see adam.user in secondaryRepo.fossil since usernames are not shared ?

what is right way to set it up, should I create all my teammates accounts in newly created repo before join login-group ?

what is then login-group good for ? since I have to create user and define its password in all repos ...

You have a complex setup. Therefore, I recommend:

1. First get everything working without the use of any login-groups. The login-group mechanism is just adding complication that makes your situation difficult to understand and debug.

2. After you get everything else working, then go back and turn on login-groups.

what is then login-group good for?

Login-groups were created as a convenience, to prevent users from having to enter their password multiple times, or to change their password in multiple places if their password ever does change.

Remember that Fossil was created to support SQLite development. There are several Fossil repositories for SQLite, including:

• https://sqlite.org/src for the source code
• https://sqlite.org/docsrc for the documentation
• https://sqlite.org/forum for the SQLite Forum
• https://sqlite.org/sqllogictest for the SQL Logic Test testing suite
• ... plus other non-public repositories.

It was a hassle for me to have to constantly enter my password into all of these repositories. So I created login-groups so that once you are logged into one, you are logged into all of the others for which you have a login.

You still must create a user account and set appropriate permissions on each repository separately. But once you have the accounts created, the user only has to login once in order to access all of the repositories.

Many people have accounts on the Forum, which allows them to post messages to the SQLite Forum. But most of the forum participates do not have accounts on the source repository, as they are not allowed to check in new code. It is for this reason that account management is not bundled with login-groups. We specifically do not want the fact that a user has an account on one repository to allow them equivalent access on all other repositories within the login group.

I've rewritten the login-groups doc to help with some of this confusion.

There are two other parts of the problem that are adding to the confusion:

1. Use of TLS client certs.

2. TLS termination in a proxy, rather than in Fossil itself.

Those two further interact with login groups by splitting responsibility for identifying users between the two halves.

Fossil's new TLS server feature (fossil server --cert FILE) may help here by keeping every part of this within Fossil. My major uncertainty here is whether Fossil supports client certs in this mode.

Richard,

thank you again for your time and explanation !!!

no prob w/ manual enter user account, it is just minor annoyance

but can you explain me, what does this command do ?

fossil config pull -R secondaryRepo.fossil user primaryRepo.fossil

w/ fossil 2.17 this command allowed me to login (clone/push) to other repos in same login-groups using username created in primary repo only. So I thought that it synchronizes users across repos, without need to manually enter their accounts into each repo in LG.

w/ 2.18 when I do:

fossil init primaryRepo.fossil
fossil user new adam.user "adam.user@myserver.com" "myPassword1" -R primaryRepo.fossil
fossil user capabilities "adam.user" "sa" -R primaryRepo.fossil
fossil init secondaryRepo.fossil
fossil login-group join secondaryRepo.fossil --name "test@LG" -R primaryRepo.fossil
#now, this copies users from primary to secondary and lets me login to primary and jump to secondary and stay admin but not login (push) directly to secondary
#it seems that during copy user receives some other passwd ??
fossil config pull -R secondaryRepo.fossil user primaryRepo.fossil
# this will also fail, user exists
fossil user new adam.user "adam.sida@company.org" "Passwd1" -R secondaryRepo.fossil

but when I just changed passwd of adam.user in secondaryRepo it started to work as with 2.17, I can directly login to secondary and push as well. So I suspect that fossil config pull command, just mismatches original passwd.

AW.

#it seems that during copy user receives some other passwd ??

The user's password is stored as a hash of various bits of data, and one of those pieces is a "secret" which is specific to each and every copy of every repository. Thus the passwords for one repo, when copied as-is to another repo, simply will not work because the hashes can never match what that repo expects. Fossil does not store the password as the user entered it, so it cannot recreate functional passwords when transferring users from one repository to another.

Though config pull can copy the list of users, and presumably their capabilities (though i've admittedly never cloned a user list in 14 years of using fossil), it is not capable of copying functional passwords.

hello Stephan,

thank you for explanation !!

so for new repo, after join logon-group I will have to:

• either create all users from scratch (pick some when no need to have all)
• or sync them and then reset all passwords

FYI

we have aprox 20+ separate apps to manage by SCM (potential repos) and 6-7 team members...as every hospital we suffers from employee fluctuation.

So we want to use our SSO w/ fossil as much as possible.

I made intranet login page w/ javascript that loads securely trusted personal data from LDAP and then based on LDAP user specific attributes auto login each team member to primary fossil repo + all www clients has personal certificate installed (trusted by RPX), so we need no login to fossil at all.

Today I sucessfully tested clone and autocommit/push over RPX w/ TLS client cert with http basic auth.

this setup would allow us to use even external developers in our highly secured environment.

again, thank you all for explanations and usefull hints

AW.

so for new repo, after join logon-group I will have to:

That sounds right to me but my cross-repo-account needs have never surpassed more than a handful of users in very simple setups, so i might be overlooking a detail or three which would be relevant for your case.

So we want to use our SSO w/ fossil as much as possible.

The ability to easily hook fossil in to existing SSO solutions would be a huge plus but it's never been actively explored, probably because the main developers don't use it in such environments. Certainly any patches to that effect would be, as Warren likes to put it, thoughtfully considered.

Today I sucessfully tested clone and autocommit/push over RPX w/ TLS client cert with http basic auth.

AFAIK you're the first person to ever do that with fossil. If you will post a HOWTO doc i'll be sure to get that integrated into our documentation to save the next person some effort.

thank you all for explanations and usefull hints

And thank you for your persistence in getting it running - this is a milestone event, IMO.

Login groups don’t depend on having the passwords synced. A common subset of user names suffices. Syncing the capability list is nice, though inessential.

Point being, one can log in on one repo in the group and then be logged into the others even if you aren’t able to log into them due to the hash mismatch problem Stephan brought up. Only one repo needs a useful password column, so long as that’s the common entry point.

LDAP obviates this of course. Just saying.

Only one repo needs a useful password column, so long as that’s the common entry point.

Do you mean that only this repo will be able to handle the login ? I guess to be useful it would need to be a kind of front repo that refer to the others ?

Even then, if one is logged out and access a repo without valid password column directly from bookmark, it would be redirected to a useless login page.

Do you have a use case where (and how) it could be usable?

I ask because I use login groups for a lot of repo in our server at works and the need to reset all password (or redo them from scratch) is a bit tedious.

Some cases that needs to be handle:

• Add a new user
  (Need to set password in every single repo?)
• Create a new repo
  (Need to create (or reset) all user password in it)

For sure, being able to have valid password column only in one « master » repo would simplify things a lot.

Do you have a use case where (and how) it could be usable?

I wasn't arguing that forcing a single entry point was a good idea. I was just pushing back against the claim up-thread that one must reset all passwords to be the same to use login-groups. As long as at least one repo login works, you're logged into the others, even if you can't get into them directly.

Add a new user (Need to set password in every single repo?)

Check the "apply to all" box in the Scope section of the user edit screen when you add the user. Now the user exists in all members of the login-group, with the same password and initial caps.

Create a new repo (Need to create (or reset) all user password in it)

Pushing the user table across with the config command per above will solve that. As Stephan says, the passwords are useless, but that only affects those that must enter the group via this new repo. Chances are, existing users have valid login cookies from prior successful logins, so even if you do have users who wish to enter the group via this new repo, the admin burden is a one-user-at-a-time kind of thing, not wholesale.

redirected to a useless login page.

I suspect you can fix that with the skin editor. With login groups active, there's no particular reason why you have to make the repo where you clicked "Logout" be the one that actually handles it. Make your master repo handle it, clearing the login cookie for the master, which then encourages one to log back in via the master repo.

Warren,

thanks for additional info about logon-group/user behaviour

It is confusing that ticking change everywhere & update passwd field, sets same passwd in all LG repos but fossil config pull ... user, can't set passwd into new repos properly.

actually, is there CLI command to update user passwd over whole LG repos?

IMHO this is my problem:

As long as at least one repo login works, you're logged into the others, even if you can't get into them directly.

until I can't push to such a repo from cli using my credentials, it is rather very confusing&useless that I can access it over www (even indirectly) being admin.

A.

It is confusing that ticking change everywhere & update passwd field, sets same passwd in all LG repos but fossil config pull ... user, can't set passwd into new repos properly.

It isn't strictly correct that "setting the same password in all repos" sets a password. Instead it hashes the password along with other ancillary data and stores the resulting hash, not the password. The consequences are these:

1. Some of that ancillary data differs per repo, so even after doing this, all repos in the login group won't have the same data in their user.pw field for that user.

2. Hashes are one-way functions, so there's no way to recover the original password from the hash and apply it to other repos.

it is rather very confusing&useless that I can access it over www

Then I think you want to work on tying Fossil into a proper SSO system, not continue fighting with login groups. You mention LDAP above, but there's also OAuth2, SAML, etc.

I don't see how you do LDAP "in javascript" as you say and make it secure against client-side tampering. It sounds like security in the "My Name Is…" sticker sense of identity assertion.

Today, "LDAP" is almost always code for "Active Directory," so maybe you want to be looking into adding an AD FS gateway to Fossil?

Warren,

IMHO inside corporate doesn't seem OAUTH,SAML,JWT always benefitial.

It's scenarios/workflows are perfect for "enemy" environment (internet) where user must confirm "yes I do trust/allow". But inside our intranet we force our users to "always trust" what we serve them :) plus even when RPX supports forward auth, w/ oldschool M$ kerberos SSO... it's tough.

We are 7 hospitals in 7 cities, having own "LAN" site, spanned 100km between most distant ones, redundant optical network, 9500 employes, 35000 electronic devices connected to our segmented network, hundreds of medical analyzators and thousands end users windows stations, from win xp to W11, Win servers, unix servers, medical servers, we don't consume any SAAS or cloud services all onpremise only + very limited budget for mini dev team.

we are under M$ extorture :(, and despite we have license for ADFS, it is prohibited because of security + we wish to go more FOSS-way.

there is clear picture what to do, but the (time) cost of integration all tools and is very high, so we slowly move toward some real SSO.

if LG would work as expected, it would be extremely usefull for 1-2 years now.

any hint for, CLI command to update user passwd over whole LG repos ?

b.r.A.W.

inside corporate doesn't seem OAUTH,SAML,JWT always benefitial.

SAML is about as enterprisey as you could wish. It's got the XML, it's got the OASIS, it's got the SOAP. The spec is even sponsored by IBM, Microsoft, Oracle, SAP, and Red Hat. What more do you need? A J2EE binding, maybe?

"enemy" environment (internet)

At your scale, your LAN is the enemy environment. If you think otherwise, you haven't been paying attention. How do you suppose so many of your fellow hospital networks have been cryptomalwared?

from win xp

You confess this in a thread about security? 🤦‍♂️

ADFS, it is prohibited because of security

Um…what? As far as I know, AD FS remains unbroken. Complicated, yes, but insecure? Not that I'm aware.

we wish to go more FOSS-way.

Then maybe FreeIPA will work for you. There's even a page in the docs on web app authentication, including a section on "federated authentication via SAML."

CLI command to update user passwd over whole LG repos

for repo in *.fossil
do
    fossil user password fred BARNEY -R $repo
done

Warren,

thank's for hint with CLI :)))), simpliest is always best.

just one more side note: in medical industry, apps are very very conservative and its release proces is loong (eg. even modern GE medical monitors vital function uses win xp, aside of special unix inside). In fact I have very few apps that somehow supports modern 2FA SSO, kerberos is high-tech :), so may be within next 10 years...

AW.