The EOL of OpenSSL 1.1.1 is 2023-09-11, which is before the *release* of FreeBSD-14, nevermind the EOL of FreeBSD 14.
I think that wasn't the case with the originally planned release schedule. But in the end, it doesn't matter much.
I second that.
The major roadblock (OpenSSL 3) has been sorted out a few weeks ago. My 14-CURRENT machines seem to work fine with OpenSSL 3. I've seen a lot of activity in ports regarding OpenSSL 3 compatibility as well, but this seems to have mostly settled now.
That's an interesting idea. It's effectively what you're doing anyways as soon as you set
ssl in DEFAULT_VERSIONS to anything other than base.
-- as long as this is our quasi-standard for anything crypto (like TLS), we're doomed anyways....
I think I remember someone making this proposal in one of the mailing lists, but I can't find it now. The advantages of this approach are that base would not be tied to a particular TLS implementation. They could experiment with something more sane, like say, Libtls.
discourse.haproxy.org
Although I manged to boot from a USB stick, I never managed to boot from a hard disk. In any case, what I was working on was a Seagate GoFlex Home which is different to a dockstar. To be honest it would be nice to have a forum to discuss installation of FreeBSD on retro systems, albeit no longer supported.
Not really, the decision would have to be made during 13-CURRENT cycle, the ongoing discussion is about 15 at earliest.
That would be a good reason indeed! But it isn't even simple when done just in base, there's also 3rd-party software (e.g. heimdal) included relying on OpenSSL
IIRC there was also a discussion about this when LibreSSL first reached feature-parity with OpenSSL and the major problem always was, that OpenSSL is (deliberately?) a fast-moving target in terms of features and API.That would be a good reason indeed! But it isn't even simple when done just in base, there's also 3rd-party software (e.g. heimdal) included relying on OpenSSL
I'd think that belongs in here:
This is always a problem with OpenSource projects. Forking is a good way to get improvements, but it's better for the community to get changes integrated upstream (FreeBSD fixes to ZFS that would get pushed upstream). So I can understand the influx of people to improve the upstream (OpenSSL).
But if upstream/"the standard" keeps changing the API (think MS) it makes it hard to keep up.
Having used OpenSSL API myself just a tiny little bit (for basic TLS support in "poser"), I'd rather claim it's unfixable. Of course, "forking" doesn't improve anything either when the problems already start with the API, which nevertheless became the "de-facto standard"
Exactly like MS APIs, no?
Can you install a system? Can you verify said system does what you need?
I have a lot of machines running FreeBSD as a workstation. Laptops and desktops. I ask a lot of questions on the forums but I don't send any data to the developers. Is there some place I could contribute hardware data for developers? All I know is my RX 6400 doesn't work and if there's anyway I can help make that dream a reality I will.Can you install a system? Can you verify said system does what you need?
Congratulations, you have the skill to be a tester
Seriously, I know I was a bit flippant, widespread installs and normal use on different systems helps more than one can realize. "well if we always install on mobo XYZ with NNN RAM and CPU ABC" tells the project very little.
