This issue is not concrete enough to have some kind of "done" so ->invalid
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 1 2018
This issue is invalid.
Thanks, Werner.
With the latest data everything works fine.
I also a problem with incorrect cipher state resetting if last chunk is 0-size.
C:\Users\XavierFRUTON>gpg --gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
The only other add-in that I use is Skype, but I`ve disabled that and re-uploaded the log. We are using Exchange 2010 SP3
Thanks. Error is there:
Thanks, file attached
I close this bug as wontfix. If you can provide the requested changes for libtool please re-open this bug.
That is weird, I've never heard of that before.
rW981a6fae5355 Fixes the problem with Kleopatra's config files.
Feb 28 2018
That will be the IP of proxy.x.com - the log shows that it finds that. But the log also shows that it can't find the address for the other names. "No Name" is EAI_NONAME.
I did some digging with Wireshark:
- there are DNS queries for proxy records A & AAAA (ipv4 & ipv6 - both regardless of --disable-ipv6)
- DNS reply returns correct IP address in A record
- there are no outgoing connections to proxy IP address
The button shows and I can select Sign or Encrypt but they don't register / stay selected they just have a grey highlighted background whilst hovering over them... they do not toggle / stay selected.
Is it possible that your %APPDATA% directory is redirected? Maybe you are running into T3818 I also got "General Error" when trying to generate a key because of that bug.
What do you mean by "Does nothing"? The button should toggle and then when you send the mail kleopatra should show a dialog to select the signing / encryption keys.
With the attached commit gpgconf works. Key generation in Kleopatra also handles the case now that gpgconf does not work.
The underlying problem is that gpgconf does not work in such an environment.
$ gpg-error --desc GPG_ERR_WRONG_NAME 313 = (0, 313) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_WRONG_NAME) = (Unspecified source, Unknown error code)
Note that "Wrong name" severely misses information about that it is connection related in any way. :)
Just adding "Connection problem: TLS: " would already help a lot.
Well, if your proxy inhibits GnuPG to retrieve information about the keyservers, GnuPG can't do anything about it.
Debugging network problems is always hard and applications should not include tcpdump facilities. Right, I consider TLS network failures identical to layer 3 network failures because we should assume that all traffic is encrypted. Wrong certificates are also a severe network failure much like wrong voltage levels at layer one ;-).
I found another encoding error which renders the test data uploaded yesterday useless: Here is a bogus AEAD packet:
00000040 d4 84 01 07 01 00 6c 34 7c 37 83 24 2a 11 bc 1c 00000050 bd 1a 76 da 93 8a [start chunk] 32 cd 80 a5 8e db 3a 7d 4a 40 00000060 c5 0d 82 01 8d 64 7f 65 cd ca 58 d0 e7 db 3b 5e 00000070 89 d9 1b c8 d9 93 1a 37 3c 0e a5 8f 4b 0d 9f db 00000080 34 56 c8 f1 e9 b7 f5 0b d2 53 4f 6c fd f8 e9 16 00000090 cd a4 ae f6 7f 65 [tag] ef 5f 96 af 62 70 f4 30 27 37 000000a0 68 61 95 0a fb 23 [extra tag] a6 66 75 7a 47 bb 57 d3 da 5a 000000b0 4d d1 c2 2f 43 39 [final tag] cd 22 91 16 1d 92 17 1f f2 cf 000000c0 0f c9 11 56 d0 a9
Just to clarify:
1.I'm behind corporate network
2.Network resolves only local addresses, so this is correct: dirmngr[7416]: resolving 'hkps.pool.sks-keyservers.net' failed: No name
3.Network address of the proxy is resolvable (I can see it's address and it responds to ping
4.Internet browser without proxy will not work
5,Internet browser with the proxy below works
6.When using gpg on this computer outside of corporate network everything works
An additional note: It is harder than with gpg-2.0 to get more details about a failed attempt to receive pubkey material. The keyserver options cannot be called from gpg direclty, but have to be given to dirmngr. I don't have a solution this, it is just an observation.
The stripped down log is
Feb 27 2018
@werner Problem persists (same results with disabling ipv4 or ipv6
Here is the build log from unpatched gpgme https://www.zq1.de/~bernhard/temp/gpgme-build-log-2033.txt
it has some tracebacks from t-callbacks.py
is a simple script to check that the encrypted files in the above tarball. How to use:
cd gnupg mkdir test-aead cd test-aead tar xzf gnupg-aead-enc-files-20180227.tar.gz sh checktestdata.sh gnupg-aead-enc-files-20180227/*
password is "abc". I have some comments in the commit logs.
Can you please show the output of these failing tests? I assume you are running on a 64 bit platform.
Hi Werner, thanks.
Looks like our tests against GnuPG are passing now.
Can you please provide the password for this file as well? 'password' doesn't seem to fit.
@Ainahir thanks for the info. However, your problem might be different because you are on Windows and not on Linux.
Please use for dirmngr --debug=ipc,dns instead of --debug-level=guru
Here is a file
same behavior on gpg 2.2.1
Could you please try on the command line. (If you don't know how, see: https://www.wikihow.com/Open-the-Command-Prompt-in-Windows )
The problem is still that other - non-gpgme threads - can still use getenv and friends without us noticing that. But I see no solution for this. In any case this code is the best we can do.
Hi aheinecke,
I did some tests with 2.0.7-beta10 and still found some issues.
The message I attached as a test case in previous comment is now properly handled, I see no "signature.asc" attachment and message is correctly tagged as trusted sender; this test message was sent from Evolution and I sent it to myself (sorry for not pointing this out before).
My test works now with this commit.
Feb 26 2018
I think the problem is with the selction change event. When we query for selection item (1) we trigger an itemLoad event which apparently causes this behavior. I've disabled everything else in our event handling code so we don't touch the mail at all (non crypto mails we never touch much).