Re: [Trustedqsl-testing] OpenSSL 3.0.0

[Rick M. <k1...@ar...>]

The function causing the problem here is "tqsl_ssl_error_is_nofile()".
It is intended to determine if an error in the SSL libraries was
caused because of a failure to open a file.

The "ERR_GET_LIB(l) == ERR_LIB_SYS" stanza means "did this error occur when
calling the system libraries?"
and the "ERR_GET_FUNC(l) == SYS_F_OPEN" means "did this error occur from an
fopen() call?"

If OpenSSL isn't going to return the function detail, then this entire
section should be deleted and fall back on the second check.
        if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT)
                return 1;

I'll map the first check out for OpenSSL > 3.0

As far as the libraries are concerned, I will be happy to take a fix that
works across all Linux distributions.  I think what's been happening here
is changes being made based on the last distribution to complain, which
isn't ideal.
73,
    -Rick


On Sun, Dec 5, 2021 at 11:37 AM Richard Shaw <hob...@gm...> wrote:

> On Sun, Dec 5, 2021 at 9:35 AM Greg Troxel <gd...@le...> wrote:
>
>>
>> Richard Shaw <hob...@gm...> writes:
>>
>> > On Sun, Dec 5, 2021 at 8:56 AM Greg Troxel <gd...@le...> wrote:
>> >
>> >>
>> >> Richard Shaw <hob...@gm...> writes:
>> >>
>> >> > Index: tqsl-2.5.9/src/openssl_cert.cpp
>> >> > ===================================================================
>> >> > --- tqsl-2.5.9.orig/src/openssl_cert.cpp
>> >> > +++ tqsl-2.5.9/src/openssl_cert.cpp
>> >> > @@ -4285,7 +4285,7 @@ static int
>> >> >  tqsl_ssl_error_is_nofile() {
>> >> >   unsigned long l = ERR_peek_error();
>> >> >   if (tQSL_Error == TQSL_OPENSSL_ERROR &&
>> >> > - ERR_GET_LIB(l) == ERR_LIB_SYS && ERR_GET_FUNC(l) == SYS_F_FOPEN)
>> >> > + ERR_GET_LIB(l) == ERR_LIB_SYS == SYS_F_FOPEN)
>> >> >   return 1;
>> >> >   if (tQSL_Error == TQSL_SYSTEM_ERROR && tQSL_Errno == ENOENT)
>> >> >   return 1;
>> >>
>> >> Did you also meen to remove " == SYS_F_FOPEN"?
>> >>
>> >> Is there really no semantics change from this?  (It seems sensible to
>> >> adjust, but I am not entirely following.
>> >
>> > Should it be removed? I only really hack at C/C++ code.
>>
>> I am surprised it builds and I'm not sure what it does.
>>
>> Basically
>>
>>   && ERR_GET_FUNC(l) == SYS_F_FOPEN
>>
>> is a logical and an equality test.   So dropping the entire test could
>> make sense and your + line would then be
>>
>> >> > + ERR_GET_LIB(l) == ERR_LIB_SYS)
>>
>> but I don't understand what this did, and how one should try to do the
>> same thing in the 3.0.0 world.
>>
>
> Fixed in my patch, unfortunately I can't answer the last part...
>
>
> (It strikes me as aggressive to be moving to 3.0.0, but those are tough
>> calls, and surely beyond your control..)
>>
>
> Well Fedora tends to be leading edge... Latest kernels, latest GCC, latest
> python (currently testing 3.11 alpha) etc.  Someone has to be first, right?
>
> There's also some additional deprecated functions in OpenSSL 3  if you
> want to get ahead of it.
>
>
> https://kojipkgs.fedoraproject.org//packages/trustedqsl/2.5.9/1.fc36/data/logs/x86_64/build.log
>
> Just search on "deprecated:"
>
> Here's the porting guide:
>
> https://www.openssl.org/docs/manmaster/man7/migration_guide.html
>
>
> >> > I also have patches I maintain to clean up rpath/lib install location
>> and
>> >> > to provide a soversion for the tqsl library (required by Fedora).
>> >>
>> >> I'd be interested to see the rpath/lib patch.  pkgsrc norms are to have
>> >> RPATH of /usr/pkg/lib set in /usr/pkg/foo as /usr/pkg (or whatever) is
>> >> not in the default search path.  I know that various packaging systems
>> >> have very different rpath rules, and I think that leads to a need to be
>> >> able to configure the build for the varying environments.
>> >
>> > As long as you're installing into system library locations (which we
>> are)
>> > they're already in the library search path so RPATH isn't needed, in
>> fact
>> > as a packager I have to remove RPATH in these situations.
>>
>> Yes, but we are installing not into the system library path and thus we
>> need to set RPATH.  This is the basic difference between systems that
>> have "base system" and then "packages" and systems that have "single
>> base system but many things are optional".  The first is the traditional
>> UNIX approach, and the second the GNU/Linux approach.
>>
>> Even on GNU/Linux, if someone builds tqsl themselves with
>> prefix=/home/johndoe/HAM, then RPATH is needed and should happen.  So
>> it's really a special case that if libdir is /usr/lib then RPATH should
>> be skippped, and in general it should be included.
>>
>> > So I guess maybe the first step would be to wrap some conditionals
>> around
>> > the current logic so it's only used when needed.
>> >
>> > Here's my rpath/install patch:
>> >
>> >
>> https://src.fedoraproject.org/rpms/trustedqsl/blob/rawhide/f/tqsl-2.5-rpath.patch
>> >
>> > The first part just roto-rooters the RPATH stuff from
>> apps/CMakeLists.txt
>> > since I don't need it. Probably not acceptable as is :)
>>
>> Indeed, that is not acceptable as it breaks many other systems.  My
>> impression is that CMake already has the concept of whether RPATH should
>> be set or not and there are cmake-time config arguments to say which way
>> it should be.  I would say aligning to that is the standard approach.
>>
>
> Yes, so I guess the question is why was that code once needed? Or are
> there corner cases?
>
>
> > The 2nd part should be more interesting to you. Here I replace all the
>> > logic and replace it with the GNUInstallDirs module which will set all
>> the
>> > CMAKE_INSTALL_... variables correctly for Linux systems since RPM and
>> DEB
>> > based systems handle this very differently. This probably should be
>> wrapped
>> > in an "IF(LINUX)" conditional.
>>
>> If it's only for GNU/Linux systems, yes, but GNUInstallDirs seems like
>> the right approach in general.  pkgsrc path norms are basically
>> inherited from autoconf and thus from the GNU coding standards, with
>> some adjustments to be similar to the BSD hier(7), but all of that
>> mostly is a common history from the 80s.
>>
>> As for "libsuffix", my view is that that standard libdir is $prefix/lib,
>> and systems that use lib64 are unusual and it's ok to expect them to be
>> configured wtih cmake libsuffix=64 or whatever, but if there's a way to
>> query if the current system is like that and do it automatically, that's
>> ok.
>>
>
> As far as I know lib64 is used on all RPM based systems (certainly Fedora,
> RHEL, OpenSUSE) that support multi-arch which allows use of 32-bit
> libraries on 64-bit systems.
>
>
> Does the Fedora world use lib64 on x86_64, or just lib?  I have the
>> impression that lib64 happens on Debian.
>>
>
> No Debian uses a /lib/<multiarch-tuple> type arrangement.
>
> https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
>
> Thanks,
> Richard
> KF5OIM
> _______________________________________________
> Trustedqsl-testing mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedqsl-testing
>


-- 
Rick Murphy, D.Sc., CISSP-ISSAP, K1MU/4, Annandale VA USA