Thanks so much!

Hi @CDanis , we took a look at this repository found minimal problems, please feel free to move forward with using OpenTelemetry!

Just quickly running semgrep supply-chain against these codebases, it found that wikimedia/service-runner@master had two dependency vulnerabilities with undetermined reachability and that wikimedia/service-template-node@master had two dependency vulnerabilities with undetermined reachability and one with confirmed reachability.

I did an initial security assessment of this service from the angle of how great the concern is around the security of the module it replaces (service-runner) and just taking an initial look at the service itself from a security perspective.

Rescinding after checking in with @acooper and clarifying that this was created out of a misunderstanding.

@Aprum is working on an new rapid assessment process that would allow us to unblock this ticket, we are hoping to get this done by next week.

Is there a target date for deployment? We are trying to decide on priority as we are developing a new process that would help us expedite tickets like this in future, but don't yet have it and are working on developing it.

Hey @mpopov when do you need this done by? We're caught a little between developing a new process that would allow us to expedite approvals like this in future, and whether we need to special case high priority tickets for now with the old or interim process which will take time away from developing the new process.

Hi @mmartorana ,
Thank you for taking the time to review this plugin! We're glad to read that it is overall in good shape. We will address the minor issues in the git history during our sprints this quarter.

In T365525#10005016, @MusikAnimal wrote:

Yes, we could use a different branch but for Gerrit I think that means we have to rely on relation chains and just not merge, right? Indeed that would seriously hamper development. So I think we will go with a feature flag -- but I believe that is going to be necessary anyway because in order to do the security review, we need the extension deployed to the Beta cluster, but also simultaneously not deploy to production.

<threadjack>

In T355150#10001057, @Pppery wrote:

There are currently 61 extensions at https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation with no documented steward, and probably another dozen that are in some limbo state where a team has nominal responsibility but then declares it as unsupported (like Babel for example).

In T365525#9998963, @sbassett wrote:

So the extension would be deployed to wikimedia production, but only translations would be made available for it? e.g. anything in its i18n directory? If I'm understanding this correctly, that sounds fine.

The requirement for some WMF team to support new extensions itself seems unnecessary and hypocritical. There are currently 61 extensions at https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation with no documented steward, and probably another dozen that are in some limbo state where a team has nominal responsibility but then declares it as unsupported (like Babel for example). Audiutor (or ChessBrowser, or any of the other volunteer-written extensions that the WMF has refused to install) would be in a situation significantly better, maintenance-wise, than most WMF-run code, in having at least one person who cares.

Hey @mpopov - per the minutes from our recent quarterly review planning session, @acooper was going to follow up on this and a couple other review requests as it relates to acceptance and scheduling.

In T365525#9988592, @MusikAnimal wrote:

My question for you: If we (i.e. my manager) agree to accept all security risks, how likely if at all would it be to ship the extension with just translations, then we slowly add code to it over time? This would make the transition considerably easier, and allow us to address some issues we have now such as T370230: Migrate translations to Community Requests. When we have enough code moved over for the extension to run standalone, we can ask for a proper security review. Until then, we could have all code (other than the translations) behind a feature flag, which we will not enable until the security review is complete. How does that sound? I know this is highly unusual but I thought it was at least worth inquiring :)

I agree.

@sbassett As you may have noticed, work on this extension stalled. We had to go the MediaWiki-extensions-Gadgets route for the initial launch, but we are planning to extensionize the code.

<threadjack>

In T355150#9907769, @Tgr wrote:

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

@sbassett: I have folks on my team very eager to use this again for reporting. (I've asked them to pause until it's marked as Approved in ITS' Software Catalog.) Is there an ETA for this review?

This is a placeholder / early request. The development of this extension is only just getting started, so this review is not yet actionable at this time, but we'd like to get in the queue early. We will update this task when we have a clearer idea of when we'd like to deploy to production.

Maryum gave me a link to the previous service runner: https://github.com/wikimedia/service-runner