Solved Delay of 13.0 Release

Sure, and that's well warranted! I'm just surprised release candidates receive security updates, too. 👍
To me, it's irrelevant, cause all my services are linked to libressl…
 
I suspect this was done because RC4 wasn't going to be released quickly enough. The OpenSSL issue appears to be actively exploited at the moment, so that would certainly warrant a quick fix. If RC4 was rushed because of the OpenSSL issue they would probably have had to schedule a RC5 too.
 
JFYI: The release team just announced that RC4 might be delayed further somewhat. There are no technical reasons for this; it’s rather that one of the main release engineers got an urgent private appointment (not related to FreeBSD).
 
About SSL? I received an email yesterday afternoon or evening. (EDT, GMT -4), including a patch, or the ability to fix with freesd-update.
 
About SSL? I received an email yesterday afternoon or evening. (EDT, GMT -4), including a patch, or the ability to fix with freesd-update.
Now it came in (today March 26, 12:00 UTC). IIRC you're a ports(7) maintainer & maybe these are ranked before mere mortals in the mailing list, I'd be fine with that if it's so. Or you've been a subscriber for a long time and thus higher in the list.
 
Yes and thanks to the daily check enabled in my crontab(5) I had the fixes already available to install when I checked my e-mail today :) freebsd-version: 12.2-RELEASE-p5
 
Yes and thanks to the daily check enabled in my crontab(5) I had the fixes already available to install when I checked my e-mail today :) freebsd-version: 12.2-RELEASE-p5
... and here I checked out the latest source code af61348d61f51a88b438d41c3c91b56b2b65ed9b and rebuilt my system FreeBSD Tuna2 12.2-RELEASE-p5 FreeBSD 12.2-RELEASE-p5 TUNAZ2 amd64
 
I think most of us would rather they delayed it and got it right, rather than met the deadline and found some important things not working. And as far as getting annoyed because someone had to have a delay for personal reasons, let's hope we're better than that. I remember the outrage when a CentOS release (maybe even a point release, I don't remember) was delayed because a CentOS developer had the *temerity* to get married (and, if I remember correctly, in another country than his own), and I always thought that was pretty petty.
 
Well, first of all, I would expect a ton of things that aren't 100% correct in the first -RELEASE. That's just normal, cause you won't get testing on a large scale before there is a -RELEASE. But -RCs should make sure there are no severe bugs that might be deal-breakers for many users.

That said, 13 had a pretty bumpy ride so far, going up to -BETA4 and now to -RC4, which is probably due to the massive changes in that release. Thankfully, the wireguard fiasco was spotted in time… Now, also having a delayed -RC4 matches the picture in an ironic way, such a thing is very uncommon and there must be pressing private reasons (and we don't really need to know details).

Still I think this will be a great -RELEASE, and, as always, it will improve further over time.
 
Frankly I'm fine with that. Thanks for the headsup. I don't know if it is the wg related or not but I do like to think that maybe some additional internal auditing is taking place.
 
Most certainly not, this code was removed before RC3, and you don't (re-)introduce a new feature during RC phase.
Right. I meant if maybe internally there is some sort of audit because of the wg. But that's me thinking out loud, not a statement.
 
regarding the mailing list for security updates, is subscribing to this one https://lists.freebsd.org/mailman/listinfo/freebsd-security-notifications sufficient?
either that or you let freebsd-update(8) check for updates periodically, e.g. through crontab(5) or anacrontab(5):
Code:
# $Id: anacrontab,v 1.5 2021/03/31 19:32:59 root Exp root $
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

# days          make sure the command is executed at least every 'days' days
# delay         delay in minutes, before a command starts
# id            unique id of a command
#
# REM           sysrc anacron_nice=10 @boot from rc.d & in crontab(5) it's nice.
# REM           sysrc anacron_flags="-s" serialize jobs, thus delay isn't important.

# days  delay   id                      command
  1       1     ntpdate                 csh -c 'ntpdate -4uv {0,1,2}.de.pool.ntp.org'
  1       2     freebsd-update          freebsd-update cron
  [...]
then you get an e-mail when new updates are available. Of course you have to freebsd-update install them manually.
 
Back
Top