@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.

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.

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 :)

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. Keeping feature development on a separate, undeployed branch would probably be preferred to a wikimedia production feature flag, but I'm not sure if that would suit your development needs. Regardless, it sounds like we should place this review request into our backlog again, for now? Until we have a better sense of when most of the code will be ready for the extension?

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.

Awesome! We will start migrating messages, then. Note currently the repo has other files in it, including a Hooks.php, but they all appear to be no-ops. We can remove this code for now if it is of concern.

Keeping feature development on a separate, undeployed branch would probably be preferred to a wikimedia production feature flag, but I'm not sure if that would suit your development needs.

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.

Regardless, it sounds like we should place this review request into our backlog again, for now? Until we have a better sense of when most of the code will be ready for the extension?

I suppose for now, yes. My wild estimate is some months before we're ready for a security review. I understand you do your reviews quarterly, so we can still aim for the end of Q1 2024-25 (~2 months from now).

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.

Ok, that's fair.

I suppose for now, yes. My wild estimate is some months before we're ready for a security review. I understand you do your reviews quarterly, so we can still aim for the end of Q1 2024-25 (~2 months from now).

Since this was already assigned at the beginning of this quarter, yes, it should be possible. If you could just keep this task updated with any key progress, that would be great.

Hey @JWheeler-WMF and @KSiebert -

Any update on when all relevant code might be ready for a security-review? Since we only have a week and a half or so left in the current quarter, I'm guessing we'd now be targeting a date next quarter?

In T365525#10162571, @sbassett wrote:

Any update on when all relevant code might be ready for a security-review? Since we only have a week and a half or so left in the current quarter, I'm guessing we'd now be targeting a date next quarter?

I was just going to write you!

We are racing to get things migrated over this week and early next week, in hopes of still getting a review this quarter. While the bulk of the code will be present (but not necessarily merged), it will not be a fully functioning extension quite yet. Allow me to explain :)

We are in a unique situation here where the Wishlist is an ongoing, self-evolving product that is powered by a combination of gadgets, bot tasks, and on-wiki templates/modules. A slow, piecemeal migration to an extension I think is the only reasonable way for this to ever happen given given we're working with a moving target. That migration started with the translations, which as you know are deployed now. Next is data persistence (parser function + hook to persist to db), then finally the Vue application to render a UI to the user. The stuff that lives on wiki pages now will probably stay that way, so visually there's not a lot to the extension that isn't already live, if that means anything.

My thought was, since most of the code that powers the Wishlist is a Vue application (and other on-wiki content not subject to code review), having the Vue code ported over and running minimally would be enough for security review? I.e. I'd like to get the [[ meta.wikimedia.org/wiki/Community_Wishlist/Intake | intake form ]] loading on a Patch Demo, and I think we'll also have some of the MinT integration ready to demo as well. The code will be available on Gerrit for static analysis etc., but won't necessarily be merged yet. The remaining code that is yet to be written will largely be the same as what we did for MediaWiki-extensions-PageAssessments and MediaWiki-extensions-Phonos (other parser function extensions) – that is to say, we aren't treading into technical unknown territory, and thus perhaps willing to accept any implicit security risks.

We can of course postpone the target date for this task, but I hope that doesn't mean we will need to wait another 3 months for review. The longer we wait, the more fragmented the two implementations of the Wishlist become. I think, as irregular or counter-intuitive as it may seem with respect to security and release engineering, it's most practical to migrate the software to the extension in piecemeal chunks. It's not an issue yet, but eventually https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes will contain too much content for a wiki page, necessitating pagination, and that's the point where we really need to have an extension (or hacky Toolforge tool with CORS errors in the JS console…). Hence why I outlined the proposed road map (T366194) in its stated order. I still think within just a few days, we can have most of those checkboxes at T366194 ticked, it just won't be production-ready per-se due to the unusual circumstances we're working with.

Regardless, I will set a personal deadline of Tuesday, September 24 or sooner to have a mostly working (but static) survey on Patch Demo. I'll keep this task updated along the while, and come Tuesday/Wednesday you let me know if we have enough for the review. How does that sound? :)

Many thanks in advance!

@MusikAnimal - Ideally we'd have any and all relevant code for this project completed (or at least in a very stable state) for the security review. Our team would typically like to avoid performing multiple, piecemeal reviews of different codebases and/or re-reviewing more volatile codebases. If we can have most of that in place by September 24th, that's great, though I cannot guarnatee the review will be completed before the quarter ends, a few days later. Though it could very likely be completed within the first week or two of the next quarter, for sure. If we can't guarnatee that all relevant code is in a stable or near-complete state by September 24th, then I think it would be best to discuss a different completion date. However, we are happy to try to accommodate various engineering team milestones and deadlines, and would try to work with you to complete the review earlier next quarter (as opposed to the last week or two). Let me know how you'd like to proceed.

I don't think we'll get it done by the 24th (which is already today in some parts of the world). But if we can aim for a date within the first couple of weeks of next quarter that sounds great, I think! We're making progress now with moving all the functionality from the gadget, so hopefully the code will be representative of the completed extension (e.g. it'll show what we're aiming for with the special pages, database tables, parser functions, font-end access of remote APIs, etc.). Perhaps not perfect, and we'll be continuing to work on it, but the skeleton (and a fair bit of the detail) will be done.

Ok, thanks @Samwilson. I'm going to move this task back to our quarterly planning column where it will be re-reviewed during our next scheduled planning session (October 1st, 2024). I'll note that we'll plan to complete this review sometime within the month of October 2024.

Thanks all, I set the target date of the task to first of November 2024.

Hey @Samwilson @KSiebert @MusikAnimal - I've got this assigned to me for this quarter and plan to begin the review as soon as the code is ready this month. If you could let me know when that happens on this task, that would be great.