Re: SSL configured wrong for DragonFly. How can it be fixed?

[John Marino <netbsd%marino.st@localhost>]

On 11/25/2016 01:56, Jonathan Perkin wrote:
> * On 2016-11-25 at 00:03 GMT, John Marino wrote:
>
> > pkgsrc assumes OpenSSL base at /usr:
> > security/openssl/builtin.mk:127:BUILDLINK_PREFIX.openssl= /usr
> >
> > This assumption is wrong for DragonFly which has a private OpenSSL library
> > only for base use.  pkgsrc is supposed to build and use its own OpenSSL.
> >
> > The BUILDLINK_PREFIX.openssl is hardcoded. What's the proper fix for pkgsrc?
> > (Yes, I know I can patch it in pkgsrc-synth).
>
> pkgsrc will only enable a builtin if it finds the necessary libraries
> and headers in the base system.

Unfortunately this statement isn't true at all.
1. It only checks for headers, not libraries
2. It arrives at the wrong value at all these examples (termcap, curses, 
readline, openssl).  It seems not to consider the possibility that no 
base library exists at all.

> This is performed using the
> BUILTIN_FIND_* variables defined in security/openssl/builtin.mk.  If
> those tests aren't satisfied and IS_BUILTIN.openssl=no then pkgsrc
> will not use the builtin, even if you ask it to.

yet that it does.  The point of the original post is that those tests 
are insufficient, which may have been unknown to everyone but me and wiz.

> Thus if you don't want users to use your private OpenSSL then the best
> solution is to modify your installation in a way that software cannot
> find it.  The way SmartOS does this is described here:

You misunderstand.
It's hidden well.  pkgsrc didn't find it.  It's using it anyway.

> Until that is implemented though you can provide hints to pkgsrc for
> it to prefer pkgsrc or native implementations of builtin-aware
> software by setting e.g.
>
>   _OPSYS_PREFER.openssl?= pkgsrc
>
> in mk/platform/DragonFly.mk.  See mk/platform/SunOS.mk for some
> examples.

Two comments:
1) "PREFER" implies a choice.  There's no choice here; DF users must use 
the pkgsrc-based version.  Any user-based directive that differs is 
simply unsupported.
2) I don't see a practical difference in setting this (misleading) 
variable and just skipping the faulty tests altogether.

Actually I think I set both the BUILTIN (no) and preference for ncurses 
and readline in platform.mk just to make sure the right thing happens. 
Wiz wasn't a fan of that due to its overriding user directives but 
that's exactly what I wanted to do.


> These variables take precedence over a user's PREFER_PKGSRC=yes or
> PREFER_NATIVE=yes setting, but they do not take precedence over
> PREFER.openssl or if "openssl" is specifically listed in PREFER_*, so
> it is still possible that users could configure their pkgsrc to use
> your base OpenSSL.

Except that it's not technically possible without modifying the pkgsrc 
makefiles themselves.  Those libraries are not on any standard path.

Thanks,
John

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus