Board to vote on the mantra requirement
Greg Troxel
gdt at lexort.com
Mon Jun 15 15:14:24 PDT 2026
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.
More information about the Sac
mailing list