Manual section: | 1 |
---|
git-remote-gcrypt is a git remote helper to push and pull from repositories encrypted with GnuPG, using a custom format. This remote helper handles URIs prefixed with gcrypt::.
Supported backends are local, rsync:// and sftp://, where the repository is stored as a set of files, or instead any <giturl> where gcrypt will store the same representation in a git repository, bridged over arbitrary git transport. See "Performance" below for backends comparison.
There is also an experimental rclone:// backend for early adoptors only (you have been warned).
The aim is to provide confidential, authenticated git storage and collaboration using typical untrusted file hosts or services.
install.sh
script on other systemsCreate an encrypted remote by pushing to it:
git remote add cryptremote gcrypt::rsync://example.com:repo git push cryptremote master > gcrypt: Setting up new repository > gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R > [ more lines .. ] > To gcrypt::[...] > * [new branch] master -> master
The following git-config(1)
variables are supported:
remote.<name>.gcrypt-participants
gcrypt.participants
Space-separated list of GPG key identifiers. The remote is encrypted
to these participants and only signatures from these are accepted.
gpg -k
lists all public keys you know.
If this option is not set, we encrypt to your default key and accept
any valid signature. This behavior can also be requested explicitly
by setting participants to simple
.
The gcrypt-participants
setting on the remote takes precedence
over the repository variable gcrypt.participants
.
remote.<name>.gcrypt-publish-participants
gcrypt.publish-participants
By default, the gpg key ids of the participants are obscured by
encrypting using gpg -R
. Setting this option to true
disables
that security measure.
The problem with using gpg -R
is that to decrypt, gpg tries each
available secret key in turn until it finds a usable key.
This can result in unnecessary passphrase prompts.
gcrypt.gpg-args
--use-agent
.remote.<name>.gcrypt-signingkey
user.signingkey
user.signingkey
if your default signing key is not
part of the participant list. You may use the per-remote version
to sign different remotes using different keys.remote.<name>.gcrypt-rsync-put-flags
gcrypt.rsync-put-flags
rsync
when uploading to a remote using the
rsync://
backend. If the flags are set to a specific remote, the
global flags, if also set, will not be applied for that remote.How to set up a remote for two participants:
git remote add cryptremote gcrypt::rsync://example.com:repo git config remote.cryptremote.gcrypt-participants "KEY1 KEY2" git push cryptremote master
How to use a git backend:
# notice that the target git repo must already exist and its # `next` branch will be overwritten! git remote add gitcrypt gcrypt::git@example.com:repo#next git push gitcrypt master
The URL fragment (#next
here) indicates which backend branch is used.
rsync
, curl
and rclone
for remotes rsync:
, sftp:
and
rclone:
respectively. The main executable requires a POSIX-compliant
shell that supports local
.man gpg
for
more information.rsync://user@host:path
whereas plain rsync uses either user@host:path
or
rsync://user@host/path
.In addition to adding the rclone backend as a remote with URI like
gcrypt::rclone://remote:subdir
, you must add the remote to the
rclone configuration too. This is typically done by executing
rclone config
. See rclone(1).
The rclone backend is considered experimental and is for early adoptors only. You have been warned.
Example manifest file (with ellipsis for brevity):
$ gpg -d 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a 542051c7cd152644e4995bda63cc3ddffd635958 refs/heads/next 3c9e76484c7596eff70b21cbe58408b2774bedad refs/heads/master pack :SHA256:f2ad50316...cd4ba67092dc4 z8YoAnFpMlW...3PkI2mND49P1qm pack :SHA256:a6e17bb4c...426492f379584 82+k2cbiUn7...dgXfyX6wXGpvVa keep :SHA256:f2ad50316...cd4ba67092dc4 1 repo :id:OYiSleGirtLubEVqJpFF
Each item extends until newline, and matches one of the following:
<sha-1> <gitref>
pack :<hashtype>:<hash> <key>
keep :<hashtype>:<hash> <generation>
repo <id>
extn <name> ...
To detect if a git url is a gcrypt repo, use: git-remote-gcrypt --check url
Exit status is 0 if the repo exists and can be decrypted, 1 if the repo
uses gcrypt but could not be decrypted, and 100 if the repo is not
encrypted with gcrypt (or could not be accessed).
Note that this has to fetch the repo contents into the local git repository, the same as is done when using a gcrypt repo.
Every git push effectively has --force
. Be sure to pull before
pushing.
git-remote-gcrypt can decide to repack the remote without warning, which means that your push can suddenly take significantly longer than you were expecting, as your whole history has to be reuploaded. This push might fail over a poor link.
git-remote-gcrypt might report a repository as "not found" when the repository does in fact exist, but git-remote-gcrypt is having authentication, port, or network connectivity issues.
git-remote-helpers(1), gpg(1)
The original author of git-remote-gcrypt was GitHub user bluss.
The de facto maintainer in 2013 and 2014 was Joey Hess.
The current maintainer, since 2016, is Sean Whitton <spwhitton@spwhitton.name>.
This document and git-remote-gcrypt are licensed under identical terms, GPL-3 (or 2+); see the git-remote-gcrypt file.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。