Please ask any Unix sysadmin for help. Paid support is available from the companies listed here: https://gnupg.org/service.html and there are lot of others.

Hi Werner,

The platform is illumos, a fork of OpenSolaris.

No response.

Thanks for the update, any fix for above issues not able make and make install

I don't know. We only provide binary packages for Windows.

could you tell me how to download direct binary pkg which we can directly install for solaris 10

below also failed to make .

HI Werner,

No, it's not. It still misses "-O" entirely.

It's solved!

getting same error with 1.7 version also.

Could you please help me on this, any fix do you have for this kind of issue.

not able to apply given patch in my unix box, please find the below output.

Could you please provide me the dyñamic library path to set my profile Solaris 10 command

On Sat, 29 Jul 2017 15:12, noreply@dev.gnupg.org said:

could you please guide me order to install below libraries and I will update you once I apply that patch .

Also could you please guide me the order to install these libraries to solaris box.
I am installing as below order:
npth-1.5
libgpg-error-1.27.tar
libgcrypt-1.8.0.tar
libassuan-2.4.3.tar
libksba-1.3.5.tar
gnupg-2.1.21.tar

You can apply this patch by first navigating to libgcrypt-1.8 path and then giving following command (you need 'patch' tool to be installed):

please guide me how to add this patch in solaris 10 os version

In libgcrypt, _gcry_md_extract has different return type in gcrypt-int.h than in md.c. Does attached patch solve the problem?

URL | name ]]URL | name ]]Hi Werner,

Please provide information on how you build this. That is invocation of configure and make and best attsch the created config.log.

The fixed sed expression still does not work correctly; it misses the plain "-O" form of the option. As per gcc docs, -O is the same as -O1, and clang accepts it (and the build falls over with it) even though it does not document it at all.

The warning is just a warning, so no problem. The pragma even indicates the compiler for which it is intended.

According to this, setting LD is not sufficient to make gcc use a different linker.

https://patents.stackexchange.com/questions/5766/is-an-expired-patent-in-the-public-domain

I found US patent which is expired due to fee: https://patents.google.com/patent/US7080109B2/en
The technique is described in : https://koclab.cs.ucsb.edu/docs/koc/j56.pdf
This is related paper: https://koclab.cs.ucsb.edu/docs/koc/j47.pdf

Intel has patent application for folding technique for Montgomery reduction: US8392494
which is described in this paper: https://www.cse.buffalo.edu/srds2009/escs2009_submission_Gopal.pdf

Ah, ok, thanks for the info!

Likely fixed by commit a4d1595a2638db63ac4c73e722c8ba95fdd85ff7 (rijndael-aesni: split assembly block to ease register pressure) in 1.7 branch (and included in 1.7.3+).

I am closing this, because this particular change was rejected. Eventually libtool might get updated on its own merits, so no need to track this here.

Compiler bug. Probably misdetection of aesni support in old AMD processors?

Intel has patent application for folding technique for Barret reduction: US20070297601
and it is granted as: US8229109

The part of using Simultaneous Multiple Exponentiation (SME) for RSA is not patented, I think.
So, let me consider with SME.

Another area would be faster (constant time) Barrett reduction.

In search of algorithm, I found this slide:
http://www1.spms.ntu.edu.sg/~ccrg/documents/chienning-multiexponentiation.pdf

I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:

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.

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 T3245: cipher-gcm-intel-pclmul.c:418:17: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long').

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).

See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int'.

No way to test on El Capitain anymore. It works on Sierra.

With the new rndjent as used with libgcrypt 1.8 under Windows rhis can be claimed as finished.

@werner Is it clearer now if gcryptrnd will be removed or ported?

If we will ever do this, then only in conjunction with appropriate continuous integration tools that report on new warnings and progress. Closing here.

and the platform is ...

The version of libtool that you ship does not have the necessary patches required to support my platform. Normally this isn't a problem because autogen.sh (or autoreconf) will update it.

You may not run your own version of libtool or libtoolize. Only the maintainer updates the autotools related files including libtool. This is to avoid bugs stemming from different or broken versions of autotools. This makes it much easier to reproduce bugs.

Applied in rCe0958debe1a7: secmem: Fix SEGV and stat calculation..

Here is a test case:

I had an older version of libgcrypt (1.6.5) in my /usr/local/bin. I removed that version, ran the make check again, and this time got a fail again for random: image not found. I continued the installation, and libgcrypt-1.7.6 successfully (it appears, anyway!) installed.

Patch applied and pushed.