# Having trouble with RLSA-2022:5467 **URL:** \ **Category:** Rocky Linux Help & Support\ **Created:** [July 25, 2023, 4:35pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800 "2023-07-25T16:35:55Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![jevans](https://avatars.discourse-cdn.com/v4/letter/j/f08c70/32.png) [@jevans](https://forums.rockylinux.org/u/jevans)\ **Post date:** [July 25, 2023, 4:35pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800/1 "2023-07-25T16:35:56Z")
Hi folks, I’m pulling my hair out over [RLSA-2022:5467](https://errata.rockylinux.org/RLSA-2022:5467), having noticed that two packages listed as being affected, libzip and php-pecl-zip, aren’t being updated on my systems via dnf. We’re using the php:7.4 module, but I don’t see that being relevent since php-pecl-zip isn’t tied to that module. The package versions on my system are - ``` libzip-1.6.1-1.module+el8.6.0+789+2130c178.x86_64 ``` - ``` php-pecl-zip-1.18.2-1.module+el8.6.0+789+2130c178.x86_64 ``` and the updated packages that I see on the mirrors are - ``` libzip-1.7.3-1.module+el8.6.0+790+fc63e43f.x86_64 ``` - ``` php-pecl-zip-1.19.2-1.module+el8.6.0+790+fc63e43f.x86_64 ``` There are other packages listed in RLSA-2022:5467, but they’ve all updated just fine. Nothing seems to depend on php-pecl-zip, so I was suspecting the issue must be libzip. The 1.6.1 version provides libzip.so.5.1, whereas the 1.7.3 version provides libzip.so.5.3, but when I try to look at the local packages on my system with various incantations of `dnf repoquery --requires ...` to see if anything is specifically tied to libzip.so.5.1, nothing comes up (they all just list libzip.so.5, as expected?). Building the RPMs for libzip and php-pecl-zip from the updated SRPMs and manually installing them works just fine, no incompatibilites encountered. In fact, just manually installing the updated php-pecl-zip RPM works with the 1.6.1 libzip, so that seems to shoot down my original theory that libzip was the issue. It’s not a mirror issue… I’ve spun up VMs with Alma Linux and CentOS 8 Stream, and I see the same thing. So I’m puzzled, I feel like I’m not seeing something pretty basic here. ---
**Author:** ![Ritov](https://avatars.discourse-cdn.com/v4/letter/r/3ec8ea/32.png) [@Ritov](https://forums.rockylinux.org/u/Ritov)\ **Post date:** [July 25, 2023, 5:52pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800/2 "2023-07-25T17:52:02Z")
Whats the output of: ```auto dnf module list php ``` and ```auto rpm -qi php-pecl-zip libzip ``` ---
**Author:** ![jevans](https://avatars.discourse-cdn.com/v4/letter/j/f08c70/32.png) [@jevans](https://forums.rockylinux.org/u/jevans)\ **Post date:** [July 25, 2023, 6:16pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800/3 "2023-07-25T18:16:52Z")
```auto $ dnf module list php Last metadata expiration check: 5:00:46 ago on Tue 25 Jul 2023 07:13:16 AM MDT. Rocky Linux 8 - AppStream Name Stream Profiles Summary php 7.2 [d] common [d], devel, minimal PHP scripting language php 7.3 common [d], devel, minimal PHP scripting language php 7.4 [e] common [d], devel, minimal PHP scripting language php 8.0 common [d], devel, minimal PHP scripting language Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled ``` ```auto $ rpm -qi php-pecl-zip libzip Name : php-pecl-zip Version : 1.18.2 Release : 1.module+el8.6.0+789+2130c178 Architecture: x86_64 Install Date: Tue 25 Jul 2023 10:28:05 AM MDT Group : Unspecified Size : 137193 License : PHP Signature : RSA/SHA256, Tue 10 May 2022 10:58:25 AM MDT, Key ID 15af5dac6d745a60 Source RPM : php-pecl-zip-1.18.2-1.module+el8.6.0+789+2130c178.src.rpm Build Date : Tue 10 May 2022 10:19:54 AM MDT Build Host : ord1-prod-x86build003.svc.aws.rockylinux.org Relocations : (not relocatable) Packager : infrastructure@rockylinux.org Vendor : Rocky URL : https://pecl.php.net/package/zip Summary : A ZIP archive management extension Description : Zip is an extension to create and read zip files. Name : libzip Version : 1.6.1 Release : 1.module+el8.6.0+789+2130c178 Architecture: x86_64 Install Date: Tue 25 Jul 2023 10:12:41 AM MDT Group : Unspecified Size : 115172 License : BSD Signature : RSA/SHA256, Tue 10 May 2022 10:51:12 AM MDT, Key ID 15af5dac6d745a60 Source RPM : libzip-1.6.1-1.module+el8.6.0+789+2130c178.src.rpm Build Date : Tue 10 May 2022 10:03:54 AM MDT Build Host : ord1-prod-x86build001.svc.aws.rockylinux.org Relocations : (not relocatable) Packager : infrastructure@rockylinux.org Vendor : Rocky URL : https://libzip.org/ Summary : C library for reading, creating, and modifying zip archives Description : libzip is a C library for reading, creating, and modifying zip archives. Files can be added from data buffers, files, or compressed data copied directly from other zip archives. Changes made without closing the archive can be reverted. The API is documented by man pages ``` ---
**Author:** ![Ritov](https://avatars.discourse-cdn.com/v4/letter/r/3ec8ea/32.png) [@Ritov](https://forums.rockylinux.org/u/Ritov)\ **Post date:** [July 25, 2023, 6:45pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800/4 "2023-07-25T18:45:40Z")
> [@jevans](#): > > ```auto > php 8.0 common [d], devel, minimal PHP scripting language > > ``` The newer packages that you mentioned are part of the php:8.0 stream and do not belong to the php7.4. This is also reflected in the mentioned errata … ---
**Author:** ![jevans](https://avatars.discourse-cdn.com/v4/letter/j/f08c70/32.png) [@jevans](https://forums.rockylinux.org/u/jevans)\ **Post date:** [July 26, 2023, 4:23pm UTC](https://forums.rockylinux.org/t/having-trouble-with-rlsa-2022-5467/10800/5 "2023-07-26T16:23:50Z")
I agree, from the output of 'dnf module info php:8.0" , those two newer packages do not belong to php:7.4. The changelogs of the packages listed in the errata do reflect that the CVE was addressed, EXCEPT for the two packages in question. So, I think that libzip and php-pecl-zip should not have been included in the errata. The reason I’m torqued about this is that an independent auditing tool we use started screaming at me over this.