This repository was archived by the owner on Oct 27, 2018. It is now read-only.
set --trust-model=always when encrypting#5
Open
joeyh wants to merge 14 commits intobluss:masterfrom
joeyh:master
Open
set --trust-model=always when encrypting#5joeyh wants to merge 14 commits intobluss:masterfrom joeyh:master
joeyh wants to merge 14 commits intobluss:masterfrom
joeyh:master
Conversation
Otherwise gpg may prompt to verify if we want to encrypt to users who
do not have a defined trust level. But, the participants setting
explicitly listed them, so we know we want to encrypt to them.
closes #3
This is needed by git-annex assistant when it sets up a gcrypt repository, to ensure that the gpg key it was asked to use to encrypt the repo is the same key used to sign it. If it's not, pulling from the repo won't work, due to git-remote-gcrypt's "Only accepting signatories" check. The user may have a global user.signingkey setting (I do), but be setting up a different special-purpose key for encrypting their git repo. The git-annex assistant cannot mess with the global value, so needs this to override it.
Author
|
Added another patch git-annex needs |
This is to allow programs to determine if a repo uses gcrypt, per #6. Since this program already knows the name of the manifest file and how to download it and decrypt it, it makes sense to do the check here rather than in, eg, git-annex.
For unknown reasons, it makes --list-keys sometimes not show fingerprints of certian keys.
The gcrypt-id is cached to there when running --check
… is set. Pass --no-tty to gpg in this situation. This is needed to interoperate with the git-annex assistant, which often runs without a controlling terminal, and will in a new version always do so. Conflicts: debian/changelog
set -e causes the xecho to not run if the xgrep fails. At least with OSX's /bin/sh, which is: GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) This didn't happen on Linux with: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) Possibly a bug in bash, or an OSX-specific bug. However, disabling set -e in the subshell seems a good idea anyway. fixes https://github.com/blake2-ppc/git-remote-gcrypt/issues/15
When a gcrypt remote is not available, for any reason (network being down, the drive containing it not being mounted, etc), pushing to the remote causes a new repository ID to be created. Instead, we now fail loudly when a remote is unavailable and when the remote ID is already set. https://github.com/bluss/git-remote-gcrypt/issues/20 (cherry picked from commit b46d48a)
Keyrings managed with gpg2 can contain secret keys whose public part is unavailable to classic gpg; on the other hand, gpg2 won't see keys created in gpg after an initial import. Situations in which error messages like "gpg: error reading key: public key not found" pop up can now be circumvented by setting the gpg.program git configuration entry to gpg2.
|
All of the improvements in this pull request are incorporated in my fork, which is the version included in Debian and Ubuntu. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Otherwise gpg may prompt to verify if we want to encrypt to users who
do not have a defined trust level. But, the participants setting
explicitly listed them, so we know we want to encrypt to them.
closes #3