Updating username could lead to getting around being `denounced`

• GitLab's user API does offer user IDs. https://docs.gitlab.com/api/users/
• I'm fairly certain Gitea does too (which will go, to some degree, downstream to Forgejo/Codeberg/etc.) but I couldn't find any docs for that besides that user IDs exist. I expect that they would be shown when you attempt to search up a user by their username.
• I have no idea about other places like SourceHut.

As an aside, this is a common type of problem. I've even seen it happen even in the official GitHub app! I used to go by @jbmagination but changed my name when I transitioned. I made an organization so I could keep redirects and such, but the app still attempts to take me to @jbmagination... which makes it a PITA to manage my profile.

• GitLab's user API does offer user IDs. https://docs.gitlab.com/api/users/
• I'm fairly certain Gitea does too (which will go, to some degree, downstream to Forgejo/Codeberg/etc.) but I couldn't find any docs for that besides that user IDs exist. I expect that they would be shown when you attempt to search up a user by their username.
• I have no idea about other places like SourceHut.

As an aside, this is a common type of problem. I've even seen it happen even in the official GitHub app! I used to go by @jbmagination but changed my name when I transitioned. I made an organization so I could keep redirects and such, but the app still attempts to take me to @jbmagination... which makes it a PITA to manage my profile.

I think it'd be cleanest to use a new platform key here, example:

github-id:1234

And the reason (trailing data) can contain whatever, such as usernames.

I think it'd be cleanest to use a new platform key here, example:

github-id:1234

And the reason (trailing data) can contain whatever, such as usernames.

I think it'd be cleanest to use a new platform key here, example:

github-id:1234

And the reason (trailing data) can contain whatever, such as usernames.

vouch

vouch

vouch

Vouched both of you by the way since you seem like thoughtful humans.

Vouched both of you by the way since you seem like thoughtful humans.

Vouched both of you by the way since you seem like thoughtful humans.

vouch @suprstarrd

vouch @suprstarrd

vouch @suprstarrd

For organisation purposes, #5

For organisation purposes, #5

I got here as I wanted to say something similar but even more scary to me than someone evading a ban.

If you vouch for someone by username and they rename their account some time later, an attacker could create a new account with the old vouched for name and suddenly inherit these permissions.

This is a common attack vector with domain name resurrection, or github user resurrection leading to attacks on package managers for example.

So I believe very strongly that vouches should be stored by user id, but indeed having the username for human readability is a big plus.

It's not as scary as it sounds, since vouching gives you permission to merely participate, not to merge code or any of that. I'm still open to a user ID option as this issue is still open, but it's nothing to be overly worried about. Vouched people are the lowest bar amongst many other gates.

I got here as I wanted to say something similar but even more scary to me than someone evading a ban.

If you vouch for someone by username and they rename their account some time later, an attacker could create a new account with the old vouched for name and suddenly inherit these permissions.

This is a common attack vector with domain name resurrection, or github user resurrection leading to attacks on package managers for example.

So I believe very strongly that vouches should be stored by user id, but indeed having the username for human readability is a big plus.

I know he replied above but at opencode a vouched user doesn't give you any "extra" permissions it just allows/approves you as an actual human that is not someones OpenClaw bot.

I hear you in this case it's not so scary but what happens when someone builds vouch into a repo in a way where it grants you merge access? If you truly want to build this as an open system for others to reuse you should IMO avoid building in footguns :)

@Seldaek I think you are missing the purpose of vouch - it's meant to be a "filter" to instantly close AI PRs. It's not supposed to be fully-featured GH issue/PR moderation bot! AFAIK, vouchbot can only enable someone to open a PR(, not grant merge access to the repo; if you want control like this you may be looking for a different project).

Yup I get that, I just thought while reading about it that it'd be an interesting experiment for collaborative open source if maintainers were just brought in using vouch. Anyway no biggie just wanted to voice the concern :)