The bot’s code (in ~tools.wosretbot/wosretbot) is GPLv3-licensed (and published on GitLab), hallelujah! This means we won’t have license headaches.

I see two pieces of secret information so far:

• user-password.py, with a bot password for WosretBot. I expect we’ll want to delete this, and a new account for the bot (e.g. WosretBot2) should be created; @Tkarcher do you agree?
• wosretbot/nonpublic.toml, with user name(s) to exclude from certain notifications? I don’t really understand this feature; @Tkarcher do you know what it does?

Usual question: given that this is a bot (i.e. it's users are not relying on that specific tool's URL staying the same), and it's source is properly licensed and published, what will adoption let you accomplish that simply creating a new tool and setting up the published source code there will not?

In T392781#10771037, @LucasWerkmeister wrote:

I see two pieces of secret information so far:

(And the replica.my.cnf, but we agreed in another adoption request that this usually doesn’t need clearing.)

@LucasWerkmeister: I agree with setting up a new bot, but as Wosretbot is still active on a daily basis (only certain parts are buggy), I'd rather set up the new bot and password before the adoption and share the bot password with you via a secure channel, so you can replace the file instead of deleting it and ensure a smooth transition.

@taavi: The bot is still active, but some parts are buggy (see the long error logs in the tool folder). Creating a new one while keeping the old one running would lead to redundant tools and possible conflicts.

In T392781#10771043, @Tkarcher wrote:

@LucasWerkmeister: I agree with setting up a new bot, but as Wosretbot is still active on a daily basis (only certain parts are buggy), I'd rather set up the new bot and password before the adoption and share the bot password with you via a secure channel, so you can replace the file instead of deleting it and ensure a smooth transition.

Sure, that would work for me.

I see two pieces of secret information so far: [...] wosretbot/nonpublic.toml, with user name(s) to exclude from certain notifications? I don’t really understand this feature; @Tkarcher do you know what it does?

Not sure, but I can tell you the name is misleading, as the file is fully public (I just tested it, I can read it). So I'd suggest to keep it to avoid any disruptions, but if you insist on deleting it, I can easily restore it afterwards.

As discussed, I now created User:WosretBot2. @LucasWerkmeister : Attached you'll find the new BotPassword encrypted with the PGP key I found on your homepage. Let me know if you can decrypt it, or whether you'd prefer any other secure channel (e. g. Signal).

In T392781#10771889, @Tkarcher wrote:

I can tell you the name is misleading, as the file is fully public (I just tested it, I can read it).

I was aware of that and intentionally didn’t mention it. Just because the file is technically world readable doesn’t mean it was supposed to be public – accidentally world-readable files on Toolforge are a dime a dozen. Which is why I wanted to know what this feature does and whether the people listed in the file would expect it to be public or not.

It appears the context for that file is this discussion; given that the discussion is public, it’s probably okay to leave the file public after all.

Mentioned in SAL (#wikimedia-cloud) [2025-04-28T16:52:12Z] <lucaswerkmeister> for file in pywikibot-WosretBot.lwp .mysql_history; do sudo mv "$file" "$file.pre-T392781"; sudo chown root: "$file.pre-T392781"; done

Mentioned in SAL (#wikimedia-cloud) [2025-04-28T16:56:07Z] <wmbot~lucaswerkmeister@tools-bastion-13> updated user-password.py with WosretBot2 credentials and removed user-password.py.sik (T392781)

I looked for non-world-readable files again with find . -name .kube -prune -or -name .cache -prune -or ! -perm -o=r, and apart from the files mentioned above, didn’t see anything else that looked like it needed cleaning.

Mentioned in SAL (#wikimedia-cloud) [2025-04-28T16:59:49Z] <lucaswerkmeister> added Tkarcher to maintainers (T392781)

Should be done, I think – please check :)

In T392781#10773574, @LucasWerkmeister wrote:

Should be done, I think – please check :)

Thanks! Looks good - I can log in and access all files.

Unfortunately, switching to the new bot did not go as smoothly as I had hoped: There're a couple of dependencies in the code on specific User:{Botname}/Subpages which obviously do not exist for the new bot yet, so I'm going through the logs right now and try to recreate all subpages needed for WosretBot2. But this I should be able to handle/solve myself - as far as I'm concerned, this task can be closed as successfully done. Thanks again!

Sorry for necro-posting, but I don't want to open a new task for this quick adoption-related question: I also requested access to https://gitlab.wikimedia.org/toolforge-repos/wosretbot a couple of days ago. Am I even supposed to get access to this repository as per the adoption policy? (Would be a convenient alternative to creating a duplicate "wosretbot2" repo) And if yes: Is anyone actively monitoring these requests in Gitlab, or should I use another channel to request access?

In T392781#10785259, @Tkarcher wrote:

Sorry for necro-posting, but I don't want to open a new task for this quick adoption-related question: I also requested access to https://gitlab.wikimedia.org/toolforge-repos/wosretbot a couple of days ago. Am I even supposed to get access to this repository as per the adoption policy? (Would be a convenient alternative to creating a duplicate "wosretbot2" repo) And if yes: Is anyone actively monitoring these requests in Gitlab, or should I use another channel to request access?

I just approved your request. #someday someone will write the code for T317376: Update GitLab repo owners when tool maintainers change, but until then you did a reasonable thing both in using the gitlab UI to ask to join and in using Phabricator to ask for help when the original request went unhandled.