Won't FixCommunication
ArchivedPublic

Members

  • This project does not have any members.

Watchers

  • This project does not have any watchers.

Recent Activity

Jul 27 2017

marcus merged T3026: Export gpgme-pthread.pc into T1329: pkg-config support for gpgme.
Jul 27 2017, 4:59 PM · Won't Fix, gpgme, Feature Request

Jul 17 2017

marcus archived Won't Fix.
Jul 17 2017, 5:47 PM
marcus closed T3016: Vague error message: key X can't be retrieved (without telling anybody why) as Wontfix.
Jul 17 2017, 5:46 PM · Won't Fix, Bug Report, gnupg
marcus closed T3012: gpg-agent 2.0.30 not able to create SHA-2 signatures with scute as Wontfix.

gpgtools will have to update.

Jul 17 2017, 5:42 PM · Won't Fix, Bug Report, gnupg (gpg20), scd, gnupg
marcus merged task T2970: libgcrypt fails to build without NEON instruction set on arm64 into T2975: building libgcrypt fails on ARM64/FreeBSD 11x STABLE.
Jul 17 2017, 5:41 PM · Bug Report, Won't Fix, libgcrypt
marcus closed T2811: please compare the timestamps of secring.gpg and .gpg-v21-migrated and consider re-migration as Wontfix.

werner said this won't be fixed.

Jul 17 2017, 5:38 PM · Won't Fix, Feature Request, gnupg
marcus closed T1426: the way gpg updates the pubring files makes it impossible to symlink it as Wontfix.
Jul 17 2017, 5:34 PM · Won't Fix, gnupg, Feature Request
marcus closed T1901: seed.c: the right operand of '^' is a garbage value as Wontfix.
Jul 17 2017, 5:33 PM · Won't Fix, libgcrypt

Jun 22 2017

marcus closed T1741: comparison between signed and unsigned integer as Wontfix.

If we will ever do this, then only in conjunction with appropriate continuous integration tools that report on new warnings and progress. Closing here.

Jun 22 2017, 5:09 PM · Won't Fix, libgcrypt
marcus closed T1991: pinentry-w32 needs to adjust button sizes as Wontfix.

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.

Jun 22 2017, 5:07 PM · pinentry, Feature Request, Won't Fix, Not A Bug

May 9 2017

werner added a comment to T2820: GPGME: Allow to set the keyring for a context.

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.

May 9 2017, 9:07 AM · Won't Fix, gpgme, Feature Request
aheinecke added a comment to T2820: GPGME: Allow to set the keyring for a context.

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 9 2017, 9:05 AM · Won't Fix, gpgme, Feature Request

May 8 2017

werner closed T2820: GPGME: Allow to set the keyring for a context as Resolved.

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).

May 8 2017, 7:20 PM · Won't Fix, gpgme, Feature Request
aheinecke added a comment to T2820: GPGME: Allow to set the keyring for a context.

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.

May 8 2017, 5:39 PM · Won't Fix, gpgme, Feature Request
aheinecke reopened T2820: GPGME: Allow to set the keyring for a context as "Open".

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.

May 8 2017, 5:35 PM · Won't Fix, gpgme, Feature Request
werner closed T2820: GPGME: Allow to set the keyring for a context as Resolved.

GPGME is about making GPG easy and not to cover very special use cases. I'll thus close this bug.

May 8 2017, 2:07 PM · Won't Fix, gpgme, Feature Request

Mar 31 2017

marcus moved T3016: Vague error message: key X can't be retrieved (without telling anybody why) from Done to Backlog on the gnupg board.
Mar 31 2017, 3:04 AM · Won't Fix, Bug Report, gnupg
marcus moved T3016: Vague error message: key X can't be retrieved (without telling anybody why) from Backlog to Done on the gnupg board.
Mar 31 2017, 3:03 AM · Won't Fix, Bug Report, gnupg

Mar 30 2017

admin created Won't Fix.
Mar 30 2017, 6:42 PM

Mar 28 2017

werner added a project to T3016: Vague error message: key X can't be retrieved (without telling anybody why): Won't Fix.
Mar 28 2017, 2:44 PM · Won't Fix, Bug Report, gnupg

Mar 22 2017

wglas85 added a comment to T3012: gpg-agent 2.0.30 not able to create SHA-2 signatures with scute.

Hello Werner,

The problem is, that some projects liek gpgtools for MacOS are reluctantly sticking to
gnupg-2.0 :-/

So, I'd love to have this patch committed in order to ease the transition phase from

2.0 to 2.1 for them.

Regards, Wolfgang
Mar 22 2017, 1:17 PM · Won't Fix, Bug Report, gnupg (gpg20), scd, gnupg
werner added projects to T3012: gpg-agent 2.0.30 not able to create SHA-2 signatures with scute: scd, gnupg (gpg20), Won't Fix.
Mar 22 2017, 12:28 PM · Won't Fix, Bug Report, gnupg (gpg20), scd, gnupg

Mar 1 2017

cpm added a comment to T2970: libgcrypt fails to build without NEON instruction set on arm64.

Yes, it's the same issue.

Mar 1 2017, 3:14 PM · Bug Report, Won't Fix, libgcrypt
werner added a comment to T2970: libgcrypt fails to build without NEON instruction set on arm64.

Isn't this the same as T2975 ?

Mar 1 2017, 3:04 PM · Bug Report, Won't Fix, libgcrypt

Feb 23 2017

cpm added a comment to T2970: libgcrypt fails to build without NEON instruction set on arm64.

Ok, thanks!

Feb 23 2017, 9:17 PM · Bug Report, Won't Fix, libgcrypt
werner added a project to T2970: libgcrypt fails to build without NEON instruction set on arm64: Won't Fix.
Feb 23 2017, 8:31 PM · Bug Report, Won't Fix, libgcrypt
werner added a comment to T2970: libgcrypt fails to build without NEON instruction set on arm64.

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.

Feb 23 2017, 8:31 PM · Bug Report, Won't Fix, libgcrypt

Jan 6 2017

werner added a project to T1426: the way gpg updates the pubring files makes it impossible to symlink it: Won't Fix.
Jan 6 2017, 7:04 PM · Won't Fix, gnupg, Feature Request
werner added a project to T1345: gpg should try to connect using HTTP if HKP fails: Won't Fix.
Jan 6 2017, 6:59 PM · Won't Fix, Feature Request, gnupg
werner added a project to T1148: 1.4.x pinpad support (reader covadis vega-alpha => cannot used secure PIN): Won't Fix.
Jan 6 2017, 6:55 PM · Won't Fix, gnupg (gpg14), Feature Request, gnupg
werner closed T2118: Command --quick-gen-key ignores --default-cert-expire, --edit-key ignores --default-sig-expire as Resolved.
Jan 6 2017, 5:33 PM · Won't Fix, gnupg (gpg21), Bug Report, gnupg
werner closed T2427: Allow universal --batch more, with STDIN reads as Resolved.
Jan 6 2017, 5:21 PM · Won't Fix, Not A Bug, Bug Report, gnupg

Jan 2 2017

werner added a comment to T2894: setpref does not update preferences secret key, needed for export-secret-keys.

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.

Jan 2 2017, 1:56 PM · Won't Fix, Bug Report, gnupg
werner added a project to T2894: setpref does not update preferences secret key, needed for export-secret-keys: Won't Fix.
Jan 2 2017, 1:56 PM · Won't Fix, Bug Report, gnupg

Dec 9 2016

werner added a project to T2394: Broken link to noepatents.org: Won't Fix.
Dec 9 2016, 11:18 AM · Won't Fix, libgcrypt, Bug Report

Nov 20 2016

werner added a project to T2811: please compare the timestamps of secring.gpg and .gpg-v21-migrated and consider re-migration: Won't Fix.
Nov 20 2016, 5:23 PM · Won't Fix, Feature Request, gnupg

Nov 14 2016

thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

Regarding the original issue discussed here:
What about an option in gpg/gpgme to limit all operations to keys contained in a
"whitelist" file?

(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
here, etc.)

Nov 14 2016, 4:17 PM · Won't Fix, gpgme, Feature Request
thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

Reported the problem mentioned here in T2835
("keyid-format none" ignored for --verify and other commands)

Nov 14 2016, 4:14 PM · Won't Fix, gpgme, Feature Request
thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

(repost, I just noticed that neal is not in the nosy list. I'll unlink the old
entry afterwards)

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.

Nov 14 2016, 4:01 PM · Won't Fix, gpgme, Feature Request
neal added a comment to T2820: GPGME: Allow to set the keyring for a context.

@thomas: You may want to look at gpg sync, which I think makes at least some of
what you want to do easier.
https://firstlook.org/code/2016/10/12/introducing-gpg-sync-an-open-source-tool-for-organizations-that-encrypt-email/

Nov 14 2016, 10:53 AM · Won't Fix, gpgme, Feature Request
thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

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 14 2016, 9:53 AM · Won't Fix, gpgme, Feature Request

Nov 11 2016

werner added a comment to T2820: GPGME: Allow to set the keyring for a context.

Sign the keys and set the signing key to fully trusted.

Nov 11 2016, 5:23 PM · Won't Fix, gpgme, Feature Request

Nov 10 2016

thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

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

certain tasks:

  1. 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)

  1. Iterate over all keys and do something with them (here: publish them in the

WKD after having made changes to the set of keys)

Nov 10 2016, 1:06 PM · Won't Fix, gpgme, Feature Request
werner added a comment to T2820: GPGME: Allow to set the keyring for a context.

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 10 2016, 12:28 PM · Won't Fix, gpgme, Feature Request

Nov 9 2016

thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

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?

Nov 9 2016, 9:14 AM · Won't Fix, gpgme, Feature Request
werner added a comment to T2820: GPGME: Allow to set the keyring for a context.

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 9 2016, 8:51 AM · Won't Fix, gpgme, Feature Request

Nov 8 2016

thomas assigned T2820: GPGME: Allow to set the keyring for a context to werner.
Nov 8 2016, 5:29 PM · Won't Fix, gpgme, Feature Request
thomas added a comment to T2820: GPGME: Allow to set the keyring for a context.

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
--no-options:

  1. /etc/apt/trusted.gpg
  2. /usr/share/keyrings/debian-keyring.gpg
  3. our company's keyring with acceptable keys for encryption of certain

sensitive information

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.

Nov 8 2016, 5:29 PM · Won't Fix, gpgme, Feature Request
werner added a project to T2820: GPGME: Allow to set the keyring for a context: Won't Fix.
Nov 8 2016, 5:20 PM · Won't Fix, gpgme, Feature Request

Oct 5 2016

werner added a project to T2118: Command --quick-gen-key ignores --default-cert-expire, --edit-key ignores --default-sig-expire: Won't Fix.
Oct 5 2016, 2:59 PM · Won't Fix, gnupg (gpg21), Bug Report, gnupg