I see. I just pushed two fixes.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 10 2016
May 9 2016
Thanks. Fix released with 2.0.30 and 2.1.12.
We can close this bug after the release of 1.4.21
Fixed in all branches.
Master 2.1: d9f9b3be036747c9f55060aed47896f951bfb853
1.4: d957e4388f72581b1ec801613b5629b5ea3f586d
2.0: eb7806d63df63663170ba86f0673caa34b944c28
For some reason, the commit messages of 1.4 and 2.0 refers
master commit of 2f3e42047d17313eeb38d354048f343158402a8d.
Perhaps, I did in my repo and it was 2f3e420 and apply it to 1.4 and 2.0.
Then, I pushed 1.4, 2.0, and 2.1. and 2.1 was failed because of
non-fast-forward. Then I rebased for 2.1.
May 6 2016
Patch applied in dc417bf0c555a7416d0aedde6645fd1087660f92 (Dec 15, 2015)
iirc, we removed the patch from 2.1 due to some problems. We plan to work on it
in 2.3.
Neal, what is the status of this bug?
We still need to check whether has been fixed for 1.4 and 2.0.
For which branches has this been fixed?
Do we have releases for all of them?
2.1.12 does a verbose check and fix during --edit-key. We will eventually call
that reorder function during import. But let's wait for bug reports with the
--edit-key triggered code.
Fixed in 2.1.12
May 4 2016
Should be solved now: Use Libgpg-error 1.22 and GnuPG 2.1.12.
May 3 2016
1.3.4 has been released.
1.3.4 has been released
I just released 1.3.4 and thus closing this bug and 2342 and 2343. Thanks again
for you help.
Fixed with commit 3f74c2c. Thanks.
The use in cert-basic is correct because get_oid_desc accepst a NULL pointer.
However, some libc versions bail out on a NULL for "%s"; I fixed that too.
May 2 2016
Another problem has been fixed in 6677d8b.
I intentionally set up more hubs from computer to the device to cause an error.
When an error occurred, scdaemon continued to report "Card error", even after I
inserted the device directly to the computer.
Now, it returns "No such device" for severe errors, and scdaemon can recover
from such errors.
Apr 28 2016
The particular problem of T2306 (aheinecke on Apr 25 2016, 06:53 PM / Roundup) has been fixed in cb4fee8.
I think that it was not always reproducible because it depends on timing (only
when it detected an error at bulk_in, the problem happened). I'm not sure if
the difference of old/new libusb mattered for this problem.
Apr 26 2016
libgpg-error 1.22 is out with fix. Please test.
libgpg-error 1.2.2 is out. Please test with it.
Apr 21 2016
Apr 19 2016
Thanks for the info and the patch.
I have pushed commit 4545372 to master and it will eventually go into 1.7.1.
commit d02de6c should fix that.
Use '=' for an exact match and optionally '*' for a substring match.
Apr 16 2016
Apr 15 2016
Thank you for your patch. Yes, we already located the issue is the alignment.
I think that it were good if the MTX were placed at the head. While your patch
works, it changes ABI of the lock object for existing archs, unfortunately.
I fixed the detection of Solaris in:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=f7a77c5c236ecec846de9be46703026f9b01008f
And I believe that the bug reported here had gone.
Please test current development master.
Apr 14 2016
The attached is an analysis from the Solaris/SPARC point of view.
One of the possible SPARC specific fixes:
- ./src/posix-lock-obj.h.orig Wed Apr 13 08:24:20 2016
+++ ./src/posix-lock-obj.h Wed Apr 13 08:24:25 2016
@@ -29,7 +29,7 @@
typedef struct
{
- long vers;
+ long long vers;
#if USE_POSIX_THREADS
union { pthread_mutex_t mtx;
- ./src/gen-posix-lock-obj.c.orig Wed Apr 13 08:23:59 2016
+++ ./src/gen-posix-lock-obj.c Wed Apr 13 08:24:29 2016
@@ -66,7 +66,7 @@
int i;
#endif
struct {
- long vers;
+ long long vers;
#ifdef USE_POSIX_THREADS
pthread_mutex_t mtx;
#endif
@@ -105,7 +105,7 @@
union and include a long and a pointer to a long. */ printf ("typedef struct\n" "{\n"
- " long _vers;\n"
+ " long long _vers;\n"
" union {\n" " volatile char _priv[%d];\n" "%s"
@@ -138,7 +138,7 @@
printf ("/* Dummy object - no locking available. */\n" "typedef struct\n" "{\n"
- " long _vers;\n"
+ " long long _vers;\n"
"} gpgrt_lock_t;\n" "\n" "#define GPGRT_LOCK_INITIALIZER {%d}\n",
Note, that this was not fully tested on other platforms and might need
additional changes in the header files. I did some minor tests on
Solaris amd64/SPARCv9/SPARCv7, Linux amd64/SPARCv9.
Mar 29 2016
Fixed on 2016-03-19 with commmit af9a4afb. Note that --quiet shall not suppress
all output.
(The commit you gave is wrong).
Thanks for the report. Probably fixed with commit e2c5781.
Mar 24 2016
Not easy yet, need more time to dig.
Mar 23 2016
GpgOL-1.4 which we will include in 2.3.1 will have an option dialog where you
can enable and disable S/MIME. Default in 1.4 is off.
-> Testing until 2.3.1 is released.
ping - will check tonight.
Mar 22 2016
Mar 21 2016
Mar 18 2016
Mar 17 2016
Fixed with commit 1aad5c6.
Thanks for the easy test case.
Mar 16 2016
I believe I have also seen this issue (or something very similar) on my Windows
7 64bit machine. I am running gpg 2.1.11. I hope this isn't redundant, but it
seems that I need to restart scdaemon anytime I unplug/replug my yubikey or
suspend/resume my computer.
Sometimes it doesn't recover even after restarting scdaemon. In those cases, I
am able to fix it by stopping scdaemon, removing the yubikey, starting scdaemon,
and finally reinserting the yubikey.
Mar 8 2016
I have only been pulling from .tar.gz files.
Mar 2 2016
Ibraheem very kindly tested again. However, it is still not working completely.
He writes:
It's still core dumping... Out of curiosity, I explicitly defined
'USE_DOUBLE_FOR_ALIGNMENT 1' and the checks were passing on Solaris with no more
core dumps. I guess that means they're on the right track, just have to get the
preprocessor directives right for gcc and Solaris.
Full details are in
https://mail-index.netbsd.org/pkgsrc-users/2016/03/01/msg023078.html
Mar 1 2016
Thank you for clarification. I didn't know that pkgsrc supports other
platforms. Now, I understand.
The intention is that USE_DOUBLE_FOR_ALIGNMENT for Solaris 32-bit version.
I thought that checking ILP32 worked (but not, in fact). I believe that LP64
checking works (at least with GCC).
Feb 29 2016
I'm working on pkgsrc, which is a portable packaging system origination on
NetBSD. I myself work mostly on NetBSD.
However, we have patches for non-NetBSD platforms in pkgsrc, and this patch was
worked on by the two people mentioned earlier. Since I can not test on Solaris,
I asked them to test on Solaris, and Ibraheem did that.
I hope that clears it up.
Let me clarify/confirm. Does it work on Solaris? And now do you speak for NetBSD?
My fix is specific to Solaris (no matter if it's Sparc or not). It doesn't
handle any issues for NetBSD.
I seems that Sparc GNU/Linux doesn't have this alignment issue, but (for me) it
is highly likely that sparc architecutre requires the alignment of 8-byte.
Feb 27 2016
Thank you for the patch.
I don't have the environment, but I asked the original reporter to test.
Sadly, his reply is negative, see:
https://mail-index.netbsd.org/pkgsrc-users/2016/02/27/msg023071.html
Feb 26 2016
Please test.
Feb 25 2016
I assume that this patch solved the problem. Thanks for reporting!
Feb 24 2016
Hi Neal,
Thanks for the patch, works great on the couple of keys I tried it on.
Unfortunately I'm unsure how to build OpenPGP keys with deliberately wrongly
ordered packets, so my tests are probably not exhaustive :-( But looking at
your code (from an outsider's perspective), I can't see how revocation
certificates etc would be handled differently from certificate signatures.
I found two issues though:
+ ndataa = pubkey_get_nsig (a->pubkey_algo);
+ ndatab = pubkey_get_nsig (a->pubkey_algo);
I guess it should be "b->pubkey_algo" on the second line.
Also, since the "check" command of the GnuPG prompt can modify the keyblock, it
should set "modify" accordingly:
-8<----------------------------------------------------------------------------------->8-
diff --git a/g10/keyedit.c b/g10/keyedit.c
index d7c2a4b..ede350a 100644
- a/g10/keyedit.c
+++ b/g10/keyedit.c
@@ -2190,8 +2190,9 @@ keyedit_menu (ctrl_t ctrl, const char *username, strlist_t
locusr,
break; case cmdCHECK:
- check_all_keysigs (keyblock, count_selected_uids (keyblock),
- !strcmp (arg_string, "selfsig"));
+ if (check_all_keysigs (keyblock, count_selected_uids (keyblock),
+ !strcmp (arg_string, "selfsig")))
+ modified = 1;
break; case
cmdSIGN:-8<----------------------------------------------------------------------------------->8-
I understand that by default only selfsigs are reordered for performance
reasons. May I suggest to also consider the key to sign with (for instance
specified with "--local-user")? This can be useful, otherwise in order to avoid
potential duplicates signers might have to type "check" before signing a key.
Also (repeating what we discussed about on IRC so it gets indexed on the web :-)
Due to the append-only nature of keyservers, an uploaded badly ordered key
can't be fixed on the keyserver. As a consequence, with the current algorithm
each refresh would undo fixing the packets' order and removing the duplicates.
Ideally keys would be reordered upon import, and the merge algorithm would avoid
duplicate (for instance it could assume the local copy to be properly ordered,
and not add a packet to the local copy if said packet was found elsewhere on the
keyblock).
Feb 19 2016
Feb 18 2016
Yes, that patch fixed the problem for me.
Feb 12 2016
This should be fixed in acac103. (I was able to exactly reproduce your problem
and the patch fixed it for me.) If you are able to test and it works for you,
please report back here.
Thanks!
Patch looks good, thanks!
Sorry, here it is.
I think you attached the original patch once again by mistake...
This would be final version.
If !create, we can let it return earlier.
You are right to have the check against CREATE.
I'll include that check.
Feb 10 2016
Thanks for the patch, but it still needs a small change. You don't want to
create the directory or the lock file if the user specified --no-auto-check-trustdb.
How about this patch?
Please try attached patch.
While I understand it's a regression (and it's urgent for you), I downgrade the
priority.
It will be soon in the repo.
Feb 9 2016
to be released with 1.6.5
Jan 26 2016
I commited an adjusted patch for GnuPG 2.1 (3e50236).
Jan 22 2016
Thanks. I did some modifications and also fixed an unrelated bug in the
detection of the poolname. Will go into 2.1.11.