gpgtools will have to update.
Jul 27 2017
Jul 17 2017
werner said this won't be fixed.
Jun 22 2017
If we will ever do this, then only in conjunction with appropriate continuous integration tools that report on new warnings and progress. Closing here.
Nobody started to hack on it in two years, and buried in this bug report nobody will find it. If this is still a desirable task, a new ticket should be opened.
May 9 2017
Well, this will be a different thing and more related to the to-be-implemented key origin feature.
I would thus suggest to open a new task for this.
I think we are talking "aneinander vorbei". AFAIK we agreed (on the Osnabrück meeting) that we will cater to this usecase: Multiple different keyrings for some operations. Or "curated" keyring. Through GPGK and so we will have some API (key probably not a keyring for a context) like this in GPGME at some point in the next years. This is why I think this issue might be kept open to say: Yes we see the usecase but we will not solve it by exposing, what you call a hack, through GPGME. But we will solve it at some point with a better solution.
May 8 2017
Back to you original problem: What you are trying to do is a hack to work around properties of GnuPG. Namely, that GnuPG stores its state in a _directory_ and you are modifying parts of this state (e.g. pubring.gpg). This is why GPGME allows you to switch to another directory but obviously does not allow you to modify parts of a directory (i.e. the state).
FWIW I strongly disagree with the sentiment that GPGME should be a "dumbed down" "Easy" GnuPG API. It should be GnuPG made stable -> A stable and reliable C API for the Free Software OpenPGP implementation GnuPG. But this is off topic. SCNR. It's much easier just to use process calls in many cases but I understand why this should not be done and leads to maintenance problems / bugs.
As discussed: The proper solution for this is GPGK, a Pubkey deaemon for GnuPG that would cater to audited / monitored keyrings. The usecase has not gone away and from my talks with people in the community and my general experience it is not "special" and definitely not "very special". It's important for Software Developers using GPGME that want to have keyrings for their Software Seperate from the general GnuPG user setup.
GPGME is about making GPG easy and not to cover very special use cases. I'll thus close this bug.
Mar 31 2017
Mar 30 2017
Mar 28 2017
Mar 22 2017
The problem is, that some projects liek gpgtools for MacOS are reluctantly sticking to
So, I'd love to have this patch committed in order to ease the transition phase from
2.0 to 2.1 for them.
Mar 1 2017
Yes, it's the same issue.
Isn't this the same as T2975 ?
Feb 23 2017
You need to wait for 1.8 - in a few weeks.
I looked at the required changes but decided not to backport that for 1.7.6.
Jan 6 2017
Jan 2 2017
Note that ff you have the secret key you can set the preferences.
Can't be fixed in 1.4 or 2.0. Has been fixed in 2.1.
Dec 9 2016
Nov 20 2016
Nov 14 2016
Regarding the original issue discussed here:
What about an option in gpg/gpgme to limit all operations to keys contained in a
(accept --recipient keys only if they are contained in the file, --list-keys
shows only keys listed in this file, --refresh-keys only refreshes keys listed
Reported the problem mentioned here in T2835
("keyid-format none" ignored for --verify and other commands)
(repost, I just noticed that neal is not in the nosy list. I'll unlink the old
neal: Interesting idea, this (or for a non-gui version: a signed list of
fingerprints available from a central source and retrieving those keys) would
solve 2 (iterating over all keys) and 3 (regularly update).
For the non-gui variant I wondered about how to use --verify and check that the
file was signed by the authority key (--verify only prints the keyid,
"--keyid-format none" does not allow --verify to print fingerprints in 2.1.15,
I'll file a separate issue). I was a bit disappointed when I saw that gpg sync
just calls the command line with --keyid-format 0xlong and does screen scraping
to verify the verification.
But still, how to solve 1 with gpg itself? Of course I could "manually" verify
in the application that only the intended keys have been used, but as shown with
gpg sync's code above: This is not always easily possible.
@thomas: You may want to look at gpg sync, which I think makes at least some of
what you want to do easier.
Sign the keys and set the signing key to fully trusted.
does not solve 1.:
Encrypt a file to any of those key (but no others!),
(because people may trust other keys)
and it does not solve 2. without keeping a separate list of keys/fingerprints:
Iterate over all keys
additionally _all_ users have to regularly update _all_ these keys, otherwise
things like expired subkeys will lead to failing encryption. (This is no theory:
We've been there and don't want to have this again)
Nov 11 2016
Sign the keys and set the signing key to fully trusted.
Nov 10 2016
Please tell me how I should model my workflows in this case:
- There is a a centrally managed set of public keys (currently in a keyring
file, but I'm open to suggestions)
- Different users should be able to use this set of keys (and no others) for
- Encrypt a file to any of those key (but no others!), but also decrypt the
file with their secret key (which is not centrally managed)
- Iterate over all keys and do something with them (here: publish them in the
WKD after having made changes to the set of keys)
We try to deprecate the use of the --keyring option because that is too
troublesome for many reasons. We can't remove that option from gpg proper for
compatibilty reasons. But not adding a new feature to GPGME won't raise any
compatibility problem and thus we can fortunately reject this request.
Nov 9 2016
Ah, I understand. I currently have two keyrings (the default keyrings and
debian-keyring.gpg) in my user account. So I will export the keys from
debian-keyring.gpg and import them into my regular keyring.
But this is a different topic from the one described here:
This issue is about allowing gpgme to use exactly one different keyring (not an
additional keyring) that is different from the default keyring or other keyrings
configured in the user's gpg.conf.
So it is just about allowing in gpgme what is already possible via the command
line. Or maybe you would prefer to allow passing command line options to gpg via
gpgme to avoid the wrapper script mentioned below?
I have explained this several times over the last decade. The primary reason is
that it is not possible to keep a consistent vewi on the localally availabale
keys when a user is allowed to remove and add storage at will without gpg having
any control over it. You may end up with duplicated keys and gpg will only
update one of them. The next time the keyrings are "mounted" in a different
order and key is used for update. This leads to all kinds of problems. This is
not a distributed database with a 3 -phase commit system.
I have proposed a solution gor 2.3 based a on central key managing daemon, which
then has the chance to track changes. Interesting fact is that aheinecke has
strongly opposed that idea.
Nov 8 2016
Besides the WKD scenario Andre describes, there are already many existing uses
of a separate keyring where having other keyrings configured via
~/.gnupg/gpg.conf already conflicts with the intended use, except when using
- our company's keyring with acceptable keys for encryption of certain
Basically everywhere where multiple users use a single keyring, often with
"--trust-model always", where you do not want additionally configured keyrings
to disturb the result and give a false sense of security.
Please explain why this a Bad Thing[tm] and what the correct workflow would be.
Oct 5 2016
Aug 18 2016
Aug 9 2016
Aug 5 2016
Jun 13 2016
I did not see anything in the FAQ dealing specifically with the GUI not
working. That is what this bug is about. I agree that changing the cipher-algo
should be done cautiously, but either the front-end should not permit it to
appear to happen, or the front-end should actually do the expected behavior
(namely, changing the config files).
Jun 3 2016
For modern gnupg, we no longer support v3 keys, and we're considering making
--with-fingerprint the default (see
https://lists.gnupg.org/pipermail/gnupg-devel/2016-January/030748.html), so i
think this suggestion should actually be reconsidered.
Apr 7 2016
Apr 5 2016
Mar 17 2016
Mar 14 2016
Feb 9 2016
Jan 22 2016
Jan 21 2016
Jan 15 2016
We wont fix that because it has been fixed in 2.1 and backporting make no sense
given that an easy workaround is available.
Dec 18 2015
Dec 9 2015
Some more infos:
says that this is a problem for a number of people.
Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.
Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.
So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.
Dec 8 2015
Nov 18 2015
The reporter wasn't to specify the secret key to use. Werner indicated that
--try-secret-key does what the reporter wants in 2.1, but that this won't be
backported to 2.0. As such, I'm marking this issue as resolved.
I'm going to close this. The right forum to address these issues is the OpenPGP
Nov 17 2015
Nov 12 2015
Nov 6 2015
Nov 3 2015
GtkSecureEntry has been removed from pinentry.
Oct 28 2015
Oct 16 2015
Oct 3 2015
The manual is not maintained anymore and thus we don't apply fixes, sorry.