Today
So w/o the new option we have:
Thanks Werner.
I updated the rendered form of the English GPH with a warning and a link to the blog.
Thanks for the hint.
The behaviour might have changed a bit because of the ldap: prefix i use now, or i have missed this case the last time:
Given some cert on the "download" server, I can find it, if dirmngr.conf contains only the "download" server, or if the "download" server is listed first:
Will be in the next release.
testing will wait for special build
it does not make sense to have a workboard item for this parent ticket.
Independent of keyserver order in dirmngr.conf, --search-keys still offers keys from the upload server, but the download fails:
For "Although the upload server is used for upload, the gpg message still displays the first keyserver" see T8025
I am using that version and key daily. No problems seen.
Looks good to me on gpg4win-5.0.0-beta479 @ win11:
was tested already by timegrid
This does not happen any more, tested with Gpg4win-5.0.0-beta479
Tested with Gpg4win-5.0.0-beta479
in Gpg4win-5.0.0-beta479
Looks good to me on gpg4win-5.0.0-beta479 @ win11:
with Gpg4win-5.0.0-beta479 the listing after creating the new key with ADSK looks ok now:
I think we won't fix that for 2.2
I assume, that testing the functionality is the only thing I can do here.
That was also fixed in gnupg 2.2.50 and thus vsd 3.3.3
That was fixed with 2.2.52 which fixed a bug in the fix done in 2.2.50 (see rG31fef13df1). Note that 2.2.48 to 2.2.50 had only internal releases.
Given that the 2.2 fix has been tested and resolved and we don't have another ticket for 2.6, we can close this one.
Looks good to me on gpg4win-5.0.0-beta479 @ win11
Okay, let's backport this.
Note that for exploiting this bug a second preimage attack for SHA-1 is required. This kind of attack on SHA1 is not yet possible.
Tested with gpg4win-5.0.0-beta479 @ win11
@tfry tested this, and it seems fine.
Yesterday
What I did wrong was that I did not include the global trustlist.txt (which is not read by default in Gpg4win) in the user trustlist.
This can be done by putting "include-default" at the beginning of the trustlist.txt in the users GNUPGHOME.
Okay. Confirmed and understood. The problem is that file system watcher doesn't watch the trustdb.gpg file because the file did not yet exist when the watcher was initialized. And during the import we disable the file system watcher so that it doesn't notice the creation of the file and therefore doesn't start watching it.
Addendum: I currently do not think we can do anything about this, except for documenting it.
I suppose you selected "Allow", then, and yes, that's enough to "fix" the problem. Chromium does remember the decision (unfortunately, it also remembers if you selected "Block", and some users are doubtlessly going to do so).
i didn't see any of this in chromium 141.0.7390.77, but i do after an upgrade to 143.0.7499.170. but only at the first start. when i closed chromium and launched it again, the logo appeared as desired (i did a successful pairing the first time).
when do you see this precisely?
Panel Used By
| Dashboard | Jab's Dashboard |