Closing due to compiler error.
May 16 2019
Dec 11 2018
Sep 21 2017
Jul 6 2017
I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:
Jul 5 2017
With an integer overflow.
This is a standard dynamic sized array:
Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).
At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.
Maybe casting to a void* helps to disable the check in the compiler.
I can replicate the issue on my system.
It is not the line 681, actually.
Jul 4 2017
I think that the problem is in your usage with your tool. Please have a look at md_open function in cipher/md.c.
This bug is not the one in libgcrypt, but in the compiler.
Same argument can apply to MD5. See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int' of SHA2.
See T3248: mpiutil.c:501:37: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' for unsigned integer overflow.
It is intentionally used.
And in the C programming language, it is defined that unsigned integer never overflows (it is computed as modulo 2).
Jun 8 2017
Hello. Please note that this is a bug tracker and not a support forum. Nevertheless, let's investigate.
May 5 2017
May 3 2017
Mar 30 2017
Dec 9 2015
The keyserver preferences are major privacy problem. They should not be used
and in fact they are ignored in Tor mode. Thus we should not put too much work
in fixing this wish.
Dec 8 2015
Now that we have a dirmngr daemon, this should be feasible. I plan to implement
it like this:
Add two flags to the KS_GET command, --enqueue and --drain-queue. --enqueue
merely enqueues the key id and returns immediately, unless --drain-queue is
This will also help us address issue #1827.
May 11 2015
Nov 21 2014
0.9.6 will be release today, thus I close it.
Nov 19 2014
It's not crashing for me with master but its not fixed.
I acidentally ran into this while checking out a windows crash and found the cause:
echo $GPG_AGENT_INFO /run/user/1000/keyring-Lvs93w/gpg:0:1
At least this was my problem and as "Ubuntu" is the platform it is likely that
this was the original problem.
I've commented in the launchpad report.
Nov 7 2014
This is likely fixed in 0.9.5 release Sep 1.
Nov 6 2014
Feb 21 2011
Please provide a proper test case which is independent of the
distribution. Do not report distribution specific problems to an
upstream package. Thanks.
Dec 18 2010
Jun 18 2010
This has already been fixed in the trunk. I just backported it to 1.4 and 2.0.
(svn rev 5361).
Jun 17 2010
Dec 10 2009
That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.
Dec 8 2009
From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).
Sep 3 2009
Jul 20 2009
Done for 2.0 in svn r5082; will also be packaged with gnupg 1.4.10.
We can't print an error message because that would let gpg treturn with an error
code and lead to problesm with scripts which assume the current way of doing
things. A warning is possible but Unix tools generally don't do that.
Jul 17 2009
Jul 13 2009
Fixed in SVN. Thanks.
Jul 10 2009
Jul 9 2009
The first part is not easy to fix and would require quite some rework. I don't
think this is justified.
May 12 2009
Forget the second part. It prints this message only, if it indeed needs input
and giving --yes works in this case too. So there was a fault on my side.
May 11 2009
Maybe we misunderstood(?). The gpg-agent is not used.
I don't want to decided whether thisis a bug. The thing is that using gpg with
gpg-agent is more of a temporary solution than something we want to work as
clean as possible. For such use cases it is better to use gpg2.
May 9 2009
Sep 1 2008
No, we don't want to do that. If you do not like this use the option: