Re: pkgin from 8.0/amd64 -> "SSL support disabled"?

[Havard Eidnes <he%NetBSD.org@localhost>]

> On 12/08/2020 11:50, Havard Eidnes wrote:
>>    https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/8.0/All
>> you end up with a pkgin which is built with a libfetch which is *not*
>> build with the openssl option.  How that happened I have no further
>> insight into, I'm afraid.
>
> This is because to have anything SSL in 8.x now you have to use pkgsrc
> SSL which means that a fully static pkgin would have to include a
> static version of openssl (which might well increase the size a lot).

Well, as far as I can see, if I build pkgin on 8.1, I get dynamic
linking with pkgsrc openssl, but openssl/buildlink3.mk insists on
openssl>=1.1.1, so the in-tree openssl is apparently a no-go for pkgin
itself.

Not saying you're not right about the general rule about use of
OpenSSL in pkgsrc, but ... pkgin with SSL on 8.0 did work before with
the in-tree OpenSSL, so why can't it continue to work until 8.x is
formally retired?  To my eyes it doesn't look like libfetch makes
"advanced" usage of features which are only available in newer
versions of OpenSSL.

On 8.1, PKG_SUGGESTED_OPTIONS ends up as "inet6" only, but if I put

PKG_OPTIONS.libfetch=inet6 openssl

in /etc/mk.conf, libfetch still builds without problems, and is built
with -DWITH_SSL.

However, as noted above, pkgin builds with pkgsrc openssl, and I get
link conflicts and dependency on two libcrypto's on 8.x:

  CCLD     pkgin
ld: warning: libcrypto.so.12, needed by /usr/lib/libarchive.so, may conflict with libcrypto.so.1.1
ld: warning: libcrypto.so.12, needed by /usr/lib/libarchive.so, may conflict with libcrypto.so.1.1

and ldd says

work/pkgin-20.5.1/pkgin:
        -larchive.4 => /usr/lib/libarchive.so.4
        -lbz2.1 => /usr/lib/libbz2.so.1
        -lc.12 => /usr/lib/libc.so.12
        -lcrypto.12 => /usr/lib/libcrypto.so.12
        -lcrypt.1 => /lib/libcrypt.so.1
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
        -lexpat.2 => /usr/lib/libexpat.so.2
        -llzma.2 => /usr/lib/liblzma.so.2
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lz.1 => /usr/lib/libz.so.1
        -lssl.1.1 => /usr/pkg/lib/libssl.so.1.1
        -lcrypto.1.1 => /usr/pkg/lib/libcrypto.so.1.1
        -lsqlite3.1 => /usr/lib/libsqlite3.so.1

This cause for this is probably not libfetch's "special" build...

The resulting executable is at least able to do an "update" via SSL,
but you're not supposed to have two dynamic -lcrypto libraries
linked...


Operationally, I was quite peeved that I got struck at this dead end;
it's like someone planted a land mine to go off whenever anyone dared
to update their binary packages on 8.x.  It's not as if we do not
support 8.x; it's 7.x which got an extension and is due for retirement.


>> Thus, if you rely on using "pkgin" and have a strong preference for
>> fetching the packages using https, you will find yourself at a dead
>> end (which is pretty terrible).
>> To recover from this, you will need to rebuild and re-install libfetch
>> using pksrc, and then rebuild and re-install pkgin.  In libfetch you
>> can do "make show-var VARNAME=PKG_SUGGESTED_OPTIONS" to make sure
>> "openssl" is among the suggested options.
>
> Would a manual install of the 9.0 pkgin from the CDN using pkg_install
> fix this wihtout requiring rebuild?

That would also work, yes.  (I've followed my own route, but the
pkgin I got from the 9.0 build works as expected.)

Regards,

- Håvard