brig-sh/brig

brig sh <ref> <command> does not run the command it was given. It joins the trailing words with spaces and re-parses the result through bash -lc, so every argument boundary the caller set is thrown away and re-derived by the shell. Anything with a space, a quote, a glob, a ; or a $ comes out different from what was typed, and the failure is silent: the command runs, it just runs something else. We hit this while reproducing another bug from inside a sandbox. brig sh ubuntu sh -c 'echo FIRST; echo SECOND' prints a blank line and SECOND, never FIRST. Why shellArgv in internal/wrap/run.go:635: func shellArgv(command []string) []string { if len(command) > 0 { return []string{"bash", "-lc", strings.Join(command, " ")} } return []string{"bash", "-l"} } Shell (the sh verb) and ShellAttached (the --json path) both go through it. The three words sh, -c, echo FIRST; echo SECOND are joined into the single string sh -c echo FIRST; echo SECOND and handed to bash -lc. bash then splits it back i

Describe the bug assets/README.md forbids putting the on-dark mark on a light background and forbids recoloring the bars. No file in the repository links to it. README.md uses four of the assets it governs (README.md:3-4, :107, and the footer logo) without referencing the rules. Expected behavior A link from the README, from CONTRIBUTING.md, or from the docs index, so a contributor adding a mark meets the rules before they break one. Actual behavior The rules are reachable only by browsing into assets/. Environment d11ba32. Additional context #111 adds a link from the docs index, which closes the discovery half. Filing this because the rules are also worth stating where the assets are actually used, and because a rule that only exists in a file nobody opens is not enforceable in review. One correction worth making in the same pass: assets/README.md describes architecture.svg without noting that it is embedded with <img src>. That means its internal <title> and <desc> are never read by

Describe the bug .github/workflows/release.yml opens by telling a maintainer that a release needs no signing key and no registry secret. The same file then uses seven secrets. The header .github/workflows/release.yml:5-7: The built-in GITHUB_TOKEN is enough: the release goes to this repository, which is where the token already has write access. No signing key and no registry secret are involved. What the file actually references 63: NOTARY_KEY_P8: ${{ secrets.NOTARY_KEY_P8 }} 77: private-key: ${{ secrets.NOFIRE_BOT_PRIVATE_KEY }} 86: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 89: MACOS_SIGN_P12: ${{ secrets.MACOS_CERT_P12 }} 90: MACOS_SIGN_PASSWORD: ${{ secrets.MACOS_CERT_PASSWORD }} 92: MACOS_NOTARY_KEY_ID: ${{ secrets.NOTARY_KEY_ID }} 93: MACOS_NOTARY_ISSUER_ID: ${{ secrets.NOTARY_ISSUER_ID }} 96: HOMEBREW_TAP_GITHUB_TOKEN: ${{ steps.tap-token.outputs.token || secrets.HOMEBREW_TAP_GITHUB_TOKEN }} An Apple notary key is staged at :61-66, a Developer ID certificate and its pa

Describe the bug --json works on brig ls, brig agent ls and brig secret ls. Completion offers it on none of them. To reproduce Reproduced on 0.1.0-rc18. The flag works: $ brig ls --json { "apiVersion": "brig.sh/v1alpha1", "kind": "SandboxList", ... $ echo $? 0 Same for brig agent ls --json (kind: AgentList) and brig secret ls --json (kind: SecretList), both exit 0. Completion does not know: $ brig __complete ls - :names --quiet -q $ brig __complete agent ls - :none $ brig __complete secret ls - :none Cause completion.go:206-211 hardcodes brig lss flag list as {"--quiet", "-q"}, under a comment that now reads stale: "One flag, no operand". The group entries {name: "ls"} at completion.go:464 (agent) and completion.go:518 (secret) declare no flags at all. Expected behavior Completion offers --json on all three. Actual behavior A user tabbing for the flag concludes it does not exist. brigs own error text already knows better: brig ls extra says "takes no arguments other than -q and -

Describe the bug There is no .github/ISSUE_TEMPLATE/config.yml, so the issue chooser shows Bug report and Feature request and nothing else. SECURITY.md:30-32 asks a reporter not to open a public issue for a security problem, and the page where they start offers no other route. Expected behavior A config.yml with a contact link to the private advisory form, so the private path is visible at the moment the reporter is choosing: contact_links: - name: Report a security vulnerability url: https://github.com/brig-sh/brig/security/advisories/new about: Do not open a public issue. Report privately here. blank_issues_enabled is worth deciding in the same change. Actual behavior A reporter with a vulnerability meets two public templates and has to find SECURITY.md on their own. Environment d11ba32. Additional context Small and self-contained. The cost of the gap is one public disclosure that could have been private.