What this review found
No material or immediate-danger item was identified.
Minor cautions
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If that action's repository were compromised, a malicious update could run in this workflow. This is common practice but less safe than pinning to a specific hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The Linux job references subosito/flutter-action@v2 at line 108 using a major-version tag rather than a SHA pin. A tag is mutable; if the upstream repository is compromised, a new tag push would execute altered code in this workflow context. First-party actions (actions/checkout, actions/upload-artifact) are lower risk but also tag-pinned.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA for stronger supply-chain integrity; first-party actions at major-version tags are lower priority.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:108
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If that action's repository were compromised, a malicious update could run in this workflow. This is common practice but less safe than pinning to a specific hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The Linux job references actions/checkout@v4 at line 107 using a major-version tag rather than a SHA pin. A tag is mutable; if the upstream repository is compromised, a new tag push would execute altered code in this workflow context.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA for stronger supply-chain integrity; first-party actions at major-version tags are lower priority.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:107
zizmor reported excessive-permissions
Minor caution · high confidence
The web build step doesn't spell out the minimum permissions it needs, so it may get more access than necessary. This is a common CI hygiene issue and doesn't directly endanger users.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The web job builds a Flutter web bundle and uploads it as an artifact. It has no explicit permissions block, so it inherits the repository or workflow default token permissions, which may be broader than the job needs (only artifact upload). No sensitive write target is used in this job beyond upload-artifact. This is a CI hardening gap, not a direct user-facing vulnerability.
Impact: low · Exploitability: unlikely
Developer action: Add a job-level permissions block with only the scopes this job needs (e.g., contents: read).
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:239-257
zizmor reported unpinned-uses
Minor caution · high confidence
This build step uses a version tag instead of locking to a specific commit. It's a best-practice gap that makes supply-chain attacks theoretically easier, but the action used is an official GitHub one.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The linux-clean-smoke job references actions/download-artifact@v4 by floating major tag rather than a SHA digest. If the tag were ever moved to a compromised commit, the job would run untrusted code. This is a standard supply-chain hardening gap; the action is GitHub-maintained and the job only reads artifacts for a smoke test.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/download-artifact to a full commit SHA instead of a floating tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:214
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If that action's repository were compromised, a malicious update could run in this workflow. This is common practice but less safe than pinning to a specific hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The Windows job references subosito/flutter-action@v2 at line 78 using a major-version tag rather than a SHA pin. A tag is mutable; if the upstream repository is compromised, a new tag push would execute altered code in this workflow context.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA for stronger supply-chain integrity; first-party actions at major-version tags are lower priority.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:78
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version label for a build tool instead of locking it to an exact copy. If someone hacked that tool's repository, they could swap in bad code under the same label. This is a common shortcut and not an active problem, but locking to a specific version is safer.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The checkout action is referenced by major version tag rather than a pinned commit SHA. If the action repository were compromised, a malicious update could be pushed under the same v4 tag. This is a supply-chain hardening best practice gap, not an active vulnerability. The action is a first-party GitHub action widely used and referenced only by major version.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a full commit SHA instead of the v4 major-version tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:42
zizmor reported unpinned-uses
Minor caution · high confidence
Same as the checkout finding: the workflow uses a version label instead of an exact lock. Locking to a specific version is a safer practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The setup-java action is referenced by major version tag rather than a pinned commit SHA. Same supply-chain hardening gap as other unpinned actions. This is a first-party GitHub action used for JDK setup.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/setup-java to a full commit SHA instead of the v4 major-version tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:43
zizmor reported unpinned-uses
Minor caution · high confidence
Same version-label issue, this time for a community-maintained Flutter setup tool. Locking to a specific version is a safer practice, especially for third-party tools.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The subosito/flutter-action is a third-party action referenced by major version tag rather than a pinned commit SHA. Third-party actions carry slightly higher supply-chain risk than first-party GitHub actions when unpinned, but this is a widely used community action for Flutter setup.
Impact: low · Exploitability: unlikely
Developer action: Pin subosito/flutter-action to a full commit SHA instead of the v2 major-version tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:47
zizmor reported excessive-permissions
Minor caution · high confidence
The Windows build step doesn't declare exactly what permissions it needs, so it may get more access than necessary. It only needs to read code and upload build files, so it should say so explicitly.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The windows job has no explicit permissions block, so it inherits the repository default GITHUB_TOKEN permissions. If the repository default is read-and-write (GitHub's historical default), the job holds write scopes it does not need. The job only checks out code, builds, and uploads artifacts. It does not interact with releases, issues, or other repository objects. The release job correctly scopes its permissions to contents: write.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block to the windows job (e.g., permissions: contents: read) or add a top-level permissions: {} default.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:73-101
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If that action's repository were compromised, a malicious update could run in this workflow. This is common practice but less safe than pinning to a specific hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The Windows job references actions/upload-artifact@v4 at line 97 using a major-version tag rather than a SHA pin. A tag is mutable; if the upstream repository is compromised, a new tag push would execute altered code in this workflow context.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA for stronger supply-chain integrity; first-party actions at major-version tags are lower priority.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:97
zizmor reported excessive-permissions
Minor caution · high confidence
The whole workflow doesn't set a default permission level, so build steps may get more access than they need. Setting a minimal default at the top of the file is a good practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The workflow has no top-level permissions block. Build jobs (android, windows, linux, web) inherit the repository default token permissions, which may include write scopes they do not need. The release job correctly declares permissions: contents: write. A top-level permissions: {} or permissions: contents: read default would ensure build jobs operate with least privilege.
Impact: low · Exploitability: unlikely
Developer action: Add a top-level permissions: contents: read (or permissions: {}) block so all jobs default to least privilege, then override only the release job with contents: write.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:22-285
zizmor reported artipacked
Minor caution · high confidence
A scanner flagged that build artifacts might accidentally include Git credentials. In this case the uploaded artifact is the compiled web output, not the source code folder, so credential leakage is unlikely.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The web job uses actions/checkout@v4 and then uploads a zip of build/web as an artifact. The artipacked concern is that checkout persisting the GITHUB_TOKEN into .git/config could leak into an artifact. Here the artifact is a Flutter web build output directory, not the repository working tree, so the git credential would not be included in the uploaded zip. Residual risk is low.
Impact: low · Exploitability: unlikely
Developer action: No change required for this specific data flow; optionally set persist-credentials: false on checkout for defense in depth.
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/release.yml:243
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a popular release-publishing tool by its version nickname instead of locking it to an exact, unchangeable snapshot. If someone changed what that nickname points to, the workflow could run different code. This is a common shortcut but can be made safer.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The release step uses a third-party GitHub Action referenced by major version tag only rather than a full commit SHA. Major version tags are mutable and can be retargeted by the action repository owner or a compromise of that repository. The action has contents:write permission and uploads built artifacts to a GitHub Release, so a retargeted tag could alter release behavior. This is a common pattern in open-source workflows and the action is well-known, but SHA pinning is the recommended hardening practice.
Impact: low · Exploitability: unlikely
Developer action: Pin third-party actions to a full commit SHA instead of a mutable version tag to prevent tag retargeting from changing the code that runs in the release pipeline.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:280
zizmor reported unpinned-uses
Minor caution · high confidence
This build step uses a version tag instead of a locked commit hash for an upload action. It's a minor supply-chain hygiene gap with no direct user impact.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The linux job references actions/upload-artifact@v4 by floating major tag. This is a supply-chain hardening gap; the action is GitHub-maintained and used only to upload build tarballs and AppImages. No user secrets or runtime data flow through this reference.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/upload-artifact to a full commit SHA instead of a floating tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:193
zizmor reported unpinned-uses
Minor caution · high confidence
A third-party Flutter setup action is referenced by version tag rather than a locked commit. This is a minor supply-chain hygiene gap.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The web job references subosito/flutter-action@v2 by floating major tag. This is a third-party action used to install the Flutter SDK for a build. Pinning to a SHA would prevent tag-swap supply-chain attacks. The action does not handle credentials or user data; it only sets up the toolchain.
Impact: low · Exploitability: unlikely
Developer action: Pin subosito/flutter-action to a full commit SHA instead of a floating tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:244
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a GitHub-provided tool by its version nickname instead of an exact snapshot. Since it is an official GitHub tool the risk is lower, but locking to an exact version is still the safer approach.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The release step uses a first-party GitHub Action for downloading artifacts, referenced by major version tag rather than a full commit SHA. First-party actions are lower risk than third-party, but the tag is still mutable. The action only reads previously uploaded build artifacts in this context, limiting the blast radius if the tag were retargeted. SHA pinning remains the recommended practice.
Impact: low · Exploitability: unlikely
Developer action: Pin first-party actions to a full commit SHA instead of a mutable version tag for consistency with supply-chain hardening best practices.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:269
zizmor reported excessive-permissions
Minor caution · high confidence
This smoke-test step doesn't declare minimum permissions, so it may inherit more access than it needs. It only reads build files and checks for missing libraries, so the practical risk is low.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The linux-clean-smoke job downloads an artifact and runs an ldd check inside a Fedora container. It has no explicit permissions block, so it inherits default token permissions. The job only reads artifacts and runs a local binary dependency check; it does not write to the repository or releases. The broad default is a hardening gap, not an exploitable vulnerability in this data flow.
Impact: low · Exploitability: unlikely
Developer action: Add a job-level permissions block with only the scopes this job needs (e.g., contents: read).
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:209-237
zizmor reported excessive-permissions
Minor caution · medium confidence
The workflow does not appear to restrict the permissions granted to the automatic workflow token. If a compromised dependency or action ran in this workflow, it could use the token with broader permissions than necessary. Setting explicit minimal permissions reduces that risk.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The Linux job (lines 103-208) does not declare a job-level permissions block, and no top-level permissions block is visible in the supplied context. Without explicit restrictions, the GITHUB_TOKEN defaults to broad write permissions. While the job only needs to upload artifacts, a compromised step could abuse the token's default scope. Declaring permissions: contents: read at the workflow level and overriding only where needed follows least-privilege practice.
Impact: low · Exploitability: plausible
Developer action: Add an explicit top-level permissions block with contents: read and grant write only to the specific scopes each job needs.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:103-208
zizmor reported unpinned-uses
Minor caution · high confidence
This upload step uses a version tag instead of a locked commit hash. It's a minor supply-chain hygiene gap with no direct user impact.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The web job references actions/upload-artifact@v4 by floating major tag. This is a GitHub-maintained action used only to upload a web build zip. No credentials or user data are involved beyond the compiled web output. Supply-chain hardening gap only.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/upload-artifact to a full commit SHA instead of a floating tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:253
zizmor reported unpinned-uses
Minor caution · high confidence
The workflow uses a version tag instead of a fixed commit hash for a GitHub Action. If that action's repository were compromised, a malicious update could run in this workflow. This is common practice but less safe than pinning to a specific hash.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The Windows job references actions/checkout@v4 at line 77 using a major-version tag rather than a SHA pin. A tag is mutable; if the upstream repository is compromised, a new tag push would execute altered code in this workflow context.
Impact: low · Exploitability: plausible
Developer action: Pin third-party actions to a full commit SHA for stronger supply-chain integrity; first-party actions at major-version tags are lower priority.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:77
zizmor reported excessive-permissions
Minor caution · high confidence
The Android build step doesn't declare its permissions, so it may get more access than necessary. It only needs to read code and upload a build file.
Technical evidence
Scanner reason: zizmor matched workflow-security rule excessive-permissions in this repository.
Contextual assessment: The android job has no explicit permissions block and inherits repository defaults. The job checks out code, optionally decodes signing secrets for APK signing, builds, and uploads an artifact. It does not need write access to repository objects. The signing secrets are GitHub Secrets mapped to job env vars and used only for the Gradle build; they are not exfiltrated or persisted in artifacts.
Impact: low · Exploitability: unlikely
Developer action: Add an explicit permissions block to the android job (e.g., permissions: contents: read) or rely on a top-level permissions: {} default.
- Scanner
- zizmor 1.28.0
- Rule
- excessive-permissions
- File role
- tooling
- Source
- .github/workflows/release.yml:33-71
zizmor reported unpinned-uses
Minor caution · high confidence
This checkout step uses a version tag instead of a locked commit hash. It's a minor supply-chain hygiene gap with no direct user impact.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The web job references actions/checkout@v4 by floating major tag. This is a GitHub-maintained action used to fetch source for a build. Pinning to a SHA would prevent tag-swap supply-chain attacks. No credentials or user runtime data flow through this reference.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/checkout to a full commit SHA instead of a floating tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:243
zizmor reported unpinned-uses
Minor caution · high confidence
Same version-label issue for the file-upload tool. Locking to a specific version is a safer practice.
Technical evidence
Scanner reason: zizmor matched workflow-security rule unpinned-uses in this repository.
Contextual assessment: The upload-artifact action is referenced by major version tag rather than a pinned commit SHA. Same supply-chain hardening gap as other unpinned actions. This is a first-party GitHub action used to upload build outputs.
Impact: low · Exploitability: unlikely
Developer action: Pin actions/upload-artifact to a full commit SHA instead of the v4 major-version tag.
- Scanner
- zizmor 1.28.0
- Rule
- unpinned-uses
- File role
- tooling
- Source
- .github/workflows/release.yml:67
Expected scanner matches (16)
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake key used in a test to make sure the app hides real keys if a provider accidentally echoes them back in an error message. It is not a real secret and is not sent anywhere.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value is a synthetic test constant inside a unit test for a credential-redaction function. It is used only as input to verify that scrubProviderBody removes reflected bearer tokens from provider error bodies. The value is not a live credential, is not transmitted, and is not loaded at runtime outside the test harness.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/scrub_provider_body_test.dart:13
OpenGrep reported tavernkeeper.persistence.startup-modification
Expected behavior · high confidence
This is just a comment explaining why the camera scanner does not turn on automatically when the page opens. It has nothing to do with making the app start when your device boots or staying running in the background.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification in this repository.
Contextual assessment: The flagged line is a developer comment explaining why the MobileScannerController is constructed with autoStart disabled. The surrounding class is a full-screen QR-code scanner page whose camera lifecycle is manually managed via start/stop calls bound to widget lifecycle and app-resume events. There is no OS-level startup registration, boot persistence, background service creation, or scheduled task insertion. The scanner rule matched on the term 'autoStart' in a comment, not on any persistence mechanism.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.persistence.startup-modification
- File role
- production
- Source
- lib/screens/lan_connect_screen.dart:587
zizmor reported artipacked
Expected behavior · high confidence
The scanner worried that login tokens might leak through uploaded files. The workflow only uploads finished app builds, not the whole working folder, so any tokens stay behind and are discarded when the build machine shuts down.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked heuristic flags checkout credential persistence risk. In this workflow, actions/checkout runs with default token persistence, but all uploaded artifacts are specific build outputs (APK, zip, tar.gz, web zip) rather than the full workspace. The .git directory containing the persisted token is never included in any artifact. The Android signing secrets are written to local workspace files used during the Gradle build and are not uploaded as artifacts.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/release.yml:42
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is another made-up test value used to check that the app scrubs keys from error messages. It is not a real secret and poses no risk.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value is a fabricated hex-looking string used as a test fixture to verify scrubProviderBody redacts an unrecognized key shape from provider error bodies. It is a local constant in a test file, never used as an actual credential, and never transmitted.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/scrub_provider_body_test.dart:28
zizmor reported artipacked
Expected behavior · medium confidence
The scanner flagged a risk that build artifacts might contain stored passwords or keys. In this workflow, the uploaded artifacts are narrowly scoped build outputs (an APK, a zip, a tarball), and the signing secrets are written to paths outside those artifact boundaries, so the risk does not apply here.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked heuristic fires on artifact uploads following use of secrets. In the Linux job (line 107), the checkout step precedes artifact uploads at line 193. The uploaded paths are pyre-linux-x64.tar.gz and Pyre-*.AppImage, which are build outputs created by tar and appimagetool. No secret material is written into those paths. The signing secrets (KEYSTORE_BASE64, STORE_PASSWORD, etc.) are only used in the Android job, whose artifact path is narrowly scoped to the APK output. The key.properties file is written to android/key.properties, which is not included in any artifact upload path.
Impact: low · Exploitability: unlikely
Developer action: Confirm that artifact upload paths never include directories where signing secrets or key material are written.
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/release.yml:107
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake key used only to test that the app correctly hides real API keys when they appear in error messages. It is not a real secret and cannot be used to access anything.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged value is a synthetic test constant inside a unit test file. It is used as a fixture to verify that the scrubProviderBody function removes reflected API keys from provider error bodies. It has already been redacted by the scanner and is not a live credential. No runtime data flow, network destination, or persistence is involved.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/scrub_provider_body_test.dart:13
Gitleaks reported generic-api-key
Expected behavior · high confidence
The scanner flagged a line of code that looks like it might contain a secret, but the text is just an internal label the app uses to remember that a data migration step is done. It contains no password, key, or sensitive information.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The gitleaks generic-api-key rule matched a string constant declaration on line 32. The matched value is a local SharedPreferences preference key name used to track whether a one-time attachment migration has run. It is not a credential, API key, token, or secret of any kind. There is no network destination, no external transmission, and no sensitive data involved. This is a false positive from the scanner's heuristic.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- production
- Source
- lib/services/attachment_migration.dart:32
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake placeholder key used only inside a test to make sure the app's encryption and decryption code works correctly. It is not a real secret and is never sent anywhere.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value is a synthetic test fixture assigned to the apiKey field of an ApiProvider constructed inside a unit test. It is used to exercise the toJsonEncrypted/decodeIncomingProvider round-trip logic. The value is not a live credential, is not transmitted to any external destination, and is confined to the test file scope.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/provider_sync_apply_test.dart:29
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a made-up test string used to check that decryption returns the expected value. It is not a real API key and is only used inside the test.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The matched value is a hardcoded expected result in a unit test assertion, verifying that the decrypted key matches the original plaintext used in the round-trip test. It is a mock value, not a real credential, and exists only within the test file with no network or persistence destination.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/provider_sync_apply_test.dart:47
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a fake API key placed inside a test to make sure the app's encryption system works correctly. It is not a real secret and is never sent anywhere; it only exists to verify that sensitive keys are properly encrypted before syncing between devices.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: This candidate is a test fixture in a unit test file. The matched value on line 29 is an ApiProvider constructor argument used to exercise the provider sync encryption round-trip. The scanner already redacted the original matched text. The surrounding test (lines 21-49) builds a provider, encrypts it via toJsonEncrypted, asserts the plaintext key is absent from the wire envelope, then decrypts it back. No real credential is transmitted or persisted; the value exists solely to test that encryption and decryption function correctly.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/provider_sync_apply_test.dart:29
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is another made-up test string used to confirm the app hides API keys in error messages. It is not a real credential and poses no risk.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged value is a placeholder constant defined within a test group and used solely to exercise the scrubProviderBody redaction logic. There is no connection to any real provider account, no network call, and no persistence. It exists to validate that an active API key embedded in an unrecognized error shape is scrubbed before display.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/scrub_provider_body_test.dart:28
zizmor reported superfluous-actions
Expected behavior · high confidence
The scanner notes that a built-in tool could do the same job as the add-on used here. Using the add-on is a normal preference and is not a security problem.
Technical evidence
Scanner reason: zizmor matched workflow-security rule superfluous-actions in this repository.
Contextual assessment: The scanner flags the release action as superfluous because GitHub runners can create releases using the GitHub CLI or API without a dedicated action. Using a well-maintained action for this purpose is a legitimate design choice and does not introduce a security vulnerability. This is an informational style finding, not a security defect.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- zizmor 1.28.0
- Rule
- superfluous-actions
- File role
- tooling
- Source
- .github/workflows/release.yml:280
zizmor reported artipacked
Expected behavior · medium confidence
The scanner flagged a risk that build artifacts might contain stored passwords or keys. In this workflow, the uploaded artifacts are narrowly scoped build outputs, and the signing secrets are written to paths outside those artifact boundaries, so the risk does not apply here.
Technical evidence
Scanner reason: zizmor matched workflow-security rule artipacked in this repository.
Contextual assessment: The artipacked heuristic fires on artifact uploads following use of secrets. In the Windows job (line 77), the checkout step precedes the artifact upload at line 97. The uploaded path is pyre-windows-x64.zip, a build output created by Compress-Archive from the Release directory. No secret material is written into that path. The signing secrets are only used in the Android job, whose artifact is narrowly scoped to the APK output.
Impact: low · Exploitability: unlikely
Developer action: Confirm that artifact upload paths never include directories where signing secrets or key material are written.
- Scanner
- zizmor 1.28.0
- Rule
- artipacked
- File role
- tooling
- Source
- .github/workflows/release.yml:77
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is a test assertion checking that after encrypting and then decrypting a key, the app gets back the correct value. The string is a made-up placeholder, not a real secret, and only serves to confirm the decryption logic works.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: This candidate is a test assertion on line 47 checking that the decrypted key equals the expected plaintext value after a round-trip through toJsonEncrypted and decodeIncomingProvider. The value is an obviously synthetic test string. It is used to verify decryption correctness and is never transmitted, stored, or used for authentication. No real credential is involved.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- test
- Source
- test/provider_sync_apply_test.dart:47
Gitleaks reported generic-api-key
Expected behavior · high confidence
This is just a label the app uses to remember it already moved some image files. It is not a password or key to any service.
Technical evidence
Scanner reason: Gitleaks matched secret-detection rule generic-api-key in this repository.
Contextual assessment: The flagged line defines a SharedPreferences key name used to track whether a one-shot attachment migration has completed. It is a local storage preference identifier, not a credential or API key. No secret value is present; the string is a namespaced boolean flag key consumed only by the app's own migration logic.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- gitleaks 8.30.1
- Rule
- generic-api-key
- File role
- production
- Source
- lib/services/attachment_migration.dart:32
OpenGrep reported tavernkeeper.persistence.startup-modification
Expected behavior · high confidence
This line tells the camera scanner library not to start the camera automatically, so the app can control when the camera turns on and off. It is a normal camera setting, not anything that makes the app persist or restart on its own.
Technical evidence
Scanner reason: OpenGrep matched static-analysis rule tavernkeeper.persistence.startup-modification in this repository.
Contextual assessment: The flagged line is the autoStart:false constructor argument for MobileScannerController inside a QR scanner page. This disables the mobile_scanner widget's automatic camera start so the page can control start/stop timing itself, avoiding a known permission-dialog race condition on Android. No startup persistence, boot registration, daemonization, or background task scheduling is present. The match is a keyword false positive on a camera configuration parameter.
Impact: none · Exploitability: unlikely
Developer action: none
- Scanner
- opengrep 1.26.0
- Rule
- tavernkeeper.persistence.startup-modification
- File role
- production
- Source
- lib/screens/lan_connect_screen.dart:598