Daily Security Run Lists db5 As Vulnerable

I am getting the following at the bottom of my Daily Security Run report::

Code:
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 instead

So, I installed db18, however, when I try to remove db5 with "pkg remove db5" then pkg wants to also remove six other dependent packages as follows:

Code:
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 7 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        apache24: 2.4.52
        apr: 1.7.0.1.6.1_1
        db5: 5.3.28_8
        mod_php74: 7.4.27
        portupgrade: 2.4.16,2
        ruby27-bdb: 0.6.6_8
        serf: 1.3.9_6

Number of packages to be removed: 7

The operation will free 86 MiB.

Proceed with deinstalling packages? [y/N]:N

Obviously, I need to keep these other dependent packages. So, how do I remove db5 and migrate to db18 for the dependent packages?

As an FYI, I installed all of the binaries on my server with pkg instead of ports except for exim and dovecot which were installed from ports since I needed to customize those configurations.

Thanks,

Gordon
 
packages - you wait until those packages are upgraded with the new dependency. For quarterly packages, this can take a while.
 
  • Like
Reactions: mer
Three solutions, two of them involve building from ports.

  1. Build www/apache24 and devel/apr from ports and disable the BDB option. That removes the dependency entirely.
  2. Set DEFAULT_VERSIONS+= bdb=18 in /etc/make.conf and build www/apache24 and devel/apr from ports. This will change the dependency to databases/db18.
  3. Do nothing. Wait for this to resolve itself. The removal of databases/db5 is scheduled for 30 June. Individual ports will either switch to databases/db18 or remove this dependency before that time. As we say down here, there's no blood running out of it, so no need to panic.
 
Last edited:
Tingo and SirDice,

Thanks very much for your replies. I will wait until the dependent packages are upgraded as you suggested.

Thanks again,

Gordon
 
This raises mixed feelings for me.

On one hand, if advance deprecation warnings are for port maintainers and packagers, those are the people they should be sent to. Sending them to users just causes noise which makes the security e-mail harder to read and interpret. Users need to know when they need to do something, not when maintainers need to do something.

On the other hand, if the system actually uses db5 or php74 other than as a back-end dependency for something else, the user might well need to prepare to migrate as that kind of upgrade is not always backward-compatible. PHP 8.1 tightens security over PHP 7.4 and support for some ways of doing things has been dropped, so server scripts might break, so some users do need these messages to enable them to correct problems before applying the changes to live servers.

So FreeBSD wouldn't be able to please everyone whichever approach it took!
 
On one hand, if advance deprecation warnings are for port maintainers and packagers, those are the people they should be sent to. Sending them to users just causes noise which makes the security e-mail harder to read and interpret.
Not really, I love those notifications.

I often use non-default versions, such as more recent versions of PHP or Python. I've previously entered lines in my make.conf to address this.

I've just never gone from version 5 to version 18 in a single go before, hence my hesitancy. SirDIce basically told me it was safe in this instance to do what I've done before. And they were right!
 
We're in June and this warning has been around for nearly 3 months now, and still apr has not been upgraded to change its dependency on db5. Beginning to feel concerned I've tried looking for apr in ports to find out who maintains it but it's not there! Instead (I presume) we have devel/apr1. So it appears apr has been dropped in favour of apr1.
 
Thanks for clarifying. However, I think I'm still right to feel concerned, so I'm delving a little deeper into poudriere and apr, but I think that's probably for another thread as otherwise this one will go down a particular route not relevant to most people.
 
BDB version in ports is handled by DEFAULT_VERSIONS as already mentioned earlier. So, nothing to be concerned about ports consuming BDB, they automatically depend on the default version. You could ask why the default version wasn't changed yet though. Probably some problems with a few consumers? Or maybe just "didn't find the time yet" ;)
 
Hypothetically, if the package is not upgraded before the EOL date, what will happen? The message has me a little worried that it will get uninstalled along with all of its dependencies, Apache in particular. Hopefully that is not the case, but the "EOLd" part tends to suggest it.

Also hypothetically, if I need to install a new server after the EOL date, will I even be able to do it? Presumably the package won't get offered after that, but Apache still depends on it. Or will the package still be available?

(I don't want to build the server myself from ports, I much prefer using the binary packages. At least for the time being.)

Thanks.
 
It will be removed from the available list of packages to be installed. Apache24 actually depends on db >=5 so if it can't find 5 I presume it will look for the next higher version when rebuilt or being installed.

However, deleting it from ports and packages isn't going to change anything installed on your computer until your next pkg upgrade, when the change to the new version will happen. Even then, you'll be asked to review the changes and approve them before it goes ahead.

Unless you've set your machine up with cron jobs to make these changes automatically (in which case disable those jobs) nothing's going to be done to your computer without your action and if you don't like what's proposed just type "N".
 
Blech, I recalled that Oracle had screwed up BDB somehow but messing with the license for versions > 5 I didn't know about. Affected ports should build without it by default..
 
Rest assured, they're not going to rip out db5 and break a bunch of ports that still have a dependency on it.
 
I don't find that reassuring. I find it worrying. This unmaintained and potentially insecure program is still the default dependency of applications which had three months to be checked with a later, more secure, version, and the deadline set has been missed. When will "they" be able to remove this outdated port so applications build by default on something more secure?
 
I must admit, I had hoped that the db5 situation would be resolved long before now. We are nearing one year of EOL for it and it is still a part of my setup, which is rather worrying. Is there anything I can do to help, considering that I know nothing at all about FreeBSD internals and/or development?
 
Back
Top