Delay in FreeBSD 14.0 release schedule

sean137 said:
which is before the *release* of FreeBSD-14
Click to expand...
I think that wasn't the case with the originally planned release schedule. But in the end, it doesn't matter much.

OpenSSL EOL will certainly hit stable/13, and I don't know what's the plan here (probably backporting fixes?). But for a new release with a planned lifecycle of 5 years, that's certainly something you don't want.
 
Crivens said:
I'll be wearing a black ribbon for that, cause I like MIPS a lot. But I can't prevent it or put more steam behind MIPS to make it tier1 again. A sad day.
Click to expand...
I second that.
News around MIPS (as architecture) is like watching soap opera. Wonder if they can pull themselves up from dead or not.
 
zirias@ said:
I think that wasn't the case with the originally planned release schedule. But in the end, it doesn't matter much.

OpenSSL EOL will certainly hit stable/13, and I don't know what's the plan here (probably backporting fixes?). But for a new release with a planned lifecycle of 5 years, that's certainly something you don't want.
Click to expand...

I highly suspect there will be a lot of downstream effort to keep OpenSSL 1.1.1 alive with security patches for quite a while, given there are many upstream projects and even whole OS/distributions that seem to completely ignore the fact 1.1.1 will be EOLed soon. Not saying this is a good thing, and I really hope we won't see the same story as with e.g. NPAPI Java (I had to keep that crap alive with old 32bit browsers until this may for some business-critical application...), but I doubt the EOL date will be an immediate death date for 1.1.1.
However It is definitely the only correct thing to include 3.0 in the 14.0-RELEASE, even if it causes some delay and probably breakage/fallout. But for the 13-RELEASE branch I see the whole thing a bit more relaxed and even go as far as predicting, that the 13.N branch will be more stable and probably compatible until the better part of the ecosystem catches up.
I hope to be proven wrong, but looking back at history I fear we will have OpenSSL 1.1.1 around for several years to come...
 
I'm fine with dot zero releases getting delayed. I may be misremembering, but 5.0 took a while to get out. There were big changes from 4.x, related to scaling and SMP (hence DragonFlyBSD) but when 5.0 finally got out, I waited a week or 2 before updating and it was pretty solid for me.
 
rotor said:
It looks like the 14.0 release Schedule is moving along once again...
Click to expand...
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.
 
Thanks zirias@ that's one thing a lot of folks forget. FreeBSD is nominally "kernel plus base userland" but how that plays into ports/packages is always important.
 
"The Core Team is working with other teams to ensure that FreeBSD 14.0-RELEASE will be of the highest quality." :-)
"The new schedule targets 14.0-RELEASE for October, 2023."
 
yuripv79 said:
TBH, I'd really love to see openssl libs made private and ports using the openssl from ports.
Click to expand...
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.

But on the other hand ... base needs TLS for some tools (I once tried building it without OpenSSL, which works fine, but isn't really usable when even fetch(1) can't use https ...), so what exactly would it buy if ports weren't allowed to link to it? You still have to issue some SA for base when there's a vuln in its OpenSSL. You still have to make sure ports work fine with the latest OpenSSL version. Hm!

Of course, gratuitous rant, OpenSSL just sucks, the API is close to unfixable and about the code, well I didn't dare to look myself, but there's this nice (very old) article claiming it was "written by monkeys" ? -- as long as this is our quasi-standard for anything crypto (like TLS), we're doomed anyways....

edit: Disclaimer: This was a completely personal opinion (just so nobody is mislead by this yellow badge on my account) ?
 
yuripv79 said:
TBH, I'd really love to see openssl libs made private and ports using the openssl from ports.
Click to expand...
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.

Base could also more easily sidestep "improvements" like a particular library's decision to completely break backwards compatibility and introduce significant performance problems to boot.
discourse.haproxy.org

Openssl 3.x speed issues

Hi, We’re having issues upgrading from ubuntu 20.04 to ubuntu 22.04. After test different haproxy versions (the one shipped by ubuntu, 2.4, and 2.7.3) and different openssl versions (the one shipped by ubuntu, 3.0.2, and 3.0.7) we always see blocking issues in the TLS handsake under high load...
discourse.haproxy.org discourse.haproxy.org
 
Phishfry said:
I think they (core) decided to axe MIPS.
I have not seen any mips questions here in quite a while.
We were conditioned for a possible axe for 32 bit Intel on 14 so quite a relief.
armv7 seems to be kept around too.

Sorry balanga but dockstar is out of there. armv5 is to be removed I believe.
Click to expand...
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.

1690752656764.png
 
Jose said:
They could experiment with something more sane, like say, Libtls.
Click to expand...
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 :(
 
zirias@ said:
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 :(
Click to expand...
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.
Without a stable API and feature set, something like a compatibility-layer/shim with a stable interface would be necessary to really make drop-in replacements happen.
 
balanga said:
Although I manged to boot from a USB stick, I never managed to boot from a hard disk. In any case, why 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.

View attachment 16662
Click to expand...
I'd think that belongs in here:
forums.freebsd.org

Installing and Upgrading FreeBSD

Installing and upgrading the FreeBSD base system. Do not post questions about ports or packages here.
forums.freebsd.org forums.freebsd.org
 
msplsh said:
Heartbleed woke up a bunch of people to work to improve OpenSSL instead of fork it.
Click to expand...
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).

Now OpenSSL vs LibreSSL. In theory (talking generalities here) there should be a relatively standard/stable API because a library performing encryption/decryption in theory should be stable. Yes I know I used theory multiple times :) But if upstream/"the standard" keeps changing the API (think MS) it makes it hard to keep up.
 
msplsh said:
Heartbleed woke up a bunch of people to work to improve OpenSSL instead of fork it.
Click to expand...
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" :oops:
 
I'm so excited about the next version. I love to hear that there are delays it just increases the anticipation. FreeBSD is such a great system and I'm so stoked for version 14. When I was looking to move to a new os there were two main considerations for me, SSL and accelerated graphics support. FreeBSD is the absolute best option I found. So, whatever work is being done I'm sure is going to be worth the wait. If I had the skill I would help. ?
 
LibreQuest said:
If I had the skill I would help.
Click to expand...
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.
 
mer said:
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.
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top