Re-enabling old ciphers in openssl

[Russell L. Carter]

On 12/27/20 4:49 PM, Dan Mahoney (Gushi) wrote:
> Hey there all.

[...]

> Here are the questions I can't seem to answer:
> 
> 1) There's no make.conf entry to override the openssl ciphers.  This 
> needs to be done at the port level.  (Probably reasonable, I don't think 
> there should be an insecure "flavor")  But in the interest of making 
> things reproducible, is there a "Standard" way to keep this consistent 
> without running "make config" every time, or echo'ing options into 
> /var/db/ports/security-openssl/options?
> 
> 2) I'm unclear as to what to put in make.conf to tell ONE PORT to use 
> the openssl from ports, while I want all the others to use base.  I know 
> this is in some cases askign for trouble, but the nagios plugins are 
> standalone binaries.  Is there some method in make.conf or on the port 
> command line to tell ONE PORT to use a defaults+=ssl-openssl without 
> making it the default for ALL PORTS?
> 
> 3) If I do all that, ports seems to lack a standard way to build static 
> binaries, which is what I'd really like.  Is there an easy way to do 
> this, or is it best to work outside the ports system at that point?
> 
> -Dan
> 


Not judging.  I am always in some sort of disagreement with the
otherwise world-class ports+poudriere system of FreeBSD package
management.  Like, now, texlive.  And I locally maintain a
fluctuating group that occasionally has members migrate back
into mainstream ports because my disagreement is no longer
material.

If I was in your situation, I would start with whatever version of
openssl works best for the obsolete packages you want to link/plugin
against.  Stuff the source down into /usr/local/pkg/repo/openssl1,
write some 15 liner shell scripts to configure, build, and install
it to /usr/local/pkg/lib.  In my experience one needs to fixup
PREFIX and occasionally rpaths.  Other hacks go into a git branch
in the repo.  Setup your path for your obsolete packages user
account and off you go.  (Could be some dependency hell in your
future, I would keep it simple.)

*or*

Install an ancien version of FreeBSD that does what you want
in a vm.  No idea how to deal with the packages for that system,
maybe it's trivial.  This method is how I deal with Unifi software
(on old debian versions) after battling the outdated "*" problem
for years.  Works great with bhyve.  If I want a current version
of something that doesn't work great in the obsolete version and
is orthogonal to the support task at hand I generally just try to
configure, build, and install it to... /usr/local/pkg in the vm
Compared to dealing with this before, now my life is awesome.
OMG I forgot FreeBSD => jails.  I don't use jails but that would
be the quickest route here I'm guessing.

I am assuming here that you don't need any big frameworks, because
then I doubt it would make sense at all to battle the problem this
way.

Good luck!
Russell