Re: [openssl-dev] [openssl.org #4606] BUG: Windows Startup Code in OpenSSL RAND_poll() Is Ineffective

[Joey Yandle via RT]

This is fixed in 1.1.

On Jul 5, 2016 11:29 AM, "Noel Carboni via RT"  wrote:

> This message is to the OpenSSL source code maintainers via
> r...@openssl.org:
>
> I reported this a while back and no one has seen fit to fix it.
>
> On Windows, the RAND_poll() function in the OpenSSL library uses ancient
> Heap32First and Heap32Next function calls to enumerate heap entries from
> all processes, because presumably this is considered to be a good source
> of entropy.
>
> Unfortunately, these specific methods, because of things that have been
> changed in Windows since the original design of the OpenSSL library, are
> now so tremendously inefficient that you are actually getting nearly
> zero entropy, as well as wasting a huge amount of computer time.
>
> We're measuring the time to get to the VERY FIRST check of the MAXDELAY
> operation - i.e., exactly ONE heap block has been read - as over one
> half second, and that's on a fast machine!
>
> The reason is described clearly here:
>
> https://blogs.msdn.microsoft.com/oldnewthing/20120323-00/?p=8023
>
> In short, on a Windows 7 or newer system OpenSSL is spending a full
> second before the timeout occurs gathering one or maybe a very few heap
> blocks to contribute a few bytes of entropy to the random seed.
>
> What that article says is that the Heap32First and Heap32Next are NO
> LONGER VALID FUNCTIONS on Windows to be used for the purpose of
> gathering entropy!  You're not really walking many entries at all and
> thus you are not getting the entropy you think you are.
>
> Various software packages use your library and expect it to initialize
> its own random seed effectively, which it is NOT doing.  Instead, it's
> spending a full second spinning Windows' wheels behind the scenes and
> quite possibly even disrupting other operations, for ALMOST NO BENEFIT
> in entropy gathering.  I cannot stress this enough.
>
> If you believe this should be worked-around by seeding the library
> directly, or by building an alternate copy of the library oneself,
> please bear this in mind:
>
> Not everyone who ultimately uses OpenSSL has control over how OpenSSL is
> being initialized.
>
> Imagine, for example, that the OpenSSL library is embedded in another,
> higher-level library, and that the product using the higher-level
> library has NO DIRECT EXPOSURE to OpenSSL.  This, in fact, is the case
> with our own software.  Every startup of our software, which we expect
> to be interactive, takes MUCH longer than it should - a significant
> portion of one second - because of this bug.
>
> Also, if you think that the MAXDELAY parameter should be shortened, that
> is not valid either.  You should understand that even the first check of
> that timeout is delayed by a significant portion of a second!
>
> This needs to be fixed!
> -Noel Carboni
> ProDigital Software
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4606
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr

[Joey Yandle via RT]

Looking over your logs, you appear to be configuring with no-asm, then
calling do_ms.  Does it work when you configure with asm and call do_nasm?

The do_ms target doesn't get much attention these days.
On Jun 12, 2016 5:56 AM, "Simon Richter via RT"  wrote:

> Hi,
>
> the 1.0.2 branch fails to compile in the VC-WIN32 configuration:
>
> mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr
>
> Full log available at
>
>
> http://ci.kicad-pcb.org/job/windows-openssl-msvc/cpu=x86,label=windows/376/consoleFull
>
>Simon
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

> In the makefile created by Perl, the linker binary name is assigned to a 
> variable named LINK. This variable $(LINK) is called to execute the linker 
> call.
> This causes a serious collision with the MS Visual Studio build system which 
> also relies on a variable named LINK:

Are you invoking msbuild.exe to build openssl?  The supported build 
instructions use nmake.exe directly on the generated makefiles.

What is your build invocation?

cheers,

Joey


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

https://github.com/openssl/openssl/pull/620


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #2275] CVS HEAD: BIO b_sock: ioctl(FIONBIO) is not available everywhere; completed BIO_socket_nbio() so the #ifdef clutter in apps/* and other spots can be discarded aft

[Joey Yandle via RT]

> Anyone interested in looking at this and porting it to master?

Looks pretty easy, I'll do it.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

I verified the problem on both 1.0.2f and master:

set LINK=/DEBUG
perl Configure VC-WIN64A
ms\do_win64a.bat
nmake -f ms\nt.make

 link /nologo /subsystem:console /opt:ref /debug 
/out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp
LINK : fatal error LNK1181: cannot open input file 'link.obj'
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 12.0\VC\BIN\amd64\link.EXE"' : return code '0x49d'


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

[Joey Yandle via RT]

> And verify attached diff and report back.

The diff works perfectly on master, but exposed a new bug (bare 
snprintf).  The following patch fixes it.  I can make a PR (or add it to 
my existing PR #512) if you'd like.

diff --git a/test/ssltest.c b/test/ssltest.c
index 5d6700e..9cd2a53 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -1890,7 +1890,7 @@ int doit_localhost(SSL *s_ssl, SSL *c_ssl, int 
family, long count,
  if (BIO_do_accept(acpt) <= 0)
  goto err;

-snprintf(addr_str, sizeof(addr_str), ":%s", BIO_get_accept_port(acpt));
+BIO_snprintf(addr_str, sizeof(addr_str), ":%s", 
BIO_get_accept_port(acpt));

  client = BIO_new_connect(addr_str);
  BIO_set_conn_ip_family(client, family);


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3914] Library on Windows does not export SSL_CTX_set_options or SSL_set_options

[Joey Yandle via RT]

 I was kind of surprised to learn this... The SSL library on Windows
 does not export SSL_CTX_set_options or SSL_set_options.

That's because it's a macro:

grep -r SSL_CTX_set_options | grep define

ssl/ssl.h:# define SSL_CTX_set_options(ctx,op) \


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3735] [bug] Openssl transitive dependency to libexplain (minor)

[Joey Yandle via RT]

 Tardy is referenced in the openssl Makefile tar rule, which is there
 the dependency manifests.

 Surely you build your packages from the release tar balls? That means
 that this rule is never used.


Many package managers (including debian's, depending on the mode in 
which it is run) will unpack a tarball, run 'make dist' on it, and then 
build the resulting tarball.  In those cases, tardy is properly a build 
dependency.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev