Skip to content

Releases

vlt v0.3.0

Choose a tag to compare

@github-actions github-actions released this 12 Nov 08:14

Security

  • vlt refuses to open a passphrase-protected file (vlt.age, or a secret file in an older vault being upgraded) that demands more passphrase-hashing work than vlt ever uses (more than 2^20; vlt writes 2^18), and says so. Anyone who can change the vault's files, such as a server or a shared folder, could otherwise make every unlock use gigabytes of memory and take many seconds.
  • Built with the go1.27.4 toolchain, which fixes GO-2026-6859 in net/http (used by the update check).
  • Exported files are readable only by you on macOS, Linux and OpenBSD (mode 0600). They were created with your default permissions, usually readable by every user of the computer, so an exported SSH or TLS key was exposed (and ssh refuses a key others can read). The export is written to a new file and renamed into place, so nobody who opened the file the save dialog created can read it through that, and a symlink at the path is replaced rather than written through. On Windows the folder's permissions still apply.
  • An exported file's decoded contents are wiped from memory if the vault locks just as decoding finishes; they were left for the garbage collector to reclaim.
  • A secret file is only accepted at the path its own name and group give, and only if it holds a named secret of a known type. Whoever can write the vault's files (a server, a shared folder) could otherwise copy one secret's file over another's, or into another group, and vlt would open it there. Such files, like damaged ones, fail to open and are left out of the list, which now counts them under it; Details… names them (before, only the log knew).

Changed

  • Built with Fyne 2.8.2 (was 2.7.3) and age 1.3.2 (was 1.3.1). Building on Linux now also needs libwayland-dev.
  • Error messages no longer show internal prefixes such as "store.CopyTo" or "store.Update: write:". Each says what couldn't be done and why in plain words ("Couldn't move the vault: can't create the folder /Volumes/usb/vault: permission denied"), keeping the file's path (for a vault on a server too) and what the server said.
  • Saving a secret whose file another copy of vlt has since given to a differently named secret now names that secret.
  • The auto-lock and clipboard sliders in Settings take effect when you let go of them (or on a tap or key press), not while dragging.
  • CI runs the tests on macOS and Windows too, not only on Linux, in a random order; before, those systems were only built.
  • CI checks its own workflow with actionlint and zizmor, and the packaging scripts with shellcheck, on every push and pull request; before, these ran only by hand or in a local hook. The packages are built only once they pass.

Fixed

  • On Windows, a file given as the vault location was taken for an empty folder: vlt offered to create a vault there, and creating it then failed. It now shows the error screen saying the location is a file, not a folder, on every system (macOS and Linux showed the error screen, with "not a directory").
  • When the vault can't be listed (a lost connection, a permission problem), the list now says why and offers Retry; it used to look empty.
  • A server vault whose folder has #, ? or % in its name, given as an ssh:// location (with a port or a one-letter host), was saved unescaped, so vlt could not open it again. Locations are now saved in a form that reads back as themselves, including folders with leading or trailing spaces, @[ in the path, or a folder named ~ at the server's root.
  • A host that isn't an IPv6 address but holds a colon ([:]:vault), or a stray ] in a host name, was accepted; both are now refused, as is a server folder name with a control character (a NUL would make the server use another folder).
  • host:~//vault and ssh://host/~//vault named /vault at the server's root instead of vault in your home directory. SSH:// is now read like ssh://.
  • A dropped connection or a disk error while reading another copy's vlt.lock was reported as "Vault Already Open", and Open Anyway then met the same fault. A dropped connection is now retried, and an error that persists is treated like a failure to write the lock: logged, and the vault opens without recording that it is open. A lock file that is damaged, or that you may not read, still counts as open elsewhere.
  • Settings no longer offers to switch to, or move to, the current vault when its location is written another way (an unescaped space in an ssh:// location saved by an older version, say).
  • A vault location set by VLT_VAULT_DIR, or saved by an older version, is shown in the form vlt saves (me@nas:/srv/vault for ssh://me@nas/srv/vault), like one chosen in Settings, and the error screen no longer offers Use the Vault on This Computer when the location already is that vault, written another way.
  • Moving a vault that has another vault in a folder inside it (a backup copy, say) copied that vault's key file into the new location without the rest of it, as if it were a secret. The vault inside is now left where it is.
  • A vault kept in a folder inside your vault is no longer counted under the list as a secret file that couldn't be read.
  • On Windows, a folder chosen with Browse… (Settings) or Open Existing Vault… was written with forward slashes (C:/Users/me/vault); it now uses the usual backslashes, as does the path in an error about a failed export.
  • Importing a file whose name is taken by a secret file that can't be read now says so and suggests renaming the file; it showed a decryption error.
  • Move Vault could be started again while the vault was still being copied, and Switch Vault or Change Passphrase could run in the middle of a copy, leaving a half-copied vault, or a copy with the old passphrase's key. While one of the three runs, the others now wait: the button is disabled and the status bar asks you to wait.
  • A move that stopped part-way (the vault locked, or the connection dropped) left the new folder with the vault key and only some secrets, so switching there opened what looked like the vault with secrets missing, and moving there again said "vault already exists". The vault key is now copied last: an unfinished copy has none, and unlocking it says so. Moving the vault to the same place again finishes the copy, without copying again what is already there. If the vault changed since, vlt says so and asks you to delete that folder and move again (it used to say "vault already exists"), and a vault another copy of vlt creates there meanwhile is never overwritten.
  • The auto-lock no longer cuts off Move Vault or Change Passphrase. A move to a server can take longer than the auto-lock timeout without any input, and a passphrase change cut off while saving could take effect without telling you. While either runs, the auto-lock now waits (for up to an hour without input) and then counts down in full; Lock still locks at once. If you lock while the passphrase is being changed, vlt now tells you afterwards whether it changed.
  • A passphrase change for a vault on a server that lost its connection was reported as failed, though the server may have saved it, so the passphrase you thought current could then be refused. When the connection drops after vlt has asked the server to put the new key in place, vlt now says the change may or may not have been saved, and to try the new passphrase if the current one is refused; a connection lost before then, or a server that can't be reached, is reported as a failed change (the current passphrase still works).
  • A passphrase change on this computer whose folder could not be synced after the new key was put in place was reported as failed, though the new key may have been saved. It is now reported as possibly saved, like a server change whose connection dropped.
  • Locking a vault in a network folder (SMB, NFS and the like) that had stopped answering froze the window, since vlt removed its lock file before going on. The vault key is still forgotten at once, and the lock file is now removed in the background. A removal that finishes late no longer deletes the lock of a copy of vlt that has opened the vault since (on another computer, or the next unlock here), so that copy is still reported as open elsewhere. Quitting just as an unanswered "Vault Already Open" question times out, or while Open Anyway takes the lock over, now waits for the lock to be released, and the vault being taken over is locked at once by the auto-lock or quitting.
  • Locking during Change Passphrase froze the window, and kept the vault key in memory, for as long as the new passphrase took to process (a second or more). The vault now locks at once, and the interrupted change is reported as not made.

vlt v0.2.0

Choose a tag to compare

@github-actions github-actions released this 01 Nov 22:34

Added

  • One-time codes. A record with a TOTP secret shows its current code, the seconds until it changes, and Copy Code, like an authenticator app. The secret can be the base32 text a site shows or the whole otpauth://totp/… link from its QR code (6–8 digits, a period of 1–300 s, SHA-1, SHA-256 or SHA-512); HOTP and Steam Guard links are refused. A new or changed TOTP secret that can't be read is refused when saving. The TOTP secret lives in the vault with the password, so whoever unlocks the vault has both factors.
  • Check for updates. Help → Check for Updates… (and Check Now in Settings) asks GitHub for the latest release and, if it is newer than this build, shows its notes with Open Release Page. A Settings option, off by default, checks when vlt starts and, once the vault is unlocked, tells you once about each new release. vlt never downloads or installs anything itself. The README has a new Updating vlt section.

Security

  • Dependabot proposes Go module and GitHub Actions updates weekly (each release at least 7 days old), and CI also runs govulncheck every Monday, so a newly published vulnerability is reported without a push.

Fixed

  • Builds report their version from the nearest vX.Y.Z tag only, so another tag can't make a release build look like a development build.

Changed

  • A GitHub release's notes are now its CHANGELOG.md section (they were GitHub's generated list of changes), and a release tag without a dated changelog section fails CI before anything is packaged or published. The README has a Releasing checklist.
  • The license is now BSD 3-Clause (it was MIT). Like MIT, it disclaims all warranty and liability; it also forbids using the copyright holder's name to endorse derived products. Copies of 0.1.0 remain available under MIT.
  • The module path is github.com/heyjdp/vlt and the app ID io.github.heyjdp.vlt (they were the placeholders github.com/yourorg/vlt and io.yourorg.vlt). Fyne keeps settings per app ID, so on its first start vlt carries the vault location, auto-lock timeout and clipboard TTL over from 0.1.0's settings file. On macOS the app's bundle ID changes too. (Gatekeeper asks once more, Open Anyway, as it does for every new download.)

vlt v0.1.0

Choose a tag to compare

@github-actions github-actions released this 29 Oct 15:46