Additionally, we might want some sort of delayed or batched CRL-checking that doesn't block signature verification with another network interaction, but would protect the user against future problems.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 30 2018
Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.
Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.
Thanks for your additional suggestion. I pushed the change.
Jan 29 2018
Confirming this bug in Gpg4win version 3.0.3 (previous version was OK).
I did a few more tests and here are some more observations:
For qt: adding /usr/pkg/qt5/bin to the path makes the build succeed. I think you should take a look at the build rules though, since it seems that it wants to execute the header file if "moc" is not found.
For BSD Make issue, please try:
Ah, yes. Will do. Thank you for reminder.
Thanks for the report.
Fixed in master.
For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure
Using BSD make on git head of gpgme, I see
Thank you. I think you can update the comment below the implementation now ("/* FIXME: Implement this when we have the specification for it. */) and the #error line.
Still open.
Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.
Jan 27 2018
I just thought that going by your comment on Sat, Jan 27, 5:29 PM that you would use libdns, instead of resolv.conf directly. Maybe I understood that comment wrong.
dirmngr looks into /.etc/resolv.conf and does not know anything about systemd specific things (nor do I). Thus having a symlink seems to be an appropriate solution.
Note that it works as expected if I symlink /run/systemd/resolve/stub-resolv.conf to /etc/resolv.conf. Other programs appear to not require this change.
I can reproduce this issue with gpg 2.2.4, systemd-resolved and Arch Linux. Unlike the original reporter, I do not have 127.0.0.1 in my /etc/resolv.conf. I do however have it in /etc/hosts.
It turned out to be a bug in Enigmail. The "," in the key list s wrong.
Jan 26 2018
Checked - it builds fine now. Thanks!
I push my change to master.
Please test.
Jan 25 2018
- Collect all data in OOM, then start a thread to do the encryption.
- Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
- Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
- Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.
Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.
Jan 24 2018
Regarding truncation, it seems draft of the RFC has some contradicting statements. In "5.2.2. {5.2.2} Version 3 Signature Packet Format" it says:
Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.
I close this bug - if you can provide the log files please feel free to reopen.
Thanks for the long explanation. I think it should go into pinentry proper. I will have a closer look on it.
That might be the case. I suggest to use
Please note that Section 13.6 of RFC 4880 says:
Are you sure that you are runtime linking to the same libgpg-error version you used for the build?
This would then be a 1024 bit DSA key according to the DSA-2 specification. Back when DSA was introduced to PGP the specs did not specify a truncation. Maybe because there were no hash algorithms larger than 160 bits at that time.
Actually, I was using rightmost 160 bits of hash instead of leftmost. Key below also uses DSA/1024 with SHA256, but I'm using 160 bits from the left and it can be imported correctly
Thank you, that's useful.
You can compare your key with a key generated by GnuPG.
If you look at the specs of DSA you will see that using SHA-256 truncated to 160 bits is not defined. DSA 1024 uses a 160 bit subgroup and thus SHA-256 would need to be truncated to 160 bits. If you want to look closer at that key the command
Jan 23 2018
Key signed with SHA1