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