Hi Dennis
Yes, 10-main.conf is modified for both the versions.
Following are changes.
<<< file 1:
/view/rdl117_linuxx86_64/vobs_tools/src/openssl-1.1.1b/Configurations/10-main.conf@
@/main/1
>>> file 2: 10-main.conf
********************************
-----[16 changed to 16]-----
< ASFLAGS => "/nologo /Zi",
---
> ASFLAGS => "/nologo",
-----[44 changed to 44]-----
< ASFLAGS => "/nologo /Zi",
---
> ASFLAGS => "/nologo",
-----[211 changed to 211]-----
< ex_libs => add("-lsocket -lnsl -ldl"),
---
> ex_libs => add("-lsocket -lnsl -ldl -lm -lrt"),
-----[1226 changed to 1226]-----
< lib_cflags => add("/Zi /Fdossl_static.pdb"),
---
> lib_cflags => add("/Fdossl_static.pdb"),
-----[1228-1229 changed to 1228-1229]-----
< dso_cflags => "/Zi /Fddso.pdb",
< bin_cflags => "/Zi /Fdapp.pdb",
---
> dso_cflags => "/Fddso.pdb",
> bin_cflags => "/Fdapp.pdb",
The error is coming for OPENSSL_sk_new_null which is changed in 1.1.1b
compared to 1.1.1 with https://github.com/openssl/openssl/pull/7721.
Can this be related ?
Thanks and Regards,
Ram Krushna
On Wed, Mar 27, 2019 at 4:07 PM <openssl-users-requ...@openssl.org> wrote:
> Send openssl-users mailing list submissions to
> openssl-users@openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
> openssl-users-requ...@openssl.org
>
> You can reach the person managing the list at
> openssl-users-ow...@openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
> 1. Re: Internal IP Exposed (Kyle Hamilton)
> 2. Re: Reg solaris support for openssl 1.1.1b (ramakrushna mishra)
> 3. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
> 4. Re: Building OpenSSL 1.1.1b for WinCE700 (???? (Souju TANAKA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Mar 2019 22:09:31 -0500
> From: Kyle Hamilton <aerow...@gmail.com>
> To: Abdul Qoyyuum <aqoyy...@cardaccess.com.au>
> Cc: openssl-users <openssl-users@openssl.org>
> Subject: Re: Internal IP Exposed
> Message-ID:
> <CAPMEXDY1UVrXFrfFJbFq=
> 34rhm-wdvz2yonr2ds+3l9uzz9...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> That's a configuration issue with the servers, not an issue with the
> openssl command itself.
>
> There's no information on what the back-end HTTP server software is
> being used. If it were Apache, there would be a ServerName directive
> that could change the server's idea of what name it should refer to
> itself as. I don't have information on other server software
> configuration.
>
> -Kyle H
>
> On Sun, Mar 24, 2019 at 7:34 PM Abdul Qoyyuum
> <aqoyy...@cardaccess.com.au> wrote:
> >
> > Hi all,
> >
> > New to the mailing list and a complete newbie to openssl and the likes.
> There's a ticket by a client that I'm new at and he claims that there's a
> security problem with the openssl command to his servers.
> >
> > Internal IP exposed after running a openssl (version 1.1.0j) connect
> command:
> >
> > openssl s_client -connect 103.XX.XXX.XX:10443 -quiet
> >
> > Where 103.XX.XXX.XX is a Public IP. And after it shows the certificates,
> typed the following:
> >
> > GET /images HTTP/1.0
> >
> > And hit enter twice, the following gets displayed:
> >
> > HTTP/1.0 301 Moved Permanently
> > Date: Mon, 25 Mar 2019 00:10:13 GMT
> > Server: xxxxxxxx-xxxxx
> > Location: https://10.240.123.1:10443/images/
> > Connection: close
> > Content-Type: text/html; charset=utf-8
> > X-Frame-Options: SAMEORIGIN
> > Content-Security-Policy: frame-ancestors 'self'
> > X-XSS-Protection: 1; mode=block
> > X-Content-Type-Options: nosniff
> > Strict-Transport-Security: max-age=28800
> >
> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> > <HTML><HEAD>
> > <TITLE>301 Moved Permanently</TITLE>
> > </HEAD><BODY>
> > <H1>Moved Permanently</H1>
> > The document has moved <A HREF="https://10.240.123.1:10443/images/
> ">here</A>.<P>
> > </BODY></HTML>
> > read:errno=0
> >
> > The 10.240.123.1 is an internal IP and it is exposed by this little
> method. Although not shown when using curl -kv -O command.
> >
> > Is there a way to cover up the "Location" or at least the internal IP
> from being exposed? Thanks.
> >
> > Sorry if this isn't clear or if this is the wrong place to ask this.
> >
> > --
> > Abdul Qoyyuum Bin Haji Abdul Kadir
> > HP No: +673 720 8043
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Mar 2019 10:08:12 +0530
> From: ramakrushna mishra <rama.krush...@gmail.com>
> To: openssl-users@openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID:
> <CAHgr=
> k+nbgaw735roc+aqbfw4b7vxcyi7o6vsqdqn6_7xy4...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> > Hi All,
> >
>
> Thanks for your responses.
> I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> version".
> I followed the same procedure for openssl 1.1.1b and when I run "openssl
> version" seeing the mentioned error. i.e
> "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> OPENSSL_sk_new_null: referenced symbol not found
> Killed
> ".
>
> So, How come it works with openssl 1.1.1 and not with 1.1.1b.
> I am using the same machine and same procedure to configure and install it.
> So, Is there anything different that need to be done for 1.1.1b version ?
>
> Thanks and Regards,
> Ram Krushna
>
>
> >
> > On Sat, Mar 16, 2019 at 6:20 AM <openssl-users-requ...@openssl.org>
> wrote:
> >
> >> Send openssl-users mailing list submissions to
> >> openssl-users@openssl.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >> https://mta.openssl.org/mailman/listinfo/openssl-users
> >> or, via email, send a message with subject or body 'help' to
> >> openssl-users-requ...@openssl.org
> >>
> >> You can reach the person managing the list at
> >> openssl-users-ow...@openssl.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of openssl-users digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >> 1. Re: Reg solaris support for openssl 1.1.1b (Jakob Bohm)
> >> 5. Re: Reg solaris support for openssl 1.1.1b (Dennis Clarke)
> >>
> >>
> >> ----------------------------------------------------------------------
> >>
> >> Message: 1
> >> Date: Fri, 15 Mar 2019 18:19:53 +0100
> >> From: Jakob Bohm <jb-open...@wisemo.com>
> >> To: openssl-users@openssl.org
> >> Subject: Re: Reg solaris support for openssl 1.1.1b
> >> Message-ID: <649ef06e-0f64-65bb-cb43-cfde681fd...@wisemo.com>
> >> Content-Type: text/plain; charset=utf-8; format=flowed
> >>
> >> On 15/03/2019 14:33, Dennis Clarke wrote:
> >> > On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >> >> My guess is that your binary is loading the system's shared
> libraries.
> >> >> To find out whether this is the case, try
> >> >>
> >> >> ??? ldd bin/openssl
> >> >>
> >> >> If my assumption is correct, you might have to set the
> LD_LIBRARY_PATH
> >> >> explicitely.
> >> > Actually LD_LIBRARY_PATH is evil.
> >> >
> >> > The correct way to do this is to compile with a RUNPATH set in the
> >> > output ELF files.
> >> LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> >> testing
> >> a newly compiled binary before installing the libraries to their final
> >> locations, perhaps
> >> on the same, perhaps on another machine.
> >>
> >> P.S.
> >> I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> >> RUNPATH as
> >> presumed by the above answer.
> >>
> >> Enjoy
> >>
> >> Jakob
> >> --
> >> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
> >> Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10
> >> This public discussion message is non-binding and may contain errors.
> >> WiseMo - Remote Service Management for PCs, Phones and Embedded
> >>
> >>
> >>
> >> ------------------------------
> >> Message: 5
> >> Date: Fri, 15 Mar 2019 20:49:30 -0400
> >> From: Dennis Clarke <dcla...@blastwave.org>
> >> To: openssl-users@openssl.org
> >> Subject: Re: Reg solaris support for openssl 1.1.1b
> >> Message-ID: <4b08232c-f734-987c-814c-5acef59f4...@blastwave.org>
> >> Content-Type: text/plain; charset=utf-8
> >>
> >> On 3/15/19 1:19 PM, Jakob Bohm via openssl-users wrote:
> >> > On 15/03/2019 14:33, Dennis Clarke wrote:
> >> >> On 3/15/19 5:38 AM, Matthias St. Pierre wrote:
> >> >>> My guess is that your binary is loading the system's shared
> libraries.
> >> >>> To find out whether this is the case, try
> >> >>>
> >> >>> ???? ldd bin/openssl
> >> >>>
> >> >>> If my assumption is correct, you might have to set the
> LD_LIBRARY_PATH
> >> >>> explicitely.
> >> >> Actually LD_LIBRARY_PATH is evil.
> >> >>
> >> >> The correct way to do this is to compile with a RUNPATH set in the
> >> >> output ELF files.
> >> > LD_LIBRARY_PATH overriding the compiled in RUNPATH is appropriate when
> >> > testing
> >> > a newly compiled binary before installing the libraries to their final
> >> > locations, perhaps
> >> > on the same, perhaps on another machine.
> >> >
> >> > P.S.
> >> > I don't known if the Solaris loader lets LD_LIBRARY_PATH override
> >> > RUNPATH as
> >> > presumed by the above answer.
> >>
> >> Yes it certainly does. Otherwise testing a new custom lib would be a
> >> royal pain as opposed to just a pain. Also most people still, after
> >> twenty years, know what LD_LIBRARY_PATH env var is for and it is a waste
> >> of breath trying to explain it after decades of watching folks skewer
> >> themselves over and over and over ....
> >>
> >> dc
> >>
> >>
> >>
> >> ------------------------------
> >>
> >> Subject: Digest Footer
> >>
> >> _______________________________________________
> >> openssl-users mailing list
> >> openssl-users@openssl.org
> >> https://mta.openssl.org/mailman/listinfo/openssl-users
> >>
> >>
> >> ------------------------------
> >>
> >> End of openssl-users Digest, Vol 52, Issue 19
> >> *********************************************
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20190326/09253e6e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 26 Mar 2019 02:55:38 -0400
> From: Dennis Clarke <dcla...@blastwave.org>
> To: openssl-users@openssl.org
> Subject: Re: Reg solaris support for openssl 1.1.1b
> Message-ID: <4c02f69c-512b-d5c8-67a2-eebe6e3f3...@blastwave.org>
> Content-Type: text/plain; charset=utf-8
>
> On 3/26/19 12:38 AM, ramakrushna mishra wrote:
> > Hi All,
> >
> >
> > Thanks for your responses.?
> > I am able to build openssl 1.1.1 on my solaris and able to run "openssl
> > version".
> > I followed the same procedure for openssl 1.1.1b and when I run "openssl
> > version"? seeing the mentioned error. i.e?
> > "ld.so.1: openssl: fatal: relocation error: file openssl: symbol
> > OPENSSL_sk_new_null: referenced symbol not found
>
> Did you modify Configurations/10-main.conf ?
>
>
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 27 Mar 2019 19:33:44 +0900
> From: ???? (Souju TANAKA) <sojuli...@gmail.com>
> To: openssl-users@openssl.org
> Subject: Re: Building OpenSSL 1.1.1b for WinCE700
> Message-ID:
> <
> capvkbatrzbmqyamhfijs9wbgct_s7zk_jvitu1sia35-pfl...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> It works with our custommized cURL code.
> I wrote a detailed build instruction for CE.
> https://qiita.com/souju/items/94117c024862f57459c3
>
> > It would be good if you created a github PR for this so the changes can
> be
> > considered for inclusion.
>
> Thank you. I post the PR.
> https://github.com/openssl/openssl/pull/8596
>
> Regards,
> Souju TANAKA
>
>
> 2019?3?19?(?) 18:39 Matt Caswell <m...@openssl.org>:
>
> >
> >
> > On 19/03/2019 07:08, ???? wrote:
> > > Hello,
> > >
> > > I have successfully build OpenSSL 1.1.1b (only libraries, no app) for
> > > WINCE700-ARMV4I, though I don't do any tests. Here is what I did. I
> hope
> > > original sources will be changed so as there is no need to change.
> >
> > It would be good if you created a github PR for this so the changes can
> be
> > considered for inclusion.
> >
> > Matt
> >
> >
> > >
> > > 1. Modify wcecompat.
> > >
> > > Add an alias, "_access" for access() in wcecompat io.h as below.
> > > --
> > > #define access _wceaccess
> > > #define _access _wceaccess
> > > --
> > >
> > > 2. Set Environmental variables
> > >
> > > set OSVERSION=WCE700
> > > set PLATFORM=VC-CE
> > > set TARGETCPU=ARMV4I
> > > set WCECOMPAT=C:\Users\dev\tanaka\wcecompat
> > > set LIB=C:\Program Files (x86)\Microsoft Visual Studio
> > > 9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows CE
> > > Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I;C:\Program Files\Microsoft
> > > SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio
> > > 9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio
> > 9.0\VC\lib
> > > set INCLUDE=C:\Program Files (x86)\Windows CE
> > > Tools\SDKs\YOUR_SDK_NAME\Include\ARMV4I;C:\Program Files
> (x86)\Microsoft
> > Visual
> > > Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual
> > Studio
> > > 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
> > > set Path=C:\WINCE700\sdk\bin\i386\arm;C:\Program Files (x86)\Microsoft
> > Visual
> > > Studio 9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio
> > > 9.0\VC\VCPackages;C:\Program Files\Microsoft
> > >
> >
> SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
> > > Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;C:\Program Files
> > > (x86)\Microsoft Visual Studio 9.0\VC\BIN;%Path%
> > > set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio
> > > 9.0\VC\ATLMFC\LIB;"C:\Program Files (x86)\Windows CE
> > > Tools\SDKs\YOUR_SDK_NAME\Lib\ARMV4I";C:\Program Files (x86)\Microsoft
> > Visual
> > > Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio
> > > 9.0\VC\ce\lib\ARMV4I;
> > >
> > > 3. Configure
> > >
> > > (for ARM)(Configurations/windows-makefile.tmpl) Delete a line of
> > "setargv.obj".
> > > setargv.obj in C:\Program Files (x86)\Microsoft Visual Studio
> 9.0\VC\lib
> > is for
> > > x86 and cannot be linked with ARM objs.
> > >
> > > C:\Strawberry\perl\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm
> > no-ssl3
> > > no-stdio no-async no-engine VC-CE
> > >
> > > Using full path to specify Strawberry perl. I recommend Strawberry perl
> > here to
> > > avoid error messages, I used 5.24.4.1-32bit.
> > >
> > > I added 3 options of "no-stdio" and "no-engine", "no-async". Because..
> > > * no-stdio: GetStdHandle() and STD_INPUT_HANDLE cannot be used in
> > WinCE. (used
> > > in apps\apps.c)
> > > * no-engine: Lack of CreatePipe() in WinCE (used in
> engines\e_dasync.c)
> > > * no-async: Lack of ConvertFiberToThread() in WinCE (used in
> > > crypto\async\arch\async_win.c)
> > > By "no-stdio" option, we build only libraries. No command line
> > application are
> > > generated.
> > >
> > > 4. Modify "makefile"
> > >
> > > * Add -D_MSC_VER=1300 in "CFLAGS="
> > > * In "CNF_CPPFLAGS=", change -I"\$(WCECOMPAT)/include" to
> > -I$(WCECOMPAT)/include
> > > * Change CNF_EX_LIBS=3 to CNF_EX_LIBS=ws2.lib crypt32.lib
> kernel32.lib
> > > $(WCECOMPAT)\lib\wcecompat.lib $(WCECOMPAT)\lib\wcecompatex.lib
> > corelibc.lib
> > > coredll.lib
> > >
> > > 5. Modify C Source
> > >
> > > Comment out a line of "# define stat _stat" in
> > > crypto\conf\conf_def.c
> > > crypto\rand\randfile.c
> > > crypto\store\loader_file.c
> > > Comment out a line of "# define fstat _fstat" in
> > crypto\rand\randfile.c.
> > >
> > > (crypt/init.c 167l and 777l) For lack of GetModuleHandleEx() in CE,
> > Change "#
> > > ifdef DSO_WIN32" to "# if defined(DSO_WIN32) && !defined(_WIN32_WCE)"
> > > -----------------
> > > # ifdef DSO_WIN32
> > > {
> > > HMODULE handle = NULL;
> > > BOOL ret;
> > >
> > > /* We don't use the DSO route for WIN32 because there is a
> > better way */
> > > ret = GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
> > > -----------------
> > >
> > > (crypto\rand\randfile.c 257l) For lack of GetEnvironmentVariableW() in
> > CE,
> > > Change "#if defined(_WIN32) && defined(CP_UTF8)" to "#if
> defined(_WIN32)
> > &&
> > > defined(CP_UTF8) && !defined(_WIN32_WCE)"
> > >
> > > (for ARM)(include\internal\refcount.h)
> > > * Add "#include <winbase.h>" for InterlockedExchangeAdd().
> > > * (106l) In function CRYPTO_UP_REF() and CRYPTO_DOWN_REF(), change 2
> > > "_InterlockedExchangeAdd()" to be "InterlockedExchangeAdd()". There is
> no
> > > _InterlockedExchangeAdd() for non x86 in C:\Program Files (x86)\Windows
> > CE
> > > Tools\SDKs\YOUR_SDK_NAME\Include\Armv4i\winbase.h.
> > >
> > > (crypt/threads_win.c 27l) For lack of
> > InitializeCriticalSectionAndSpinCount() in
> > > CE, change
> > > ------------------
> > > /* 0x400 is the spin count value suggested in the documentation */
> > > if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
> > > OPENSSL_free(lock);
> > > return NULL;
> > > }
> > > ------------------
> > > to
> > > ------------------
> > > #ifndef _WIN32_WCE
> > > /* 0x400 is the spin count value suggested in the documentation */
> > > if (!InitializeCriticalSectionAndSpinCount(lock, 0x400)) {
> > > OPENSSL_free(lock);
> > > return NULL;
> > > }
> > > #else
> > > InitializeCriticalSection(lock);
> > > #endif
> > > ------------------
> > >
> > > 6. Build
> > >
> > > nmake
> > >
> > > Then we will get the following artifacts.
> > > libcrypto.lib
> > > libcrypto-1_1.dll
> > > libcrypto-1_1.pdb
> > > libssl.lib
> > > libssl-1_1.dll
> > > libssl-1_1.pdb
> > >
> > > Regards,
> > > Soju TANAKA
> > >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20190327/9585737c/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openssl-users mailing list
> openssl-users@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> End of openssl-users Digest, Vol 52, Issue 41
> *********************************************
>
