Add full plugin audit#12
Closed
Oleg-Melnik wants to merge 1 commit into
Closed
Conversation
Vladyslav-Kuksiuk
approved these changes
Jul 23, 2026
Vladyslav-Kuksiuk
left a comment
Vladyslav-Kuksiuk
left a comment
Collaborator
There was a problem hiding this comment.
@Oleg-Melnik I've left a few comments and moved the high-risk item into a separate issue.
However, I think it's better to group smaller comments into issues rather than adding the audit file to the codebase.
Comment on lines
+49
to
+51
| `.github/workflows/check.yml` still triggers only on `pull_request`. The post-merge state of `master` | ||
| is never verified, and the README badge reflects the latest PR run, not `master`. Flagged in every | ||
| review since PR #1. Two lines: add `push: branches: [master]`. |
Collaborator
There was a problem hiding this comment.
It doesn't make sense to execute check on master, as check is performed to verify that PR is buildable and passes tests. It's just redundant two-step verification.
Comment on lines
+55
to
+57
| Consumers running `./gradlew check` will not get embedding verification; the README shows manual | ||
| invocation without explaining that this is deliberate (network dependency). Either wire it (possibly | ||
| opt-in) or add one sentence of rationale to the README's *Execution* section. |
Collaborator
There was a problem hiding this comment.
I don't think that plugin should extend default tasks. Only user should specify when to call the plugin.
Comment on lines
+75
to
+79
| Publishing metadata is complete and Portal-ready (plugin ID `io.spine.embed-code`, POM, sources/javadoc | ||
| jars, configuration-cache compatibility declared), but the only workflow is `check.yml`. There is no | ||
| `publishPlugins` workflow, no tag-triggered release, and no documented manual release procedure or | ||
| CHANGELOG. Before Portal submission, add at least a documented release process; a tag-triggered | ||
| workflow with Portal keys in repository secrets is the standard shape. |
Collaborator
There was a problem hiding this comment.
We have an issue for this. It will be added, when plugin passes Gradle Plugin Portal verification.
Comment on lines
+91
to
+96
| ### L2. `sha256` with rolling latest is advised against but not enforced | ||
|
|
||
| The KDoc now says to configure `sha256` "together with `version`", but the combination | ||
| (`sha256` set, `version` absent) is still accepted and hard-fails on the next upstream release when | ||
| the downloaded asset stops matching. Consider failing fast at execution with a message that says to | ||
| pin `version`, rather than surfacing as a digest mismatch. |
Collaborator
There was a problem hiding this comment.
It's more of a debugging feature. I don't think anyone will actually add the sha256 version hash to the configuration.
Comment on lines
+123
to
+127
| ### L7. README no longer explains `$name/` references for named sources | ||
|
|
||
| The named-source example is followed only by the mutual-exclusivity note; the sentence explaining that | ||
| embedding instructions reference the roots as `$model/` / `$database/` was dropped during the PR #9 | ||
| README restructure and not restored. |
Collaborator
There was a problem hiding this comment.
We are not supposed to describe how works Embed-Code, only the plugin. Embed-Code app has own documentation, which is mentioned in the readme.
Comment on lines
+157
to
+159
| - **Sticky latest:** "latest" is resolved once and pinned until `clean`. This is now clearly documented | ||
| in the README (*Version* section) with the local re-verification behavior. Users wanting automatic | ||
| updates must clean; that tradeoff is deliberate. |
Collaborator
There was a problem hiding this comment.
This behavior already gone, as well as latest version usage.
Comment on lines
+29
to
+41
| ### H1. Linux asset mapping will break on the next upstream release | ||
|
|
||
| `EmbedCodePlatform.kt:73` requests the Linux asset as `embed-code-linux` (bare binary). | ||
| Verified live during this audit: the current upstream latest (`v1.2.4`) still publishes | ||
| `embed-code-linux` unzipped, so everything works **today**. However, the upstream release workflow | ||
| on `embed-code-go`'s default branch now zips the Linux binary ("Publish Linux as a ZIP so Unix | ||
| executable permissions survive extraction"). The **next** release will publish `embed-code-linux.zip`, | ||
| and latest-mode installs on Linux will fail with HTTP 404 — and the `addReleaseTagMigrationHint` text | ||
| will not explain why. | ||
|
|
||
| **Recommendation:** try `embed-code-linux.zip` first and fall back to the bare asset (or select by | ||
| release metadata), so both existing and future releases install. Update the functional-test fixture | ||
| (`createFakeRelease`) in the same change — it currently mirrors the bare-binary layout and masks this. |
Collaborator
Author
|
Closed after all the necessary issues were created. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a full static audit of the plugin at
master(a2b0478, plugin0.1.1) as.agents/tasks/embed-code-gradle-plugin-audit.md. Documentation only — no production code changes.The audit covers all production sources,
buildSrc/build scripts, the CI workflow, tests, and theREADME, and includes a live check of the upstream
embed-code-gorelease layout. The build and testsuite were not executed.
Findings at a glance
EmbedCodePlatformmaps the Linux asset to the bareembed-code-linux. It worksagainst every published release today (
v1.2.4still ships it unzipped), but the upstream releaseworkflow now zips the Linux binary, so the next release will publish
embed-code-linux.zipandlatest-mode installs on Linux will 404.
master(pull_request-only);checkEmbeddingnot wired intocheck; the ZIP-extraction path has no CI coverage (no macOS runner); no toolchain auto-provisioning(build needs JDK 25 + 17); no release/publish automation ahead of Portal submission.
IOExceptionininstallFromVerifiedAsset,sha256+rolling-latest notenforced, redundant path re-validation, duplicated
buildSrcversions, and other cleanups.latest, concurrent daemons, zipsize caps, API rate limits) recorded with rationale.
re-verification restored post-Harden cached release asset handling #9.
No correctness or security defects were found in the current code. H1 is the one item that will cause a
real-world outage and is worth fixing proactively.