How to track the "Security" branch rather than "Release" branch? Why not?

E

Ed_Flecko

Perhaps I don't quite understand and someone can enlighten me.

I have installed the current, "release" version of FreeBSD. I see on the wiki at: http://www.freebsdwiki.net/index.php/FreeBSD_Release_Branches , it says "If stability is the most important factor on this system, you may want to track something called the security branch. This branch only updates for security updates and major bug fixes from the code you originally installed."

This sounds like exactly what *I* want! I'd have the most stable system (in my case, my desktop daily driver) possible, as well as the most secure system by having all available patches installed, etc., etc. I don't know why the "average user" wouldn't want this as well? Am I overlooking something?

Can you tell me how to track this branch? I can't find anything on the web that explains how to do this. Tracking the "security" branch is like a hidden secret.

:-)

Thank you for your feedback!

Ed
 
You can do that. The security branch only receives security fixes, so it is very stable. Nothing else moves there.
It will probably save you from the small snags when something changes and the package system can't keep up (in other words, it takes a few days or more before the snag is fixed via an update).

The downside is that if there is an improvement in base that isn't a security fix (library change, bundled application) that goes into the release branch, your security branch won't receive it.

These days, I only track releases (using either freebsd-update or packaged base). And sometimes there are bumps in the road. I follow FreeBSD and news about it quite close, so for most bumps I know how to fix or avoid them. But I'm an "old hand" when it comes to FreeBSD.
 
tingo said:
You can do that. The security branch only receives security fixes, so it is very stable. Nothing else moves there.
It will probably save you from the small snags when something changes and the package system can't keep up (in other words, it takes a few days or more before the snag is fixed via an update).

The downside is that if there is an improvement in base that isn't a security fix (library change, bundled application) that goes into the release branch, your security branch won't receive it.

These days, I only track releases (using either freebsd-update or packaged base). And sometimes there are bumps in the road. I follow FreeBSD and news about it quite close, so for most bumps I know how to fix or avoid them. But I'm an "old hand" when it comes to FreeBSD.
Click to expand...
Thank you for your reply.

Let me make sure I understand. By tracking the security branch, you would not receive the benefit of any bug fixes to existing, installed applications if said fixes were not "security" related. Correct?

If I want to track the security branch, how do I do that? That's what I don't understand.

Ed
 
tingo said:
he security branch only receives security fixes, so it is very stable.
Click to expand...
In my time of using FreeBSD, I have never seen a tag or branch like "security/15.1". To my knowledge the "security branch" for any given supported release has been the "releng" branch or tag.
 
If you click the link to the Wiki, at the top it talks about the "CURRENT, STABLE and Security" branches. By implication, in this specific context I think "Security Branch" == "Releng Branch"
 
Security branches are additionally described (in messages to support mailing lists, for example) by their patch level. If there have been 3 major patches to the RELENG_5_4 security branch, for example, an up-to-date 5.4 user will be running 5.4-p3 .
Click to expand...
Yep you might be right mer
 
  • Like
Reactions: mer
Ed_Flecko said:
I have installed the current, "release" version of FreeBSD. I see on the wiki at: http://www.freebsdwiki.net/index.php/FreeBSD_Release_Branches , it says "If stability is the most important factor on this system, you may want to track something called the security branch. This branch only updates for security updates and major bug fixes from the code you originally installed."
Click to expand...
you are using an unofficial wiki as the source of your information. That page has not been updated since 2009. This was before the switch to git, so release branches are named differently now. I think mer might be right.
 
Ed_Flecko said:
Thank you all for your feedback.

So, for the average user, like me, just stick with the "Release" branch (https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/15.1/), update your system periodically, and "call it good"? Sound about right?

Ed
Click to expand...
Yes. Applications/Packages/Ports: by default will track "quarterly" so you would update them every three months. Some applications like firefox/other browsers may do updates on the quarterly branch more often, but releng is the security branch.
 
Man, that wiki article is old.

The "security" branch it is referring to is RELENG_6_0, which is the branch that had 6.0-RELEASE plus security/errata fixes. That's the old CVS branch naming convention. This "security" branch would translate today to releng/15.1 for example. Which is 15.1-RELEASE plus security/errata fixes.

In general, when we talk about a -RELEASE version this includes all the latest security and errata fixes.

Also note the separation of third party software (ports/packages) and the base OS. This article is about the base OS only.
 
  • Like
Reactions: mer
mer said:
Yes. Applications/Packages/Ports: by default will track "quarterly" so you would update them every three months. Some applications like firefox/other browsers may do updates on the quarterly branch more often, but releng is the security branch.
Click to expand...
Thank you for the clarification!

I'll have to look around, but is there any reason not to try and automate your system using cron to do the "pkg update" and "pkg upgrade" on a daily, weekly, etc. schedule?

Ed
 
Ed_Flecko said:
I'll have to look around, but is there any reason not try and automate your system using cron to do the "pkg update" and "pkg upgrade" on a daily, weekly, etc. schedule?
Click to expand...
Yes. Sometimes, any repository can be in bad state for a given software. You may have one or more software removed. You may also have a blocking bug in a new version.

My advice is to always see what pkg upgrade says and postpone if it wants to delete something.
 
Emrion said:
Yes. Sometimes, any repository can be in bad state for a given software. You may have one or more software removed. You may also have a blocking bug in a new version.

My advice is to always see what pkg upgrade says and postpone if it wants to delete something.
Click to expand...
Excellent..thank you!

Ed
 
Ed_Flecko said:
I'll have to look around, but is there any reason not to try and automate your system using cron to do the "pkg update" and "pkg upgrade" on a daily, weekly, etc. schedule?
Click to expand...
There might be reasons, but I've been doing unattended updates for years on a webserver :p (did pkg update/upgrade + reboot daily 15.0-16.0 amd64, and now 15.1 aarch64 on RPi; prior was openSUSE Tumbleweed similar zypper dup/reboot)

My Pi has this that cron's daily 6am:
Code: 
freebsd-update fetch -F --not-running-from-cron > /dev/null
freebsd-update install

pkg update -f
pkg upgrade -y
pkg autoremove -y

shutdown -r now 'FreeBSD OS Updater'
 
Ed_Flecko said:
Thank you for the clarification!

I'll have to look around, but is there any reason not to try and automate your system using cron to do the "pkg update" and "pkg upgrade" on a daily, weekly, etc. schedule?

Ed
Click to expand...
Everyone has different ideas, but for me, my systems which are daily drivers I manually run freebsd-update fetch to see if there are any updates to the base OS (NOTE: this command will NOT work on a system that is installed with pkgbase), and again manually run pkg upgrade -n (the -n says "check but don't do anything") to see if any applications need upgrading.
If the base OS is pkgbase, then the "pkg upgrade -n" check works for both base OS and applications.

Some people try to automate but I've been bitten by Windows "forced update" and tend towards caution.

if you have not yet installed your system, take a good look at using ZFS for the root filesystem instead of UFS.
 
mer said:
Everyone has different ideas, but for me, my systems which are daily drivers I manually run freebsd-update fetch to see if there are any updates to the base OS (NOTE: this command will NOT work on a system that is installed with pkgbase), and again manually run pkg upgrade -n (the -n says "check but don't do anything") to see if any applications need upgrading.
If the base OS is pkgbase, then the "pkg upgrade -n" check works for both base OS and applications.

Some people try to automate but I've been bitten by Windows "forced update" and tend towards caution.

if you have not yet installed your system, take a good look at using ZFS for the root filesystem instead of UFS.
Click to expand...
I like your "pkg upgrade -n" command. I think I'll stick with that.

:-)

Have a great weekend!

Ed
 
That wiki doesn't seem like a reliable source to me, also... checked their frontpage yet?

Code: 
peter@zefiris:/usr/src $ git branch -r | grep secur
peter@zefiris:/usr/src $

But let's skip all of this, and focus on what really matters here: OP, computer security isn't a product (or switch) which you can flip on and then consider yourself safe. It doesn't work that way, and worse yet: such a mindset can become really problematic in the longer run.

Instead it's gained through discipline and knowledge/experience: understand what you're doing, and why you're doing it. Set up rules to keep yourself safe, and then also stick to those rules.

If you don't fancy constant updates then maybe check a quarterly release? But honestly... This is just my 2 cents, but if you really value security then I'd utilize both the sourcetree & ports collection. Takes more time to get started, sure, but you're in full control over things and you can make the process as easy or as hard as you'd like.

Take my Apache webserver (www/apache24).... there are a lot of features which I specifically excluded from building because I either don't need them or... because I don't trust them (looking at you WebDAV! :p). I don't 'do' suexec, the server supports a very specific set of authentication schemes and most of what I don't need or trust.. isn't there.

As a result my server won't react in the same way to someone who has "simply" installed and configured Apache. Even if someone manages to breach the jail and tries to reconfigure stuff then... "oopsie", some easy targets simply aren't there. Like, at all.

My point you wonder? Despite all this it's extremely easy to manage. It's not as if I have to cope with daily updates. Heck, even a weekly check is more than enough and usually not too extensive. Despite tons of specific customizations.
 
ShelLuser said:
My point you wonder? Despite all this it's extremely easy to manage. It's not as if I have to cope with daily updates. Heck, even a weekly check is more than enough and usually not too extensive. Despite tons of specific customizations.
Click to expand...
That is why FreeBSD has the mailing lists. The security ones are very useful because you get notified "hey you may want to check this". I think these lists only cover what we consider "base OS", not sure if something in packages would wind up here or if there is an equivalent "packages/ports-security" mailing list.
 
You must log in or register to reply here.
Back
Top