We as GPGTools would also like to see this addition being integrated into GnuPG, since we do plan to switch to keys.openpgp.org in the near future, as we have long been hoping for a key server with better performance and among other things email verification. Without this change, revocations would not work as expected in combination with hagrid however. Preferably of course in the 2.2.X branch.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 10 2019
Hi Maximilian,
Hi, @JW-D, as the 'fixed' version of mailvelope has been released, could you please confirm if the issue is solved for you with mailvelope 3.3.1, or if you're still affected? Thank you.
@gniibe: I doubt that your fix really makes a difference. The majority of time is spend on searching the keyring for keys. This is why I have the gpgk thing in the works.
I pushed my change as: rT7b2c4d9dd50b: Support GCM.
Please test.
I pushed the fix. Thanks for your cooperation.
Thanks for further testing.
I realized that it's not the left border drawing problem in fact, but the newline should be between the description and passphrase line.
I'm going to fix this.
Err... my repo for 2.2 was a week old. Now, I updated, and confirmed it's there.
Thanks having the support!
Jul 9 2019
Release done.
Managed to get the build correct. (patches in 1 sec)
I did this already on July 3 with commit 458973f502b9a43ecf29e804a2c0c86e78f5927a
You probably have one of the spammed keys in your keyring. This is a problem with the keyserver networks. Do not use --auto-key-retrieve and avoid using the keyservers until we provide a mitigation with the next gpg4win/gnupg release. See also T4591
Thanks for the update! With git-master, the toy example above works fine. However, pinentry-curses seems to hang with real commands from gpg. Here is an example:
$ ./curses/pinentry-curses OK Pleased to meet you SETDESC 請輸入密語來解鎖 OpenPGP 私鑰:%0A%22Chih-Hsuan Yen <yan12125@gmail.com>%22%0A3072 位元長的 DSA 金鑰, ID F98EF2A7B0A098AE,%0A建立於 2018-04-25 (主要金鑰 ID 3FDDD575826C5C30).%0A OK SETPROMPT 密語: OK GETPIN
(CPU usage of ./curses/pinentry-curses goes > 90%)
I pushed the change to master.
Please test.
Please consider to backport rG914fa3be22bf: dirmngr: Support the new WKD draft with the openpgpkey subdomain. from master. Cherry-pick mostly works, only dirmngr/server.c needs manual edit (because of resolve_dns_name change).
Allowing WKD service by subdomain (openpgpkey) is good, because it is easier to deploy by separate admin, in some situations.
I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.
When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.
Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).
I find Phabricator differential interface is quite horrible to use.
Jul 8 2019
then they are sorted by their binary content.
I will leave these in the main file, as they might benefit from "static", and I do not want to rely on LTO for that.
(if I ever get PPC HW access).
and cryptogam wrapper functions
yes, python2.7 and python3.7
Thanks. I really like this Altivec intrinsic approach. I might reimplement rest of the bulk block cipher functions this way later (if I ever get PPC HW access).
Using several python versions?
Sorry for that
No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.
rM7d0a979c07d2 disabled the test for this. @werner says:
Jul 5 2019
@gcwilson Can you notify the performance team of this new patch?
Because this is a GPGME bug.
That is a limit for the web key service to publish a certificate. IIRC, Debian developers do not use this but Debian creates the WKD from a database.
This is especially relevant if you are not going to implement the fallback to import-clean that was proposed in T4591.
I see that you have lowered the WKD limit to 64KiB with 6396f8d115f21ae15571b683e9ac9d1d7e3f44f4 -- i think this is a mistake, as reasonable certificates can be several times that size (e.g. zack's cleaned certificate, mentioned above). I'd prefer a limit of 256KiB.
why is this fix not relevant for the 2.2 stable branch? I've had no feedback on this proposed patch.
and from my understanding they are sending the self-signatures anyway.
This is not just about keys.openpgp.org. It's about any keystore that implements user id redaction, for whatever reason. When you say "what they can do is accept only user ids which…" i think you mean "the userid-redacting keystores can instead redistribute user ids which …". Is that right?
I think we should not backport this to 2.2 - okay?
Quiet tricky to get right; needs some rework.
Done for master and 2.2.
Works for me! :-)