- User Since
- Mar 27 2017, 4:48 PM (78 w, 1 d)
Running with -v would really be helpful.
Mon, Sep 24
Maybe not on Linux but the environment is visible from other processes in the same way as the command line. So I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task.
- Administrative work
- Fixed some regression in gpgme's "make check"
- Simplified libgpg-error header generation
- gpgme-json work
Sat, Sep 22
Please see my comment on T4152.
Please check again with a recent upstream release or report to Debian. The release from Debian is pretty old and has a couple of non-standard patches.
Fri, Sep 21
Thu, Sep 20
Wed, Sep 19
Tue, Sep 18
Andre explained that we don't do that anymore on purpose. Duck and read the discussion related to this if you are intereested. A related thing is that no-grab does not work on all platforms because it was designed for standard X but nowdays toolkits have their own ideas what is right and what is wrong.
no-grab does only work on certain platforms. Thus this is no bug.
pinentry-qt giving Gtk- warnings? Very strange. Please give an example. You can start pinentry on the command line like
if you start gpg-agent in that deprecated way it sees the envvars. it will even see them if it is as suggested started on-demand by gpg. However, things are different when a gpg-agent is already running; in that case only the listed envvars are conveyed to the pinentry.
We need a way to replicate your problem, a few questions first:
I would call that a feature because it makes sure that the Pinentry always shows up the same regardless of an application selects a different theme.
Mon, Sep 17
Wed, Sep 12
The background of my earlier comment was that I didn't tested GPGME in this regard.
Okay. So for GPGME should we add --no-keyring if --override-session-key is also enabled? I think this would be better than relying on the fact that gpgme ignores the returned error code.
Tue, Sep 11
@dkg does --no-keyring solves the problem for you?
We assume that this has meanwhile been fixed.
Mon, Sep 10
Well, the counterpart in gpg-agent is missing.
Actually it fails only when you set TERM to the empty string. Unsetting TERM still works:
Another address does not help as long as we are forced to use a Google account. That is not subject to discussion. sorry.
You may indeed post to gnupg-devel if that helps to raise the attention of the Travis folks. If they need support we would be glad to help.
This has always been the case and the worst thing which can happen is that (64 bit keyid clash) you might not be abale to import the "real" key. Keyserver's never promised to deliver the correct (in whatever sense) key, but are merely an anonymous and distributed stoarage systenms. This is why gpg does not trust a key by default but requires you to validate the key by other means (WoT, second channel, Web Key Directory).
- Adminstrative work
- VS-NfD vendor meeting in Bonn
- Minor code work
@catenacyber thanks fo this bug report.
Sat, Sep 8
Thanks for your comments, Stephan.
Fri, Sep 7
Thu, Sep 6
Wed, Sep 5
Which is the correct way to handle this. We merely gave the MDC packet a standard packet structure so to help with debugging. Decryption needs to defer the 22 bytes to be able to detect the MDC packet.
Thu, Aug 30
Release done with these major news:
- gpg: Refresh expired keys originating from the WKD. [T2917]
- gpg: Use a 256 KiB limit for a WKD imported key.
- gpg: New option --known-notation. [T4060]
- scd: Add support for the Trustica Cryptoucan reader.
- agent: Speed up starting during on-demand launching. [T3490]
- dirmngr: Validate SRV records in WKD queries.
Wed, Aug 29
There is no way for us to fix. It is a shell issue.
We won't fix that. If you want to build for Apple iOS make sure to use
The “this” is used so that we don't have too many strings to translate.
I added a call to print_further_info which will in --verbose mode explain it.
@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?
We won't do that. Those with badly encoded user ids should create new keys or meanwhile have done so. The whole charset back and forth encoding adds a lot of complexity for some legacy applications. Frankly I would like to get rid of all code conversions and stick to utf-8.
In T3464 is is described how you can do it. Sure, in your case you want to have a home directory so that the agent and pinentry can work. --no-keyring makes sure that a decryption with a private key can't happen. How we have the cache for symmetric encrypted data which you can disable with --no-symkey-cache.
--verify-files is mostly useful for scripting and and not for manual checking. With scripting etc you always need to use --status-fd and with that you get:
To use encryption and for both purposes: encryption and authentication.
I was already implementing a --no-homedir when I figured that we have --no-keyring. Using that with any homedir fulfills the requested purpose.
Will be in 2.2.10
Will be in 2.2.10
Tue, Aug 28
The question is now to model the API for this. For 0x02 it seems to be pretty clear: We assume it is a detached signature on a zero length file and make sure that no signed file is given.
This was actually reported against 2.0.31 which reached EOL 8 months ago.
Backport done for 2.2.10
AFAICS this is now implemented. We have the option --with-key-origin and even support in GPGME.
Done. To be released with 2.2.10.
FWIW, we record the origin of the keys. So you have the information. Use --with-key-origin in a key listing. GPGME also has the info.