Shane Jaroch [Sat, 3 Jan 2026 05:00:31 +0000 (00:00 -0500)]
linting, testing; coverage reported 63.8%
monkeypatch to fix kcov invocation on posix shell
(add dedicated target for pure /bin/sh testing)
remove old redundant exit 0 in test
add force push/SIGINT tests
fix silently passing (actually failing!) test
force push reword [TODO: restore require-explicit-force-push]
manifest versioning to help verify compatible & authenticity
show signer version; inject version to test
require --force to init or overwrite manifest
split up large repacking test
add separate test for repack with large objects
add method to clean unencrypted files off remote
prevent privacy leaks of previously unencrypted blob
privacy test
more safety/privacy checks and clean command/check early in execution
don't publish participants in new test
remove useless debug log statement
tidy default fetch; small fix to init
Shane Jaroch [Thu, 1 Jan 2026 04:35:42 +0000 (23:35 -0500)]
feat: Add Makefile, CI, and improved testing infrastructure
Adds a Makefile for standardizing test/lint/install workflows, a GitHub Actions CI workflow, and coverage reporting tools. Also updates install.sh to support version detection.
Shane Jaroch [Thu, 1 Jan 2026 04:35:15 +0000 (23:35 -0500)]
fix(gpg): Handle ECDH checksum error with many keys
Allow PRIVDECRYPT to iterate all secret keys instead of failing on the
first checksum error.
Anonymous recipients caused a bug in prior versions (with ed25519 keys)
where if GPG couldn't decrypt using the first key in a user's keybox,
all push and pull operations would fail with a checksum error and exit
code 2 (EVEN IF the user had the correct key in their 2nd or 3rd slot).
The fix traps the 'error' and logs it, but lets PRIVDECRYPT continue.
The manifest's integrity is still verified by the subsequent grep.
If decryption truly fails, the script will exit safely.
GET and PUT are meant to exit nonzero on failure, and without this flag, they
always exit zero when rclone is used, even when a file is not found. That
confuses other parts of the code.
Joey Hess [Wed, 20 Jan 2021 15:23:01 +0000 (11:23 -0400)]
support more standard rsync URIs
This adds support for "rsync://user@host/path", which is a valid URI,
and will be parseable by URI parsers, unlike the old "rsync://user@host:path",
which at least some URI parsers will reject due to the ":path" looking
like an unparseable port number. The old nonstandard URI form is also
still accepted.
Note that, the path in the new URI form is not relative to the home
directory, but absolute. This is necessary because "/path" looks like an
absolute directory, and there needs to be a way to specify an absolute
directory. Something like "/~/path" could be added to specify the home
directory, but seems like an unncessary complication.
Note that rsync supports rsync:// URIs itself, but those communicate
with a rsync daemon on its own port, rather than via ssh. gcrypt already
was using rsync:// to denote rsync over ssh, and this does not change
that. So, the url has to be rewritten from "rsync://user@host/path"
to the rsync location "user@host:/path"
I used this test suite while developing the rather complicated sed
expression, to make sure I did not break handling of the old URI form.
set -e
test $(rsynclocation "rsync://host/path/foo") = host:/path/foo
test $(rsynclocation "rsync://host:path/foo") = host:path/foo
test $(rsynclocation "rsync://user@host/path/foo") = user@host:/path/foo
test $(rsynclocation "rsync://user@host:path/foo") = user@host:path/foo
test $(rsynclocation "rsync://user@host/path:foo") = user@host:/path:foo
test $(rsynclocation "rsync://user@host:path:foo") = user@host:path:foo
test $(rsynclocation "rsync://user@host/path:foo/bar") = user@host:/path:foo/bar
test $(rsynclocation "rsync://user@host:path:foo/bar") = user@host:path:foo/bar
test $(rsynclocation "rsync://user@host/path/foo/bar") = user@host:/path/foo/bar
test $(rsynclocation "rsync://user@host:path/foo/bar") = user@host:path/foo/bar
Sean Whitton [Mon, 11 May 2020 22:20:43 +0000 (15:20 -0700)]
generalise GNU/Linux installation instructions
There isn't much point in listing distro-specific commands with the
same package name in each one, as users of those distros will already
know those commands.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
The flags will be applied to `rsync` during uploading when using the `rsync://`
backend. If `remote.<name>.gcrypt-rsync-put-flags` is set, the flags set in
`gcrypt.rsync-put-flags` will not be applied to the remote `<name>`.
This change also includes documentation.
We have tested with the following configurations:
1. none set
2. `git config gcrypt.rsync-put-flags "--perms --chmod=g+rX"`
3. `git config remote.<name>.rsync-put-flags "--perms --chmod=o+rX"`
4. both (2) and (3)
All local files start with only owner permissions set, and umask is set to 077.
In (1), no change in behavior as before, as expected. In (2), the remote files
have the group permissions set, as expected. In (3), the remote files have the
other permissions set, as expected. In (4), the remote files have the other
permissions set, but do not have the group permissions set, as expected.
Code review comments [1]:
- Man pages should not be marked as %doc
- man pages extension should be globbed as the compression may change in the future.
- the man page should be installed unzipped. The compression will be handled by the rpm build process.
- %doc /usr/share/man/man1/%{name}.1.gz → %{_mandir}/man1/%{name}.1*
Also update the setup line to %{name}-%{version} to
match the folder setup from the tar.gz file downloaded
from https://git.spwhitton.name/%{name}/snapshot/%{name}-%{version}.tar.gz
Sometimes, git-remote-gcrypt reports 'gcrypt: Repository not found', but
this can be due to all sorts of connectivity issues, or even due to
ssh-agent using a wrong identity. This should at least be in the docs as
it is a very unprecise error message.
projects / gamesguru / git-remote-gcrypt.git / log