[GH-ISSUE #79] Declare the SHA256 of settings-ui.txz in gow.plg #29

New issue

Closed

opened 2026-10-15 12:54:58 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 12:54:58 +00:00

Owner

Originally created by @unraid-ca-review-bot on GitHub (Sep 3, 2026).
Original GitHub issue: https://github.com/games-on-whales/unraid-plugin/issues/79

This plugin is currently listed in Community Applications, and it will be subject to removal from CA if an integrity hash is not added. gow.plg declares no <MD5> or <SHA256> for settings-ui.txz, so nothing pins what installs as root: whatever the release URL serves on the day is what gets installed. A declared hash on every download is now required for plugins to remain in CA.

This is filed as an issue rather than a pull request because your .plg is published as a release asset and the package is built in CI, so a hash committed to main would be wrong the moment the next release is built. The fix belongs in auto-release.yml, and you are already most of the way there.

What is needed

One <SHA256> line inside the <FILE> element that downloads the package:

<FILE Name="&plugin;/packages/settings-ui-&version;.txz">
  <URL>&gitReleaseURL;/settings-ui.txz</URL>
  <SHA256>&sha256;</SHA256>
</FILE>

with &sha256; declared alongside your other entities:

<!ENTITY sha256    "0000000000000000000000000000000000000000000000000000000000000000">

For reference, the value for the current release 2026.08.19a is:

settings-ui.txz — 58,864 bytes — e2fe70ad5a757339357a159597c61bf03558c05f38aa6acb18c1e70f19c66f64

The hash is static: it is the SHA-256 of the file as built. Whenever settings-ui.txz changes, the <SHA256> value must change with it or the plugin will fail to install. Generating it in the release workflow, as below, means there is never a value to update by hand.

Suggested change to `auto-release.yml`

Your Generate checksums step already computes exactly this value into dist/settings-ui.txz.sha256. Substituting it into the copy of gow.plg that is attached to the release, after the package is built and before Create GitHub release, is enough:

      - name: Pin package hash in gow.plg
        run: |
          SHA=$(cat dist/settings-ui.txz.sha256)
          sed -i 's/<!ENTITY sha256[[:space:]]*"[^"]*">/<!ENTITY sha256    "'"$SHA"'">/' gow.plg

The gow.plg on main keeps the placeholder; the released gow.plg, which is what &pluginURL; points at, carries the real hash.

With the hash declared, Unraid's plugin installer verifies the download against it and refuses to install a package that does not match. It also skips re-downloading a package that is already present on the flash and matches.

<MD5> is also accepted by Unraid if that fits better; <SHA256> is the stronger choice and is preferred when both are present.

What this does not cover

This concerns the missing integrity hash and nothing else. It is not a review of anything else in the plugin.

This came out of the Community Applications integrity review of plugins already in the feed. The suggested change is offered as a convenience, not a demand; how you implement it is your call. The requirement to add a hash stands either way.

Originally created by @unraid-ca-review-bot on GitHub (Sep 3, 2026). Original GitHub issue: https://github.com/games-on-whales/unraid-plugin/issues/79 **This plugin is currently listed in Community Applications, and it will be subject to removal from CA if an integrity hash is not added.** `gow.plg` declares no `<MD5>` or `<SHA256>` for `settings-ui.txz`, so nothing pins what installs as root: whatever the release URL serves on the day is what gets installed. A declared hash on every download is now required for plugins to remain in CA. This is filed as an issue rather than a pull request because your `.plg` is published as a release asset and the package is built in CI, so a hash committed to `main` would be wrong the moment the next release is built. The fix belongs in `auto-release.yml`, and you are already most of the way there. ### What is needed One `<SHA256>` line inside the `<FILE>` element that downloads the package: ```xml <FILE Name="&plugin;/packages/settings-ui-&version;.txz"> <URL>&gitReleaseURL;/settings-ui.txz</URL> <SHA256>&sha256;</SHA256> </FILE> ``` with `&sha256;` declared alongside your other entities: ```xml <!ENTITY sha256 "0000000000000000000000000000000000000000000000000000000000000000"> ``` For reference, the value for the current release `2026.08.19a` is: - `settings-ui.txz` — 58,864 bytes — `e2fe70ad5a757339357a159597c61bf03558c05f38aa6acb18c1e70f19c66f64` **The hash is static: it is the SHA-256 of the file as built. Whenever `settings-ui.txz` changes, the `<SHA256>` value must change with it or the plugin will fail to install.** Generating it in the release workflow, as below, means there is never a value to update by hand. ### Suggested change to `auto-release.yml` Your **Generate checksums** step already computes exactly this value into `dist/settings-ui.txz.sha256`. Substituting it into the copy of `gow.plg` that is attached to the release, after the package is built and before **Create GitHub release**, is enough: ```yaml - name: Pin package hash in gow.plg run: | SHA=$(cat dist/settings-ui.txz.sha256) sed -i 's/<!ENTITY sha256[[:space:]]*"[^"]*">/<!ENTITY sha256 "'"$SHA"'">/' gow.plg ``` The `gow.plg` on `main` keeps the placeholder; the released `gow.plg`, which is what `&pluginURL;` points at, carries the real hash. With the hash declared, Unraid's plugin installer verifies the download against it and refuses to install a package that does not match. It also skips re-downloading a package that is already present on the flash and matches. `<MD5>` is also accepted by Unraid if that fits better; `<SHA256>` is the stronger choice and is preferred when both are present. ### What this does not cover This concerns the missing integrity hash and nothing else. It is not a review of anything else in the plugin. This came out of the Community Applications integrity review of plugins already in the feed. The suggested change is offered as a convenience, not a demand; how you implement it is your call. The requirement to add a hash stands either way.

bsakaguchi closed this issue

2026-10-15 12:54:58 +00:00

bsakaguchi commented

2026-10-15 12:54:59 +00:00

Author

Owner

@JBailes commented on GitHub (Sep 4, 2026):

Fixed.

@JBailes commented on GitHub (Sep 4, 2026): Fixed.

bsakaguchi referenced this issue

2026-10-15 12:55:12 +00:00

[PR #30] [MERGED] Fix issue 29 deployment and documentation gaps #53