I don't think yapperbot runs a webservice, and AFAICS all of its configuration files are either world-readable or have secrets in them.. what are you trying to do with this adoption request that you can't do otherwise?

The bot seems to be actively editing (https://en.wikipedia.org/wiki/Special:Contributions/Yapperbot) which means the tool is not obviously meeting the "The tool must have been nonfunctional (no webservice/offline) for 14 days." qualification criteria.

Bot operation would be disrupted by an adoption as we would need to remove the current SUL bot account's credentials. I'm not certain of this, but I assume that each task would have to go through WP:BRFA again following the ownership change to become attached to a new SUL bot account.

It's only working because Legoktm (who I note supports adoption) manually poked it.

In T361426#9674790, @taavi wrote:

... its configuration files are either world-readable or ...

Oh interesting. In the WinSCP FTP client, I just tried navigating to /data/project/yapperbot and was able to get it to open.

I remember I tried this on a couple random folders a couple months ago and wasn't able to open any of them.

How often are files world-readable on Toolforge? Does this just depend on what the chmod of the folder and files has been set to by its owner?

In T361426#9675158, @Novem_Linguae wrote:

How often are files world-readable on Toolforge? Does this just depend on what the chmod of the folder and files has been set to by its owner?

The default permissions and umask make a tool's $HOME and everything in it world readable. This is something that comes up internally at the WMF just about every time a new SRE or Security team member discovers Toolforge. T337140: Files created in a tool's home directory can be read by other tools provides some context from one such past discussion.

A number of the directories(folders) and files that run the yapperbot code are protected--at least for me. Try these commands:

cd /data/project/yapperbot
ls -ltR

(The last command is a recursive list of all files starting from the top directory.)
You will see that important directories (and files) are protected from view, e.g. /data/project/yapperbot/frs, which has the most important code.

In T361426#9674806, @bd808 wrote:

The bot seems to be actively editing (https://en.wikipedia.org/wiki/Special:Contributions/Yapperbot) which means the tool is not obviously meeting the "The tool must have been nonfunctional (no webservice/offline) for 14 days." qualification criteria.

As @Pppery noted, I temporarily fixed the tool as a stop-gap until an adopter could be found. (On-wiki I stated that unless someone stepped up I'd just turn it off in 2 months, thankfully it won't be coming to that!)

In T361426#9674790, @taavi wrote:

I don't think yapperbot runs a webservice, and AFAICS all of its configuration files are either world-readable or have secrets in them.. what are you trying to do with this adoption request that you can't do otherwise?

Since the new maintainer is new to Toolforge, I think it'll end up being simpler for them to take over an existing tool (and just plug in new credentials) versus copying something and setting it up fresh. (The latter might be the better long-term option but I hope we can avoid forcing that now)

While you all are deciding what to do with the adoption process, could you please unprotect the code files in yapperbot so that they are readable by me? I would not need to be able to modify them--only read. At this point, I don't need the password. If you are unfamiliar with Go (language)--which is new to me too--I can do my best to explain what any or each of the files and directories are for. The documentation for the code is sparse, and I do plan to add documentation somewhere for future code review.

In order to maintain the code--either at its original location or at the new location of feedback-request-service-bot--I need to be able to see the most current version of the code that is running on Wikipedia right now. When I first wrote this post of today, I had trouble running the version from github. However, I believe I am able to get it to work now. (I have deleted all information on the problems that I had originally detailed here).

Novem_Linguae and I both agree that it is better not to continue to work with a version which may not be correct and up to date. There is no way to be sure that the version on Toolforge is identical to the one published on github.

Also, although Legoktm said that I could rewrite the code for a new bot in any language, I see no reason to reinvent the wheel. I plan to understand the current Go code in its entirety and also learn how Legobot supports FRS. And to document, document, document.

@taavi Would it be possible to unprotect the yml files in the yapper bot directory ? Based on a cursory reading of the code, they should not contain any account secrets in them, but rather contain configuration variables that would assist @DavidTornheim with setting up the new tool.