From Martin.Spott at mgras.net  Sat Jun  6 11:23:34 2026
From: Martin.Spott at mgras.net (Martin Spott)
Date: Sat, 06 Jun 2026 20:23:34 +0200 (CEST)
Subject: [MOTION] Bid for OSGeo System Admin contract 2026
In-Reply-To: <ahffi1zVEKVC-0-q@c23>
Message-ID: <20260606182334.E36016DFC@rumba.mgras.de>

Great, my +1, if acceptable,

	Martin

From lnicola at dend.ro  Fri Jun 12 11:49:43 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Fri, 12 Jun 2026 21:49:43 +0300
Subject: [MOTION] Bid for OSGeo System Admin contract 2026
In-Reply-To: <ahcKh9W9esqp9zup@c23>
References: <ahcKh9W9esqp9zup@c23>
Message-ID: <08573708-1069-42d0-b49d-c3963bfa9147@app.fastmail.com>

+1

Lauren?iu

On Wed, May 27, 2026, at 18:15, Sandro Santilli via Sac wrote:
> This is my bid for System Admin Contract 2026, general support.
> I am bidding for 60 hrs at ?128/hr for a total of ?7,080.
>
> This would come out of an approved budget of 16000 USD ( ?13,756 as of today ).
>
> The proposed contract can be found here:
> https://nextcloud.osgeo.org/apps/files/files/6586476?dir=/Admin/Contracts/Proposed
>
> --strk;
>
>   Libre GIS consultant/developer ?
>   https://strk.kbt.io/services.html
>
> Attachments:
> * signature.asc

From trac_osgeo at osgeo.org  Sat Jun 13 05:17:52 2026
From: trac_osgeo at osgeo.org (OSGeo)
Date: Sat, 13 Jun 2026 12:17:52 -0000
Subject: [OSGeo] Batch modify: #3067, #2976, #3002, #3009, #3018, #3033, #3039,
 ...
In-Reply-To: <092.8d569764d746dd5882395bbb2bd6588b@osgeo.org>
References: <092.8d569764d746dd5882395bbb2bd6588b@osgeo.org>
Message-ID: <085.f463d8973be0ceaee9589f1da3932202@osgeo.org>

Batch modification to #3067, #2976, #3002, #3009, #3018, #3033, #3039, #3253, #3413, #3428, #3429, #3436, #3440 by strk:
milestone to Milestone Sysadmin Contract 2026-I (strk)
Comment:
Ticket retargeted after milestone closed
-- 
Tickets URL: <https://trac.osgeo.org/osgeo/query?id=3067%2C2976%2C3002%2C3009%2C3018%2C3033%2C3039%2C3253%2C3413%2C3428%2C3429%2C3436%2C3440>
OSGeo <https://osgeo.org/>
OSGeo committee and general foundation issue tracker.

From strk at kbt.io  Sat Jun 13 05:19:37 2026
From: strk at kbt.io (Sandro Santilli)
Date: Sat, 13 Jun 2026 14:19:37 +0200
Subject: [MOTION PASSED] Bit for OSGeo System Admin contract 2026 for strk
Message-ID: <ai1K2XSKq1RdKvWS@c19.localdomain>

I declare the motion to grant me a sysadmin contract passed.

Motion thread as seen on Discourse:
  https://discourse.osgeo.org/t/motion-bid-for-osgeo-system-admin-contract-2026/153870/4

To recap, it got:

  +1 Regina Obe
  +1 Jorge Sanz
  +1 Martin Spott
  +1 Vicky Vergara ( Discourse only, hit by [1] )
  +1 Markus Neteler ( Discourse only, hit by [1] )
  +1 Lauren?iu Nicola

I've opened a new milestone in Trac [2] and moved my old tickets there.

[1] https://trac.osgeo.org/osgeo/ticket/3584
[2] https://trac.osgeo.org/osgeo/milestone/Milestone%20Sysadmin%20Contract%202026-I%20(strk)

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20260613/30124d11/attachment.sig>

From tomkralidis at gmail.com  Sat Jun 13 06:49:26 2026
From: tomkralidis at gmail.com (Tom Kralidis)
Date: Sat, 13 Jun 2026 10:49:26 -0300
Subject: [MOTION PASSED] Bit for OSGeo System Admin contract 2026 for strk
In-Reply-To: <ai1K2XSKq1RdKvWS@c19.localdomain>
References: <ai1K2XSKq1RdKvWS@c19.localdomain>
Message-ID: <15E7FE1B-EB5E-41BB-B6D2-9DB767D82880@gmail.com>

Thanks. +1 from me.

..Tom

Sent from my iPhone

> On Jun 13, 2026, at 09:19, Sandro Santilli <strk at kbt.io> wrote:
> 
> ?I declare the motion to grant me a sysadmin contract passed.
> 
> Motion thread as seen on Discourse:
>  https://discourse.osgeo.org/t/motion-bid-for-osgeo-system-admin-contract-2026/153870/4
> 
> To recap, it got:
> 
>  +1 Regina Obe
>  +1 Jorge Sanz
>  +1 Martin Spott
>  +1 Vicky Vergara ( Discourse only, hit by [1] )
>  +1 Markus Neteler ( Discourse only, hit by [1] )
>  +1 Lauren?iu Nicola
> 
> I've opened a new milestone in Trac [2] and moved my old tickets there.
> 
> [1] https://trac.osgeo.org/osgeo/ticket/3584
> [2] https://trac.osgeo.org/osgeo/milestone/Milestone%20Sysadmin%20Contract%202026-I%20(strk)
> 
> --strk;
> 
>  Libre GIS consultant/developer ?
>  https://strk.kbt.io/services.html
> <signature.asc>

From strk at kbt.io  Mon Jun 15 09:14:39 2026
From: strk at kbt.io (Sandro Santilli)
Date: Mon, 15 Jun 2026 18:14:39 +0200
Subject: Board to vote on the mantra requirement
Message-ID: <ajAk7xoyWq8ZpdGO@c19.localdomain>

I've stumbled upon the minutes from the board meeting of March 31, 2026
and found what looks like an ill-defined motion to:

  - Drop the "mantra" requirement to become an OSGeo User

  - Allow anyone with a passport from major corporations (Google, Meta, Apple, Microsoft) to automatically become an "OSGeo User"

The motion goal seems to be aimed at simplifyinng the onboarding experience,
but seems to be missing the point of the "mantra" as an intentional barrier
we setup to protect ourselves from spammers.

In this era of raising barriers against AI agents finding a contrary motion to
instead open up our shared house to strangers seems unexpected so I'm voicing
my concern about it.


On the technical side, I'd be very favorable in deploying Keycloack as
a Single Sign On solution, to allow services provided by OSGeo and by
others to accept the "OSGeo Passport" in addition to other passports
they may choose to support, but I think there's still a value in the effort
it takes to obtain such "OSGeo Passport" and that removing that barrier would
reduce such value.

I hope the board members will make an effort to understand the topic more deeply
in order to be able to take an informed decision, and I'm surprised SAC list was
not involved in the conversation.

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20260615/72c10e4c/attachment.sig>

From lr at pcorp.us  Mon Jun 15 09:40:20 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 15 Jun 2026 12:40:20 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <ajAk7xoyWq8ZpdGO@c19.localdomain>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
Message-ID: <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>

> I've stumbled upon the minutes from the board meeting of March 31, 2026
> and found what looks like an ill-defined motion to:
> 
>   - Drop the "mantra" requirement to become an OSGeo User
> 
>   - Allow anyone with a passport from major corporations (Google, Meta,
> Apple, Microsoft) to automatically become an "OSGeo User"
> 
I agree here.  It's unclear from the motion, if we are just to trust anyone with a Google or Meta or whatever account with out proper vetting.



> The motion goal seems to be aimed at simplifyinng the onboarding
> experience, but seems to be missing the point of the "mantra" as an
> intentional barrier we setup to protect ourselves from spammers.
> 
> In this era of raising barriers against AI agents finding a contrary motion to
> instead open up our shared house to strangers seems unexpected so I'm
> voicing my concern about it.
> 
> 
> On the technical side, I'd be very favorable in deploying Keycloack as a Single
> Sign On solution, to allow services provided by OSGeo and by others to accept
> the "OSGeo Passport" in addition to other passports they may choose to
> support, but I think there's still a value in the effort it takes to obtain such
> "OSGeo Passport" and that removing that barrier would reduce such value.
> 
If keycloak allowed that, that would be great.  Don't know enough about it to know and how exactly it would tie in to some of our other services 
Like weblate / discourse which already support multiple auths.

I think I'd still want to stick with LDAP at least for accessing our servers, because we use that to hold our ssh public keys to authenticate project members to access their servers.
I'm not sure if keycloak could do that, it sounds like it would still need LDAP as an authentication source and delegate to that.


The main pain points I see with LDAP brought up:

a) The MFA brought up in the motion - which I agree with that we need MFA for LDAP for the id.osgeo.org but I suspect that is not that hard to fix.

b) What LDAP is used for that it may not need to be:
1) Signing up for code sprints on WIKI -- it is kinda silly someone needs an OSGeo account to sign up for a code-sprint, that probably should just be moved to discourse (I need to check but I think there is an event's plugin we can use or mark a topic as a wiki and allow people to add their names) .  Discourse already is pretty frictionless you can self-register, use github, or a https://id.discourse.com  which lets you sign up with any of those commercial services already.

2) The large number of QGIS plugin authors needing an OSGeo account, which thankfully Richard Duivenvoorde has been handling now.
   For this case, I really would like Keycloak rolled out for this and see how it works before we put any great effort in changing our other infrastructure to support it.
https://github.com/qgis/QGIS-Plugins-Website/issues/274



> I hope the board members will make an effort to understand the topic more
> deeply in order to be able to take an informed decision, and I'm surprised SAC
> list was not involved in the conversation.
> 
> --strk;
> 
>   Libre GIS consultant/developer ?
>   https://strk.kbt.io/services.html


From strk at kbt.io  Mon Jun 15 10:19:51 2026
From: strk at kbt.io ('Sandro Santilli')
Date: Mon, 15 Jun 2026 19:19:51 +0200
Subject: Board to vote on the mantra requirement
In-Reply-To: <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
Message-ID: <ajA0N3BDLxq1t5V1@c19.localdomain>

On Mon, Jun 15, 2026 at 12:40:20PM -0400, Regina Obe wrote:

> The main pain points I see with LDAP brought up:
> 
> a) The MFA brought up in the motion - which I agree with that we need MFA for LDAP for the id.osgeo.org but I suspect that is not that hard to fix.

Note that some of our services already support multi-factor authentication locally,
for example Gitea: https://gitea.osgeo.org/user/settings/security

To activate MFA we need a _second_ factor, so by definition something in addition to what we already have, which means you don't need to ditch LDAP in order to get MFA.

> b) What LDAP is used for that it may not need to be:
>
> 1) Signing up for code sprints on WIKI

I'm not familiar with the code sprints setup, I guess even an email would be ok to sign-up ?

> 2) The large number of QGIS plugin authors needing an OSGeo account

I think the QGIS Plugins Repository service could just accept whatever
passport is provided by the companies QGIS PSC decides to trust, there's
no need to change anything on the OSGeo infrastructure side for that, and
definitely we don't need a centralized Keycloack for that (as long as I know).

I see the "accept other passports" as something we want to enable or disable
on a per-service basis. Some services provide more protection against spam,
some are weaker, we want stronger identity for the weaker ones, I think.

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20260615/717b986c/attachment-0001.sig>

From lr at pcorp.us  Mon Jun 15 10:27:27 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 15 Jun 2026 13:27:27 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <ajA0N3BDLxq1t5V1@c19.localdomain>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us> <ajA0N3BDLxq1t5V1@c19.localdomain>
Message-ID: <005901dcfcec$3d31fd80$b795f880$@pcorp.us>

> > The main pain points I see with LDAP brought up:
> >
> > a) The MFA brought up in the motion - which I agree with that we need MFA
> for LDAP for the id.osgeo.org but I suspect that is not that hard to fix.
> 
> Note that some of our services already support multi-factor authentication
> locally, for example Gitea: https://gitea.osgeo.org/user/settings/security
> 
Yes so does our wordpress, which was brought up, but we don't have using it enforced.
We don't have enforced on gitea either.

We didn't do that to minimize friction but that would be the first thing.

I think though that id.osgeo.org should require MFA cause that's where people setup their passwords, emails, and put their public keys.
That has always bothered me it does not require MFA.


> To activate MFA we need a _second_ factor, so by definition something in
> addition to what we already have, which means you don't need to ditch LDAP
> in order to get MFA.
> 
> > b) What LDAP is used for that it may not need to be:
> >
> > 1) Signing up for code sprints on WIKI
> 
> I'm not familiar with the code sprints setup, I guess even an email would be ok
> to sign-up ?
> 

I know that a lot of OSGeo events create a page on the wiki and have people signup there.
I was thinking possibly https://talks.osgeo.org could be used for this but not sure cause that would be the most logical place to put it since the calendar of who's speaking is in there already and all the international and many of the local FOSS4Gs are already using it to accept speakers.

> > 2) The large number of QGIS plugin authors needing an OSGeo account
> 
> I think the QGIS Plugins Repository service could just accept whatever
> passport is provided by the companies QGIS PSC decides to trust, there's no
> need to change anything on the OSGeo infrastructure side for that, and
> definitely we don't need a centralized Keycloack for that (as long as I know).
> 
> I see the "accept other passports" as something we want to enable or disable
> on a per-service basis. Some services provide more protection against spam,
> some are weaker, we want stronger identity for the weaker ones, I think.
> 
> --strk;
> 
>   Libre GIS consultant/developer ?
>   https://strk.kbt.io/services.html


From gdt at lexort.com  Mon Jun 15 10:30:22 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 15 Jun 2026 13:30:22 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <ajAk7xoyWq8ZpdGO@c19.localdomain> (Sandro Santilli via Sac's
 message of "Mon, 15 Jun 2026 18:14:39 +0200")
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
Message-ID: <rmi5x3jzp75.fsf@s1.lexort.com>

Sandro Santilli via Sac <sac at lists.osgeo.org> writes:

> I've stumbled upon the minutes from the board meeting of March 31, 2026
> and found what looks like an ill-defined motion to:
>
>   - Drop the "mantra" requirement to become an OSGeo User
>
>   - Allow anyone with a passport from major corporations (Google, Meta, Apple, Microsoft) to automatically become an "OSGeo User"

Speaking as someone on the periphery who has never been clear on this,
because I've had an osgeo id for a really long time:

  I have been seeing "mantra" and found it odd phrasing.  It was seemed
  obvious that somehow people needed permission for account creation, to
  stop spa, and that makes sense, but I would have expected that people
  could create an account and then someone -- perhaps a large class of
  people -- could approve the person as not a spammer to make it really
  active, vs getting timed out, and we'd do that if someone had been
  interacting reasonably or something.  Deciding to turn that off seems
  surprising.

  I find the word "passport" to be very strange, and I wonder if I'm
  just not up on terminology.  I would think this is an account that can
  be used as an identity provider, and if that's what people mean would
  be good to actually say that.

  I find the idea of accepting an account with a "major corporation"
  (when people can't just sign up) as deeply offensive and contrary to
  what osgeo should be doing.  That normalizes big tech's bad practices,
  including invasive identity requirements.  I am frequently spammed by
  google, via people that have created google accounts and gmail, and by
  people that have further created custom domains.  The idea that a
  google account proves that you aren't a spammer is ludicrous.

  I would go so far as to say that accounts from an IdP should only be
  accepted for signup if they meet ethical standards, such as not
  requiring the person to provide a phone number.  If osgeo does not
  have a True Name policy, then add that too.   I'm less concerned about
  letting a person who can log in link another IdP.

> On the technical side, I'd be very favorable in deploying Keycloack as
> a Single Sign On solution, to allow services provided by OSGeo and by
> others to accept the "OSGeo Passport" in addition to other passports
> they may choose to support, but I think there's still a value in the effort
> it takes to obtain such "OSGeo Passport" and that removing that barrier would
> reduce such value.

Modulo using the word 'passport', that makes a lot of sense to me.



Perhaps we should be separating authentication and the authorization
function for account creation.  The big issue is requiring authorization
for osgeo account creation.

From gdt at lexort.com  Mon Jun 15 10:39:34 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 15 Jun 2026 13:39:34 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us> (Regina Obe's message
 of "Mon, 15 Jun 2026 12:40:20 -0400")
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
Message-ID: <rmi1pe7zort.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

>> On the technical side, I'd be very favorable in deploying Keycloack as a Single
>> Sign On solution, to allow services provided by OSGeo and by others to accept
>> the "OSGeo Passport" in addition to other passports they may choose to
>> support, but I think there's still a value in the effort it takes to obtain such
>> "OSGeo Passport" and that removing that barrier would reduce such value.
> 
> If keycloak allowed that, that would be great.  Don't know enough
> about it to know and how exactly it would tie in to some of our other
> services Like weblate / discourse which already support multiple
> auths.
>
> I think I'd still want to stick with LDAP at least for accessing our
> servers, because we use that to hold our ssh public keys to
> authenticate project members to access their servers.  I'm not sure if
> keycloak could do that, it sounds like it would still need LDAP as an
> authentication source and delegate to that.

It may be interesting to look at openstreetmap's experience.  There is
now, I think, OAUTH2, and various things can invoke that to get
credentials to act as the user against the main site.  That may be
different from federated identity "login with foo".

I think the LDAP/ssh issue is that beyond the web authentication flow
(which can be turned into MFA by requiring that at login time), there is
authentication *not via web protocols* and in particular ssh pubkeys.
So an osgeo user has

  web authentication
  a set of ssh keys

whether the ssh keys are in in LDAP or some other mechanism matters for
maintainability but I don't see it as fundamental.  (I also don't see a
reason to change.).

I think it's entirely reasonable, as a long term plan, to have all
services that do web auth to use some kind of oauth2 and not accept
passwords, and thus not have to have passwords in LDAP.

> The main pain points I see with LDAP brought up:
>
> a) The MFA brought up in the motion - which I agree with that we need MFA for LDAP for the id.osgeo.org but I suspect that is not that hard to fix.

I don't follow "MFA for LDAP".  The issue is not so much access to LDAP
but MFA for people wanting access while being validated by credentials
stored in LDAP.  Maybe you meant that.

> 2) The large number of QGIS plugin authors needing an OSGeo account, which thankfully Richard Duivenvoorde has been handling now.
>    For this case, I really would like Keycloak rolled out for this and see how it works before we put any great effort in changing our other infrastructure to support it.
> https://github.com/qgis/QGIS-Plugins-Website/issues/274

That sounds like they are deciding that they are willing to take any
account with no anti-spam signup.
And, to discriminate in favor of those with big tech relationships.

From lr at pcorp.us  Mon Jun 15 10:52:19 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 15 Jun 2026 13:52:19 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <rmi5x3jzp75.fsf@s1.lexort.com>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain> <rmi5x3jzp75.fsf@s1.lexort.com>
Message-ID: <000001dcfcef$b668d860$233a8920$@pcorp.us>

> > I've stumbled upon the minutes from the board meeting of March 31,
> > 2026 and found what looks like an ill-defined motion to:
> >
> >   - Drop the "mantra" requirement to become an OSGeo User
> >
> >   - Allow anyone with a passport from major corporations (Google, Meta,
> Apple, Microsoft) to automatically become an "OSGeo User"
> 
> Speaking as someone on the periphery who has never been clear on this,
> because I've had an osgeo id for a really long time:
> 
>   I have been seeing "mantra" and found it odd phrasing.  It was seemed
>   obvious that somehow people needed permission for account creation, to
>   stop spa, and that makes sense, but I would have expected that people
>   could create an account and then someone -- perhaps a large class of
>   people -- could approve the person as not a spammer to make it really
>   active, vs getting timed out, and we'd do that if someone had been
>   interacting reasonably or something.  Deciding to turn that off seems
>   surprising.
> 
Yah we had that with wiki, but what happened is the list of people queued up
waiting to be approved and no one had time to approve them.
I think the main issue is regardless whether you allow people to register
and vet them later or vet them before they register.
You still have the same problem:

Someone has to vet them, and everyone seems to be trying to get around
having no one vet them to save people time.
So the burden always falls on just a few people who get exhausted and leave.

Like for example on discourse we do allow everyone to register, use github,
use ldap whatever, but the very first post they do we require vetting.
That is because we got spammed a lot when we didn't require vetting.

Even there where there are quite a few people that can vet, the burden ends
up falling on just a few people because no one has time to vet anyone.

Now if we did have keycloak, in theory we could allow OpenStreetMap (IdP) as
a trusted provider and if they've already vetted someone, chances are we can
trust that person and not bother revetting for most services we provide.
Same for PostgreSQL and other open source orgs that already have a single
sign on system.

I do prefer the vet first (to make sure you are a good actor or autovetting
if we really trust the IdP) before allowing your identity to exist in our
system, cause otherwise your system is just filled with spam accounts.
Some services require more vetting than others, but a basic account should
allow you to do something.

> 
> 
> Perhaps we should be separating authentication and the authorization
> function for account creation.  The big issue is requiring authorization
for
> osgeo account creation.

The big issue is having an account you can do something with.  I agree that
yes the authorization is a separate issue.
To Sandro's and your point, it really matters the level of vetting you need
what we allow a non-authorized account to do.

I feel it should increase with longevity and past performance.  Discourse
has kind of this idea, where it increases your user permissions as you
interact more with the system e.g asking questions, providing solutions etc.


From lr at pcorp.us  Mon Jun 15 10:57:00 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 15 Jun 2026 13:57:00 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <rmi1pe7zort.fsf@s1.lexort.com>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>	<003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
 <rmi1pe7zort.fsf@s1.lexort.com>
Message-ID: <000101dcfcf0$5e46a170$1ad3e450$@pcorp.us>

> I think the LDAP/ssh issue is that beyond the web authentication flow
(which
> can be turned into MFA by requiring that at login time), there is
authentication
> *not via web protocols* and in particular ssh pubkeys.
> So an osgeo user has
> 
>   web authentication
>   a set of ssh keys
> 
> whether the ssh keys are in in LDAP or some other mechanism matters for
> maintainability but I don't see it as fundamental.  (I also don't see a
reason to
> change.).
> 
> I think it's entirely reasonable, as a long term plan, to have all
services that do
> web auth to use some kind of oauth2 and not accept passwords, and thus not
> have to have passwords in LDAP.
> 

Agree.  Yes it wasn't so much the MFA of LDAP as much as just protecting our
id.osgeo.org website where they edit their profile and register their ssh
keys.
You can't do anything with an ssh key if you are not in the shell group
anyway.  So it's mostly a concern with shell users having their accounts
compromised.



From gdt at lexort.com  Mon Jun 15 11:03:40 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 15 Jun 2026 14:03:40 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <000001dcfcef$b668d860$233a8920$@pcorp.us> (Regina Obe's message
 of "Mon, 15 Jun 2026 13:52:19 -0400")
References: <ajAk7xoyWq8ZpdGO@c19.localdomain> <rmi5x3jzp75.fsf@s1.lexort.com>
 <000001dcfcef$b668d860$233a8920$@pcorp.us>
Message-ID: <rmise6ny937.fsf@s1.lexort.com>

That makes sense why it's hard, but the idea that "user has an account
with $somebody is evidence that they are not a bad actor" fundamentally
does not make sense, unless the other entity has signup/vetting rules
that are at least as strict.

AFAIK you can just sign up with OSM.  If you misbehave your edits are
reverted and you get blocked.  But as with osgeo I've had an account for
a long time and have no recent experience.   I'm pretty sure that
accepting osm members as vetted will just lead spammers to register
there, then register at osgeo, which even seems scriptable ;-)


From lnicola at dend.ro  Mon Jun 15 12:42:24 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Mon, 15 Jun 2026 22:42:24 +0300
Subject: Board to vote on the mantra requirement
In-Reply-To: <rmise6ny937.fsf@s1.lexort.com>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain> <rmi5x3jzp75.fsf@s1.lexort.com>
 <000001dcfcef$b668d860$233a8920$@pcorp.us>
 <rmise6ny937.fsf@s1.lexort.com>
Message-ID: <2f1c2516-acc7-4c6f-bbdc-35d22eeda649@app.fastmail.com>

> the idea that "user has an account with $somebody is evidence that they are not a bad actor" fundamentally does not make sense

And yet this was exactly criterion based on which I've sent the mantra to hundreds of people: a GitHub account showing their email address.

Over the past couple of years, I've probably sent thousands of responses to mantra-request. I'm pretty certain I have not stopped a single spammer. I did stop a bunch of people with no public online identity. It's not a contribution I'm proud of.

> passport

That term reminds me of Microsoft Passport, which wasn't that great, was it? People aren't logging in with Gmail because it's their passport, but rather because it's convenient to remember one less password. It's not a statement, it's just convenience.

> arguments for keeping the mantra

First, I'd like to point out that the staunchest supporters of the mantra are not responding to ~300 requests each month. I did that for a long time. I finally cracked when, after asking a 500th user to upload the source code of a QGIS plugin (instead of a ZIP), I got instead a Python file called "source code" added to the repo.

Thanks to Richard for picking this up.

> I think the QGIS Plugins Repository service could just accept whatever passport is provided by the companies QGIS PSC decides to trust

It already accepts GItHub, GitLab and Gmail.

> older arguments about requiring a domain to get an account

I'd hate this. Not everyone has or needs a domain. I've never seen such a high bar to enter a community, especially one that calls itself "Open".

> older arguments not wanting to get more issues filed

This is just as bad as stalebot.

> older arguments about the sense of a community

Sure, a community would be nice, but how many of the thousands who registered to publish their plugins or to report a PostGIS issue are really part of the community? They uploaded their plugin or filed their issue, and none of us saw them again.


So yeah, I don't think I would miss the mantra too much if it went away.

Laurentiu

From lnicola at dend.ro  Mon Jun 15 13:36:40 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Mon, 15 Jun 2026 22:36:40 +0200
Subject: Board to vote on the mantra requirement
In-Reply-To: <2f1c2516-acc7-4c6f-bbdc-35d22eeda649@app.fastmail.com>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain> <rmi5x3jzp75.fsf@s1.lexort.com>
 <000001dcfcef$b668d860$233a8920$@pcorp.us>
 <rmise6ny937.fsf@s1.lexort.com>
 <2f1c2516-acc7-4c6f-bbdc-35d22eeda649@app.fastmail.com>
Message-ID: <daaaab8d-86c7-41ac-b0d1-c4348b35084e@app.fastmail.com>

PS: I think the mantra is fine, but its scope is too large. It's fine if we make people jump through hoops to get a page on our WordPress. But for QGIS I think we should just tell them to use the other SSOs.

Laurentiu

From gdt at lexort.com  Mon Jun 15 15:14:24 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 15 Jun 2026 18:14:24 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <2f1c2516-acc7-4c6f-bbdc-35d22eeda649@app.fastmail.com>
 (=?utf-8?Q?=22Lauren=C8=9Biu?= Nicola"'s message of "Mon, 15 Jun 2026
 22:42:24 +0300")
References: <ajAk7xoyWq8ZpdGO@c19.localdomain> <rmi5x3jzp75.fsf@s1.lexort.com>
 <000001dcfcef$b668d860$233a8920$@pcorp.us>
 <rmise6ny937.fsf@s1.lexort.com>
 <2f1c2516-acc7-4c6f-bbdc-35d22eeda649@app.fastmail.com>
Message-ID: <rmi4ij3xxhb.fsf@s1.lexort.com>

Your points about the mantra process being a lot of work and not
achieving its security goals are compelling.  I am an outsider, but this
leaves me not seeing the point of keeping doing that.






>> passport
>
> That term reminds me of Microsoft Passport, which wasn't that great,
> was it? People aren't logging in with Gmail because it's their
> passport, but rather because it's convenient to remember one less
> password. It's not a statement, it's just convenience.

The situation makes me really uncomfortable with using the word.  It's
just an ID provider, and nothing more.  I suggest osgeo adopt a policy
of not using the term passport.

I also think using words so that normies will think they will
udnerstand, when they don't, is harmful.

>> I think the QGIS Plugins Repository service could just accept whatever passport is provided by the companies QGIS PSC decides to trust
>
> It already accepts GItHub, GitLab and Gmail.

Again that seems wrong to preference big tech.

It seems like osgeo is attempting to be an ID provider with osgeo
accounts, and that qgis repo should just use those (which people, having
created an account, can perhaps associate some ID provider with, in an
open standards even handed way that doesn't preference specific
proprietary monopolies).  I perceive that qgis plugins is not doing this
because getting an osgeo id is too hard.



It also seems like it would be good to separate authorization for
specific actions from the identity part of an account.  presumably for a
plugin, there is some review of the plugin, that it is ok enough
technically and not malicious, and that would result in setting an
ok-to-publish-this-plugin bit on that person's account.

Sounds like apple pie, but feels like we are multiple steps sideways
based on historical baggage.  My $0.02 lookign from mostly outside.


From Martin.Spott at mgras.net  Tue Jun 16 14:37:39 2026
From: Martin.Spott at mgras.net (Martin Spott)
Date: Tue, 16 Jun 2026 23:37:39 +0200 (CEST)
Subject: Board to vote on the mantra requirement
In-Reply-To: <ajAk7xoyWq8ZpdGO@c19.localdomain>
Message-ID: <20260616213739.D190367D7@rumba.mgras.de>

In article <ajAk7xoyWq8ZpdGO at c19.localdomain> you wrote:

> In this era of raising barriers against AI agents finding a contrary motion to
> instead open up our shared house to strangers seems unexpected so I'm voicing
> my concern about it.

I'd like to note that at the times when I mostly dropped out of OSGeo
infrastructure maintenance, which I did years before the AI era, we already
had approx. 15.000 registered LDAP accounts, of which just a few hundred at
maximum were backed by real OSGeo users.

Nowadays I'd expect the user database to fill up even quicker with crap
unrelated to OSGeo if barriers against AI agents get removed.

Kind regads,

	Martin
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

From strk at kbt.io  Wed Jun 17 11:05:02 2026
From: strk at kbt.io (Sandro Santilli)
Date: Wed, 17 Jun 2026 20:05:02 +0200
Subject: Board to vote on the mantra requirement
In-Reply-To: <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
Message-ID: <ajLhzhG4wsGYFn2M@oli>

On Mon, Jun 15, 2026 at 12:40:20PM -0400, Regina Obe wrote:
> On Mon, Jun 15, 2026 at 06:14:39PM +0200, Sandro Santilli wrote:
> >
> > Single Sign On solution, to allow services provided by OSGeo and by
> > others to accept the "OSGeo Passport" in addition to other passports
> 
> If keycloak allowed that, that would be great.

I think it does. I'm sure SimpleID for OpenID-2.0 does support LDAP too, and a ticket
to deploy THAT as a Single Sign On was filed 10 years ago:

  https://trac.osgeo.org/osgeo/ticket/1824

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20260617/a58fa434/attachment.sig>

From strk at kbt.io  Wed Jun 17 11:22:05 2026
From: strk at kbt.io ('Sandro Santilli')
Date: Wed, 17 Jun 2026 20:22:05 +0200
Subject: Board to vote on the mantra requirement
In-Reply-To: <005901dcfcec$3d31fd80$b795f880$@pcorp.us>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us>
 <ajA0N3BDLxq1t5V1@c19.localdomain>
 <005901dcfcec$3d31fd80$b795f880$@pcorp.us>
Message-ID: <ajLlzeaTHDwwoLMI@oli>

On Mon, Jun 15, 2026 at 01:27:27PM -0400, Regina Obe wrote:

> I think though that id.osgeo.org should require MFA cause that's where
> people setup their passwords, emails, and put their public keys.
> That has always bothered me it does not require MFA.

You mean id.osgeo.org/ldap/create, right ?
Did you file a ticket about it ? Feel free to assign to me if you do.

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/sac/attachments/20260617/570c7e03/attachment.sig>

From lr at pcorp.us  Wed Jun 17 12:25:29 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 15:25:29 -0400
Subject: Board to vote on the mantra requirement
In-Reply-To: <ajLlzeaTHDwwoLMI@oli>
References: <ajAk7xoyWq8ZpdGO@c19.localdomain>
 <003d01dcfce5$a88374d0$f98a5e70$@pcorp.us> <ajA0N3BDLxq1t5V1@c19.localdomain>
 <005901dcfcec$3d31fd80$b795f880$@pcorp.us> <ajLlzeaTHDwwoLMI@oli>
Message-ID: <002c01dcfe8f$0f387950$2da96bf0$@pcorp.us>

> > I think though that id.osgeo.org should require MFA cause that's where
> > people setup their passwords, emails, and put their public keys.
> > That has always bothered me it does not require MFA.
> 
> You mean id.osgeo.org/ldap/create, right ?
> Did you file a ticket about it ? Feel free to assign to me if you do.
> 
> --strk;
> 
>   Libre GIS consultant/developer ?
>   https://strk.kbt.io/services.html

Done https://trac.osgeo.org/osgeo/ticket/3587