Do you see the same stack trace when simply using the random number generator: ./openssl rand 64 What if you simply use SHA1: ./openssl sha1 <somefile> On 04/14/2015 12:17 PM, John Unsworth wrote: > > Is no-one interested at all about this problem? Or do I need to send > it to another place? > > > > Regards, > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Unsworth > *Sent:* 10 April 2015 14:54 > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is > broken > > > > I have compiled 1.0.1m in the same way and that works fine using asm. > > > > John. > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *John Unsworth > *Sent:* 10 April 2015 12:21 > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken > > > > I have an application that runs quite happily using OpenSSL 1.0.1h on > Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause > problems. > > > > 1 When building 1.0.2 using > > > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 > -xldscope=hidden > > > > openssl s_client crashes on start: > > > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > > Segmentation Fault (core dumped) > > -bash-3.00$ pstack core > > core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 > > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, > 44) + 8 > > 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 > > 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c > > 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 > > 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 > > 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 > > 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 > > 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 > > 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 > > > > 2 So I then rebuilt adding no-asm flag. It manages to connect but > negotiation fails with an error: > > > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad > record mac:s3_pkt.c:1456:SSL alert number 20 > > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: > > > > This is against the server that is still running 1.0.1h and can be > successfully connected with openssl built with 1.0.1h. > > > > Note that the 64 bit build seems to work perfectly. Unfortunately for > historical reasons we need to use the 32 bit version. > > > > The 32 bit builds that we use on Windows and Linux also work > perfectly. Is it something to do with byte order? > > > > Regards, > > John. > > > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150415/fcf997c2/attachment.html>
