ask people on LOD casual chat about that

This is the async conversation with the LOD sharing crew:

• Is there a way to include secret/security fixes (not in git/gerrit yet) in builds?

Yes, you can always apply .patch files manually. There is no automated way to do this though

The above being the general option, here's how roughly WMF handles it: At WMF infrastructure, e.g. Wikidata, the changes providing fixes to security are manually applied on top of automatically deployed code, after each deployment. Those "patches" are turned into actual Gerrit changes that merge to respective repositories prior to make the release of that code (E.g. mediawiki release)
I fail to know what is the exact timeline for this but this happens not earlier than after there's enough of certainty that the security vulnerability is not affecting WMF wikis

Another engineer advises: IMHO this must not happen; regardless of where you get the patches from, this would make them public (anyone could compare the PHP code in the images with the one in Git).

• Is that actually needed?

The only reason you'd want to do this is to test if they work. You can't put them anywhere public until they are on gerrit anyway or you will leak the security fix early

• How do you all do it?

Wikibase.cloud just waits until they are public on gerrit and them "moves fast". This isn't ideal but it's the best we have without a totally private code storage and build and test solution

This has been the accepted trade off for Wikibase Suite releases in the past as well. It has been found acceptable as the severity of known security issues has not been critical.
It certainly was not meant as the permanent approach

• Follow up: how would the totally private code storage solution work for Suite? I am thinking that we could put in the private patches in the release pipeline to do the build of the code and make the release. Then the docker images would not be exposing those patches explicitly, is that right?

There could be options to "privately" prepare the code but I believe no way to quietly publish it. PHP code is plain text, I am not sure it could be hidden in some way.
Container images would expose the patches. Maybe only "implicitly" (define "explicitly") in the sense the container image will have the patched code. One could take the publicly available code and diff. This way they could see what the vulnerable code was, and possible use this knowledge against not updated Wikibases.

Basically, we'd need to find a place to privately store and run the whole content of the release pipeline including the source code, extra patches, the output of the build run but also the stored build images.

Judging by my last comment I would say that, at least for now, it is not a priority to check this topic further based on the following conclusions:

• The security patches are implemented and published quickly enough (TM) and no one has mentioned a moment where this has been a need
• It would be on a case by case basis that we would decide to add those patches to the build. However, the complexity to release them without disclosing them is too high for the small gain.
• Not exposing the wikibases that have not been patched yet is a priority that should prevail

Thanks for all the research. This makes perfect sense to me.

With T353733 we could be able build the suite from any REL_ branch as well as main. This allows us to test the patches as soon as they are released, and test the commit right before them any time before. It is not so probable that security fixes will introduce incompatibilities, so I agree that we do not need special handling here. I would still vote for T353733 soon as this brings us to a point I'd consider "close enough".

I'd consider this ticket done now.