Skip Menu |
 

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 101638
Status: open
Priority: 0/
Queue: Net-SSLeay

People
Owner: Nobody in particular
Requestors: MITHALDU [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Download (untitled) / with headers
text/plain 262b
The error message it prints is: OPENSSL_Uplink(02831000,08): no OPENSSL_Applink Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) that it can be easily fixed: https://www.openssl.org/support/faq.html#PROG2 Note the last paragraph.
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 09:02:34 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Hello, I have not been able to reproduce this yet. how did you build and install your openssl 1.0.1l? Cheers. On Tuesday, January 20, 2015 04:57:39 PM you wrote: Show quoted text
> Tue Jan 20 16:57:38 2015: Request 101638 was acted upon. > Transaction: Ticket created by MITHALDU > Queue: Net-SSLeay > Subject: On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: MITHALDU@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > > The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) that > it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 829b
Some more information: I'm running this ActivePerl: This is perl 5, version 16, subversion 3 (v5.16.3) built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2012, Larry Wall Binary build 1604 [298023] provided by ActiveState http://www.ActiveState.com Built Apr 14 2014 14:32:20 You may need to try and install a newer ActivePerl, since the dmake+gcc packages installed when cpan is first run, may be locked on older versions. To get my OpenSSL i downloaded it from here: http://slproweb.com/download/Win32OpenSSL-1_0_1L.exe Once that was installed i set the OPENSSL_PREFIX (sp) env var to point at that directory and attempted an install. If you need more information, please ask here, or poke me on irc.perl.org as Mithaldu at pretty much any time. :)
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 10:14:55 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.2k
Hi, On Wednesday, January 21, 2015 06:24:15 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > Some more information: > > I'm running this ActivePerl: > > This is perl 5, version 16, subversion 3 (v5.16.3) built for > MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more > detail) > > Copyright 1987-2012, Larry Wall > > Binary build 1604 [298023] provided by ActiveState > http://www.ActiveState.com Built Apr 14 2014 14:32:20 > > You may need to try and install a newer ActivePerl, since the dmake+gcc > packages installed when cpan is first run, may be locked on older versions. > > To get my OpenSSL i downloaded it from here: > > http://slproweb.com/download/Win32OpenSSL-1_0_1L.exe > > Once that was installed i set the OPENSSL_PREFIX (sp) env var to point at > that directory and attempted an install.
By what method did you 'attempt an install' Full transcript would help. Cheers Show quoted text
> > If you need more information, please ask here, or poke me on irc.perl.org as > Mithaldu at pretty much any time. :)
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
I simply did cpan Net::SSLeay. I'll prepare a transcript from the start.
Download (untitled) / with headers
text/plain 189b
I just realized i did not need to set the prefix for the install, maybe i misremembered that from other things. Here's a transcript: https://gist.github.com/wchristian/77942bb7fc260370ec3f
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 12:23:50 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 765b
Thanks. I can reproduce now. Alas the fix is not as simple as just #include'ing applink.c. In a perl environment, that produces lots of errors due to perls redefinitions of fget to PerlSIO_fgets etc. Ideas? Cheers. On Wednesday, January 21, 2015 07:31:00 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > I just realized i did not need to set the prefix for the install, maybe i > misremembered that from other things. > > Here's a transcript: https://gist.github.com/wchristian/77942bb7fc260370ec3f
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 753b
That's why i didn't include a patch myself. The problem is that you don't want to include it in your XS, but in the generated C code. Others have indicated that Module::Build will do the right thing if you use a key called c_source or c_sources. However with Module::Install, i have no clue and i couldn't find anyone who had. I personally tried with this: https://metacpan.org/pod/Module::Install::XSUtil However due to you having that private module in your inc dir, it's not as easy as deleting the inc dir and letting MI rebuild its stuff. You could try asking in #toolchain, or contacting the maintainer of MI, or anyone else really who actually knows how it works. I failed in finding anyone who didn't simply tell me "MI is bad, don't use it." :(
Download (untitled) / with headers
text/plain 568b
On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote: Show quoted text
> Thanks. > I can reproduce now. > > Alas the fix is not as simple as just #include'ing applink.c. > In a perl environment, that produces lots of errors due to perls > redefinitions > of fget to PerlSIO_fgets etc.
That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, that will turn off PerlHost integration. PerlHost is not something you're terribly likely to want (and it breaks a lot of external stuff), though I can't guarantee you won't without being familiar with this codebase. Leon
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Thu, 22 Jan 2015 18:13:31 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.1k
Hi Leon, thanks. That certainly works. But I cant find much info on what the side effects of #define NO_XSLOCKS might be, or even about PerlHost. Any pointers? Cheers. On Wednesday, January 21, 2015 10:33:51 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote:
> > Thanks. > > I can reproduce now. > > > > Alas the fix is not as simple as just #include'ing applink.c. > > > > In a perl environment, that produces lots of errors due to perls > > > > redefinitions > > of fget to PerlSIO_fgets etc.
> > That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, > that will turn off PerlHost integration. PerlHost is not something you're > terribly likely to want (and it breaks a lot of external stuff), though I > can't guarantee you won't without being familiar with this codebase. > > Leon
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Fri, 23 Jan 2015 08:17:53 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 1.3k
Hmmm, well I am baffled now. In testing here, I have added #define NO_XSLOCKS before XSUB.h I have added the applink.c include to SSLeay.xs. I can see its being compiled OK and I can see the resulting OPENSSL_Applink in the SSLeay.dll file (reported by dumpbin). Yet at runtime I still get "no OPENSSL_Applink" Anyone have any ideas? using Perl 5.16.1, shining light 1.0.1j, Visual Studio Express 2010 Cheers. On Wednesday, January 21, 2015 10:33:51 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > On Wed Jan 21 21:24:12 2015, mikem@airspayce.com wrote:
> > Thanks. > > I can reproduce now. > > > > Alas the fix is not as simple as just #include'ing applink.c. > > > > In a perl environment, that produces lots of errors due to perls > > > > redefinitions > > of fget to PerlSIO_fgets etc.
> > That can be turned off by #defining NO_XSLOCKS before #including XSUB.h, > that will turn off PerlHost integration. PerlHost is not something you're > terribly likely to want (and it breaks a lot of external stuff), though I > can't guarantee you won't without being familiar with this codebase. > > Leon
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 418b
The only hint i have is that this code does the relevant check: applink = (void **(*)())GetProcAddress(h, "OPENSSL_Applink"); if (applink == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no OPENSSL_Applink")); So if that error comes out, then it's highly likely that the function simply didn't get compiled in. Then again, i am not a C developer.
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sat, 24 Jan 2015 06:55:18 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Hmmm, some hints found here http://comments.gmane.org/gmane.comp.encryption.openssl.user/47487 seem to indicate that OpenSSL_Applink must be in the .exe not in the .dll. If that is so, then we are out of luck: for us the .exe is perl.exe, which we have no option to modify. Cheers. On Friday, January 23, 2015 04:16:17 AM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > The only hint i have is that this code does the relevant check: > > applink = (void **(*)())GetProcAddress(h, "OPENSSL_Applink"); > if (applink == NULL) { > apphandle = (HMODULE) - 1; > _tcscpy(msg + len, _T("no OPENSSL_Applink")); > > So if that error comes out, then it's highly likely that the function simply > didn't get compiled in. > > Then again, i am not a C developer.
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 176b
I've asked bulk88 to weigh in on this and hope he'll find the time soon. And additionally i've sent an email to the shining lights folks to see if they can help the situation.
RT-Send-CC: kmx [...] atlas.cz
Download (untitled) / with headers
text/plain 214b
kmx, roping you in because you seem to have a custom-compiled openssl for Strawberry. Do you think it would be viable to turn that into an Alien::OpenSSL module? Would you be able to share your compilation process?
Hi,

my openssl build script for MS Windows + gcc + mingw-w64 is here: https://github.com/StrawberryPerl/build-extlibs/blob/master/build.sh#L544

Basically it is built via ./Configure ... + make tests + make install_sw. The latest version (1.0.2) builds fine without any additional patches and passes all tests.

As for your Alien::OpenSSL idea:

There already exists Alien::OpenSSL, unfortunately MSWin32 does not seem to be their priority: http://matrix.cpantesters.org/?dist=Alien-OpenSSL+0.07

I used to love the Alien::* concept. As you can check I have couple of Alien::* modules under my maintenance + I have also invested significant effort to quite complicated Alien::SDL + Alien::SDL2 modules maintained by others. But things changed.

Couple of months ago I had a discussion with Chris Marshall (from PDL project) about more extensive use of Alien::* modules for detecting external libraries in PDL (mostly to make life of Windows users easier). We have even done some research and it turned out that just a very few Alien::* modules currently available on CPAN are Windows friendly (I am not far from true when I say that only my Alien::* modules do not ignore MS Windows platform).

You can go to https://metacpan.org/requires/distribution/Alien-Base?sort=%5B%5B2,1%5D%5D and check cpantesters result for each Alien::*

Many of the Alien::* modules are simply a peace of junk because the authors simply take an URL for src tarball and use UNIX build style ./configure && make install and completely ignore MS Windows (and we both know that Windows users have much harder times when trying to compile/install any external library from sources). In most cases they even do not bother to at least try to detect whether the library in question is not already installed on a Windows box.

Example (and one of the sources of my pessimistic approach):

*/ You might know about strawberry perl PDL edition (strawberry perl + many additinal libraries, mostly maths/scientific).

*/ It comes bundled with fftw3 external library in a hope that Windows users will be able to use PDL::FFTW3

*/ PDL::FFTW3 module uses Alien::FFTW3 for fftw3 detection (which does not seem bad at the first sight)

*/ but Alien::FFTW3 intentionally sends all Windows users to the hell: https://metacpan.org/source/ZOWIE/Alien-FFTW3-0.03/Build.PL#L7

*/ ok, I have fixed that; however my pull request https://github.com/drzowie/Alien-FFTW3/pull/3 got no response

Similar story with Alien::GSL.

Maybe it is only my personal perspective but I really try to do what I can on strawberry perl side to make external libraries detection as easy as possible: 1/ if necessary I bundle config scritps like freetype-config.bat gsl-config.bat etc. 2/ strawberry perl has working pkg-config; 3/ strawberry perl supports ExtUtils::PkgConfig module; 4/ strawberry perl supports PkgConfig module What else do they need to not ignore MS Windows and try at least to detect already pre-installed libraries? (for sure it is easier do: die "install a real operating system" if $^O eq 'MSWin32' )

To sum up: having truly
cross-platform Alien::OpenSSL is doable, I am just not sure whether it is worth the effort.

BTW here are couple of RTs I have submitted to improve openssl detection on MS Windows:
https://rt.cpan.org/Public/Bug/Display.html?id=56455
https://rt.cpan.org/Public/Bug/Display.html?id=84369
https://rt.cpan.org/Public/Bug/Display.html?id=77605
https://rt.cpan.org/Public/Bug/Display.html?id=84367
all of them ignored for years. What are the chances that we will manage to convince them to switch to Alien::OpenSSL?

--
kmx

P.S. sorry for spoiling this Net-SSLeay ticket with my pessimistic Alien::* thougths :)
Download (untitled) / with headers
text/plain 2.1k
On Tue Jan 20 16:57:38 2015, MITHALDU wrote: Show quoted text
> The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) > that it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
The problem is, the OpenSSL build process assumes that OpenSSL will be embedded in an application (starting EXE), not embedded in a library (DLL). The code in https://github.com/openssl/openssl/blob/master/ms/uplink.c in OPENSSL_Uplink is evil. it does "GetModuleHandle(NULL)" to get the process starting .exe's HMODULE, then scans its export table (.EXEs almost never export anything, they can't (normally) be used as DLLs) for certain magic functions that it calls. This smells like something written by a unix person "in my days son, we didn't have shared libraries, our programs directly executed Interrupt 0x80 to call the kernel" if ((h = GetModuleHandle(NULL)) == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no host application")); break; } That is unreachable code. GetModuleHandle with NULL is a series of ptr derefs "return(HMODULE) NtCurrentTeb()->Peb->ImageBaseAddress;" It will always return true unless you go mucking around in the PEB, which I will now have to do fix this very bad design by OpenSSL. OpenSSL should have offered "void RegisterApplink(applinktable * table);" instead of looking at the export table of the process starting EXE. Related commit https://github.com/openssl/openssl/commit/3fc378aa0b464d6296fbf4f0d84b66a207b3f8a2 So there are 2 ways to fix this to get existing shining light openssl. Win32::API::Callback::IATPatch to hook that GetModuleHandle call to return the XS module's HMODULE and then openssl can interrogate a DLL we control (Net::SSLeay's XS DLL) for the correct exports. Other way, from boot:, save old NtCurrentTeb()->Peb->ImageBaseAddress to perl save stack, then do NtCurrentTeb()->Peb->ImageBaseAddress = __ImageBase;// (our XS DLL's HMODULE) then do something that will tickle OPENSSL_Uplink, OPENSSL_Uplink will do its eveil thing then, when we regain control, we restore the original NtCurrentTeb()->Peb->ImageBaseAddress, Bug solved.
Download (untitled) / with headers
text/plain 2.1k
On Tue Jan 20 16:57:38 2015, MITHALDU wrote: Show quoted text
> The error message it prints is: > > OPENSSL_Uplink(02831000,08): no OPENSSL_Applink > > Stackoverflow suggests ( http://stackoverflow.com/a/22435989/145119 ) > that it can be easily fixed: > > https://www.openssl.org/support/faq.html#PROG2 > > Note the last paragraph.
The problem is, the OpenSSL build process assumes that OpenSSL will be embedded in an application (starting EXE), not embedded in a library (DLL). The code in https://github.com/openssl/openssl/blob/master/ms/uplink.c in OPENSSL_Uplink is evil. it does "GetModuleHandle(NULL)" to get the process starting .exe's HMODULE, then scans its export table (.EXEs almost never export anything, they can't (normally) be used as DLLs) for certain magic functions that it calls. This smells like something written by a unix person "in my days son, we didn't have shared libraries, our programs directly executed Interrupt 0x80 to call the kernel" if ((h = GetModuleHandle(NULL)) == NULL) { apphandle = (HMODULE) - 1; _tcscpy(msg + len, _T("no host application")); break; } That is unreachable code. GetModuleHandle with NULL is a series of ptr derefs "return(HMODULE) NtCurrentTeb()->Peb->ImageBaseAddress;" It will always return true unless you go mucking around in the PEB, which I will now have to do fix this very bad design by OpenSSL. OpenSSL should have offered "void RegisterApplink(applinktable * table);" instead of looking at the export table of the process starting EXE. Related commit https://github.com/openssl/openssl/commit/3fc378aa0b464d6296fbf4f0d84b66a207b3f8a2 So there are 2 ways to fix this to get existing shining light openssl. Win32::API::Callback::IATPatch to hook that GetModuleHandle call to return the XS module's HMODULE and then openssl can interrogate a DLL we control (Net::SSLeay's XS DLL) for the correct exports. Other way, from boot:, save old NtCurrentTeb()->Peb->ImageBaseAddress to perl save stack, then do NtCurrentTeb()->Peb->ImageBaseAddress = __ImageBase;// (our XS DLL's HMODULE) then do something that will tickle OPENSSL_Uplink, OPENSSL_Uplink will do its eveil thing then, when we regain control, we restore the original NtCurrentTeb()->Peb->ImageBaseAddress, Bug solved.
Branch that fixes the 39_pkcs12.t failures https://github.com/bulk88/netssleay/commits/master
Mike, could you review bulk's proposed fixes please? :)
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sat, 26 Sep 2015 07:04:35 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 477b
Hi, On Friday, September 25, 2015 11:41:28 AM Christian Walde via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > Mike, could you review bulk's proposed fixes please? :)
Hmmm, Im not sure Im well qualified for that :-( -- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Fri, 25 Sep 2015 23:07:28 +0200
To: MITHALDU [...] cpan.org, "Mike McCauley via RT" <bug-Net-SSLeay [...] rt.cpan.org>
From: "Christian Walde" <walde.christian [...] gmail.com>
Download (untitled) / with headers
text/plain 151b
In that case, can you maybe throw together a dev release and get it on cpan to see what the smokers say about it? -- With regards, Christian Walde
Subject: Re: [rt.cpan.org #101638] On windows t/local/39_pkcs12.t fails with OpenSSL 1.0.1l
Date: Sun, 27 Sep 2015 08:12:26 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] airspayce.com>
Download (untitled) / with headers
text/plain 3.2k
Hmmm, well I have been trying to build net-ssleay with bulk's patch against perl 15.6.1 with Windows SDK 6.1, without success. 2 main compile problems I see (details below) are: No definition of PerlSIO_fgets and friends and NtCurrentTeb is redefined. (here it seems to get one from C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\winnt.h) If that function can be got from a windows header file, why not use that one? I am also a bit nervous of the structs PEB_FREE_BLOCK and PEB. These seem to be copied from Windows somewhere, and I dont see why they are not got with a #include rather than being in SSLeay.xs. Can bulk shed any light? gory details: cl -c -IC:\OpenSSL-Win32/include -nologo -GF -W3 -MD -Zi -DNDEBUG - O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DPERL_TEXTMODE_SCRIPTS -DUSE_SITECUSTOMIZE - DPER L_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -D_USE_32BIT_TIME_T -MD - Zi -DNDEBUG -O1 -DVERSION=\"1.72\" -DXS_VERSION=\"1.72\" "-IC: \Perl\lib\CORE" SSLeay.c SSLeay.c r:\net-ssleay\trunk\applink.c(103) : error C2065: 'PerlSIO_fgets' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(103) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(104) : error C2065: 'PerlSIO_fread' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(104) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(105) : error C2065: 'PerlSIO_fwrite' : undeclared identifier r:\net-ssleay\trunk\applink.c(105) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(108) : error C2065: 'PerlSIO_fclose' : undeclared identifier r:\net-ssleay\trunk\applink.c(108) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(110) : error C2065: 'PerlSIO_fopen' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(110) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(111) : error C2065: 'PerlSIO_fseek' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(111) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(112) : error C2065: 'PerlSIO_ftell' : undeclared i dentifier r:\net-ssleay\trunk\applink.c(112) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' r:\net-ssleay\trunk\applink.c(113) : error C2065: 'PerlSIO_fflush' : undeclared identifier r:\net-ssleay\trunk\applink.c(113) : warning C4047: '=' : 'void *' differs in le vels of indirection from 'int' SSLeay.xs(371) : error C2084: function '_TEB *NtCurrentTeb(void)' already has a body C:\Program Files\Microsoft SDKs\Windows\v6.1\Include\winnt.h(13376) : se e previous definition of 'NtCurrentTeb' On Friday, September 25, 2015 05:07:45 PM Christian Walde via RT wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=101638 > > > In that case, can you maybe throw together a dev release and get it on > cpan to see what the smokers say about it?
-- Mike McCauley VK4AMM mikem@airspayce.com Airspayce Pty Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.airspayce.com Phone +61 7 5598-7474
Download (untitled) / with headers
text/plain 633b
Ran into the same test issue on Windows 7, VS2015, OpenSSL 1.0.2l, Net-SSLeay 1.88. I don't know if what I did is correct, but I was able to get past the compilation issues of the proposed patch and pass all the self tests by: * including applink.c before XSUB.h (avoids "PerlSIO_f* undeclared" problems) * replacing the entire first WIN32 block (struct definitions) with "#include <winternl.h>" and replacing the "ImageBaseAddress" references with "Reserved3[1]" I also used the applink.c from openssl's include directory instead of adding a copy in Net-SSLeay. Again, I'm not sure if everything is working, but the tests pass.
Subject: NetSSLeay_101638.patch
--- a/Makefile.PL 2020-01-21 14:20:32.000000000 -0500 +++ b/Makefile.PL 2020-01-21 14:20:32.000000000 -0500 @@ -8,7 +8,7 @@ use File::Basename (); use Symbol qw(gensym); -# Define this to one if you want to link the openssl libraries statically into +# Define this to one if you want to link the openssl libraries statically into # the Net-SSLeay loadable object on Windows my $win_link_statically = 0; @@ -76,6 +76,7 @@ }, }, }, + ($^O eq 'MSWin32' ? (FUNCLIST => ['boot_Net__SSLeay', 'OPENSSL_Applink']) : ()), ssleay(), ); --- a/SSLeay.xs 2020-01-21 14:20:32.000000000 -0500 +++ b/SSLeay.xs 2020-01-21 14:20:32.000000000 -0500 @@ -137,6 +137,10 @@ #ifdef __cplusplus extern "C" { #endif +#ifdef WIN32 +/* applink.c needs to be included before XSUB.h to avoid compilation errors */ +#include <openssl/applink.c> +#endif /* WIN32 */ #include "EXTERN.h" #include "perl.h" #include "XSUB.h" @@ -197,6 +201,10 @@ #endif #undef BLOCK +#ifdef WIN32 +#include <winternl.h> +#endif /* WIN32 */ + /* Debugging output - to enable use: * * perl Makefile.PL DEFINE=-DSHOW_XS_DEBUG @@ -1766,6 +1774,18 @@ BOOT: { +#ifdef WIN32 +/* &__ImageBase is a more efficient way to get "HINSTANCE hinstDLL" arg passed + to DllMain of this XS module, or using GetModuleHandleEx() with + GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS (<- flag is WinXP or newer only, + no Win2k) */ +# ifndef _MSC_VER +# define __ImageBase _image_base__ +# endif + extern IMAGE_DOS_HEADER __ImageBase; + PPEB peb; + void * OrigBaseAddress; +#endif MY_CXT_INIT; LIB_initialized = 0; #ifdef USE_ITHREADS @@ -1787,6 +1807,72 @@ #else PR1("BOOT:\n"); #endif +#ifdef WIN32 + peb = NtCurrentTeb()->ProcessEnvironmentBlock; + /* make sure the data under our definition of the PEB is what we want to + replace, if the PEB definition is wrong, "peb->ImageBaseAddress" + will contain random flags, or random pointers, so then abort patching */ + if(GetModuleHandle(NULL) != peb->Reserved3[1]) // ImageBaseAddress + croak("BOOT: PEB struct definition is wrong"); + OrigBaseAddress = peb->Reserved3[1]; // ImageBaseAddress + /* do the patch */ + peb->Reserved3[1] = &__ImageBase; // ImageBaseAddress + /* verify that the patch had an effect, typically DLLs live at address + 0x10000000 unless relocated or rebased, 0x10000000 looks like a flag so + the patch location might have been a false positive, and is actually + flag 0x10000000 if the PEB definition is wrong/changed in the future by + MS, so make sure that patch's effect shows in the public API + GetModuleHandle */ + if(GetModuleHandle(NULL) != (HMODULE)&__ImageBase) { + croak("BOOT: PEB patching failed, patch had no effect"); + } + { + /* do something that ultimatley calls OPENSSL_Applink to initialize + the function pointer now so we can immediatly undo the patch */ + char fn [MAX_PATH+1]; + BIO * bio; + int bio_flags; + FILE * f; + /* we know we the XS DLL exist on disk, by the sheer fact that you cant + delete a loaded in memory DLL */ + DWORD res = GetModuleFileName((HMODULE)&__ImageBase, fn, MAX_PATH+1); + if (!res || res ==MAX_PATH+1) + croak("BOOT: GetModuleFileName failed"); + f = fopen(fn, "r"); + /* if BIO_new_file is used, applink wont be called, since openssl will + use it's CRT for the rest of the BIO's life, not SSLeay.xs's CRT */ + bio = BIO_new(BIO_s_file()); + bio_flags = BIO_get_flags(bio); +#define PLSSLEAY_FLAGS_UPLINK 0x8000 /* not defined in a public header */ + /* by default, a new BIO, has BIO_FLAGS_UPLINK flag turned on, atleast + for Win32 builds, setting a FILE * may or may not clear that flag. + Since the value of BIO_FLAGS_UPLINK may change in the future, detect + if it has changed and error out if the flag isn't in a fresh BIO + object. We must have BIO_FLAGS_UPLINK turned on to force a call + to OPENSSL_Applink */ + if((bio_flags & PLSSLEAY_FLAGS_UPLINK) != PLSSLEAY_FLAGS_UPLINK) + croak("BOOT: this Win32 OpenSSL library isn't using BIO_FLAGS_UPLINK for new BIO objects"); + /* BIO_set_fp winds up calling BIO_set_fp->file_ctrl, and in file_ctrl + in "case BIO_C_SET_FILE_PTR:", openssl does some tests to guess if + the FILE * is from openssl's CRT or not, if it guesses it is from + openssl's CRT, it then turns off BIO_FLAGS_UPLINK flag, but not all + UP_* calls do this guessing, like "case BIO_CTRL_FLUSH:", so for + saftey force BIO_FLAGS_UPLINK back on, it may or may not already + have been there based on the CRT versions and guessing of origin of + the FILE *, this guarentees that an UP_* will be called in BIO_free + */ + + BIO_set_fp(bio, f, BIO_CLOSE); + BIO_set_flags(bio, PLSSLEAY_FLAGS_UPLINK); + /* OPENSSL_Applink gets called from inside BIO_free */ + BIO_free(bio); + } + /* undo the patch, the static vars inside are now set, if this isn't done + VC C debugger and VMMap will both claim SSLeay.dll is "the process" AKA + "the .exe that started the process" which is very confusing to someone + who is using these diagnostic tools */ + peb->Reserved3[1] = OrigBaseAddress; // ImageBaseAddress +#endif } void
Download (untitled) / with headers
text/plain 470b
On Tue Feb 11 21:04:53 2020, jkahrman@mathworks.com wrote: Show quoted text
> Ran into the same test issue on Windows 7, VS2015, OpenSSL 1.0.2l, > Net-SSLeay 1.88.
What Perl are you using? Strawberry does not need this, but I guess, for example, ActivePerl does. I'd like to understand better the target environment before working on this. What I already have is a Windows host where I have sucessfully compiled OpenSSL for another case. Thanks, -- Heikki Vatiainen hvn@open.com.au
Download (untitled) / with headers
text/plain 585b
I'm facing the same issue. Consider that: 1) I'm on Windows 10 x64. 2) I'm using MSVC command line tools from VS2017. 3) I compiled Perl 5.32.0 myself with this compiler, default options. 4) I compiled OpenSSL 1.1.1g myself with this compiler, default options. I attempted to build Net::SSLeay 1.88, again, same compiler. Everything compiled well, but I too get the test error: t\local\39_pkcs12.t ... OPENSSL_Uplink(00007FFD8073CD70,08): no OPENSSL_Applink I'm about to test the solution mentioned in https://rt.cpan.org/Ticket/Display.html?id=101638#txn-1884320 I'll post back.
Download (untitled) / with headers
text/plain 224b
On Fri Aug 28 01:56:40 2020, ZARABOZO wrote: Show quoted text
> I'm about to test the solution mentioned in > https://rt.cpan.org/Ticket/Display.html?id=101638#txn-1884320 > > I'll post back.
Well, it has indeed worked. All tests passed.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.