Setup security release workflow for duo-workflow-executor

Problem statement

The duo-workflow-executor project is looking to enable the release of security fixes without revealing the vulnerability or its fix before the release.

In essence, this issue needs to answer the following:
What is the workflow for preparing, merging and releasing a security fix for duo-workflow-executor?

Info about duo-workflow-executor

  • duo-workflow-executor is a Go application that produces a Go binary. This makes it unusual in that it is not packaged into Omnibus or Helm charts.
  • The binary is downloaded directly by the Duo Workflow VS code extension. The version downloaded by clients (VS code extension) is controlled by the DUO_WORKFLOW_EXECUTOR_VERSION file in gitlab-org/gitlab.
  • duo-workflow-executor team wants to continue releasing new versions (non security releases) on their own schedule. The versioning will have to be worked out so that the duo-workflow-executor team can release new versions without affecting the version numbers used in patch and monthly releases.

Proposal

The following was proposed in a discussion in #21072 (comment 2504103445). A pre-condition for this workflow is that duo-workflow-executor is added as a managed versioning component.

The workflow for fixing a security vulnerability in duo-workflow-executor can look like the following. This occurs during a regular scheduled patch release (similar to how_to_handle_gitaly_kas_security_merge_requests.md).

  • The duo-workflow-executor team opens a security issue in the security mirror of duo-workflow-executor. It should follow the procedure documented in https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md. Note that the security issue should be labeled with reduced backports since the 3 backport MRs will not be created.
  • The duo-workflow-executor team opens an MR on the security mirror of duo-workflow-executor.
  • The above MR is merged during a patch release, which breaks mirroring from canonical to security.
  • The duo-workflow-executor team creates a tag on the security mirror of duo-workflow-executor. This tag will be mirrored to the dev mirror, which should trigger the building of a new executable (on dev) that can be tested.
  • The duo-workflow-executor team opens an MR to update the DUO_WORKFLOW_EXECUTOR_VERSION file in gitlab-org/security/gitlab with the newly created tag. RMs merge this MR when ready. This breaks mirroring if it was not already broken due to an ongoing patch release. The DUO_WORKFLOW_EXECUTOR_VERSION file on canonical will not get updated until the end of the patch release, once the release is published and RMs sync security to canonical.
  • The duo-workflow-executor team is not looking to backport security fixes at this time. (source: #21072 (comment 2505160890))
  • The patch release is published.
    • The executable built on dev is copied to canonical (by release-tools) as part of the publishing process.
  • Security is synced to canonical by release-tools. The DUO_WORKFLOW_EXECUTOR_VERSION file on canonical is updated at this point. Once DUO_WORKFLOW_EXECUTOR_VERSION is updated, clients will begin downloading the new version.

For the above to work, duo-workflow-executor needs to become a managed component.

Exit criteria

  • The patch/security release workflow is finalized.
  • Version numbering for duo-workflow-executor is finalized.
  • Issues are created for the work to add duo-workflow-executor as a managed component.
Edited by Reuben Pereira