Wikibase Suite (WBS)

15) Including and Publishing Security fixes

Date: 2021-05-03

Status

proposed

Context

WMDE needs to decide on a process for including security fixes of non-WMDE maintained software (e.g. Mediawiki, Elasticearch, WDQS) as well as WMDE maintained software (Wikibase, WDQS-frontend) and how to publish security fix releases of Wikibase suite in such cases.

Security fixes for WMDE maintained software will fall under the maintenance category and will most likely be worked on by campsite, however as the running of the pipeline and publishing of docker images requires special privileges it could make sense that this step is tasked to a certain group of people or that all engineers of WMDE are given the rights to publish releases.

Applying security fixes to the running Wikibase instance (or other Wikibase related software system) is a time-sensitive operation. Therefore WMDE will pre-announce the upcoming security release a bit in advance before making the fixes (hence also vulnerabilities) public, to allow maintainers of Wikibase instances to plan for their updates.

List of steps reporting, fixing and releasing security updates for WMDE maintained software

1. Recognizing / Reporting

2. Resolving

3. Deploy fix to WMF production environment

4. Releasing

Components Included

MediaWiki

In the case of MediaWiki or any extension (including Wikibase) on Gerrit, rebuilding and publishing through the current release process after the security fix has been applied should be sufficient to include the security fixes in the new images and release artifacts.

ElasticSearch

As for ElasticSearch we first need to acknowledge the fact that upgrading to anything beyond 7.11 would not be possible due to the new license and the fact that the version we currently pin releases to is likely not receiving security fixes. If however ElasticSearch were to receive security patches we simply need to update the pinned version and publish a new release from the pipeline.

WDQS

As for WDQS we need to identify what version contains the security fix and make sure it’s been made publicly available for us to pin it to a new release then run the pipeline and publish the resulting docker images.

Announcing the release to community

All releases, major or minor should be announced on the Wikibase User Group and Wikidata Tech mailing lists, in the Wikidata Weekly Summary, as well as on the Wikibase Telegram Group.

Pre-release announcement about the security releases will also be published on the above listed channels.

Recognizing the need to release

To some extent the most important part of continuously delivering security fixes is to be notified of when they are available. Since most of the code shipped in the Wikibase Docker Images aren’t WMDE maintained we need to become aware of when they are available to be included.

For MediaWiki we could add some simple test to compare which is the latest stable version we have released to the one that currently is available. When there is a mismatch we know there is a release available.

For other software without a constant release cycle or even explanation as to why the software was updated this will be much harder to accomplish.

Decision

Consequences