In http://ftp.openbsd.org/pub/OpenBSD/7.0/packages-stable/amd64/ you can see all updates which were made available for 7.0 users since its release (October 2021). Most aren't typical desktop applications.
When I was using OpenBSD, I did notice that in the name of security, they did insist on auditing third-party packages before allowing them into repos. And should those packages have updates - the updates get audited as well. That took up so much time and effort (There's a LOT of those desktop-oriented packages to go through, after all) that OpenBSD-cleared stuff was just WAY behind everything else. That made me think that maybe I should just use FreeBSD, and be sensible about my activities on the Internet. There's no such thing as "perfect security" or "useful and completely bug-free code". ?
I've been using OpenBSD since the 2.x days and so far as I know they've not audited third party code unless it's going into base.
Yes. An upgrade from 13.0 to 13.1 should be easy.
FreeBSD is not Linux and you even can upgrade from much older versions. Like 10.0 to 13.1 without problems.
Yes. I have systems that have been progressively upgraded from 9.0-RELEASE (when I first installed them, many years ago) all the way to 12.3-RELEASE what they're running now.
You'll get a message when you try to upgrade.
It will tell you there are no patches to download and tell you you have an unsupported version.
pkg(8) may complain about mismatched kernel version, and the installed packages could fail because they've been built for a newer version than you currently have. That's assuming you are using the official FreeBSD repositories. If you build your own repository you could build specifically for your EoL version, but you may run into various other issues.
This is why I stick to ports, rather than packages. FWIW, I like 13.0-RELEASE, it took to my hardware like a champ. ?
freebsd-update fetch install when my install reaches EOL. This mailing list thing is really useful.I don't like email and if FreeBSD would force me to subscribe to mailing lists, i'd rather use Linux.
freebsd-update fetch install and (b) when to upgrade to a new point release. I can understand that its not possible to notify user about when to run pkg upgrade coz that depends on the specific packages installed which differs from user to user.
periodic(8) is enabled by default. It will do a daily, weekly and monthly scan. The daily security run includes running pkg-audit(8). I highly recommend configuring your systems to send the periodic emails to a centralized mailbox.
Checking for packages with security vulnerabilities:
Database fetched: Mon Feb 28 03:21:51 CET 2022
db5-5.3.28_8: Tag: expiration_date Value: 2022-06-30
db5-5.3.28_8: Tag: deprecated Value: EOLd, potential security issues, maybe use db18 insteadThis I have never done before so I will search for a tutorial online but thing I want to ask.
pkg update / package upgrade ultimately the same thing instead of checking a local mail ? I mean this mail needs to be checked using CLI right ? So instead of checking a mail if I run pkg update & pkg upgrade on a regular basis I am doing the same thing.
My servers all mail to a central mailbox, and I read that with a webmail client or Thunderbird. But if you want to keep it locally, yes.
Sure. But that just updates everything. You should also regularly check pkg-audit(8). Sometimes security issues are reported but the port/package hasn't been updated yet. It's good to know where any potential issues might be hiding, you might be able to mitigate them without updating/patching. I solved the issue from the example I posted by simply eliminating that db5 dependency (I didn't need it anyway).
So you choose not to install all the updates offered ? You pick particular packages and leave the rest ? Is there a reason for that ? Like avoiding breakage ? In the short period that I have FreeBSD I have updated everything but nothing broke.
pkg-audit I find a vulnerable package say Thunderbird and there is no update available. What do I do then ? I can't uninstall Thunderbird. I need it.
Knowing there's a vulnerability is half of the battle. Like I said, sometimes you can take mitigating steps to prevent that bug from becoming a problem. And in other cases the best course of action is to stop using it until it gets fixed.