OpenSSL version 3.3.0 published

[Neil Horman]

Glad its working a bit better for you.  If you are inclined, please feel
free to open a PR with your changes for review.

Best
Neil


On Thu, May 16, 2024 at 7:40 AM Dennis Clarke <dclarke at blastwave.org> wrote:

> On 5/15/24 18:34, Neil Horman wrote:
> > You are correct, the files you reference (most of them in fact) get built
> > into separate objects in the event the build flags are different for
> shared
> > and static libraries, and should be unrelated to the issue you are seeing
> >
>
>      I was somewhat puzzled by this also. Yes.
>
> > As for the undefined symbols, thats definitely a mystery.  most notably,
> > the symbols referenced are internal.  That is to say they shouldn't be
> > exported in the symbol table for libssl.so (though a quick look with
> > objectdump shows they are, which may be a separate issue)
> >
> > Looking at the sources, I can see what _might_ be happening
> >
> > cert_comp_tests.c includes "../ssl/ssl_local.h"
> > if quic is enabled (i.e. OPENSSL_NO_QUIC is undefined), ssl_local.h
> > includes quic/quic_local.h
> > quic_local.h includes internal/quic_txp.h
> > quic_txp.h includes internal/quic_stream_map.h
> > quic_stream_map.h defines a static inline function
> > named ossl_quic_stream_recv_get_final_size which calls
> > ossl_quic_rxfc_get_final_size, which in turn
> > calls ossl_quic_rxfc_get_final_size
> >
> > I'm guessing the other symbols have simmilar patterns.
> >
>
>      I am still digging into the issue.
>      I thank you the thoughtful reply.
>
>
> > As to why its happening my first guess would be that more recent
> compilers
> > like gcc and clang do lazy symbol resolution, only resolving a
> subordonate
> > symbol, when its calling parent is found to be used.  Given
> > ossl_quic_stream_recv_get_final_size isn't called anywhere in
> > comp_stream_test.c, the compiler disposes of the symbol prior to any need
> > to resolve its called symbols, and so everything is ok.
> >
>
>      I also suspect a linker issue here and the sad fact is that the GNU
>   ld just will not suffice in this server. C'est la vie ici.
>
>
> > conversely (again, I'm guessing here) the solaris 5.10 compiler likely
> take
> > a more bulldozer-ish approach, leaving everything in the object file and
> > only stripping symbols after all resolutions are complete, leading to the
> > missing symbols error, despite its not being needed.
> >
>
>      I have to laugh at the "bulldozer" idea as you are likely quite
> correct there.
>
>
> > As to what to do about this...I'm unsure.  The quick hack I would imagine
> > would be to move the definition of ossl_quic_stream_recv_get_final_size
> > into a c file (likely quic_stream_map.c) and just declare a prototype in
> > the quic_stream_map.h header, so as to avoid the unneeded symbol
> > resolution.  You would have to lather rinse  repeat with the other
> missing
> > symbols of course.
> >
> > As to your prior question about how long the ability to support SunOS
> will
> > last, well, unfortunately I don't think any of us can say.  I believe the
> > platoform you are building on is on our unadpoted platform list:
> > https://www.openssl.org/policies/general-supplemental/platforms.html
> >
> > And while we endeavor to keep openssl building on as many platforms as
> > possible, its not feasible to cover all the currently
> > unmaintained platforms.  You do have some agency here however. If you are
> > willing and interested, you could volunteer to be a community platform
> > maintainer for your target platform.  This would entail you building
> > openssl on your adopted platform, and running the test suite routinely,
> > reporting bugs and fixing errors as they occur.  Its not a small amount
> of
> > work, but it would be a significant contribution toward ensuring that
> > openssl stays viable on the targets you need.
> >
> I can tell you that this morning I see :
>
> .
> .
> .
> All tests successful.
> Files=312, Tests=3182, 6714 wallclock secs (25.22 usr  3.10 sys +
> 6370.32 cusr 170.55 csys = 6569.19 CPU)
> Result: PASS
> `test' is up to date.
>
> hubble $ pwd
> /opt/bw/build/openssl-3.3.0_SunOS_5.10_SPARC64.005
>
> hubble $
> hubble $ psrinfo -pv
> The physical processor has 8 virtual processors (0-7)
>    SPARC64-VII+ (portid 1024 impl 0x7 ver 0xa1 clock 2860 MHz)
> hubble $
> hubble $ uname -a
> SunOS hubble 5.10 Generic_150400-67 sun4u sparc SUNW,SPARC-Enterprise
> hubble $
>
> hubble $ hash -r
> hubble $ which openssl
> /opt/bw/bin/openssl
> hubble $
>
> hubble $ ldd /opt/bw/bin/openssl
>          libssl.so.3 =>   /opt/bw/lib/libssl.so.3
>          libcrypto.so.3 =>        /opt/bw/lib/libcrypto.so.3
>          libsocket.so.1 =>        /lib/64/libsocket.so.1
>          libnsl.so.1 =>   /lib/64/libnsl.so.1
>          libdl.so.1 =>    /lib/64/libdl.so.1
>          librt.so.1 =>    /lib/64/librt.so.1
>          libstatomic.so.1 =>      /opt/bw/lib/libstatomic.so.1
>          libc.so.1 =>     /lib/64/libc.so.1
>          libmp.so.2 =>    /lib/64/libmp.so.2
>          libmd.so.1 =>    /lib/64/libmd.so.1
>          libscf.so.1 =>   /lib/64/libscf.so.1
>          libaio.so.1 =>   /lib/64/libaio.so.1
>          libdoor.so.1 =>  /lib/64/libdoor.so.1
>          libuutil.so.1 =>         /lib/64/libuutil.so.1
>          libgen.so.1 =>   /lib/64/libgen.so.1
>          libm.so.2 =>     /lib/64/libm.so.2
>          /lib/sparcv9/../libm/sparcv9/libm_hwcap1.so.2
>          /platform/SUNW,SPARC-Enterprise/lib/sparcv9/libc_psr.so.1
> hubble $ /opt/bw/bin/openssl version
> OpenSSL 3.3.0 9 Apr 2024 (Library: OpenSSL 3.3.0 9 Apr 2024)
> hubble $
>
> Which seems to work like a charm and I do have a few patches.
>
> What I would like to do is climb in and see what can be done to create a
> pure ISO 9899:1990 clean code path. May be reduced in features but would
> still work pretty much everywhere. Maybe.
>
> Sure do wish I had my old Oracle support contract to update this server
> a bit but they want a LOT of money for that.
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20240516/9218b0be/attachment.htm>