After Update 2.7.2 / 23.09.1

stephenw10

That's true, you can't fix stu..pid. But that's not the case here - this is 100% a preventable situation on both counts, and the system should therefore protect itself and remain flexible as much as it can within the framework.

As I say open a feature request for it. You may find other developers agree with you. I wouldn't be me coding that anyway.

jrey

@stephenw10 said in After Update 2.7.2:

Still digging though..

Add this to the low priority "dig" re packages (dig being the reference for unbound )

in the update ( 23.09.1)
the update log shows

unbound: 1.18.0 -> 1.18.0_1 [pfSense]

Number of packages to be upgraded: 9
[1/9] Upgrading unbound from 1.18.0 to 1.18.0_1...
===> Creating groups.
Using existing group 'unbound'.
===> Creating users
Using existing user 'unbound'.
[1/9] Extracting unbound-1.18.0_1: .......... done

unbound is working no issue, but it is logging itself as 1.18.0
and running the command

unbound -V

reports 1.18.0

where as in the 2.7.2 release there is no mention of unbound being upgraded to _1

unbound -V also reports 1.18.0 on that version
maybe that's the package the got slipped in ? or is expected

either way on 23.09.1 it is not reporting what is says was installed..

We can talk about the curl package too.. Upgraded on 23.09.1 now running 8.5.0 but 2.7.2 is still running 8.4.0 maybe that is also expected?

from 23.09.1 upgrade

Installed packages to be UPGRADED:
	curl: 8.4.0 -> 8.5.0 [pfSense]
	isc-dhcp44-relay: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	isc-dhcp44-server: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	openvpn: 2.6.5 -> 2.6.8_1 [pfSense]
	pfSense: 23.09 -> 23.09.1 [pfSense]
	pfSense-default-config-serial: 23.09 -> 23.09.1 [pfSense]
	pfSense-repo: 23.09 -> 23.09.1 [pfSense]
	strongswan: 5.9.11_1 -> 5.9.11_3 [pfSense]
	unbound: 1.18.0 -> 1.18.0_1 [pfSense]

from 2.7.2 upgrade

Installed packages to be UPGRADED:
	isc-dhcp44-relay: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	isc-dhcp44-server: 4.4.3P1_3 -> 4.4.3P1_4 [pfSense]
	openvpn: 2.6.7 -> 2.6.8_1 [pfSense]
	pfSense: 2.7.1 -> 2.7.2 [pfSense]
	pfSense-default-config: 2.7.1 -> 2.7.2 [pfSense]
	pfSense-repo: 2.7.1 -> 2.7.2 [pfSense]
	strongswan: 5.9.11_2 -> 5.9.11_3 [pfSense]

stephenw10

The curl pkg was updated in the repo. Upgrades after it was will have 8.5.0. Anything that was already upgraded can get it using pkg upgrade if needed.

The Unbound package had the port revision bumped to pull in a fix to a patch we carry:
https://github.com/pfsense/FreeBSD-ports/commit/4749e98e2dbffb8e725f68e5b437c5056c55a0bc

jrey

@stephenw10

Thanks

so the question about unbound wasn't so much about the difference between 2.x and 23.x but more about 23.x saying it is still reporting itself as 1.18.0 when it should be 1.18.0_1 ? is that the expectation?

unbound -V
reports 1.18.0

sounds like these are the parts that caused the Dec 9th date on the install completed on Sunday morning. Seems to answer that. Packages were added a couple of days after the release, and earlier installers will be "missing" or running older versions of those packages. I guess what they don't know won't hurt them.

Thanks for the clarity.

Patch

@jrey said in After Update 2.7.2 / 23.09.1:

So what I think you are saying that packages on a released build are changing in the background and after the release?
therefore those folks that updated earlier will have a different system than those who update later.. seems like the potential for a support nightmare.

@stephenw10 said in After Update 2.7.2 / 23.09.1:

We commonly upgrade packages for fixes between releases when required.

@stephenw10 said in After Update 2.7.2 / 23.09.1:

Anything that was already upgraded can get it using pkg upgrade if needed.

The Unbound package had the port revision bumped to pull in a fix to a patch we carry:
https://github.com/pfsense/FreeBSD-ports/commit/4749e98e2dbffb8e725f68e5b437c5056c55a0bc

Err
How is a user expected to know

a package such as unbound has been updated in the Netgate repro and
if they had delayed their update they would have got it but
on their install they have not as they updated early.

or does this mean users should intermittently run pkg upgrade just to in case as the "Upto to date" status may not be accurately reported in System -> Update -> System Update

jrey

@Patch

My Opinion... no you shouldn't have to --

when they "release" a system the repo for that Release version should be frozen at that version. You should never get a different bundle on Monday compared to what you got on Friday, or any other date span.

If they have to add something that was missed or late to the party. it should require a new repo.. ie 23.09.2 (or 23.09.1p1)

Slipstreaming packages into a released product is just bad practice for oh so many reasons.

if you look at my comments on this thread, even the announcement of the release wasn't "clean"

https://forum.netgate.com/topic/184642/netgate-releases-pfsense-plus-software-version-23-09-1-and-pfsense-ce-v2-7-2/7?_=1702381351314

Currently I'm trying to get through a security audit (these happen periodically in the real world) There has to be documentation on what changes are applied, when, by whom etc. Versions numbers typically have to match or auditors tends to get cranky. (so for example the unbound says 1.18.0_1 was installed but the package itself reports 1.18.0 this is NOT a pass, guaranteed. -
They are not running with the "big boys" in regards to releases and control.

I mean I get it, their lower end line of products are not intended for secure environments. But still basic adherence to release practices should not be that hard.

stephenw10

@jrey said in After Update 2.7.2 / 23.09.1:

more about 23.x saying it is still reporting itself as 1.18.0 when it should be 1.18.0_1 ? is that the expectation?

That is expected. Unbound itself, the compiled binary, is still 1.18.0 and so will report that when you call it. The port version was bumped to _1, you should see that from pkg info unbound

jrey

@stephenw10

yes I know, but that's not necessarily what the audit looks for.
They look for the what was installed see 1.18.0_1 and what is running "unbound -V" and logs both say 1.18.0

then it turns into a big long discussion about why, to mitigate the concern.

If the versioning just matched there would be no question. period.

johnpoz

@jrey said in After Update 2.7.2 / 23.09.1:

If the versioning just matched there would be no question. period.

I don't think that is going to happen with something like this - freebsd backported some stuff from 1.19 to the 1.18 release I believe.. There is not actual 1.18.0_1 from unbound (nlnetlabs).. see here

https://www.freshports.org/dns/unbound/?page=1#history

Or maybe the came up with their own fix and provided it in their package.

This is not uncommon in packages for linux and or bsd distros..

stephenw10

I understand. I'm not sure what we can do about it though. That's how the ports system has always worked AFAIK.

jrey

@stephenw10 said in After Update 2.7.2 / 23.09.1:

I'm not sure what we can do about it though

report with and display the version number from package it was installed with ? (yes I know that's a little more complicated feature, and likely wouldn't fly, but it would certainly simplify life) As it is, given the file date, build date, install log although not idea it is something that can be explained to mitigate the concern.

Not even going to bring @johnpoz 's response into the mix the last thing anyone needs to enter into the mix is that the back port came from yet a different version. I get it the _1 is a little of this a little of that. But the less of that, that requires explaining the easier it is to explain

Thanks guys,

johnpoz

@stephenw10 said in After Update 2.7.2 / 23.09.1:

That's how the ports system has always worked AFAIK.

As far back as I can remember on anything - that has always how ports have worked.. You can see a different version on the package then is actually what the application/binary version is.. This is not something for pfsense to tackle..

I feel for you if your auditors are idiots - most of them are, and many of them don't even understand what is going on other than some checkbox that matches up..

I could share many stories of dealing with their moronic take on things.. No I am not going to give you the user password hashes in the db so you can run a bruteforce on them.. If your saying its a concern - then you get the db from your box actually connected to the network as a normal user.. If the user circumvented the policy of using 3 out of the 4 with Pa55word! That is what the user did, the policy is met..

I have more of concern of giving you my user hash db - that you might leave on a usb stick in starbucks or something ;)

Why does the screensaver timeout have to be set to 2 minutes in the secured server room, that you need not only to auth to get into the building, but you also need to get through the security door into the server room with your code at the door. Twice there are 2 doors, one with your badge and 2nd with code.. And nobody is allowed in the server room other than IT admins without escort.. So why should the screen saver kick in and force me to reauth in 2 minutes.. Why can I not set it to 20 minutes..

Why do I need to change the emergency admin passwords, that are unique for every machine and locked in the safe in a sealed envelope every 90 days.. When the passwords have never been used? And nobody knows them to have possible leaked them.

jrey

@johnpoz said in After Update 2.7.2 / 23.09.1:

auditors are idiots - most of them are, and many of them don't even understand what is going on

No argument here on any of the statements you've made in that but especially the line quoted above ...

I too have been around this block way to many times.

I'm not expecting the pfSense folks to fix anything in this regard, just more of "would be really nice if" type comment. Versioning is a big issue and as we all know fixing at the level we are talking about is unlikely happen.

Why do I need to change the emergency admin passwords, that are unique for every machine and locked in the safe in a sealed envelope every 90 days

Right?

The answer of course is "because of the auditors" You might have jump off a cliff and take the other people that have access to the cabinet with you. Then it is someone else's problem how to get into the locked cabinet and more technically challenging, open the envelop.
Fair Warning: I'm taking the combination or key or whatever it is with me... just sayin' (wait is the combination/key is yet another locked and secure location?) ...

I was actually in a location not too long ago where all the locked in a cabinet requirements where followed. But then there was a yellow sticky note on each machine with the alternate admin account password stuck to the side of the machine. Brilliant, why didn't I think of that. That was fun. Shake your head, walk (no run) away.

There should be a forum group/branch for "Audit Insanity" that would be fun!