QSB-067: Multiple RPM vulnerabilities
37 views
Skip to first unread message
Andrew David Wong
Mar 19, 2021, 6:40:02 AM3/19/21
to qubes-a...@googlegroups.com, qubes...@googlegroups.com, qubes...@googlegroups.com
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM
vulnerabilities. The text of this QSB is reproduced below. This QSB and
its accompanying signatures will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
```
---===[ Qubes Security Bulletin 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
or via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls
update.qubes-vm
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
allows for bypassing package signature verification.
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/
--
The Qubes Security Team
https://www.qubes-os.org/security/
```
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/03/19/qsb-067/
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM
vulnerabilities. The text of this QSB is reproduced below. This QSB and
its accompanying signatures will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.txt
Learn about the qubes-secpack, including how to obtain, verify, and read it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
```
---===[ Qubes Security Bulletin 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
or via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls
update.qubes-vm
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
allows for bypassing package signature verification.
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/
--
The Qubes Security Team
https://www.qubes-os.org/security/
```
This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/03/19/qsb-067/
Vít Šesták
Mar 19, 2021, 7:41:41 AM3/19/21
to qubes-users
Hi, I've tried to install the updates. Even after removing systemtap and when using --clean, I am unable to install it. IIUC, I am trying to install it too soon:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing --clean
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
40 files removed
Fedora 25 - x86_64 - Updates 272 kB/s | 24 MB 01:29
Fedora 25 - x86_64 3.6 MB/s | 50 MB 00:14
Qubes Dom0 Repository (updates) 1.3 MB/s | 1.3 MB 00:01
Qubes Dom0 Repository (security-testing) 1.5 MB/s | 3.0 MB 00:02
determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- ETA
Qubes Templates repository 2.2 kB/s | 5.9 kB 00:02
Error:
Problem 1: problem with installed package satyr-0.21-2.fc25.x86_64
- cannot install the best update candidate for package satyr-0.21-2.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by satyr-0.21-2.1.fc25.x86_64
Problem 2: problem with installed package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64
- cannot install the best update candidate for package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64
- nothing provides rpm >= 4.14 needed by qubes-core-dom0-linux-4.0.29-1.fc25.x86_64
Problem 3: problem with installed package python3-hawkey-0.6.4-3.fc25.x86_64
- cannot install the best update candidate for package python3-hawkey-0.6.4-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64
Problem 4: problem with installed package libsolv-0.6.29-2.fc25.x86_64
- cannot install the best update candidate for package libsolv-0.6.29-2.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by libsolv-0.6.29-2.1.fc25.x86_64
Problem 5: problem with installed package hawkey-0.6.4-3.fc25.x86_64
- cannot install the best update candidate for package hawkey-0.6.4-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64
Problem 6: problem with installed package drpm-0.3.0-3.fc25.x86_64
- cannot install the best update candidate for package drpm-0.3.0-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64
Problem 7: problem with installed package deltarpm-3.6-17.fc25.x86_64
- cannot install the best update candidate for package deltarpm-3.6-17.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
Problem 8: problem with installed package createrepo_c-libs-0.10.0-6.fc25.x86_64
- cannot install the best update candidate for package createrepo_c-libs-0.10.0-6.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64
Problem 9: problem with installed package createrepo_c-0.10.0-6.fc25.x86_64
- cannot install the best update candidate for package createrepo_c-0.10.0-6.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64
Problem 10: problem with installed package PackageKit-1.1.5-1.fc25.x86_64
- cannot install the best update candidate for package PackageKit-1.1.5-1.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64
Problem 11: problem with installed package python2-deltarpm-3.6-17.fc25.x86_64
- cannot install the best update candidate for package python2-deltarpm-3.6-17.fc25.x86_64
- package python2-deltarpm-3.6-17.1.fc25.x86_64 requires deltarpm(x86-64) = 3.6-17.1.fc25, but none of the providers can be installed
- nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
40 files removed
Fedora 25 - x86_64 - Updates 272 kB/s | 24 MB 01:29
Fedora 25 - x86_64 3.6 MB/s | 50 MB 00:14
Qubes Dom0 Repository (updates) 1.3 MB/s | 1.3 MB 00:01
Qubes Dom0 Repository (security-testing) 1.5 MB/s | 3.0 MB 00:02
determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- ETA
Qubes Templates repository 2.2 kB/s | 5.9 kB 00:02
Error:
Problem 1: problem with installed package satyr-0.21-2.fc25.x86_64
- cannot install the best update candidate for package satyr-0.21-2.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by satyr-0.21-2.1.fc25.x86_64
Problem 2: problem with installed package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64
- cannot install the best update candidate for package qubes-core-dom0-linux-4.0.28-1.fc25.x86_64
- nothing provides rpm >= 4.14 needed by qubes-core-dom0-linux-4.0.29-1.fc25.x86_64
Problem 3: problem with installed package python3-hawkey-0.6.4-3.fc25.x86_64
- cannot install the best update candidate for package python3-hawkey-0.6.4-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by python3-hawkey-0.6.4-3.1.fc25.x86_64
Problem 4: problem with installed package libsolv-0.6.29-2.fc25.x86_64
- cannot install the best update candidate for package libsolv-0.6.29-2.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by libsolv-0.6.29-2.1.fc25.x86_64
Problem 5: problem with installed package hawkey-0.6.4-3.fc25.x86_64
- cannot install the best update candidate for package hawkey-0.6.4-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by hawkey-0.6.4-3.1.fc25.x86_64
Problem 6: problem with installed package drpm-0.3.0-3.fc25.x86_64
- cannot install the best update candidate for package drpm-0.3.0-3.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by drpm-0.3.0-3.1.fc25.x86_64
Problem 7: problem with installed package deltarpm-3.6-17.fc25.x86_64
- cannot install the best update candidate for package deltarpm-3.6-17.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
Problem 8: problem with installed package createrepo_c-libs-0.10.0-6.fc25.x86_64
- cannot install the best update candidate for package createrepo_c-libs-0.10.0-6.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by createrepo_c-libs-0.10.0-6.1.fc25.x86_64
Problem 9: problem with installed package createrepo_c-0.10.0-6.fc25.x86_64
- cannot install the best update candidate for package createrepo_c-0.10.0-6.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by createrepo_c-0.10.0-6.1.fc25.x86_64
Problem 10: problem with installed package PackageKit-1.1.5-1.fc25.x86_64
- cannot install the best update candidate for package PackageKit-1.1.5-1.fc25.x86_64
- nothing provides librpm.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by PackageKit-1.1.5-1.1.fc25.x86_64
Problem 11: problem with installed package python2-deltarpm-3.6-17.fc25.x86_64
- cannot install the best update candidate for package python2-deltarpm-3.6-17.fc25.x86_64
- package python2-deltarpm-3.6-17.1.fc25.x86_64 requires deltarpm(x86-64) = 3.6-17.1.fc25, but none of the providers can be installed
- nothing provides librpm.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
- nothing provides librpmio.so.8()(64bit) needed by deltarpm-3.6-17.1.fc25.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Regards,
Vít Šesták 'v6ak'
Vít Šesták 'v6ak'
Andrew David Wong
Mar 19, 2021, 8:59:48 AM3/19/21
to Vít Šesták, qubes-users
directly about this.
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
Vít Šesták
Mar 19, 2021, 6:12:09 PM3/19/21
to qubes-users
It seems to have been fixed now. The dom0 updates have passed. The DomU Fedora updates have succeeded with updating the macros.qubes file, which is supposingly the workaround by Qubes team.
Regards,
Vít Šesták 'v6ak'
Vít Šesták 'v6ak'
Andrew David Wong
Mar 19, 2021, 6:42:41 PM3/19/21
to Vít Šesták, Marek Marczykowski-Górecki, Demi M. Obenour, qubes-users
On 3/19/21 3:12 PM, Vít Šesták wrote:
> It seems to have been fixed now. The dom0 updates have passed. The DomU
> Fedora updates have succeeded with updating the macros.qubes file, which is
> supposingly the workaround by Qubes team.
>
> Regards,
> Vít Šesták 'v6ak'
>
I now realize that we neglected to state, in the QSB, what the desired
> It seems to have been fixed now. The dom0 updates have passed. The DomU
> Fedora updates have succeeded with updating the macros.qubes file, which is
> supposingly the workaround by Qubes team.
>
> Regards,
> Vít Šesták 'v6ak'
>
result from updating Fedora-based TemplateVMs and StandaloneVMs should
be. I presume this is it:
----------
ID: /usr/lib/rpm/macros.d/macros.qubes
Function: file.managed
Result: True
Comment: File /usr/lib/rpm/macros.d/macros.qubes updated
Started: <time>
Duration: <duration>
Changes:
----------
diff:
New file
----------
ID: dnf-makecache
Function: cmd.script
Result: True
Comment: DNF cache successfully created
Started: <time>
Duration: <duration>
Changes:
----------
Marek or Demi, can you confirm?
P.S. -- Please avoid top-posting, Vít.
Vít Šesták
Mar 19, 2021, 7:09:26 PM3/19/21
to qubes-users
Thank you, it seems that my update is successful.
On Friday, March 19, 2021 at 11:42:41 PM UTC+1 a...@qubes-os.org wrote:
P.S. -- Please avoid top-posting, Vít.
Sorry for that, I sometimes forget to remove the quoted text. Anyway, I top post only if the quoted text is not important, i.e. when I don't quote selectively.
Regards,
Vít Šesták 'v6ak'
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
Mar 19, 2021, 7:35:52 PM3/19/21
to Andrew David Wong, Vít Šesták, Demi M. Obenour, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yes this seems right (in subsequent runs, the
/usr/lib/rpm/macros.d/macros.qubes state will not have "New file"
comment, but will still have "Result: True").
Below you should also see a summary with "Failed: 0".
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBVNVIACgkQ24/THMrX
1yzSRAf+MghA3DpM18Rqikkcc3Qg9+ZEZsvXNr4cc+ZYVFLUWfdSQyVzNzMUcmPl
Y5Y6TGAjbTIJ0ni87FPMws+TeIa3SuYWwhzMk0c1NQhajOznQ9/k6HaLb3M/fpLn
mJB9KKgOtZntt3FsvysYfDPHiZ5udQVlXdD3pabOlpfZaO1+VUdwZoDlmVUdAGxa
6PZX/edN3ENuoc6FA50PNqswHZ0eSnLuh/Dyx9DcRcz/8lDn/Zs3q6u/D2WJojn0
gIs9U1ZH2u/y7jh1nbYpYpWrrLe9+gVHe7KyPg7YiggFxfz+sQMFFLlj4xA+sd4N
M5u12yktJEblUoHinSIFBHSXoqQR1Q==
=CvtC
-----END PGP SIGNATURE-----
Hash: SHA256
/usr/lib/rpm/macros.d/macros.qubes state will not have "New file"
comment, but will still have "Result: True").
Below you should also see a summary with "Failed: 0".
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBVNVIACgkQ24/THMrX
1yzSRAf+MghA3DpM18Rqikkcc3Qg9+ZEZsvXNr4cc+ZYVFLUWfdSQyVzNzMUcmPl
Y5Y6TGAjbTIJ0ni87FPMws+TeIa3SuYWwhzMk0c1NQhajOznQ9/k6HaLb3M/fpLn
mJB9KKgOtZntt3FsvysYfDPHiZ5udQVlXdD3pabOlpfZaO1+VUdwZoDlmVUdAGxa
6PZX/edN3ENuoc6FA50PNqswHZ0eSnLuh/Dyx9DcRcz/8lDn/Zs3q6u/D2WJojn0
gIs9U1ZH2u/y7jh1nbYpYpWrrLe9+gVHe7KyPg7YiggFxfz+sQMFFLlj4xA+sd4N
M5u12yktJEblUoHinSIFBHSXoqQR1Q==
=CvtC
-----END PGP SIGNATURE-----
Andrew David Wong
Mar 19, 2021, 7:49:27 PM3/19/21
to Marek Marczykowski-Górecki, Vít Šesták, Demi M. Obenour, qubes-users
However, on a few update attempts, I saw this:
Function: cmd.script
Result: False
Comment: Could not create DNF metadata cache
Started: <time>
Duration: <duration>
Changes:
----------
ID: update
Duration: <duration>
Changes:
----------
Function: pkg.uptodate
Result: False
Comment: One or more requisite failed: update.qubes-vm.dnf-makecache
Started: <time>
Duration: <duration>
Changes:
----------
Subsequent attempts were successful (had the expected output), though.
Duration: <duration>
Changes:
----------
lama...@gmail.com
Apr 2, 2021, 9:46:04 AM4/2/21
to qubes-users
Maybe it should be stated explicitly that Qubes update tool or qubesctl is needed and just updating manually through vm or Qube Manager is not sufficient.
Btw, the workaround can also be confirmed by updating manually through vm or Qubes Manager, dnf will then state that GPG signature check is enforced globally.
Reply all
Reply to author
Forward
0 new messages