Confusion over Rocky8 subversion packages (errata/modules/default)

[praines]

After a ‘dnf update’ today that got me to Rocky 8.10 I reboot and run ‘dnf update’ again and I am told everything is up to date.

I then run ‘dnf updateinfo list’ and I get

> # dnf updateinfo list
> Last metadata expiration check: 0:08:21 ago on Tue 11 Jun 2024 11:05:59 AM EDT.
> RLSA-2022:4941 Important/Sec. subversion-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64
> RLBA-2022:7542 bugfix         subversion-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64
> RLSA-2022:4941 Important/Sec. subversion-libs-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64
> RLBA-2022:7542 bugfix         subversion-libs-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64
> RLSA-2022:4941 Important/Sec. subversion-perl-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64
> RLBA-2022:7542 bugfix         subversion-perl-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64

Odd, why did that not update with ‘dnf update’. I run

> # dnf list subversion --showduplicates
> Last metadata expiration check: 0:12:17 ago on Tue 11 Jun 2024 11:05:59 AM EDT.
> Installed Packages
> subversion.x86_64                          1.10.2-5.module+el8.7.0+1065+42200b2e                           @AppStream
> Available Packages
> subversion.x86_64                          1.10.2-5.module+el8.7.0+1065+42200b2e                           Local-AppStream

and this new version is not listed. I have a local mirror repo at /space/centos/8.10 and it is definitely there:

> # find /space/centos/8.10/ -name 'subversion-1.14*'
> /space/centos/8.10/AppStream/x86_64/os/Packages/s/subversion-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64.rpm
> /space/centos/8.10/AppStream/x86_64/kickstart/Packages/s/subversion-1.14.1-2.module+el8.7.0+1066+f8abeb19.x86_64.rpm

Why is this new version not found and installed? I assume it some module strangeness and run

> # dnf module list subversion
> Last metadata expiration check: 0:21:08 ago on Tue 11 Jun 2024 11:05:59 AM EDT.
> Rocky 8 - AppStream (local)
> Name                       Stream                      Profiles                           Summary
> subversion                 1.10 [d][e]                 common [d], server                 Apache Subversion
> subversion                 1.14                        common [d], server                 Apache Subversion
> 
> Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

Okay, so it is new module track for subversion. But I am confused.

1. does the security info mean my old module track is vulnerable and I need to update the module track? Or am I safe sticking to the 1.10 track?
2. if I am not safe, how is one really supposed to stay “safe” now with these module tracks? In the past simply doing ‘dnf update’ periodically (even automated) was supposed to do that. Is that no longer the case?

[iwalker]

Because the default and enabled subversion module stream is 1.10, what you can see above with the [d][e]. You would have to do:

dnf module enable subversion:1.14

[praines]

Yes, I understand what I would have to do manually to update to the newer stream. But my question is do I NEED to from a security standpoint. Is the 1.10 stream to be considered safe? And if not how is one really supposed to automate a box keeping up to date with security issues when these module streams are involved?

[iwalker]

@praines

Is the 1.10 stream to be considered safe?

Yes, it’s safe. Red Hat generally backport fixes to the versions in their system. So sometimes you would see, for example, fixes from subversion 1.14 applied to 1.10 if that version was affected.

[praines]

Okay, thanks. I guess then ‘dnf updateinfo’ is just not very "module aware’ (yet).

[iwalker]

With modules, you would basically choose yourself a stream. Had you chosen eg: 1.14, then any updates applied to subversion 1.14 you would have gotten.

Prior to module streams, there was only a set version of say Apache or Nginx. You would never see that Apache or Nginx version increased - let’s use subversion as an example. So prior to module streams, subversion would have been 1.10 and that is all. Any updates would be applied to it, and any fixes eg: 1.14 would be backported to fix what is vulnerable in 1.10. The version though will still remain 1.10.

The idea with the module streams is that you have a choice to use the default subversion, or use the newer one. If you do a dnf module list for nginx or apache, you’ll see a lot more versions available to choose from. Red Hat always set a default one. It will never do an automatic update from 1.10 to 1.14. That’s not the idea of the module streams. The idea is to allow you to choose a different version, which subsequently will get updates/fixes.

Hope that clears it up a bit

[praines]

I am just saying it would be nice if ‘dnf updateinfo’ was more module aware so it would not report security updates for streams you are not on. This is how my confusion all started.