<div dir="auto">Hi!! <div>I want to unsubscribe. </div><div><br></div><div><br><br></div></div><div style="line-height:1.5"><br><br>-------- Original message --------<br>From: openssl-users-request@openssl.org<br>Date: Mon, Jan 27, 2020, 7:20 PM<br>To: openssl-users@openssl.org<br>Subject: openssl-users Digest, Vol 62, Issue 6<br><blockquote>Send openssl-users mailing list submissions to<br>  openssl-users@openssl.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>        https://mta.openssl.org/mailman/listinfo/openssl-users<br>or, via email, send a message with subject or body 'help' to<br>  openssl-users-request@openssl.org<br><br>You can reach the person managing the list at<br>    openssl-users-owner@openssl.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of openssl-users digest..."<br><br><br>Today's Topics:<br><br>   1. Thanks for Encoding Clarification (Douglas Morris)<br>   2. What option is not recognized by OpenSSL 1.1.1d? (Jeffrey Walton)<br>   3. Re: What option is not recognized by OpenSSL 1.1.1d?<br>      (Matt Caswell)<br>   4. Determine that there is no forward progress with non blocking<br>      SSL socket (Eran Borovik)<br>   5. Decryption slower in 1.1.1 branch? (Dan Heinz)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Sun, 26 Jan 2020 04:58:42 +0000 (UTC)<br>From: Douglas Morris <dougbmorris@yahoo.com><br>To: "openssl-users@openssl.org" <openssl-users@openssl.org><br>Subject: Thanks for Encoding Clarification<br>Message-ID: <791238297.11590163.1580014722271@mail.yahoo.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Viktor,<br>Thanks for meticulously answering my questions. I know the file name encoding is not necessarily the file content encoding. If a Python program were on a Windows computer, it might show a file name encoding of UTC-16, which would make UTC-16 a good guess for what openssl <subcommand> -text would output as bytes to be converted (the way what I'm doing works with Python's subprocess module). That was my conjectural thinking and a heuristic I though might be useful. I could get the name of the operating system from Python and map that to a 'native' encoding I suppose, but that's too much work for dubious gain. I'm not testing on Windows. It is enough to know that there is no easy and obvious way to accommodate -text bytes on various OSes, supposing they would be different. Maybe there is no difference. I expect think there should be on older WIndows and Apple OSes. Yes, I could be wrong. I'll just go with what I knowledge I have, accept the uncertainty, and concentrate on the OS that I'<br> m using, which is Linux. I could always extract public key parameters and expiration dates from the OS-consistent PEM form, not that I want to try.<br><br>So DER is binary and PEM is ASCII text (which means utf-8 and not utf-16). Going by RFC 1421 via herongyang.com, the MS line breaks are a nice touch. I got the info I need to program something and troubleshoot any encoding problems from -text output bytes that might arise. I can see that 'openssl req -in <csr> -outform DER' outputs bytes that are not to be changed. I suppose the same is true of -outform PEM. That's good to know because I was 'fixing' the received certificate (in PEM I believe) by normalizing line breaks to '\n' and then trusting Python's universal newlines mode to write out the big string in a variable to a file with the native OS-line-break encoding. I think I'll just write out the raw bytes as received. Funny, but I ran openssl x509 -text on the one test/staging certificate I saved to file only hours ago, and with the aforesaid 'normalization', and it displayed correctly. I know that doesn't prove that such treatment for a real certificate will work correctly for t<br> he Web server when the time comes, but my program is coming along and I know a little more about what's going on.<br><br>Thanks.<br><br>Douglas Morris<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200126/a3e03903/attachment-0001.html><br><br>------------------------------<br><br>Message: 2<br>Date: Sun, 26 Jan 2020 16:03:50 -0500<br>From: Jeffrey Walton <noloader@gmail.com><br>To: OpenSSL Users <openssl-users@openssl.org><br>Subject: What option is not recognized by OpenSSL 1.1.1d?<br>Message-ID:<br>  <CAH8yC8k2s3=OFjOQ=MzNUsJpyJVQmMrg8UrqXbPwVeq9vo-ZDw@mail.gmail.com><br>Content-Type: text/plain; charset="UTF-8"<br><br>I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.<br><br>Configure is dying:<br><br>    ***** Unsupported options: no-comp<br>--prefix=/home/jwalton/tmp/build-test<br>--libdir=/home/jwalton/tmp/build-test/lib<br><br>According to INSTALL at<br>https://github.com/openssl/openssl/blob/master/INSTALL, all the<br>options are supported.<br><br>Which option is not recognized by OpenSSL 1.1.1d?<br><br>Thanks in advance.<br><br><br>------------------------------<br><br>Message: 3<br>Date: Mon, 27 Jan 2020 08:40:59 +0000<br>From: Matt Caswell <matt@openssl.org><br>To: openssl-users@openssl.org<br>Subject: Re: What option is not recognized by OpenSSL 1.1.1d?<br>Message-ID: <8a3bdb62-5ef6-3fd4-2cb0-108d5b0ebdbb@openssl.org><br>Content-Type: text/plain; charset=utf-8<br><br><br><br>On 26/01/2020 21:03, Jeffrey Walton wrote:<br>> I'm trying to convert some scripts from OpenSSL 1.0.2 to OpenSSL 1.1.1d.<br>> <br>> Configure is dying:<br>> <br>>     ***** Unsupported options: no-comp<br>> --prefix=/home/jwalton/tmp/build-test<br>> --libdir=/home/jwalton/tmp/build-test/lib<br>> <br>> According to INSTALL at<br>> https://github.com/openssl/openssl/blob/master/INSTALL, all the<br>> options are supported.<br>> <br>> Which option is not recognized by OpenSSL 1.1.1d?<br><br><br>That is strange:<br><br><br>>     ***** Unsupported options: no-comp<br><br>"no-comp" *is* supported in 1.1.1! E.g<br><br>$ perl Configure linux-x86_64 no-comp<br>Configuring OpenSSL version 1.1.1e-dev (0x10101050L) for linux-x86_64<br>Using os-specific seed configuration<br>Creating configdata.pm<br>Creating Makefile<br><br>**********************************************************************<br>***                                                                ***<br>***   OpenSSL has been successfully configured                     ***<br>***                                                                ***<br>***   If you encounter a problem while building, please open an    ***<br>***   issue on GitHub <https://github.com/openssl/openssl/issues>  ***<br>***   and include the output from the following command:           ***<br>***                                                                ***<br>***       perl configdata.pm --dump                                ***<br>***                                                                ***<br>***   (If you are new to OpenSSL, you might want to consult the    ***<br>***   'Troubleshooting' section in the INSTALL file first)         ***<br>***                                                                ***<br>**********************************************************************<br><br>What was your full "Configure" line? I don't recall there being any<br>options that we removed in 1.1.x compared to 1.0.2...or if we did we<br>made them no-ops or something.<br><br>Matt<br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Mon, 27 Jan 2020 16:06:36 +0200<br>From: Eran Borovik <eran.borovik@gmail.com><br>To: openssl-users@openssl.org<br>Subject: Determine that there is no forward progress with non blocking<br>       SSL socket<br>Message-ID:<br>       <CAEiHZPQAZ-kjGH7jc=rBSwdYRdW3P9TGe4Dyb2_1BmjMQ74eug@mail.gmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi all,<br>My application is using non-blocking sockets to send and receive data. To<br>avoid issues, my code guarantees that a specific socket is always owned by<br>a specific thread, thus preventing any issues or races from concurrently<br>running send and receive at the same time on the same socket.<br>I've read thoroughly the lists regarding the best way to use non blocking<br>sockets with SSL. The common wisdom I gathered was:<br>-It is allowed to interleave SSL_read and SSL_write, meaning that SSL_read<br>doesn't have to complete successfully before issuing SSL_write( this makes<br>sense otherwise full-duplex doesn't work).<br>-SSL socket has a global state. So return value from one call negates a<br>previous return value from other call.<br><br>My question is how to determine that forward progress isn't possible and to<br>return to epoll.<br>Suppose I have a main-loop that deals with all the pending receives and<br>sends for a specific socket. For simplicity, assume that I try to<br>SSL_receive until I get some kind of an error (WANT_READ or WANT_WRITE).<br>Then I try to issue SSL_send until I get error as well, but if I read<br>correctly the group, the new error negates previous errors so prior<br>receives must be retried.<br>When do I stop? what is the best way to actually determine there can be no<br>more forward progress both on the send and the receive side, and epoll must<br>be used?<br><br>I can think on the following "algorithm" but  I am not sure if it makes<br>sense:<br>-Receive until you get an Error X.<br>-Send. If I receive a return value that isn't X, it means receive will have<br>to be retried. If I immediately receive a return value that is X, it means<br>that no more progress is possible and I need to wait with epoll.<br><br>Problem with the above algorithm, is that I am afraid that if the send<br>buffer is full and there is nothing to receive, I will keep getting<br>WANT_READ for receive, and WANT_WRITE for send until actual data arrives or<br>can be sent which defeats the purpose of epoll.<br><br>I've been banging my head here for several days. Any help here will be much<br>appreciated.<br><br>Thx,<br>Eran<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/c105e845/attachment-0001.html><br><br>------------------------------<br><br>Message: 5<br>Date: Mon, 27 Jan 2020 18:20:27 +0000<br>From: Dan Heinz <dheinz@softwarekey.com><br>To: "openssl-users@openssl.org" <openssl-users@openssl.org><br>Subject: Decryption slower in 1.1.1 branch?<br>Message-ID:<br>  <BN7PR06MB6401619418224C14BB46571AD90B0@BN7PR06MB6401.namprd06.prod.outlook.com><br>        <br>Content-Type: text/plain; charset="us-ascii"<br><br>I upgraded a library that used OpenSSL 1.0.2 to the OpenSSL 1.1.1d.  On Windows, I have found that the time to decrypt had doubled.<br>After a bit of timestamp logging, I found the RSA_private_decrypt function is taking twice as long with 1.1.1d as it did with 1.0.2t.  This is being called from a Windows 64-bit DLL.<br><br>For example, decrypting 8680 bytes of data averages about .3 seconds with the OpenSSL 1.0.2t library (statically linked).  Decrypting the same data with the OpenSSL 1.1.1d library averages about .6 seconds.<br>I'm wondering if perhaps my build configuration is incorrect or missing something for the 1.1.1d build.  Here are the configuration parameters for the 64-bit build:<br>Configure VC-WIN64A --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-asm no-idea no-mdc2 no-rc5 no-ssl2 no-ssl3 no-zlib no-comp no-pinshared<br><br>I logged things granular enough to see the speed difference was in RSA_private_decrypt, but I'm not sure why it is so much slower with 1.1.1d.  Any help or ideas would be appreciated!<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/086f8561/attachment.html><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>openssl-users mailing list<br>openssl-users@openssl.org<br>https://mta.openssl.org/mailman/listinfo/openssl-users<br><br><br>------------------------------<br><br>End of openssl-users Digest, Vol 62, Issue 6<br>********************************************<br></blockquote></div>