Karl-Einar Bergstrøm
4377eb98bf
Share `.env` files as an encrypted `lazysecrets://share/…` link. The files are encrypted with a secret's value, so anyone who can read that secret can open the link. **Sharing:** `S` → `f` on a repo (all its plain env files), an env file, or a key in one (its file). - **The key** is `share.key` from the repo's `.lazysecrets.yaml`, else from the config. It can be a `lazysecrets://` link, a Key Vault URL or an `@Microsoft.KeyVault(...)` reference. - **Without `share.key`,** a picker built on Go to opens, titled "Share .env", with "Pick a secret to encrypt with" in its own border. It lists only secrets, leaving out values from plain `.env` files. Pasting a reference picks it. Picking shares at once, and the picker stays open until the link is copied. If the secret can't be used, the reason shows in red in the picker: it can't be read, or it doesn't meet `share.keyRules` (which rule failed is named). `esc` cancels. - **`share.keyRules`** (defaults `minLength: 32`, `minClasses: 2`; never under 16) applies when sharing, not when opening. - **On Azure,** the link pins the key's version, so rotating the key doesn't break old links, and disabling a version revokes them. - **The command line:** `lazysecrets share [--key <secret>] <env files>`. **Opening** works by paste, `ctrl+o`, the clipboard offer, the link handler or `lazysecrets <link>`. 1. It first says which repo the link is from, how many files it holds and which key it uses, and decrypts only after `o`. 2. It saves into the repo's clone, found by its remote, showing which files are new, which would replace one there, and which git doesn't ignore. 3. Without a clone, it asks for a folder and saves straight away. The prompt stays open, with the reason in red, until the files are written. 4. If decryption fails, a popup says why: the first line of the reason, `r` for the whole message, `g` to go to the key's secret. A key that has changed is named by where it lives: a Databricks or SOPS value changed in place, an Azure current version that isn't the one the link was made with, or a pinned version, meaning the link may be damaged. **Format** (`internal/share`): a version byte, then a JSON header with the key, the repo and the file count, then an age file (scrypt 2^15, with the key's value as passphrase) holding the files as deflated JSON, all as unpadded base64url. Links are capped at 16 KB. A future format gets a new version, and old ones stay readable. **Safety:** - A link can only write env files, inside the folder: never in `.git`, never through a symlink. - New files are created with mode 0600. - Opening accepts an scrypt work factor of at most 2^20, and unpacks at most 1 MB. **Along the way:** - Opening a link to a secret ends on its details, as `enter` would. - `o` on an Azure secret opens its portal page, and in the versions view, that version's page. - The details pane follows its secret's list when it reloads in the background. Before, it kept what it showed first, including an old portal address. - `ref.Read` is shared by `get` and sharing, with Azure `VersionedValue` for pinning. - `provider.Contents` lets the demo repos share their env files. `--demo` has a share key (`kv-shared-prod / env-share`), so the whole flow works there. - New dependency: `filippo.io/age`. Tested end to end in the TUI and the demo, the CLI, and the `share` package. In a real vault: version pinning, opening into a clone, and revocation by disabling the version. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Reviewed-on: #54
73 lines
2.9 KiB
Markdown
73 lines
2.9 KiB
Markdown
# Development
|
|
|
|
```sh
|
|
go run ./cmd/lazysecrets
|
|
go run ./cmd/lazysecrets --demo # built-in sample data, no Azure needed
|
|
go test ./...
|
|
go test ./internal/ui/app -run TestGolden -update # after intentional UI changes
|
|
```
|
|
|
|
In `--demo`, sharing env files works end to end: `S` → `f` on a demo
|
|
repo, pick `kv-shared-prod / env-share` (the second account's) as the
|
|
key, then paste the link back. The demo repos aren't on disk, so opening
|
|
asks where to save, as for a repo you haven't cloned.
|
|
|
|
A stripped binary is about 21 MB instead of 30 MB:
|
|
|
|
```sh
|
|
go build -trimpath -ldflags "-s -w" -o lazysecrets ./cmd/lazysecrets
|
|
```
|
|
|
|
Development builds show `dev-<commit>` as their version (`-dirty` with
|
|
uncommitted changes); `go install …@v0.2.0` shows the tag, releases the
|
|
version they were built for.
|
|
|
|
## Pull requests
|
|
|
|
Pull requests into `main` are squash-merged, so each is one commit titled
|
|
like the PR. The title is a [conventional commit](https://www.conventionalcommits.org)
|
|
subject, checked by `pr-title.yml`:
|
|
|
|
| Type | For | In the changelog |
|
|
|---|---|---|
|
|
| `feat` | a new feature | Added |
|
|
| `perf` | faster or smaller, same behaviour | Changed |
|
|
| `fix` | a bug fix | Fixed |
|
|
| `refactor`, `docs`, `test`, `ci`, `chore`, `build`, `style`, `revert` | everything users don't need to hear about | no |
|
|
|
|
`feat!:` marks a breaking change, `feat(scope):` names a part. Brackets
|
|
and a missing space work too: `[feat] x`, `[feat]: x` and `feat:x` all
|
|
become `feat: x` in the changelog. `[skip changelog]` in the description
|
|
leaves a pull request out.
|
|
|
|
CI (`ci.yml`) runs gofmt, vet, staticcheck, the tests and a build for each
|
|
platform on pull requests into `main`. `main` is protected: a pull request
|
|
merges only when it's up to date with `main` (Gitea's "Update branch"
|
|
button, or a rebase, then CI again), so what lands on `main` is exactly
|
|
what its pull request tested, and CI doesn't run again there.
|
|
|
|
## Releasing
|
|
|
|
Merge as many pull requests as you like, then release `main`:
|
|
|
|
```sh
|
|
scripts/release.sh --dry-run v0.2.0 # the notes the release would have
|
|
scripts/release.sh v0.2.0 # CHANGELOG.md, commit, tag, push
|
|
```
|
|
|
|
It refuses unless you're on a clean `main` that matches `origin/main`.
|
|
[git-cliff](https://git-cliff.org) (`cliff.toml`) writes `CHANGELOG.md`
|
|
from the pull request titles. The tag runs the release workflow
|
|
(`.gitea/workflows/release.yml`): it tests, then
|
|
[GoReleaser](https://goreleaser.com) (`.goreleaser.yaml`) builds the
|
|
archives and publishes a Gitea release with them and the release's
|
|
changelog section. Then `scripts/github-release.mjs` copies that release,
|
|
notes and files, to the GitHub mirror, with the `GH_RELEASE_TOKEN`
|
|
secret (a fine-grained token that can write the mirror's contents);
|
|
without the secret it skips that. `goreleaser release --snapshot
|
|
--clean` builds the same archives locally, into `dist/`, without
|
|
publishing.
|
|
|
|
A suffix (`v0.2.0-rc.1`) makes a pre-release, which leaves `CHANGELOG.md`
|
|
alone.
|