[Galene] Re: wildcard users

[Juliusz Chroboczek <jch@irif.fr>]

> 	// 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