I commited a change which should fix this on Linux
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 23 2017
Jun 23 2017
Thanks for testing.
Well, this is a regression due to us creating creating /run/user/gnupg/ socket directories now on the fly. Thus there is no more need to create non-default home directories via gpgconf. Now, gpg-agent watches the socket file and terminates itself as soon as the socket file vanishes. Before that change the socket for a non-default home directory was created in the homedir itself and thus removing the homedir also removed the socket file and in turn gpg-agent terminated itself.
Confirmed that it now compiles ok on Fedora, thanks.
Thanks for the reminder. Fixed.
Note that LIBASSUAN_LIBS is not needed because it is already part of t_common_ldadd.
This is such a large change that I feel uneasy to close the bug before we know that there are no regressions. This Means we need to wait whether the next release will break.
For anyone following this bug, someone has worked out a (very awkward) workaround: https://stackoverflow.com/a/27689596/2505159
dirmngr.patch1 KBDownload
I'm still hitting this on Fedora. The patch is simple and was posted on the mailing list but apparently not incorporated into git:
Jun 22 2017
Jun 22 2017
No response anymore, and we can not reproduce.
Assigning to Werner for "re 1."
@werner Can we close this here?
@werner I can't find the gnu privacy handbook sources, although they are mentioned here: https://gnupg.org/documentation/guides.html
marcus closed T1301: file-encryption does not work when keyrings are stored on volumes that are made offline available as Invalid.
Thanks for the fast response!
bkrbecek added a comment to T1301: file-encryption does not work when keyrings are stored on volumes that are made offline available.
we don't use GPG4Win anymore ... so, honestly I don't know - if you want I can verify that. Or you simply close the topic ...
We don't use roundup anymore.
marcus added a comment to T1301: file-encryption does not work when keyrings are stored on volumes that are made offline available.
Is this still an issue?
Is this still an issue with the latest version?
Is this still an issue?
marcus closed T1175: The user interface server is not available or could not be started in time. You may want to try again. as Wontfix.
I don't think we can do anything about slow startup times due to anti-virus software, sorry.
Is this still an issue?
According to Wikipedia, Live Meeting was discontinued. https://en.wikipedia.org/wiki/Microsoft_Office_Live_Meeting
Is this still an issue?
marcus added projects to T972: gpgol - Message sign fails under Outlook 2007 and GPGol 1.9.12: gpg4win, Windows.
Is this still an issue?
It's not possible, unless you convince the Emacs developers to add special support for it. See http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00798.html.
I used this workaround for the years I accessed my mail over ssh and emacsclient.
Jun 21 2017
Jun 21 2017
In many cases, it's possible to make two connections (e.g. via ssh) to such a server, and in one of those connections explicitly do:
Q8WUB added a comment to T3213: No passphrase prompt when decrypting symmetric encrypted file (i.e. using gpg -c).
Justus, thank you for the response and your time. My apologies if I raised an issue in vain.
justus triaged T3215: gpgme_op_import_keys() -- unclear documentation, problematic behavior as Normal priority.
• werner added a project to T3208: gpg: can't create '(null)': No such file or directory: Info Needed.
Jun 20 2017
Jun 20 2017
By the way, when terminating pinentry with "kill -TERM ...", it shuts down correctly, while CTRL-C show "gpg: signal Interrupt caught ... exiting" and a corrupt screen layout that is reset when pressing RETURN, further confirming the above diagnosis.
The problem seems to be that the CTRL-C is sent to gpg, terminating it, but pinentry keeps running and interfers with the terminal. With "ps -j" we can verify that pinentry runs in the process group and session of gpg-agent, while gpg runs in its own process group within the shell session. So, the signal rightly goes to gpg.
Fixed in 48aae8167dcae80d43b08167a88d9eb170781a04.
justus closed T3212: when canceling pinentry dialog while creating a new subkey, secondary pinentry dialog shows up as Resolved.
Fixed in badc1cdae52bd434e5fac2e4275575afeccc2837.
justus triaged T3212: when canceling pinentry dialog while creating a new subkey, secondary pinentry dialog shows up as Normal priority.
Agreed, that is odd.
justus closed T3213: No passphrase prompt when decrypting symmetric encrypted file (i.e. using gpg -c) as Invalid.
Yes, the passphrase is cached by gpg-agent.
Jun 19 2017
Jun 19 2017
I'm not sure I understand the problem. Importing that key seems to work just fine. Listing as well.
Fixed in 6e23416fe61d4130918f2d1bf6e1f98d102c4610.
marcus edited projects for T3186: pinentry-curses, pinentry-tty both freak out at control+c, added: g10code Sprint (KW 25); removed g10code Sprint (KW 24).
Jun 17 2017
Jun 17 2017
I can't find the string ' Generating a basic OpenPGP key for our unit test' in the GnuPG 2.1 source nor in the the 2.0 source. Thus it seems to be a modified version of GnuPG. I guess that is the 2.0.30 you mentioned. Please run
• werner added a project to T3209: /usr/include/inttypes.h:269:8: error: unknown type name 'uintmax_t'; did you mean 'uintptr_t'?: gnupg (gpg20).
What is your operating system?
here's a public key version of the same key. it was available easier and should reproduce the bug just as well
Jun 16 2017
Jun 16 2017
Jun 14 2017
Jun 14 2017
Refile if problems with current versions.
We can do this with estream now.
justus closed T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place as Resolved.
Fixed as of 9b12b45aa5e67d4d422bf75a3879df1d52dbe67f.
justus added a comment to T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place.
It doesn't seem to impact performance significantly:
Jun 13 2017
Jun 13 2017
In T3203#98567, @Valodim wrote:The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
user ids with length 0 do conform with rfc4880, though
I'd suggest to skip such user id. Actually I had in mind that we did that in the past - but I may be wrong.
• werner added a comment to T2236: Importing a key with badly ordered packets doesn't reorder it, and while --edit-key does reorder it doesn't move the signature packets to the right place.
Justus: When you have implemented that, can you please do a test with my key before and after? As you may know, I have hundreds of vanity signatures so that I need to have
The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
Out of curiosity, how did you create the key? What is the use case?
This is fixed now. The fix 15d2a009931f44a60b9df6325f837add208459d6 should be easy to backport.
and the platform is ...
Jun 12 2017
Jun 12 2017
-----BEGIN PGP PRIVATE KEY BLOCK-----
marcus added a project to T3186: pinentry-curses, pinentry-tty both freak out at control+c: g10code Sprint (KW 24).
Jun 9 2017
Jun 9 2017
The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.
You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.
Jun 8 2017
Jun 8 2017
justus renamed T3194: Export of keys fails (gets mangled) if stdout is redirected to a file on Windows from GPG on Windows 10: Order of export-key command affecting exported key quality? to Export of keys fails (gets mangled) if stdout is redirected to a file on Windows.
Jun 7 2017
Jun 7 2017
thanks for help - could have been my mistake as well, so better look twice.
Sorry. I looked at path_add and not at path_remove, see my garbled line numbers I started at 1062 and not 1162.
void __declspec(dllexport)
path_remove (HWND hwndParent, int string_size, char *variables,
stack_t **stacktop, extra_parameters_t *extra)
{
char dir[PATH_LENGTH_LIMIT];
char is_user_install[2];
char *path;
char *path_new;
int path_new_size;
char *comp;
const char delims[] = ";";
HKEY key_handle = 0;
int changed = 0;
int count = 0;
HKEY root_key;
const char *env_reg;• werner added a comment to T3198: GnuPG should fail to send a key to a keyserver on "unknown options".
A few people asked for this generic option help; it is not specific to keyservers. Now we implemented that and still not okay for everyone, oh dear.
Marcus: That would be a good opportunity to get back to your old curses works ;-)
IIRC, we fixed similar bugs in the past but this is for the latest pinentry.