Add AlmaLinux and Rocky to RHEL family

[srbala]

Add AlmaLinux and Rocky distribution names to RHEL OS family for identification

https://github.com/aquasecurity/trivy/issues?q=is%3Aissue+is%3Aopen+almalinux

[srbala]

@knqyf263 Thanks for PR merge. Is trivy ready for AlmaLinux scanning or more work/release required?

[knqyf263]

Hi @srbala, we need to merge these two PRs in addition.
aquasecurity/trivy-db#149
aquasecurity/trivy#1238

But we're facing an issue. If there are two packages with the same name but different releases, how will the package used be selected? For example, nodejs-packaging has two types of releases, el8.3.0 and el8.4.0.

nodejs-packaging-23-3.module_el8.3.0+2049+b92e1eb6.noarch.rpm 2021-03-11 20:41 23K

https://ftp.riken.jp/Linux/almalinux/8.3/AppStream/x86_64/os/Packages/

nodejs-packaging-23-3.module_el8.3.0+2049+b92e1eb6.noarch.rpm 2021-03-11 20:41 23K
nodejs-packaging-23-3.module_el8.4.0+2522+3bd42762.noarch.rpm 2021-08-11 18:07 23K

https://ftp.riken.jp/Linux/almalinux/8.4/AppStream/x86_64/os/Packages/

If we display details of nodje-packaging in AlmaLinux 8.4, it shows el8.3.0.

[root@6d7b2ad82b37 /]# cat /etc/almalinux-release
AlmaLinux release 8.4 (Electric Cheetah)
[root@6d7b2ad82b37 /]# dnf info nodejs-packaging
Failed to set locale, defaulting to C.UTF-8
Last metadata expiration check: 0:00:33 ago on Sun Sep 19 11:20:09 2021.
Available Packages
Name         : nodejs-packaging
Version      : 17
Release      : 3.module_el8.3.0+2047+b07ac28e
Architecture : noarch
Size         : 19 k
Source       : nodejs-packaging-17-3.module_el8.3.0+2047+b07ac28e.src.rpm
Repository   : appstream
Summary      : RPM Macros and Utilities for Node.js Packaging
URL          : https://fedoraproject.org/wiki/Node.js/Packagers
License      : MIT
Description  : This package contains RPM macros and other utilities useful for packaging
             : Node.js modules and applications in RPM-based distributions.

Also, there are two advisories respectively.
https://github.com/aquasecurity/vuln-list/blob/f2963c8c490d048eefbf0ab270d38fa44aba67b5/alma/8/2021/ALSA-2021:0551.json#L18-L65

Which advisory should we take? Or, if we should take both advisories, how can we select one of them for vulnerability detection?

The website mentions only el8.4.0.
https://errata.almalinux.org/8/ALSA-2021-0551.html

Thanks.

[srbala]

Three versions nodejs is shipped with AlmaLinux, default is set to nodejs:10, when it changed to nodjs:14 it picks up el8_4 rpms, same way as RHEL

$ docker run --rm -it almalinux 
[root@73296dbe39c0 /]# dnf module list nodejs
Name                     Stream                   Profiles                                                Summary                            
nodejs                   10 [d]                   common [d], development, minimal, s2i                   Javascript runtime                 
nodejs                   12                       common [d], development, minimal, s2i                   Javascript runtime                 
nodejs                   14                       common [d], development, minimal, s2i                   Javascript runtime                 

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled
[root@73296dbe39c0 /]# dnf info nodejs-packaging
Available Packages
Name         : nodejs-packaging
Version      : 17
Release      : 3.module_el8.3.0+2047+b07ac28e
Architecture : noarch
Size         : 19 k
Source       : nodejs-packaging-17-3.module_el8.3.0+2047+b07ac28e.src.rpm
Repository   : appstream
Summary      : RPM Macros and Utilities for Node.js Packaging
URL          : https://fedoraproject.org/wiki/Node.js/Packagers
License      : MIT
Description  : This package contains RPM macros and other utilities useful for packaging
             : Node.js modules and applications in RPM-based distributions.

[root@73296dbe39c0 /]# dnf module enable nodejs:14
Last metadata expiration check: 0:09:26 ago on Sun Sep 19 21:44:36 2021.
Dependencies resolved.
=============================================================================================================================================
 Package                          Architecture                    Version                             Repository                        Size
=============================================================================================================================================
Enabling module streams:
 nodejs                                                           14                                                                        

Transaction Summary
=============================================================================================================================================

Is this ok [y/N]: y
Complete!
[root@73296dbe39c0 /]# dnf info nodejs-packaging
Last metadata expiration check: 0:09:41 ago on Sun Sep 19 21:44:36 2021.
Available Packages
Name         : nodejs-packaging
Version      : 23
Release      : 3.module_el8.4.0+2522+3bd42762
Architecture : noarch
Size         : 23 k
Source       : nodejs-packaging-23-3.module_el8.4.0+2522+3bd42762.src.rpm
Repository   : appstream
Summary      : RPM Macros and Utilities for Node.js Packaging
URL          : https://fedoraproject.org/wiki/Node.js/Packagers
License      : MIT
Description  : This package contains RPM macros and other utilities useful for packaging
             : Node.js modules and applications in RPM-based distributions.

[srbala]

Which advisory should we take? Or, if we should take both advisories, how can we select one of them for vulnerability detection?

@knqyf263 As inidicated above both advisories are applicable since both versions are supported

The website mentions only el8.4.0.
https://errata.almalinux.org/8/ALSA-2021-0551.html

AlmaLinux was released few months before 8.4 release, it would be appropriate that issues reported prior to the release and not yet fixed OR wont-fixed should added to the list, is that Correct? I can discuss with the community for it.

[srbala]

Carl has some input in the thread below, might help here?
aquasecurity/trivy#1053 (comment)

[knqyf263]

@srbala Thanks for the explanation! I might not understand correctly, but if they are from different stream, why are there two fixed versions in the same advisory?
https://github.com/aquasecurity/vuln-list/blob/f2963c8c490d048eefbf0ab270d38fa44aba67b5/alma/8/2021/ALSA-2021:0551.json#L18-L65

There are nodejs-packaging-23-3.module_el8.4.0+2522+3bd42762 and nodejs-packaging-23-3.module_el8.3.0+2022+0cf59502. Also, the advisory says the stream nodejs:14.
https://github.com/aquasecurity/vuln-list/blob/f2963c8c490d048eefbf0ab270d38fa44aba67b5/alma/8/2021/ALSA-2021:0551.json#L67-L73

Carl has some input in the thread below, might help here?

Yes, I looked into it, but I still don't understand why the above advisory provides two fixed versions.

[srbala]

@carlwgeorge @andrewlukoshko Please review above and advise

[knqyf263]

I guess this advisory was ported from RHSA-2021:0551, but it looks like the fixed version of nodejs-nodemon is 2.0.3-1.module+el8.3.0+6519+9f98ed83.noarch.rpm in RHEL 8.
https://access.redhat.com/errata/RHSA-2021:0551

It would be really helpful if you tell us how we should handle the two fixed versions in Alma errata.

[knqyf263]

@srbala @AndreyLevchenko Any updates? I wanted to include the AlmaLinux support in the next version.

[srbala]

@knqyf263 My knowledge is limited, @jaboutboul is reaching out someone to review/response

[andrewlukoshko]

@knqyf263 Hello. Sorry for delay.
The situation where two versions of the same package are in the same bulletin is not good and we're trying to avoid that.
But if you see that then the correct version that includes the fix is the earlier one. Newer version is just a rebuild of the same source code with updated module release.

[knqyf263]

@andrewlukoshko Thanks for the response! We saw two versions in ALSA-2021:0551:

• nodejs-packaging-23-3.module_el8.4.0+2522+3bd42762
• nodejs-packaging-23-3.module_el8.3.0+2022+0cf59502

In this case, nodejs-packaging-23-3.module_el8.3.0+2022+0cf59502 is correct, right? If you will improve it shortly, we can wait for it. But if you need some time, we can work around it by comparing versions and taking the earlier one. Then, we'll remove the logic after your improvement.

[andrewlukoshko]

@knqyf263 Let me discuss this with colleagues responsible for Errata.
I'll be back shortly.

[andrewlukoshko]

@knqyf263 Could you please make a workaround for such cases?
We're not sure we'll fix that quickly.

[knqyf263]

OK, thanks for the confirmation.