acknownledge EOLed 'security vulnerabilities' in daily run output

Since www/trac has not been updated to python3 I am stuck with lang/python27.

In my daily security run output email I have suspended notifications only showing me errors and warnings:
$ grep daily_show /etc/periodic.conf
daily_show_success="NO" daily_show_info="NO"

How-ever I now get an email every day reminding I need to upgrade python.
Checking for packages with security vulnerabilities:
python27-2.7.17_1: Tag: expiration_date Value: 2020-12-31
python27-2.7.17_1: Tag: deprecated Value: EOLed upstream

which is generated by /usr/local/etc/periodic/security/410.pkg-audit

I would like to acknowledge and suspend the message, keeping the other security vulnerabilities warnings, any ideas?
 
I don't see a solution (a periodic.conf twiddle) based on the existing code in that script but editing 410.pkg-audit and deleting the 3 occurrences of 'expiration' and 'deprecation' inside the for lists does the trick.

I wouldn't typically recommend disabling security reporting, but most often these reports are false positives. Useless daily noise. These reports could be improved (quieted) substantially by ignoring build dependencies.
 
Maybe the “expecto” utility can help. I’ve written it specifically to filter out useless things from the daily run output, leaving only the really important messages. It has a certain learning curve, though, and requires some time to configure properly.

I have to admit that it’s still Python2, and the included examples are for FreeBSD 9. But migrating it to Python3 is on top of my priority list. :)
 
The warnings do have a purpose: They are meant to nag on you.

If you cannot stand the nagging pass it on to whom it may concern. Write PRs!
If you scan the ports tree for dependency of lang/python2 it still shows that even important ports use it. This problem is not going to be resolved by putting your head in the sand.
Expiration Date EXPIRATION DATE: 2020-12-31

In June 2019 I wrote this:
 
The warnings do have a purpose: They are meant to nag on you.

If you cannot stand the nagging pass it on to whom it may concern. Write PRs!
If you scan the ports tree for Python2 it still shows that even important ports use it. This problem is not going to be resolved by putting your head in the sand.

Yes, that would be the most practical approach. I wonder how viable that is for something like www/trac though. I am already annoyed enough by having to read up on python to hopefully be able to patch some brain dead build systems (which should not rely on python in the first place - period). If it would come down to fixing a whole application i'd probably just curse the upstream and look for workarounds too (until i can replace the application with something not written in python that is).
 
The warnings do have a purpose: They are meant to nag on you.
That’s true, but sometimes you just can’t do anything about it, and then the nagging serves no purpose. Even worse, the flood of nagging messages might hide other messages that are more important to you.

I can tell you that I do whatever I’m able to do, but there are only 24 hours per day, and FreeBSD is not the only hobby I care about (and not even the most important one). When I have the choose between reading some pages of nagging messages and playing Lego with my grand niece, guess what I prefer … ;)
 
It's not as simple as submitting a PR. Plenty of upstream (outside of FreeBSD ports) projects like node.js have legacy dependencies on python 27. I don't wish to receive nightly reminders of this fact for the next 12-18 months while the build dependencies and test frameworks and 3rd party modules of those projects are updated. Therefore, this is a better solution for me, for now:

Bash:
sed -i.bak -e 's/audit expiration deprecation/audit/g' /usr/local/etc/periodic/security/410.pkg-audit
 
I dont mind been warned a port will expire, but they are a bit aggressive, e.g. it claims Bind 9.11 is EOL when upstream it is actually the current supported LTS release. The expiry date is over a year away, a bit too soon to nag. On the flip side it was a good reminder for me to migrate away from python2 packages.
 
Sorry to dig up an old post, but I'm currently facing a similar situation to OP.

In the daily security audit:

Code:
Checking for packages with security vulnerabilities:
Database fetched: Mon Feb 27 03:56:29 GMT 2023
uefi-edk2-bhyve-csm-0.2_3,1: Tag: deprecated Value: Uses Python 2.7 which is EOLed upstream

Which is problematic because:
  • At present, there is no package update that would silence this
  • By spamming it out each day, I'm being trained to not read these emails, or worse, disable them.
  • I don't really have time to fix it myself.

This thread is from 2020. Is there some workaround in 2023?

(In my day job, we run weekly security audits on our Rust codebases with cargo audit. We had a similar issue with this: often it would root up problems that don't get fixed for months and we'd be spammed by stuff we already know about, but can't fix ourselves. The solution I came up with was to allow a warning to be silenced for N days/weeks/months before resuming the spamming. I found this a decent compromise)
 
Well that kind of helped. It added curl to the list of bad packages :)


Code:
Checking for packages with security vulnerabilities:
Database fetched: Wed Mar  1 12:16:00 GMT 2023
curl-7.88.1
uefi-edk2-bhyve-csm-0.2_3,1: Tag: deprecated Value: Uses Python 2.7 which is EOLed upstream

Is there no way to silence the security problems that I've already seen?

(This also raises the question of whether periodic should be automatically updating the database? Or should I have a cron job?)
 
I'm not sure why you're even getting it.

Code:
root@hosaka:~ # pkg version -vRx efi
Updating dicelan repository catalogue...
dicelan repository is up to date.
All repositories are up to date.
uefi-edk2-bhyve-csm-0.2_3,1        =   up-to-date with remote
Only get a signal about curl at the moment:
Code:
root@hosaka:~ # pkg audit
curl-7.88.1 is vulnerable:
  curl -- multiple vulnerabilities
  CVE: CVE-2023-27538
  CVE: CVE-2023-27537
  CVE: CVE-2023-27536
  CVE: CVE-2023-27535
  CVE: CVE-2023-27534
  CVE: CVE-2023-27533
  WWW: https://vuxml.FreeBSD.org/freebsd/0d7d104c-c6fb-11ed-8a4b-080027f5fec9.html

1 problem(s) in 1 installed package(s) found.

sysutils/uefi-edk2-bhyve-csm only has a build dependency on Python 2.7:

Code:
USES=		gmake \
		python:2.7,build

You might want to run pkg-autoremove(8) and remove a bunch of build and/or outdated dependencies.
 
Well that is curious...

Code:
$ doas pkg info uefi-edk2-bhyve-csm
uefi-edk2-bhyve-csm-0.2_3,1
Name           : uefi-edk2-bhyve-csm
Version        : 0.2_3,1
Installed on   : Thu Feb 23 20:30:59 2023 GMT
Origin         : sysutils/uefi-edk2-bhyve-csm
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : BSD2CLAUSE
Maintainer     : bcran@FreeBSD.org
WWW            : https://github.com/freebsd/uefi-edk2/tree/bhyve/UDK2014.SP1
Comment        : UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
Options        :
    DEBUG          : off
Annotations    :
    FreeBSD_version: 1301000
    deprecated     : Uses Python 2.7 which is EOLed upstream
    repo_type      : binary
    repository     : FreeBSD
...

What could have gone wrong?
 
The only obvious difference is that I use my own repositories. And this system is 13-STABLE, not a -RELEASE.

Code:
root@hosaka:~ # pkg info uefi-edk2-bhyve-csm
uefi-edk2-bhyve-csm-0.2_3,1
Name           : uefi-edk2-bhyve-csm
Version        : 0.2_3,1
Installed on   : Sun Apr  4 15:40:20 2021 CEST
Origin         : sysutils/uefi-edk2-bhyve-csm
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : BSD2CLAUSE
Maintainer     : bcran@FreeBSD.org
WWW            : https://github.com/freebsd/uefi-edk2/tree/bhyve/UDK2014.SP1
Comment        : UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
Options        :
        DEBUG          : off
Annotations    :
        FreeBSD_version: 1300500
        deprecated     : Uses Python 2.7 which is EOLed upstream
        expiration_date: 2020-12-31
        repo_type      : binary
        repository     : dicelan
Flat size      : 2.00MiB
Description    :
UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS) support.
 
Looks like my package was built a long time ago and hasn't been rebuilt since. It still has an old expiration tag and FreeBSD_version points to 13.0-STABLE, which was quite a while ago. Let me try to force a rebuild of that package.
 
Ah, yes. Forgot about this. Package has been rebuilt in the mean time. Still not getting the audit warning about Python 2.7.

Package info itself has changed a bit:
Code:
root@hosaka:~ # pkg info uefi-edk2-bhyve-csm
uefi-edk2-bhyve-csm-0.2_3,1
Name           : uefi-edk2-bhyve-csm
Version        : 0.2_3,1
Installed on   : Sat Mar 25 19:58:56 2023 CET
Origin         : sysutils/uefi-edk2-bhyve-csm
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : sysutils
Licenses       : BSD2CLAUSE
Maintainer     : bcran@FreeBSD.org
WWW            : https://github.com/freebsd/uefi-edk2/tree/bhyve/UDK2014.SP1
Comment        : UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS)
Options        :
        DEBUG          : off
Annotations    :
        FreeBSD_version: 1302503
        build_timestamp: 2023-03-25T17:48:50+0000
        built_by       : poudriere-git-3.3.99.20220831
        deprecated     : Requires old edk2 version and gcc 4.8.
        expiration_date: 2024-04-01
        port_checkout_unclean: no
        port_git_hash  : 2c8ea965a6
        ports_top_checkout_unclean: no
        ports_top_git_hash: ba3d191679
        repo_type      : binary
        repository     : dicelan
Flat size      : 2.00MiB
Description    :
UEFI EDK2 firmware for bhyve with CSM (16-bit BIOS) support.

And pkg-audit(8) still only complains about curl.
Code:
root@hosaka:~ # pkg audit
curl-7.88.1 is vulnerable:
  curl -- multiple vulnerabilities
  CVE: CVE-2023-27538
  CVE: CVE-2023-27537
  CVE: CVE-2023-27536
  CVE: CVE-2023-27535
  CVE: CVE-2023-27534
  CVE: CVE-2023-27533
  WWW: https://vuxml.FreeBSD.org/freebsd/0d7d104c-c6fb-11ed-8a4b-080027f5fec9.html

1 problem(s) in 1 installed package(s) found.
root@hosaka:~ #

I do get some other messages with the periodic scripts:
Code:
root@hosaka:~ # /usr/local/etc/periodic/security/410.pkg-audit

Checking for packages with security vulnerabilities:
curl-7.88.1
uefi-edk2-bhyve-csm-0.2_3,1: Tag: expiration_date Value: 2024-04-01
zabbix62-agent-6.2.8: Tag: expiration_date Value: 2023-03-31
uefi-edk2-bhyve-csm-0.2_3,1: Tag: deprecated Value: Requires old edk2 version and gcc 4.8.
zabbix62-agent-6.2.8: Tag: deprecated Value: Will reach end of life on 2023-03-31
Yes, I know, need to upgrade Zabbix to 6.4. Server has already been done, still need to update a bunch of agents.
 
So what do we do? Just live with having the same email every day? Disable the email at the risk of missing new package vulnerabilities?
 
I have this warning in my daily mails since ages. What's the problem?
Do not disable periodic mails (if this is a server). The informations you get are very precious.

It's not only about packages, but a plenty of things.

Once, my son brings a malware in my network from his laptop. I saw its presence because it tried to connect to ssh with users / passwords used as default for some commercial IP cam. It was reported by this mail.
 
> I have this warning in my daily mails since ages. What's the problem?

As I explained earlier, if a user gets an email every day about something they already know about, it trains them to ignore the emails. This means when a real issue that they don't know about arises, they won't see it because they didn't read the email.

I'm already not reading these emails...

It's a bit like the classic "boy who cried wolf" story, is it not?
 
Take no offense, but my opinion is: if you are so easily distracted and can't take a handful of seconds to read the mails from your server(s), avoid playing admin.
 
If you ask me, the point of it being annoying is that you annoy upstream and they get it fixed faster, because, seriously Python 2 is a dead end.
 
If I cared I would write a script to filter the unwanted lines and plug it into procmail. I do a similar thing for part of my spam filtering.

From there it is easy enough to have procmail discard the mail entirely when there is no useful line left.

As an added bonus you only have to do this once (on your mail reading machine) and you can filter the cron output of an arbitrary amount of FreeBSD installations from there.
 
Back
Top