Where its offer was, instead of the footer: the first line of the
reason, r for the whole message (Key Vault's refusals list what to
check), g to go to the key's secret at the link's version, and x to
dismiss.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Go to's picker settings are one picker struct, set while picking.
- Opening a share link plans the save, then asks or saves; no more
offerWrite doing either by a flag.
- Closing the picker while it encrypts cancels the share, and a
second pick meanwhile is ignored.
- Favourites and Recent leave out plain env values as keys too.
- share.key in the config is checked with share.ParseKey, so
{{secrets/…}} is refused there already.
- A key that can't be read reads the same opening as sharing
("can't use …"); KeyError moved to share.go, maxFiles is
maxUnpacked (bytes), and a stray comment is gone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Choosing where to save a share link's files saves them right away,
unless one would replace a file there, which still asks. The folder
prompt stays open until they're written: a folder that isn't there,
or a save that fails, is said under it in red, to fix the path. Its
footer says "enter save", and a file git doesn't ignore is named in
the status line after saving.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Keys keeping to share.keyRules are random and long, so age's 2^18
(a third of a second to share and to open) bought little.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The key picker stays open until the link is made, saying "encrypting
with …" meanwhile. A key that can't be read, or doesn't keep to
share.keyRules, is shown in it in red with which rule it misses
("its value has 28 characters; share.keyRules needs 32
(minLength)"), to pick another.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The demo provider finds repos by their remote, as the repo provider
does, so a key in a demo repo's SOPS file can be read. Opening a
share link uses the repo's clone only when it's on disk (the demo's
aren't), else asks where to save. The demo GitHub client secret is 40
characters, like real ones, so it passes share.keyRules.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Providers whose containers are files give their contents through
provider.Contents, which sharing reads instead of the disk. The demo
repos build their env files from their keys, and the second demo
account has a key to share with (kv-shared-prod / env-share), so S → f
and opening the link work in --demo; the demo repos aren't on disk,
so opening asks where to save.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The picker already shows what's shared. The confirmation stays for a
key from share.key, which wasn't picked. The share format's version
is documented as kept readable.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The share popup is titled for what's shared; above the search, "Pick
a secret to encrypt with" says the recipient needs read access to it,
with Go to's tabs under it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
repoLabel draws a repo, or a file in it, with pathLabel: the repo icon
and colour. The share popups use it for what's shared, where it's
from and where it's saved, and are titled for what's shared
("Share .env", "Share 2 env files"), the key picker too.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sharing refuses a key shorter than minLength characters (default 32,
never under 16) or of fewer than minClasses kinds of lowercase,
uppercase, digits and symbols (default 2, so random hex passes),
saying so without showing it. Opening doesn't check.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sharing without share.key opens Go to as a picker of secrets instead
of asking for a link: it lists only secrets, enter picks one, and a
pasted reference picks it too. The key, there and in share.key or
--key, can be a secret's lazysecrets:// link, Key Vault URL or
@Microsoft.KeyVault(...) reference.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
S → f on a repo, an env file or a key in one copies a
lazysecrets://share link holding the env files, encrypted (age) with
a secret's value: whoever can read that secret can open it. The key is
share.key in the repo's .lazysecrets.yaml, else in the config, else
picked when sharing; on Azure the link pins its version. Opening one
says what it holds, decrypts when asked, and saves the files in the
clone of the repo (or a folder chosen), replacing existing ones only
when asked. lazysecrets share prints a link from the command line.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
kebandClaude Opus 5.5