Wikipedia:Bots/Requests for approval/DeadbeefBot II
[[User:DeadbeefBot II|DeadbeefBot II]]
{{Newbot|DeadbeefBot II|}}
Operator: {{botop|0xDeadbeef}}
Time filed: 02:10, Friday, May 23, 2025 (UTC)
Automatic, Supervised, or Manual: automatic
Programming language(s): Rust
Source code available: https://github.com/fee1-dead/usync
Function overview: Sync userscripts from Git(Hub/Lab) to Wikipedia.
Links to relevant discussions (where appropriate): Wikipedia:Bots/Requests for approval/DeltaQuadBot 9, User:Novem Linguae/Essays/Linking GitHub to MediaWiki
Edit period(s): Continuous
Estimated number of pages affected: All pages that link to User:0xDeadbeef/usync
Exclusion compliant (Yes/No): No
Already has a bot flag (Yes/No): No
Function details: The bot scans and parses the list of user scripts at Special:WhatLinksHere/User:0xDeadbeef/usync, and they must start with the following header format:
// User:0xDeadbeef/usync: LINK_TO_REPO REF FILE_PATH
so for example:
// User:0xDeadbeef/usync: https://github.com/fee1-dead/usync refs/heads/main test.js
And will start syncing from the Git file to the on-wiki script.
Any user script author intending to use the bot must (1) insert the header both on-wiki, and on the Git file themselves, serving as an authorization for the bot to operate. (2) Create an {{code|application/json}} webhook in their Git repository pointing to https://deadbeefbot.toolforge.org/webhook (URL does not work yet; have not deployed it) to notify the bot of new commits that have occured on the file.
The bot will then [https://en.wikipedia.org/w/index.php?title=User:DeadbeefBot/usync.js&diff=prev&oldid=1290861188 make edits] using the commit message and author information to update the user scripts.
Currently, it only supports js files in the User namespace, but its scope could be trivial expanded to cover more formats (CSS/plain wikitext) depending on usage.
This is an improvement upon the previous DeltaQuadBot task: Auditability is achieved through linking on-wiki edits to GitHub/GitLab URLs that tell you who made what changes. Webhooks are used instead of a periodic sync. Authorization must be given on-wiki to allow syncs to happen.
The code is currently a working demo. I'm planning on expanding its functionality to allow Wikimedia GitLab's webhooks, and actually deploying it. I will also apply for Interface Administrator perms as this bot requires IA permissions. Will also request 2FA on the bot when I get to it.
=Discussion=
- Just so we are aware of the alternatives here: bd808 suggested on [https://discord.com/channels/221049808784326656/1370532171416207371 Discord] of an alternative solution to this problem which does not involve an IntAdmin bot, where script developers can create OAuth tokens and submit those tokens to a Toolforge service, and the Toolforge service would use those OAuth tokens to make edits as the script author (0xDeadbeef/GeneralNotability/etc.) instead of having the edits coming from a single bot account. There are different trade offs. I think if we're okay with a bot having IA permissions, then this solution is more convenient to setup, as the OAuth one requires going through the extra steps of creating a token. This bot also makes those edits in a centralized place when people want to inspect which scripts are maintained using this way. beef [
talk] 02:34, 23 May 2025 (UTC)
I see a risk here in having a bot blindly copy from the github without any human verification. Interface editor rights are restricted for very good reason, as editing the site's js would be very vaulable to a potential attacker. By introducing this bot, we now also have to be concerned about the security of the github repo's the bot is copying from. Something which is external to Wikipedia. We have no control over who might be granted access to those repos, and what they might do.
In fact, it may actually hinder development of tools/scripts. Currently, as a maintainer, one can be fairly liberal in who you add to your github repo, knowing that you can review any changes when you manually move them from the GitHub to on-wiki. With this change, anyone you add to the repo, realistically should be someone the community would trust with interface admin rights. --Chris 09:49, 23 May 2025 (UTC)
:I think the bot task is more aimed at user scripts than gadgets. You don't need to be an interface admin to edit your own scripts. Being an opt-in system, script maintainers who don't wish to take on the risk can choose not to use the system. As for security, it should be the responsibility of the script author to ensure that they, and others who have been added to the repo, have taken adequate measures (like enabling 2FA) to secure their github/gitlab accounts. – SD0001 (talk) 10:14, 23 May 2025 (UTC)
:For what it's worth, there are already people doing this kind of things to their own userscripts, such as User:GeneralNotability/spihelper-dev.js. However, they were never done with a bot because the bot would need to be interface admin. So they just store BotPasswords/OAuth tokens in GitHub and write a CI job that uses that to edit on-wiki.
:Being someone with some fair bit of the open source process, I don't see why someone who wants to personally review any changes themselves should choose to add people liberally to the GitHub repo, and then choose to use this bot if it gets approved. They should try to move the development/approval cycle onto GitHub, appropriately using pull requests and [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches protected branches], or just keep doing what they are doing. beef [
::Script maintainers might be happy to take the risk of automatically copying scripts from an external site to become active client-side scripts at Wikipedia, and they might be happy with the increased vulnerability surface area. The question here is whether the Wikipedia community thinks the risk–benefit ratio means the procedure should be adopted. Johnuniq (talk) 10:36, 23 May 2025 (UTC)
:::User scripts are an "install at your own risk" already, so feel free to avoid installing user scripts that do any automatic syncing. If the community doesn't like a bot that does this for whatever reason, I can also be fine with a "store OAuth tokens that give a toolforge service access to my account" approach which requires no community approval and no bots to run, just slightly less convenient to setup.
:::All I am saying is that the {{tq|increased vulnerability surface area}} remains to be proven. WP:ULTRAVIOLET and WP:REDWARN have been doing this for years. Whether approval for code occurs on-wiki or off-wiki shouldn't matter. beef [
Has there been a discussion establishing community consensus for this task, per WP:ADMINBOT? I don't see one linked here, nor one from Wikipedia:Bots/Requests for approval/DeltaQuadBot 9. The community might also decide whether the OAuth route is preferable to the interface-admin route. Anomie⚔ 11:13, 23 May 2025 (UTC)
:Good idea, I'll post a summary to WP:VPT soon. beef [
::See Wikipedia:Village pump (technical)#Syncing user scripts from an external Git repository to Wikipedia beef [