[Galene] Re: wildcard users

[Dirk-Willem van Gulik <dirkx@webweaving.org>]

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.