[Galene] wildcard users

[Galene] wildcard users

[Dirk-Willem van Gulik]

I am currently allowing people to enter an arbitrary name (and no password) on certain calls with a definition such as:

	// Generated 2026-11-02 11:09:23 UTC, project bar-test, DB: 9656dfdac01ba854402ca635e
	{
	  "public": false,
	  "op": [
		    {
		      "username": "xxxchairpersonxxx",
		      "password":  {"type":"bcrypt","key":"XXX"}
		    }
 	 ],
	  "users": {
		"XXXXmoderator1XXX":{"permissions": "present",....},
  		"XXXXmoderator2XXX":{"permissions": "present",....}
	  },
	  "wildcard-user": {
		"password": "",  "permissions": "present"
	  },
	  "presenter": [
	    {}
	  ]
	}

And am now seeing 

	Nov  2 03:56:52 jailed-galene daemon[19372]: 
		2026/11/02 03:56:52 /var/db/galene/groups/XXXXXXXX.json: duplicate wildcard user 
			2026/11/02 03:56:52 /var/db/galene/groups/XXXXXXXXX.json: duplicate wildcard user

in my log. Why is this ? And what is the right way to allow arbitrary names (and an empty or fixed, simple PIN style, password for ad-hoc cases where sending an invite or similar hurdle/extra step is non ideal) ?

With kind regards,

Dw

[Galene] Re: wildcard users

[Juliusz Chroboczek]

> 	// Generated 2026-11-02 11:09:23 UTC, project bar-test, DB: 9656dfdac01ba854402ca635e

You're mixing the old syntax (deprecated with Galene 0.9 in May 2024) with
the new syntax.  You have a wildcard user in the new syntax:

> 	  "wildcard-user": {
> 		"password": "",  "permissions": "present"
> 	  },

and one in the old syntax:

> 	  "presenter": [
> 	    {}
> 	  ]

Since Galene will convert the old syntax to the new one internally, you
end up with a duplicate wildcard user.

The simplest way to convert the group is to update the group using the
API, Galene will rewrite the group in the new syntax.  I did

    echo '{}' | galenectl update-group -group bolduc -json

which yielded

    {
        "users": {
            "XXXXmoderator1XXX": {"permissions": "present"},
            "XXXXmoderator2XXX": {"permissions": "present"},
            "xxxchairpersonxxx": {
                "password": {"type": "bcrypt","key": "XXX"},
                "permissions": "op"
            }
        },
        "wildcard-user": {"password": "","permissions": "present"}
    }

Note that the two moderators have no password, they cannot login until you
set a password.  (This was not possible in the old syntax, which interpreted
a lack of a password as a wildcard.)

I then did

    galenectl set-password -group bolduc -wildcard -type wildcard

which yielded

    {
        ...
        wildcard-user":{"password":{"type":"wildcard"},"permissions":"present"}
    }

(The difference between an empty password and a password of type wildcard
is that the latter allows any password.)

> And what is the right way to allow arbitrary names (and an empty or
> fixed, simple PIN style, password for ad-hoc cases where sending an
> invite or similar hurdle/extra step is non ideal) ?

Both of your syntaxes are correct, you should use one or the other, just
not both.

Another note: since you're generating passwords automatically, you may
consider going through the API rather than editing files on disk.  Editing
files on disk is still supported, but of course it doesn't guarantee
mutual exclusion if two programs edit the same file at the same time.
You'll find race-free code to do that here:

   - in Go: galenectl/galenectl.go starting at line 470;
   - in JS: static/management.js.

-- Juliusz

[Galene] Re: wildcard users

[Dirk-Willem van Gulik]

On 2 Nov 2026, at 13:05, Juliusz Chroboczek <jch@irif.fr> wrote:

>> 	// Generated 2026-11-02 11:09:23 UTC, project bar-test, DB: 9656dfdac01ba854402ca635e
> 
> You're mixing the old syntax (deprecated with Galene 0.9 in May 2024) with

Ah clear - yes - we've been using this for quite a while now.

> the new syntax.  You have a wildcard user in the new syntax:
> 
>> 	  "wildcard-user": {
>> 		"password": "",  "permissions": "present"
>> 	  },
> 
> and one in the old syntax:
> 
>> 	  "presenter": [
>> 	    {}
>> 	  ]
> 
> Since Galene will convert the old syntax to the new one internally, you
> end up with a duplicate wildcard user.
> 
> The simplest way to convert the group is to update the group using the
> API, Galene will rewrite the group in the new syntax.  I did
> 
>    echo '{}' | galenectl update-group -group bolduc -jso

Ah - that is neat - did not know we could do that.

> which yielded
> 
>    {
>        "users": {
>            "XXXXmoderator1XXX": {"permissions": "present"},
>            "XXXXmoderator2XXX": {"permissions": "present"},
>            "xxxchairpersonxxx": {
>                "password": {"type": "bcrypt","key": "XXX"},
>                "permissions": "op"
>            }
>        },
>        "wildcard-user": {"password": "","permissions": "present"}
>    }
> 
> Note that the two moderators have no password, they cannot login until you
> set a password.  (This was not possible in the old syntax, which interpreted
> a lack of a password as a wildcard.)
> 
> I then did
> 
>    galenectl set-password -group bolduc -wildcard -type wildcard
> 
> which yielded
> 
>    {
>        ...
>        wildcard-user":{"password":{"type":"wildcard"},"permissions":"present"}
>    }
> 
> (The difference between an empty password and a password of type wildcard
> is that the latter allows any password.)

Clear. And clear how to set it - we never quite got that from the documentation - apologies.

>> And what is the right way to allow arbitrary names (and an empty or
>> fixed, simple PIN style, password for ad-hoc cases where sending an
>> invite or similar hurdle/extra step is non ideal) ?
> 
> Both of your syntaxes are correct, you should use one or the other, just
> not both.

Clear - thanks - and that indeed fixed it. Working now perfectly without warnings.

> Another note: since you're generating passwords automatically, you may
> consider going through the API rather than editing files on disk.  Editing
> files on disk is still supported, but of course it doesn't guarantee
> mutual exclusion if two programs edit the same file at the same time.
> You'll find race-free code to do that here:
> 
>   - in Go: galenectl/galenectl.go starting at line 470;
>   - in JS: static/management.js.

I think we are a bit addicted to generating data configuration files at the same time as we are standing up our (freebsd-jailed) ad-hoc environments  - as that is much easier to fit into our automation/IDS-es which is fairly limited in terms of what networking it can do, generally has no shell/exec()ability and currently lacks third party tools such as galenectl. But i guess we're the odd one out.

So thanks for that clear direction of travel clear - will look if we can still somehow use the API in lieu of the files (or use the APIs to generate the files in an isolated instance).

With kind regards,

Dw.

[Galene] Re: wildcard users

[Juliusz Chroboczek]

> as that is much easier to fit into our automation/IDS-es which is fairly
> limited in terms of what networking it can do

[...]

> will look if we can still somehow use the API in lieu of the files

No need to change, in your setup it's clearly easier to edit the files
directly.  And you're obviously not worried about race conditions since
Galene is not running when you generate the files.

(I really should look into providing a machine-readable schema for Galene's
configuration files.  I like CDDL myself, but I guess that most folks
already have the tooling for JSON-Schema.)

-- Juliusz