Re: [openssl-users] Building OpenSSL 1.1.0h on HPUX 11 PARISC2 64bit

Hi, > Since I can’t find any current pre-build versions of OpenSSL for this > platform, I am trying to build OpenSSL 1.1.0h with GCC 4.6.1 on HPUX 11.0. > > I’ve tried a basic ./config approach but that appears to select > hpux-parisc1_1-gcc when I want PARISC2. > > I tried building it, but

Re: [openssl-users] OpenSSL 1.1.1pre2 alpha build error: MS Windows 32 bit

On 03/01/18 01:46, Norm Green wrote: > It looks like 32 bit builds set the -WX flag (treat warnings as errors) > while the 64 bit builds don't. > > >     cl  -W3 -wd4090 -Gs0 -GF -Gy -nologo /MDd /Od -WX /Zi > /Fdossl_static /I "." /I "crypto\include" /I "include" /I >

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

> As for -lm, which symbol was undefined? > Undefined   first referenced   symbol in file fabs    test/ct_test.o >>> >>> ??? One can only wonder where does it come from. I see no fabs >>>

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

As for -lm, which symbol was undefined? >>> >>> Undefined   first referenced >>>   symbol in file >>> fabs    test/ct_test.o >> >> ??? One can only wonder where does it come from. I see no fabs >> anywhere...

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

>> As for -lm, which symbol was undefined? >> > > Undefined   first referenced >  symbol in file > fabs    test/ct_test.o ??? One can only wonder where does it come from. I see no fabs anywhere... There also was remark

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

> So testsuite is running but this is a non-optimal debug build and only > on the Fujitsu sparc and not on a baseline v9 yet. See "e_flags" in the > ELF header below which is somewhat restrictive. > >   e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ] If "somewhat restrictive"

Re: [openssl-users] OpenSSL 1.1.1pre1 fails to build on AIX 7.1

> Looks like no target .a file is passed to ar ? > > Note: OpenSSL 1.1.0 succeeds on this platform. > > > /export/localnew/RISC6000.AIX/perl-5.24.0/bin/perl -i -pe 's/^.*\|//; s/ > \/(\\.|[^ ])*//; $_ = undef if (/: *$/ || /^(#.*| *)$/); $_.="\n" unless > !defined($_) or /\R$/g;'

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

>> And "the default for all v9 architectures is -xmemalign=8s". > I'm getting confused.  Since I did not specify -xmemalign at all, And not specifying -xmemalign is equivalent of specifying 8s in 64-bit build such as one in question. > why > did the test fail with SIGBUS in the first place? 

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

> So really we could do all manner of nasty things here and watch all > manner of performance results and cool coredumps and it would be fun to > try.  However the option -xmemalign=8s will enforce "There should be no > misaligned accesses in the program". And "the default for all v9

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

> https://github.com/openssl/openssl/pull/5423 I wonder how come the problem with asn1_encode_test.c went unnoticed so far. Objects on stack are customarily aligned at pointer size, even if their declaration doesn't imply corresponding guarantee. So there are two options here: a) it's first time

Re: [openssl-users] 1.1.1 pre1 tests failing on Solaris SPARC

> Interesting comment : > > > Solaris x86 with Sun C setups >     # There used to be solaris-x86-cc target, but it was removed, >     # primarily because vendor assembler can't assemble our modules >     # with -KPIC flag. As result it, assembly support, was not even >     # available as

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

> A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully > get down to -1:5. And Mongoose will take you to ~1:2.5 (scaled to same frequency that is). Which I'd say is a fair result. Well, still could have been a bit better, but it's not unreasonable given ISA differences. Keep in

Re: [openssl-users] FW: problem with missing STDINT.H file

>> The attached text file is a snippet from attempting to install >> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when >> could not be found. > > Do you have inttypes.h instead? > > As Jeff pointed out in another email this is for uint32_t and similar > types. These get

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

> Is big number montogomery multiplication as optimized as it can be for > ARM64 as compared to X86-64 from the latest openssl github ? > We are not seeing vmull ( or pmull/pmull2) instructions in > armv8-mont.pl . > >On an ARM cortex-A72 (1GHz) and E5-2620

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

> 1. With compiler optimization disabled, OpenSSL 1.0.2d function worked > as it is. Another indication in favour of compiler bug is that it worked when you added printf. It's similar to quantum physics when by measuring you force particle to specific state. But understand me correctly. I'm not

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

>>> static inline unsigned int constant_time_msb(unsigned int a) { >>> -*return 0 - (a >> (sizeof(a) * 8 - 1));* >>> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1; >>> } >> >> >> ... Both versions >> look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 >> bits).

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

>> static inline unsigned int constant_time_msb(unsigned int a) { >> -*return 0 - (a >> (sizeof(a) * 8 - 1));* >> + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1; >> } > > > ... Both versions > look reasonable to me (ignoring the hardcoded 8 - implying a char is 8 > bits).

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

>>> C does not make such a guarantee, though recent-ish POSIX does. (This >>> system is a windows one, thought, right?) >> There are DSPs that only support 32 bit, they don't have a concept >> of 8 bit. But I think there is various code that assumes that >> char is 8 bit, and I doubt you can get

Re: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d

On 12/11/15 17:41, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> Of Andy Polyakov >> Sent: Friday, December 11, 2015 10:07 >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] CBC ciphers +

Re: [openssl-users] [openssl-dev] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken

Hi, I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work. Solaris 10 Solaris Studio 12.4 Make test log attached. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32

Re: Linking error on Soalris x86 and sparc using fips capable openssl 1.0.1h

While fips build on soalris, I am getting variour errors: Sun-Intel: FIPSLD_CC=gcc FIPSLD_LINK=g++ /unixhome/upg/Unix/SunOS/i386/OpenSource/ssl-1.0.1h/bin/fipsld -fPIC -shared -g -O2 -o libImpl.so.10.0.0 -lcrypto Text relocation remains referenced against

Re: Platform query

Does anyone want to speak up for the requirement that we continue to support BEOS (apparently B/1 and R5?), OS/2, or pre-Windows MSDOS? Minor clarification is appropriate. MSDOS is supported in single stance, namely DJGPP, which is 32-bit environment. 16-bit code was never supported by OpenSSL,

Re: Undefined reference to 'FIPS_text_start()'

Santhosh Kokala wrote: I would really appreciate, if someone helps me with this issue. Why not just think for a second? export FIPSLD_CC=g++ export CC=gcc means that it's using g++ to compile fips_premain.c. FIPSLD_CC takes precedence over CC in fipsld: CC=${FIPSLD_CC:-${CC}} export

Re: FIPS fingerprint in .data not .rodata

Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining

Re: FIPS fingerprint in .data not .rodata

Another option (but shoot it down if its bogus :-): I noticed that if I compile fipscanister.o without -fPIC, then the const variables do get placed in the (really readonly) .rodata section as desired. I thought maybe if I did that and went the static route - build libcrypto with no-shared

Re: FIPS fingerprint in .data not .rodata

Though in FIPS 2.0 there is new option that might work in this case. Besides switching to another compiler that is. Introduced to rectify situation with rodata segments not being position-independent on Win64, defining __fips_constseg might prove useful even in this situation. See if defining

Re: FIPS fingerprint in .data not .rodata

After I had gotten the extra -f options from Harvey for this platform (BSD-powerpc), Using -f[data|function]-sections options is inappropriate as they undermine the idea of capturing fipscanister code and rodata between start/end symbols. It was bad advice/idea, do *not* use those options.

Re: FIPS fingerprint in .data not .rodata

The key thing I realized is that the incore script that comes with the FIPS Object Module v2.0 tarball handles both native AND cross-compile scenarios. Even though FIPS 2.0 util/incore is capable of handling arbitrary ELF binary (native or not), it's not used in non-cross-compile/native

Re: AES-Assembler for Powerpc

The first problem was the usage of r13. On Page 3 of the PowerPC EABI spec [1], the r13 register is described as a dedicated register. So the usage of such a register is delicate. Other ABI specs are not as categorical about r2 and r13. I was told by IBM that r2 is used as TLS pointer in

Re: AES-Assembler for Powerpc

I'd suggest to move the discussion to openss-dev, as I unfortunately don't have time to follow openssl-users. I tried using the AES-assembler code for my PowerPC EABI, but everytime I start speed aes my OS crashes. The 32Bit OS is a custom one. OS crashes? Not application, but OS? The first

Re: 64 bit OpenSSL FIPS 1.2.3 with asm slow performance problems on AES

I've been having consistent performance problems with the 64 bit openssl FIPS 1.2.3 with asm on AES. The assembly code on 64 bit architectures is much slower than without assembly. Running the same tests on a 32 bit machine results with ASM being faster than no-asm, which is expected.

Re: Win32 OPENSSL_USE_APPLINK usage

I actually ended up solving it by removing all uses of BIO_new_fp() in favor of my own custom BIO that I just finished writing earlier this week. Why not BIO_new_file? Yeah, I discovered while analyzing the code that using BIO_new_file() rather than BIO_new_fp() would disengage applink,

Re: OpenSSL 0.9.8n released - it doesn't compile

This version also doesn't compile on both Suse and RedHat on the s390 z-series platform: gcc -I.. -I../.. -I../../include -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -mbackchain -DB_ENDIAN -DTERMIO -O1 -Wall -c -o md4_dgst.o md4_dgst.c md4_dgst.c: In function 'md4_block_data_order': md4_dgst.c:115:

Re: Crash in BIO_set_fp(): Windows esp SL VC9?

Aside: all 4 pairs of .lib's in lib\VC (and one in lib) are exportlibs for the one pair of DLL's, which are actually /MD but use the applink mechanism, as mentioned in the FAQ, to get the right CRT -- assuming the EXE correctly compiles applink.c, and the code you referenced does. So this

Re: exception with purify in bn_mont.c:402 (v=bn_mul_add_words(rp,np,nl,(rp[0]*n0)BN_MASK2);)

I am getting exception in crypto\bn\bn_mont.c:402 (v=bn_mul_add_words(rp,np,nl,(rp[0]*n0)BN_MASK2);) while executing with Rational purify. Does it mean that you can confirm that the program works if not executed with purify? I think bn_mul_add_words called as assembly code from

Re: openssl 0.9.8h on Solaris 10.3 amd64 blues

I compile using gcc32 with the following options: Configure solaris-x86-gcc threads no-krb5 I definitely need threads. Compilation goes through without problems but when I do a make test I get: Doing certs touch rehash.time testing... ../util/shlib_wrap.sh ./destest make[1]: ***

Re: DTLS non-compliant list (based on snapshot 20070801)

4) Handshake headers are omitted in the signature computation in both CertificateVerify and Finished messages. (RFC 4347 does not clearly state what is to be included. However, according to the TLS v1.1 (RFC 4346), it shall be the complete handshake message, starting from Handshake.msg_type.

Re: Source for entropy on Windows platforms with CryptoAPI installed

It just occurred to me that the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed (type REG_BINARY) contains the latest seeded value from everything that CryptoAPI takes into account when generating its random seed. CryptoAPI permutes it with RC4 to come up with a

Re: having both release and debug version of openssl on win32?

Actually, I have an application and a DLL. The DLL depends on the previous libraries. And I just saw the applink.c tip in the FAQ. As I don't really want to debug OpenSSL, but rather my application and my DLL, I have included applink.c in my DLL project, compiled it in Debug mode (/MDd)

Re: 0.9.8a Build Error

gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -mcpu=ultrasparc -O3 -fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DMD5_ASM -c -c -o des_enc-sparc.o des_enc-sparc.S des_enc-sparc.S: Assembler messages:

Re: Problem with OpenSSL on Solaris x86 *

Freshly installed and patched Solaris 8 x86 system # gcc -v Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.2/specs Configured with: ... Doing certs Segmentation Fault - core dumped argena.pem = .0 Segmentation Fault - core dumped Any suggestions? ./PROBLEMS, triggered gcc bugs.

Re: Binary compatibility between 0.9.7g and 0.9.7h?

I just tried to upgrade from openssl-0.9.7g to 0.9.7h and noticed that my openssh-4.2p1 server and clients now crash with segfault with the new openssl shared library! I tested this on two installations and both had this problem. We discovered similar problems caused by a change in the

Re: Binary compatibility between 0.9.7g and 0.9.7h?

Do I have to apply this to 0.9.8a too? NO. A. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager

Re: Windows BIO operation glitch

We're using the binary distributions from Shining Light for Windows compiling with Borland C++ Builder 6.0 , the source version from OpenSSL.org for Linux. Linux works peachy. ... the applink bit (which is a pain) but eventually that all seems sorted. PEM_read_X509 still crashes. ... So I

Re: s_server doesn't work with IE 6.0

I use IE 6.0 from Windows XP and Mozilla 1.7 from linux. I use openssl 0.9.8. When I start openssl s_server -key keydsa2.pem -cert certdsa2.pem -www -cipher EDH-DSS-DES-CBC3-SHA Mozilla successfully shows debug page, but IE doesn't. You should add -bugs argument to allow IE talk. In this

Re: Building the libraries with Borland Builder.

I'm a long time UNIX developer desperately trying to get OpenSSL to work on Windows with Borland Builder 6. I can't change compiler. The rest of the project needs builder, so switching to VC++ is out of the question. Keep in mind that some OpenSSL targets are 100% community supported and

Re: Building the libraries with Borland Builder.

I've downloaded the latest windows libs. They crash with this stdio linking thing. I've tried using the applink stuff to fix it and it fixes some, but not all of the places things crash. It looks like it's BIOs which are newed and then have set_fd called on them. Earlier you mentioned that your

Re: Windows BIO operation glitch

The Win32 OpenSSL Installation Project is built as follows: Visual C++ 6 SP6 w/ MASM is used to build the core DLLs and the Visual C++ libraries. Borland's IMPLIB tool is used to create libraries from the DLLs for Builder 4/5/6. As to your specific problem, I haven't been following it up

Re: relocation R_X86_64_PC32 against `OPENSSL_cpuid_setup' link failure

ld -soname libtest.so -shared -o libtest.so test.o -L/usr/src/1.3.33/openssl-0.9.8 --whole-archive -lssl -lcrypto -no-whole-archive First of all I'd recommend to use gcc -shared even to link shared objects. Not that this would remedy the R_X86_64_PC32 is no good for shared object, it's just

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

I downloaded openssl-0.9.8-stable-SNAP-20050805 and compiled it for my Windows CE platform and had a few problems. Sometimes test latest snapshot *really* means *latest*:-) 1. In the CFLAGS define, the compiler didn't like the /wd4959. It said it was unrecognized and refused to go further.

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

Steven, I've put a new wcecompat.zip up at essemer.com.au which includes ENOMEM and EAGAIN. The remainder of the problems need to be corrected in OpenSSL. Do you number wcecompat releases? I mean I'd like to mention some reference point in INSTALL.WCE, e.g. at least version x.y or

Re: openssl-0.9.8-stable-SNAP-20050805 on WinCE5.0

3. In bf_skey, memcpy was undefined, Will look into it... Looked into it and it didn't make any sense. Required header file is included so it shouldn't be a problem... Strangely enough there're a number of files calling memcpy, which are compiled prior bf_skey.c, so how come it gets angry

Re: What's the state of WinCE support in Openssl-0.9.8?

As for the source of randomness, it looks like the 0.9.8 release makes the appropriate set of WinCE calls to generate randomness. In crypto/rand/rand_win.c, there is a call to CryptAcquireContext and then CryptGenRandom. I assume these are working correctly. There was a bug in source code,

Re: Openssl 0.9.8 compilation options

I'd like to compile Openssl 0.9.8 on Solaris 10. If I strictly use the default options, whole thing is a success. Now I want to use openssl for mod_ssl and apache. According to mod_ssl's documentation, mod_ssl (v2.8.23-1.3.33) recommends to use the following option to compile openssl ./config

Re: Openssl 0.9.8 compilation options

I'd like to compile Openssl 0.9.8 on Solaris 10. If I strictly use the default options, whole thing is a success. Now I want to use openssl for mod_ssl and apache. According to mod_ssl's documentation, mod_ssl (v2.8.23-1.3.33) recommends to use the following option to compile openssl ./config

Re: Link Errors building CGI on Win32

I have developed a CGI that uses OpenSSL and it is building fine using 0.9.7e. Following the release of 0.9.8 I tried rebuilding with the new release. However, I am getting the following link errors: libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol [EMAIL PROTECTED]

Re: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86

I have another question on this build, config puts in -march=i486 but, shouldn't we be using -march=pentium The reason I ask is I see a lot of files that appear to be specific for the Pentium or later CPU - will these execute on a 80486? Yes, they will. -586 is legacy suffix and denotes

Re: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86

# ./Configure solaris-x86-gcc zlib shared -L/usr/local/lib gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D _REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=i48 6 -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -D

Re: Compilation of openssl-0.9.8-stable-SNAP-20050624 fails on Solaris 2.5.1 x86

gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHA VE_DLFCN_H -O3 -fomit-frame-pointer -march=i486 -Wall -DL_ENDIAN -DOPENSS L_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DSHA1_ASM -DMD5_ASM -DRMD160 _ASM -DAES_ASM -c -o x86cpuid-elf.o x86cpuid-elf.s Assembler: x86cpuid.s

Re: [Openvpn-users] Re: OpenSSL / OpenVPN / Padlock anomaly with small blocks of data.

Try attached patch. Also works fine. Attached the patch for openssl-0.9.7's padlock extension - yours seems to be an openssl-0.9.8 patch. Great, thanks! Andy, I guess you'll commit the change to OpenSSL CVS. Naturally! I apologize for the delay though:-) BTW, I also prototyped mnemonics in

Re: [Openvpn-users] Re: OpenSSL / OpenVPN / Padlock anomaly with small blocks of data.

padlock_verify_context() does pushfl but IIRC sometimes *skips* over popfl to avoid unnecessary key reload. Apparently it is not 100% accurate. Try attached patch. Originally I did padlock_reload_key() on each padlock_aes_cipher() call and I still believe it is not an unacceptable overhead ;-) ACE

Re: Problem with 0.9.7 SNAPSHOT 20041229

gcc -DMONOLITH -I.. -I../include -fPIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -g -O3 -Wall -DPERL5 -DL_ENDIAN -O3 -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -g -c apps.c apps.c: In function `load_cert': apps.c:734: `err' redeclared as different

Re: OpenSSL 0.9.8 pre-release

Configuring for bsdi-elf-gcc ... asm/s512sse2-elf.s: Assembler messages: asm/s512sse2-elf.s:26: Error: no such 386 instruction: `movdqu (%edx),%xmm0' You need up-to-date assembler to compile SSE2-enabled modules available in 0.9.8. I know nothing about bsdi, but it seems to be common that

Re: OpenSSL Newbie---help

2) If you were to attempt acceleration where do you get the most bang for your proverbial buck; just doing the encryption/decryption or doing the entire SSL on a card ? The encryption is where you'd get the "bang for the buck." ??? One wants to accelerate a server, right? And what does