Date: Sun, 27 Dec 2020 17:58:44 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-ports@freebsd.org Subject: Re: Re-enabling old ciphers in openssl Message-ID: <6204eddd-d4c2-b7db-4690-e70c92170682@pinyon.org> In-Reply-To: <7d31329e-aed5-3b24-a66e-43ef7d3dcbfa@prime.gushi.org> References: <7d31329e-aed5-3b24-a66e-43ef7d3dcbfa@prime.gushi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6204eddd-d4c2-b7db-4690-e70c92170682>