Skip to content

chore: release 4.2.4 - #640

Merged
phil-davis merged 2 commits into
4.2from
release/4.2.4
Sep 22, 2026
Merged

phil-davis merged 2 commits into
4.2from
release/4.2.4

Conversation

@oc-tmueller

Copy link
Copy Markdown
Contributor

Release preparation for the ownCloud 10.16.5 line.

The reason to cut this: no released version of the app carries the return-URL validation
yet.
v4.2.3 was tagged 2026-05-18 and #621 landed after it.

Two commits, and the first one is a prerequisite

  1. ci: add signed release workflow [4.2] — this branch had no release.yml at all,
    only main.yml and security-scan.yml. Releases are tag-triggered and GitHub resolves the
    workflow from the tagged commit, so tagging 4.2 today would produce no release and no
    signed artifact. Copied verbatim from master: the reusable workflow takes no php-version
    input, so nothing needs adapting for 7.4, and it signs with the repository's
    SIGNING_KEY/SIGNING_CERT/SIGNING_CHAIN secrets, which are available on any branch.
  2. chore: bump version to 4.2.4 — appinfo/info.xml and a new CHANGELOG.md section.

Contents of 4.2.4

Verification

The build path this branch had never run works. In owncloudci/php:8.3 (the runner's PHP,
Composer 2.9.8), make dist runs composer install --no-dev, which honours the
config.platform.php: 7.3 lock — "Verifying lock file contents can be installed on current
platform… Nothing to install"
— and produces a 167-entry, 236 kB tarball.

appinfo/info.xml reads 4.2.4, so the reusable workflow's tag check will pass for v4.2.4.
Signing is the only step not exercised locally; it runs in CI from repo secrets.

Tagging follows once this is merged. The marketplace upload (published there as
"Collabora Online", currently 4.2.3) is a separate manual step.

oc-tmueller and others added 2 commits September 22, 2026 17:34
Backport of #616. This branch had no release workflow at all, only main.yml and
security-scan.yml, so tagging it produced no release and no signed artifact:
releases are tag-triggered and GitHub resolves the workflow from the tagged
commit, not from the default branch.

Copied verbatim from master. The reusable workflow takes no php-version input,
so nothing needs adapting for 7.4, and it signs with the repository's
SIGNING_KEY / SIGNING_CERT / SIGNING_CHAIN secrets, which are available to
workflows on any branch - no local certificate is involved.

Verified that the build path it invokes works on this branch, which had never
run it: in owncloudci/php:8.3, the runner's PHP, `make dist` runs
`composer install --no-dev`, which honours the config.platform.php 7.3 lock
("Verifying lock file contents can be installed on current platform"), and
produces a 167 entry tarball.

Deliberately not porting lint-pr-title.yml or translation-sync.yml; this branch
takes no new features and no translation updates.

Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Release for the ownCloud 10.16.5 line. The notable change is that no released
version of this app carries the return-URL validation yet: v4.2.3 was tagged
2026-05-18 and #621 landed after it.

Also in: the pnpm settings move and lockfile repairs (#625, #632, #633), the
JavaScript unit test harness (#630), the appstore make target removal (#635),
and dependency bumps (#627, #629, #638).

Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@phil-davis
phil-davis merged commit 8844ae0 into 4.2 Sep 22, 2026
12 checks passed
oc-tmueller added a commit that referenced this pull request Sep 23, 2026
Reverts the workflow added in #640. That was my mistake: this branch ships to
ownCloud 10, and the release pipeline cannot produce an artifact oc10 accepts.

oc10 and oc11 do not share a signing generation:

  oc10  {hashes, signature, certificate}          legacy G1, single root.crt
  oc11  {v, alg, hashes, signature, certificates} G2, roots/ + intermediates/

`lib/private/IntegrityCheck/Checker.php` on 10.16 reads `certificate` in the
singular and verifies against the one `resources/codesigning/root.crt`. It has
no code path for a `v`/`certificates` envelope, nor for the ECDSA P-384
signature G2 uses. oc11's verifier accepts both generations, which is why the
same workflow is correct on master and wrong here.

The reusable release workflow signs with `ocsign`, overriding the Makefile's
`occ integrity:sign-app`. ocsign emits G2 only - its flags are --path --key
--cert --chain --core --allow-vcs --out --dry-run, with no legacy mode - and the
repository's signing secrets hold a G2 key. So a tag on this branch would have
published a tarball that fails `occ integrity:check-app` on every oc10 server,
with admins seeing a tamper warning.

Confirmed against the real artifacts rather than the docs: the marketplace
tarball for 4.2.3, which is what oc10 admins install, carries a legacy G1
envelope signed by a CN=richdocuments leaf issued by "ownCloud Code Signing
Intermediate Authority", while v4.3.0 and v4.3.1 carry G2.

Releases on this branch therefore stay manual, signed with the legacy G1 key by
whoever holds it, and uploaded to the marketplace - exactly how 4.2.1, 4.2.2 and
4.2.3 shipped. The version bump from #640 stands; only the workflow goes.

Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants