Repository navigation
Releases: hibariya/git-remote-sealed
Release list
v0.3.3
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
Full Changelog: v0.3.2...v0.3.3
v0.3.2
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
0.3.2
Security fix. If you do not fully trust your host, please upgrade
every device.
A dishonest host could make a device accept a wrong version of the
vault. The trick: the host rejects one of the device's pushes on
purpose. After that rejection, the device forgot part of what it had
already checked. The host could then show it a version that disagrees
with what it saw before, and the device did not notice.
This needs a dishonest host and unlucky timing between two devices, so
it is unlikely. But the format promises to catch it. Now the device
keeps what it checked, and it refuses such a version with the error
"vault forked".
Nothing else changed. The vault format, your vaults, and the data each
device keeps are the same as in 0.3.1, and devices on 0.3.1 and 0.3.2
can use the same vault. See CHANGELOG.md for details.
Full Changelog: v0.3.1...v0.3.2
v0.3.1
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
0.3.1
0.3.x moves the key list into the vault. Each device used to keep its
own sealed.recipients list; now the vault records the keys it is
encrypted to, and every device sees the same list. Add a key with
enroll, remove one with revoke, show them with info.
Upgrading from 0.2.x: run git-remote-sealed upgrade once per vault.
Pushes are refused until you do. See the README for the steps and the
order to do them in.
0.3.1 fixes problems found in a review of 0.3.0:
- A vault with a mismatched key list can be repaired with
compact --repair. The key check also catches an extra key of a
non-X25519 type, and runs after the rollback check. upgrade --yeshandles a lost device.- A leftover
sealed.recipientsno longer blocks the first push to a
new vault or breaksrevoke. infoworks offline, and error messages fit the command you ran.
Format 2 is unchanged. See CHANGELOG.md for the full list.
Full Changelog: v0.3.0...v0.3.1
v0.3.0
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
Full Changelog: v0.2.1...v0.3.0
v0.2.1
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
Push and pull got faster: one fewer network round trip per fetch and push, and large pushes use about half the CPU. No format change, so existing vaults work as is.
Full Changelog: v0.2.0...v0.2.1
v0.2.0
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
Full Changelog: v0.1.0...v0.2.0
v0.1.0
Static Linux builds (musl) and macOS builds. Unix only — see the
workflow for why there is no Windows binary.
Verify before use. The attestation is the stronger check — it
proves the archive was built by this repository's release
workflow, from this commit:
gh attestation verify git-remote-sealed-<target>.tar.gz \
--repo hibariya/git-remote-sealed
shasum -a 256 -c SHA256SUMS --ignore-missing
Then put git-remote-sealed on your PATH. It needs git;
encryption is built in, so no age binary is required.
Full Changelog: https://github.com/hibariya/git-remote-sealed/commits/v0.1.0