Arch Linux

@FLo please test libvirt-6.6.0-1 see [1].

[1] https://bbs.archlinux.org/viewtopic.php?pid=1926534#p1926534

Hi @loqs,

Unfortunately I still got the issue with libvirt-6.6.0-1, here are the logs :

sept. 17 21:11:48 $hostname libvirtd[128123]: libvirt version: 6.6.0
sept. 17 21:11:48 $hostname libvirtd[128123]: hostname: $hostname
sept. 17 21:11:48 $hostname libvirtd[128123]: operation failed: pool 'default' already exists with uuid xxxx-xxxx-xxxx-xxxxx-xxxxxxxxxx
sept. 17 21:11:58 $hostname libvirtd[128123]: Domain id=1 name='win10' uuid=xxxx-xxxx-xxxx-xxxxx-xxxxxxxxxx is tainted: host-cpu
sept. 17 21:11:58 $hostname libvirtd[128123]: internal error: Unable to find major for device-mapper
sept. 17 21:11:58 $hostname libvirtd[128123]: Unable to get devmapper targets for /dev/disk/by-id/ata-Hitachi_xxxxxxxxxxxxxx_xxxxxxxxxxx: Success

Thank you for the very prompt testing. Seems the backport from 6.6 is not the issue but the feature implementation itself has an issue.
There is a libvirt 5.7 PKGBUILD patch that applies on top of 5.5.0-1 attached to [1].

[1] https://bugs.archlinux.org/task/66489#comment192305

Can you please try that. If you need help applying it, I can provide more instructions.

If 5.7.0 has the issue as well then it will probably need to be reported upstream for a fix.

@loqs Thanks a lot for your help !

This is working fine with libvirt-6.7.0-1, here is how i applied the patch :
$ git clone git://git.archlinux.org/svntogit/community.git --single-branch --branch "packages/libvirt"
$ cd community/trunk/
$ curl https://raw.githubusercontent.com/archlinux/svntogit-community/3a55bd48facd239bdbe1c9153cd6cd85444571b7/trunk/PKGBUILD -o PKGBUILD #overwrite PKGBUILD w/ libvirt-6.5.0-1 PKGBUILD
$ curl https://bugs.archlinux.org/task/66489?getfile=19050 | git apply -v #apply the libvirt-6.7.0-1 PKGBUILD patch
$ makepkg -rsi
$ sudo systemctl restart libvirtd

FYI got 2 side issues :
- scream with IVSHMEM error : "can't open backing store /dev/shm/scream-ivshmem for guest RAM: Permission denied"
For now i made a quick and dirty workaround : $ chmod o+r /dev/shm/scream-ivshmem
- virt-manager is not working : "libvirt.libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory"
I did not digged yet, as virsh is working fine.

Please try applying PKGBUILd.diff to libvirt-6.5.0-2. It changes CVE-2020-14339.patch to test3.patch which includes additional commits from 6.7 and updates the checksum.
Edit:
Additional upstream commits included:
34b4b4faf01472377a7e9dc3411efd78e4ed78e1 Remove unused variables
418a7009debc464dc5f53010c0092bdfc9bbb6fa virdevmapper: Don't cache device-mapper major
b024001e0322c6ce58b2c36bbd02addb6ddfe386 virdevmapper: Handle kernel without device-mapper support
928eda2e038d26889683f94ed571a01c839ce36 virdevmapper: Ignore all errors when opening /dev/mapper/control

Sorry i got the following error when applying PKGBUILD.diff on libvirt-6.5.0-2

❯ git apply -v PKGBUILD.diff
Checking patch trunk/CVE-2020-14339.patch...
error: while searching for:
_("Unable to get devmapper targets for %s"),
next->path);
diff --git a/src/util/virdevmapper.c b/src/util/virdevmapper.c
index 40a82285f9..a471504176 100644
--- a/src/util/virdevmapper.c
+++ b/src/util/virdevmapper.c
@@ -20,38 +20,67 @@

#include <config.h>


error: patch failed: trunk/CVE-2020-14339.patch:46
error: trunk/CVE-2020-14339.patch: patch does not apply
Checking patch trunk/PKGBUILD...

Please try the following:

cd src/trunk
git reset --hard
git checkout origin/packages/libvirt
git apply -v PKGBUILD.diff

Done, it is working very well, no issues.

Can also confirm that this fix works well to solve the initial problem.

6.5.0-2 with your test3.path/PKGBUILD.diff seems to be working fine here with kvm guest disks as ZFS zvols - although no versions will build with wireshark is installed unless you use a chroot: https://bugs.archlinux.org/task/63828

Hi. Im facing the same issue on Manjaro and unclear on how to apply the patches provided by loqs on 6.5.0-2, as I'm new to the entire git process. Can someone guide me on where I could download the source of 6.5.0-2 if I have to follow loqs' instructions from #comment192901 ? Thanks in advance.

Hi @RandomJerk,

To download the source :
git clone git://git.archlinux.org/svntogit/community.git --single-branch --branch "packages/libvirt"

To apply the patch :
cd community/trunk/
curl https://bugs.archlinux.org/task/67921?getfile=19132 | git apply -v

Hello, can confirm the issue is resolved after applying PKGBUILD.diff above

Please remove libvirt-6.8.0-1
libvirt 6.6+ was not packaged as there was no chain of trust from the old key to the new.

Is there any upstream ticket for this issue?

I could not find one when the issue was originally explained in [1] so I assumed it was being handled via private communication.

[1] https://bugs.archlinux.org/task/67807#comment192332

A direct mention of the broken trust chain is in [1], which says it is partly because of the pandemic and the flooding attack on the PGP WoT.

[1] https://www.redhat.com/archives/libvirt-announce/2020-July/msg00006.html

Does the new key have to be trusted by the old key as was required in [1] [2] or can trust in the new key be established in some other manner?

[1] https://bugs.archlinux.org/task/65523#comment186477
[2] https://bugs.archlinux.org/task/65523#comment186488

(Sidenote: It seems a little inconsistent that Arch will happily build some pkgs from sources with no cryptographic signature at all.)

Could an Arch team member simply email the new upstream signatory and verify the chain of trust that way?
Or maybe nudge him to update his home page [1]
This would seem acceptable according to a comment from Allan here [2]

[1] https://mamuti.net/public_key.en.html
[2] http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/#comment-1278

Upstream have updated their website [1]. This should be sufficient IMHO.

[1] https://libvirt.org/downloads.html#keys

Please checkout libvirt-6.8.0-1 in [community-testing]. It should include the fix for this issue.

libvirt-6.8.0 was rolled back to libvirt-6.5.0 for reasons unknown..

However, libvirt-python was left at upgraded version 6.8.0.

It turns out libvirt-python-6.8.0 has a bug which breaks virt-manager when dealing with VM snapshots [1].

Do we want a separate issue to track this libvirt-python bug? Or do you want to rollback libvirt-python too?

It all seems a bit messy unfortunately.

[1] https://github.com/virt-manager/virt-manager/issues/170

> for reasons unknown

non-maintainer update containing sweeping changes without discussing it with the maintainer.

libvirt-python should therefore be rolled back too...

To the maintainer/non-mantainer of this package: Please do NOT downgrade the Archlinux official libvirt to 6.5.0-2. This is not working at all with ZFS ZVol, Devmapper is unable to recognize them!

6.8.0 fixes this problem. And 6.5.0-1 didn't have this problem.

This is the error log with "6.5.0-2" package:

"
Unable to complete install: 'Unable to get devmapper targets for /dev/zvol/vmpool/midea: Success'

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/createvm.py", line 2089, in _do_async_install
guest.installer_instance.start_install(guest, meter=meter)
File "/usr/share/virt-manager/virtinst/install/installer.py", line 542, in start_install
domain = self._create_guest(
File "/usr/share/virt-manager/virtinst/install/installer.py", line 491, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python3.8/site-packages/libvirt.py", line 4035, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirt.libvirtError: Unable to get devmapper targets for /dev/zvol/vmpool/midea: Success'

> Please do NOT downgrade the Archlinux official libvirt to 6.5.0-2. This is not working at all with ZFS Zpools,

6.5.0-2 patched with CVE-2020-14339.patch and the 6.7 commits (patch3 and PKGBUILD.diff) seems to work fine with ZFS here.

Yes, please either patch or rollback to 6.5.0-1, a non-broken build

> 6.5.0-2 patched with CVE-2020-14339.patch and the 6.7 commits (patch3 and PKGBUILD.diff) seems to work fine with ZFS here.

Definitely not working with ZFS iSCSI LUNs here. The 6.8 update fixed this, the 6.5 rollback was a very nasty surprise and broke this again.

I hope this gets fixed quickly.

Does someone have a mirror available for 6.5.0-1?

> Does someone have a mirror available for 6.5.0-1?

You can go to archives.archlinux.org and grab it. I rolled back to 6.8 from there and locked it down. This rollback is a no-go for me.

> You can go to archives.archlinux.org and grab it. I rolled back to 6.8 from there and locked it down. This rollback is a no-go for me.

Perfecto, that's what I've been looking for but was not finding. Thank you.

Hi,
with "1:6.5.0-3" the same errors occurs:

$systemctl status libvirtd:
libvirtd[56124]: internal error: Unable to find major for device-mapper
libvirtd[56124]: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success

$virt-manager:
Error starting domain: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
ret = fn(self, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/object/domain.py", line 1330, in startup
self._backend.create()
File "/usr/lib/python3.8/site-packages/libvirt.py", line 1234, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: Unable to get devmapper targets for /dev/zvol/mypoolname/myzvolname: Success

Does anyone know if there is a ticket i can follow for this issue? Same issue as everyone else which there are workaround for but...how is this not fixed yet.

Edit: Finally found it, looks like were "Waiting"

Can the maintainer please try emailing again to verify chain of trust so that we can not have a 3 month out of date libvirt package. Not including this particular issue, there are a variety of features I'm actually interested in utilizing without building my own package.

You're free to try contacting libvirt yourself, inquiring about the chain of trust; Perhaps more users inquiring about this will make them consider using pgp properly...

I've poked via various means, someone else has poked on the public libvirt ML about it as well, and nothing has come from that thus far as far as i can tell.
I just re-checked, and it still doesn't validate from over here. I'm effectively bound by patching the current libvirt until it breaks even more than it already is, or throwing the security considerations out the window...

For me the package is already completely broken. As of yesterday's update to virt-manager if I use downgraded 6.8.0 version I get an error:

Traceback (most recent call last):
File "/usr/bin/virt-manager", line 6, in <module>
from virtManager import virtmanager
File "/usr/share/virt-manager/virtManager/virtmanager.py", line 19, in <module>
from virtinst import BuildConfig
File "/usr/share/virt-manager/virtinst/__init__.py", line 43, in <module>
_set_libvirt_error_handler()
File "/usr/share/virt-manager/virtinst/__init__.py", line 33, in _set_libvirt_error_handler
import libvirt
ModuleNotFoundError: No module named 'libvirt'

And if I use the "current" 1:6.5.0-3 version I am unable to use my disk for VM (original bug report in this thread).
So I can't upgrade and I can't use 6.8.0 version at this point.

By the way Debian has 6.9.0 in their testing and unstable repositories:
https://packages.debian.org/source/bullseye/libvirt
Did they ignore security considerations or they could verify chain of trust?

> Did they ignore security considerations or they could verify chain of trust?

who knows, go ask

> Edit: Finally found it, looks like were "Waiting"

@Stevo, where did find it?

Hello,

I managed to find the new GPG key in the Qubes OS repository, so here it is: https://raw.githubusercontent.com/QubesOS/qubes-core-libvirt/eb8e668080cdba9e3730dbdc5e28d6e1c7473cdc/redhat-jiri-denemark-key.asc, I can verify libvirt 6.9 with this key.

Hope it could help

No, it does not help, unless you can also dig up a path of trust to that key.

You said "it still doesn't validate from over here." Can you be more specific? I can fetch the key using the fingerprint from the libvirt website [1]. It's present on pgp.ocf.berkeley.edu, which is the keyserver advertised by the developer on the libvirt ML [2] (which another contributor confirms). In another libvirt ML thread where the website changes are signed-off, the developer invites feedback on whether or not to include the actual key, and yet another contributor agrees that the key is publicly available [3].

$ gpg --keyserver pgp.ocf.berkeley.edu --recv-keys 453B65310595562855471199CA68BE8010084C9C
gpg: key CA68BE8010084C9C: "Jiří Denemark <jdenemar@redhat.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

$ gpg --verify libvirt-6.10.0.tar.xz.asc libvirt-6.10.0.tar.xz
gpg: Signature made Tue 01 Dec 2020 02:55:41 AM CST
gpg: using RSA key 453B65310595562855471199CA68BE8010084C9C
gpg: Good signature from "Jiří Denemark <jdenemar@redhat.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 453B 6531 0595 5628 5547 1199 CA68 BE80 1008 4C9C

"Good signature" establishes that the pubkey with the fingerprint 453B65310595562855471199CA68BE8010084C9C on pgp.ocf.berkeley.edu indeed did sign the latest release. Either you trust the key's authenticity or you don't. If you don't, can you explain the standard you're seeking so we can assist in digging up the appropriate evidence?

Also, keep in mind that there can be no public web of trust to the signer of 6.5.0 because C74415BA7C9C7F78F02E1DC34606B8A5DE95BC1F is only self-signed. You will see the exact same warning for that signature. What is your path of trust to the signer of 6.5.0?

[1] https://libvirt.org/downloads.html#keys
[2] https://www.redhat.com/archives/libvirt-announce/2020-July/msg00005.html
[3]libvir-list@redhat.com/msg208651.html"> https://www.mail-archive.com/libvir-list@redhat.com/msg208651.html

thanks, i know how pgp works.
the libvirt people are aware. blowing up all the bugreports with the same stuff does, in fact, not make anyone process it faster.

Process what exactly? It's a valid signature, and validpgpkeys specifically ignores trust anyway [1]. What would upstream need to do here?

[1] https://wiki.archlinux.org/index.php/PKGBUILD#validpgpkeys

right, any more bug report hijacking will result in accounts being disabled.
keep it to yourself or bring it up elsewhere unless it is related to the bug you're commenting under.

@Yaro please try building libvirt with the attached PKGBUILD.diff applied. Does that work for you?

@corerobe to establish a path of trust would require a signed or encryted message from C74415BA7C9C7F78F02E1DC34606B8A5DE95BC1F' Daniel Veillard <veillard@redhat.com>
stating that the new signing key for libvirt is 453B65310595562855471199CA68BE8010084C9C Jiří Denemark <jdenemar@redhat.com> ?
If so how about asking felixonmars if Arch Linux CN can get in contact with Daniel Veillard in Xiamen, China?

Alternate strategy one class libvirt as Redhat / IBM corporation project and ask a corporate officer to state the transfer of signing responsibilities has passed to Jiří Denemark.
Alternate strategy two obtain a majority of libvirt developer key signatures for Jiří Denemark then class 6.6.0 onward as a fork.

@loqs Built the package with your patch and it works. Had to disable wireshark plugin because of  FS#63828  but that is a different matter.

Hello, here is GPG signed message from Daniel Veillard which confirms the new GPG key. Hope this helps




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Starting from libvirt-6.6.0 the upstream releases will be done by Jiří Denemark
signed with his PGP key:

pub 4096R/10084C9C 2020-07-20 Jiří Denemark <jdenemar@redhat.com>
Fingerprint=453B 6531 0595 5628 5547 1199 CA68 BE80 1008 4C9C

This message is signed by the old signing key which was used for previous
releases.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE20ZoG7ka3OoXD6LUFViLJllr6l0FAl/8H9cACgkQFViLJllr
6l3iVwgAm9n703/QoIfPbxT5qGQzWK6LNriEcG2R9MLgFcW+UuGA9cqIBLhH1RaJ
q7Gc3gK0dgE2HAF6DxuG5+nkDY6LdmonLOVFWQkMCh41JHFrV6tw8y9hc/RNOb/m
gFAl4HpwYisjTRvsTRcpR3ElK6lI0Yu4GY4gJxj5qH4L5exR+kkylwuAxqP+wuyY
b/L/tP76F4+Q9SSPj0M01NRVC7V8m3yvnok5y374vtxvRFome0WMELn81vphxBLx
X7LQ1LyjvRs0HhN5MutJES5FYDzArTYZfZJozJgE465XrHxMMCbXbZ/AgAs/aD+5
x+m2mFplbS57tMEoMBP/ezbbL5wpvA==
=KnaO
-----END PGP SIGNATURE-----

Attached a copy of email where the chain confirmation can be seen - I stripped most SMTP headers for privacy reasons.

Thanks, I'll get to updating the package then; Hopefully that'll resolve these open issues.

Note for anyone wishing to verify Daniel's PGP signature, please use the attached message I posted second, rather than the inline version in a message earlier. This is because the formatting of the inline message missed double space characters in two locations, which makes it fail validation. Additionally the original message contains SMTP-style line endings, i.e. CRLF.

Note, original source of the message: https://libvirt.org/downloads.html#keys

Added early this morning via https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=d9b70d46bb5f71a3edb37f42a470545e21faa8da;hp=e110743d693cc66cf828d5c453653a5cf0a0aec5

Hello, are there any updates? thanks.

I've had a hardware failure on my signing machine which has prevented me from signing the update, I'll have someone else push the current version while I get the faulty hardware replaced.

I've pushed the updated package per coderobe's guidance to community-testing. Please take a look, everyone.

> Please take a look

A quick review:

- hey, nice use of obscure meson feature to solve the ZFS hack issue :)

- some new config files are missing from the backup() array (etckeeper users will be unhappy):

'etc/libvirt/nwfilter/allow-dhcpv6-server.xml'
'etc/libvirt/nwfilter/allow-dhcpv6.xml'
'etc/libvirt/nwfilter/allow-incoming-ipv6.xml'
'etc/libvirt/nwfilter/allow-ipv6.xml'
'etc/libvirt/nwfilter/no-ipv6-multicast.xml'
'etc/libvirt/nwfilter/no-ipv6-spoofing.xml'

- it appears netcf dep was brought back. Why? As previously mentioned[1], that pkg is completely and utterly pointless on Arch and has even resulted in upstream snark[2]

[1]. https://bugs.archlinux.org/task/66489
[2]. https://www.redhat.com/archives/virt-tools-list/2018-October/msg00049.html

It does indeed look like netcf was intentionally removed in commit "upgpkg: libvirt 6.3.0-1: major cleanup thanks to Toolybird, split off storage backends". I would assume it's therefore likewise reasonable to re-remove it.

@eschwartz @coderobe : thank you very much! libvirt package on community-testing is working fine with my previous virtualmachine on ZFS! (zvol)

I've just installed "augeas-1.12.0-2 netcf-0.2.8-8 libvirt-1:7.0.0-1" from community-testing and that's it! It started immediately from virt-manager.

I installed libvirt-1:7.0.0-1 from community-testing and it is working on my system. My setup is using pass-through for entire disk which the ticket was written against and I don't believe that case has been commented on yet.

Like Enrico, ausgeas and netcf packages were installed (from community). I don't see "ausgeas" listed as a dependency in the libvirt community-testing package listing (on the web page). It sounds like netcf isn't needed but I have not tested removing netcf from the PKGBUILD myself.

I had to install ebtables to use the default network which is an optional dependency for libvirt-7.0.0-1. It looks like libvirt 6.5.0-3 also has ebtables marked as an optional dependency but I did not need it before. (I was using 6.5.0-1 before upgrading.)

The error that I had with the default network was: "Error starting domain: Requested operation is not valid: network 'default' is not active"

To fix the 'default' network issue, I installed ebtables. (My understanding is that packages ebtables iptables dnsmasq are needed. I ran "sudo pacman -Qi ebtables iptables dnsmasq" and saw that ebtables was not installed on my system.)
sudo pacman -S ebtables --asdeps
sudo systemctl restart libvirtd
sudo virsh net-start default

Other notes: Some new files showed up for pacdiff. In addition to "/etc/libvirt/qemu/networks/default.xml", "/etc/libvirt/nwfilter/allow-dhcp-server.xml" and "/etc/libvirt/nwfilter/allow-dhcp.xml" now have pacnew files. The files on my system (not the new files) have "This is an auto-generated file" in them. I don't know the reasoning behind having default.xml default.xml in the package or why the new files are in there now so I can only comment that this is a change that I noticed.

i've removed netcf (again) and added the new config files to the backup array (thanks for the hint Toolybird) in trunk

assuming no major explosions, this ticket should be resolved then - right?

-2 is now in community.

libvirt-1:7.0.0-2 from community-testing works on my system using pass-through for entire disk. ausgeas and netcf were no longer required. (I had installed 7.0.0-1 where they were required. I was able to remove them since pacman -Qdtq showed them as unused.)

I still needed to install ebtables for default network (as expected). There were more pacnew files under nwfilter than before but I think this is expected now.