Starting VM with UEFI firmware fails with swtpm

Thanks Martin,
IIRC the new virt-manager tries to provide swtpm if present and due tot he dependency change it now it present. Since we do not yet know where the root-cause or fix will land I've added a few more affected packages for now.

But I must admit I'm super busy and this makes me feel even more torn.
If I fail to find time for this I'll need to ask in the team if someone else can ...

Understanding what happens is critical, then - once we know what it is - it might be tuned down in priority.

Also tagged/subscribed for foundations (fow swtpm) and server (for the virt bits) attention.

Right, I understand -- but introducing the dependency was an explicit decision (#1948748), and it seems it is broken for its main use case. So in the simplest case the recommends: could be reverted, and reintroduced once this is understood?

Our CI uses a Jammy Ubuntu cloud image, but with quite a large list of extra installed packages. To make sure it's not something specific to that environment, I tried this:

  autopkgtest-buildvm-ubuntu-cloud
  qemu-system-x86_64 -enable-kvm -nographic -m 2048 -device virtio-rng-pci -drive file=autopkgtest-jammy-amd64.img,if=virtio -snapshot

Log in as ubuntu:ubuntu, then

   sudo apt update
   sudo eatmydata apt install -y virtinst libvirt-daemon-system
   sudo touch /var/lib/libvirt/empty.iso
   sudo virt-install --name t1 --os-variant fedora28 --memory 128 --wait -1 --noautoconsole --disk 'size=0.25,format=qcow2' --cdrom /var/lib/libvirt/empty.iso --boot uefi

it fails in exactly the same way. So (1) this confirms it's not our Cockpit CI environment, and (2) provides a nice smoke autopkgtest for libvirt.

I agree that worst-case dropping the recommends is an option.
But only to mitigate - it is meant to be available and working.

It worked for me in the (far) past, but it might have been one of the extra updates/features landing in the meantime. Although I have not used it with virt-install yet (which also recently changed)

As invoked by the virt-stack we see:

Starting vTPM manufacturing as swtpm:swtpm @ Thu 07 Apr 2022 08:14:26 AM UTC
Successfully created RSA 2048 EK with handle 0x81010001.
  Invoking /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek ab6f56f67e86f80c401e130c0650461fe635896717fac00f49ab113f191fdcc5bafa84e8a3960be40dbbb769a43fb4b25bb532c1404bfe601bd03da20ee9e62e494216dc86cbf76cd42eb4255e0e5d129ae5c9b0790aea2733d44d188c7d4706ea6584dceaa476071cc9a8937bb5dbf006b1ff38a591470f13f00e26d67c34b11f2b82767292c8e872c48a1151a1f4b94382c6d6b199f9af0cecb0fc59fd22982b08fae6b682a6dd0fa5dac7bd3154634aa7b7015f8082d3833c7e2c2a089d3f905d733fde4983d50c76493b39dfc854f69844d3f52848036e9c36cdb96067cb99bf4a49e1f734b8bad50524a090b3723006d4b5a9ba9552390f27edb8a411f9 --dir /var/lib/libvirt/swtpm/8908c397-e4dc-4e8c-a758-2436264111cc/tpm2 --logfile /var/log/swtpm/libvirt/qemu/t1-swtpm.log --vmid t1:8908c397-e4dc-4e8c-a758-2436264111cc --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Creating root CA and a local CA's signing key and issuer cert.
Could not create root-CA:Can't load ./.rnd into RNG
4037B2BDC77F0000:error:12000079:random number generator:RAND_load_file:Cannot open file:../crypto/rand/randfile.c:106:Filename=./.rnd
Cannot write random bytes:
4037B2BDC77F0000:error:12000079:random number generator:RAND_write_file:Cannot open file:../crypto/rand/randfile.c:240:Filename=./.rnd

Running the same to a test path works fine

$ /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek ab6f56f67e86f80c401e130c0650461fe635896717fac00f49ab113f191fdcc5bafa84e8a3960be40dbbb769a43fb4b25bb532c1404bfe601bd03da20ee9e62e494216dc86cbf76cd42eb4255e0e5d129ae5c9b0790aea2733d44d188c7d4706ea6584dceaa476071cc9a8937bb5dbf006b1ff38a591470f13f00e26d67c34b11f2b82767292c8e872c48a1151a1f4b94382c6d6b199f9af0cecb0fc59fd22982b08fae6b682a6dd0fa5dac7bd3154634aa7b7015f8082d3833c7e2c2a089d3f905d733fde4983d50c76493b39dfc854f69844d3f52848036e9c36cdb96067cb99bf4a49e1f734b8bad50524a090b3723006d4b5a9ba9552390f27edb8a411f9 --dir /tmp/test/tpm2 --logfile /tmp/test/swtpm.log --vmid t1:8908c397-e4dc-4e8c-a758-2436264111cc --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
$ echo $?
0

I wanted to check if this is more virt-manager or libvirt to call it badly (or call it in a bad environment).

I spawned a default libvirt based guest with uvtool.
In there I then added the most common pattern of

<devices>
 <tpm model='tpm-tis'>
  <backend type='emulator' version='2.0'/>
 </tpm>
</devices>

This is showing kind of the same behavior.
So while most tests before were about using it directly and together with qemu but self-spawned it seems that at least in the current combination it is the way libvirt uses it that breaks the tool.

I found it in ps
4 113 1814 758 20 0 13772 5784 - S ? 0:00 \_ /usr/bin/swtpm_setup --tpm2 --tpm-state /var/lib/libvirt/swtpm/202a34a9-2ee2-4826-b206-c249f535be90/tpm2 --vmid testguest:202a34a9-2ee2-4826-b206-c249f535be90 --logfile /var/log/swtpm/libvirt/qemu/testguest-swtpm.log --createek --create-ek-cert --create-platform-cert --lock-nvram --not-overwrite

That 113 is swtpm

$ id 113
uid=113(swtpm) gid=121(swtpm) groups=121(swtpm)

In swtpm itself the executing user/group was changed (see the already referenced mir bug) to be more secure. The biggest remaining difference here vs the working execution with root is that user/group.

We have adopted that behavior as requested by Steve in bug 1948880.
In fact without 1948880 due to the respective user/group change in the swtpm package we encountered the very same issue we see now - and it was resolved by that upload.

Maybe the updates to libtpms/swtpm since then (or anything else) makes it use different directories now.

Changing the user libvirt uses to spawn swtpm indeed changes the behavior.
It now ends like:
  Need read rights on signing key /var/lib/swtpm-localca/signkey.pem for user swtpm.
  swtpm-localca exit with status 1:
  An error occurred. Authoring the TPM state failed.

That at least confirms that we seem to be on the right track.

For further tests we'll likely need to purge swtpm + some directories, reinstall it and retry from there. To ensure nothing is just based on former file ownership.

Summary of initial triage:
- It is reproducible for me as reported => confirmed
- Other than hoped it is not "just" an apparmor denial (it is in the setup stage,
  not the later swtpm that talks with the guest) :-/
- running the failing command as root locally works
- seems to be associated to the user swtpm is executed as

# clean
$ sudo apt remove --purge swtpm swtpm-tools
$ sudo rm -rf /var/lib/libvirt/swtpm /var/lib/swtpm-localca /var/log/swtpm

# re-create a clean env by re-installing swtpm
$ sudo apt install swtpm swtpm-tools

# Status after install
$ sudo ls -laF /var/lib/libvirt/swtpm /var/lib/swtpm-localca /var/log/swtpm /run/libvirt/qemu/swtpm
ls: cannot access '/var/lib/libvirt/swtpm': No such file or directory
ls: cannot access '/var/log/swtpm': No such file or directory
/run/libvirt/qemu/swtpm:
total 0
drwxrwx--- 2 libvirt-qemu swtpm 40 Apr 7 10:33 ./
drwxr-xr-x 5 root root 140 Apr 7 10:33 ../

/var/lib/swtpm-localca:
total 8
drwxr-x--- 2 swtpm root 4096 Apr 7 10:48 ./
drwxr-xr-x 43 root root 4096 Apr 7 10:48 ../

# then failing a start of a VM with swtpm configured
$ virsh start testguest --console

# File/Dir status after this
$ sudo ls -laF /var/lib/libvirt/swtpm /var/lib/swtpm-localca /var/log/swtpm /run/libvirt/qemu/swtpm /var/log/swtpm/libvirt/qemu /var/log/swtpm/libvirt
/run/libvirt/qemu/swtpm:
total 0
drwxrwx--- 2 libvirt-qemu swtpm 40 Apr 7 10:33 ./
drwxr-xr-x 5 root root 140 Apr 7 10:33 ../

/var/lib/libvirt/swtpm:
total 8
drwx--x--x 2 root root 4096 Apr 7 10:50 ./
drwxr-xr-x 8 root root 4096 Apr 7 10:50 ../

/var/lib/swtpm-localca:
total 20
drwxr-x--- 2 swtpm root 4096 Apr 7 10:50 ./
drwxr-xr-x 43 root root 4096 Apr 7 10:48 ../
-rwxr-xr-x 1 swtpm swtpm 0 Apr 7 10:50 .lock.swtpm-localca*
-rw-r--r-- 1 swtpm swtpm 0 Apr 7 10:50 index.txt
-rw-r--r-- 1 swtpm swtpm 3 Apr 7 10:50 serial
-rw-r--r-- 1 swtpm swtpm 1468 Apr 7 10:50 swtpm-localca-rootca-cert.pem
-rw-r----- 1 swtpm swtpm 2455 Apr 7 10:50 swtpm-localca-rootca-privkey.pem

/var/log/swtpm:
total 12
drwx--x--x 3 root root 4096 Apr 7 10:50 ./
drwxrwxr-x 10 root syslog 4096 Apr 7 10:50 ../
drwx--x--x 3 root root 4096 Apr 7 10:50 libvirt/

/var/log/swtpm/libvirt:
total 12
drwx--x--x 3 root root 4096 Apr 7 10:50 ./
drwx--x--x 3 root root 4096 Apr 7 10:50 ../
drwx-wx--- 2 swtpm swtpm 4096 Apr 7 10:50 qemu/

/var/log/swtpm/libvirt/qemu:
total 12
drwx-wx--- 2 swtpm swtpm 4096 Apr 7 10:50 ./
drwx--x--x 3 root root 4096 Apr 7 10:50 ../
-rw-r--r-- 1 swtpm swtpm 1730 Apr 7 10:50 testguest-swtpm.log

---

After this failed try - since the guest is abandoned we have some differences for a retry

- /var/lib/libvirt/swtpm/202a34a9-2ee2-4826-b206-c249f535be90/tpm2 no more exists
- /var/log/swtpm/libvirt/qemu/testguest-swtpm.log can't be written

$ sudo rm -rf /tmp/test2
$ mkdir /tmp/test2
$ sudo chown swtpm:swtpm /tmp/test2
$ sudo -u swtpm /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek b2e69cdcfc19832f9d174ef4c3af14cf9843efed4e986f35d011a4ac0af4a84adf93a24937bf00da5519272a1f722ae3aa33b8efbe44b3bcde8ac2cf781302801643791f379eab400482f0c4b8a9aba1676eb7b0ae45792d39746a82164c247d4d348aecba70025d74f7025d2e1896743617396337f6221bd81429c3498069056635f9ddf288fe32d9759fa6a825665e56d819b5657f5ce828e72db17e6073cf4e4c7f9dfd8ea18eebae28e9cffa6ff406d03a8a15e48a3f5acd7a3cca7d64b9aef250cc40a301132d466f346843f9a3e084bf9e19fe48b31d2512f39ddd6bc324d22db77dad619158efa5680ff4816c7fc645014e6fa03fb11ede6bc720bbd7 --dir /tmp/test --lo...

I think I got it, it is around that .rnd file as mentioned in the log.

Indeed after running this as root I have:
$ sudo ls -laF /root/.rnd
-rw------- 1 root root 1024 Apr 7 08:16 /root/.rnd

But running as swtpm I get this with strace:

This is the initial failure:
 [pid 3049] 13:10:20 (+ 0.000102) openat(AT_FDCWD, "./.rnd", O_RDONLY) = -1 EACCES (Permission denied)
 [pid 3047] 13:10:20 (+ 0.000027) read(5, "Can't load ./.rnd into RNG\n40977"..., 4096) = 161

And the others are follow ups:

[pid 3049] 13:10:20 (+ 0.000153) newfstatat(AT_FDCWD, "./.rnd", 0x7ffec42c6260, 0) = -1 EACCES (Permission denied)
[pid 3049] 13:10:20 (+ 0.000099) openat(AT_FDCWD, "./.rnd", O_WRONLY|O_CREAT, 0600) = -1 EACCES (Permission denied)
[pid 3049] 13:10:20 (+ 0.000112) openat(AT_FDCWD, "./.rnd", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
[pid 3049] 13:10:20 (+ 0.000101) write(2, "Cannot write random bytes:\n", 27) = 27
[pid 3049] 13:10:20 (+ 0.000104) write(2, "40977E3CD27F0000:error:12000079:"..., 135 <unfinished ...>

The swtpm user is created as:

swtpm:x:113:121:virtual TPM software stack,,,:/var/lib/swtpm:/bin/false

But
$ ls -laF /var/lib/swtpm
ls: cannot access '/var/lib/swtpm': No such file or directory

I guess we need to give him a better home dir?

For example drop `--no-create-home` from the postinst in /var/lib/dpkg/info/swtpm-tools.postinst?

Testing with
$ sudo mkdir /var/lib/swtpm
$ sudo chown swtpm:swtpm /var/lib/swtpm

Hmm, that was not enough yet - but it feels close ...
It seems that this is due to changes in:

 swtpm (0.6.1-0ubuntu4) jammy; urgency=medium

   * debian/patches/openssl-not-certtool.patch: Use openssl at runtime,
     not certtool.

  -- Steve Langasek <email address hidden> Fri, 05 Nov 2021 13:16:42 -0700

In there the .rnd is added
It refers to
  "RANDFILE = $ENV::HOME/.rnd\n"
And maybe in this mode not only is it user swtpm, but also stripped of HOME?
Might want to access even /.rnd in root?

With the analysis so far I'd mark all but swtpm as invalid and hope to resolve it either in that patch and/or in the way the users home dir is created.

Ok, it has
  HOME=/var/lib/swtpm

So due to the config being
  "RANDFILE = $ENV::HOME/.rnd\n"
one might expect `/var/lib/swtpm/.rnd`
But that isn't what it will resolve to, instead we see in strace that it uses:
  "./.rnd"

And surprise :-P, it does not set CWD, I checked a running program and got

# executed in /home/ubuntu:
$ sudo ls -laF /proc/$(pidof swtpm-localca)/cwd
lrwxrwxrwx 1 swtpm swtpm 0 Apr 7 13:34 /proc/3260/cwd -> /home/ubuntu/

# executed by libvirt for guest creation
$ while /bin/true; do sudo ls -laF /proc/$(pidof swtpm-localca)/cwd 2>/dev/null; done
lrwxrwxrwx 1 swtpm swtpm 0 Apr 7 13:37 /proc/3990/cwd -> //

In a set of cross checks I ran it as

#1 root, but this time in /home/ubuntu instead of in /root.

I got:
  lrwxrwxrwx 1 root root 0 Apr 7 13:40 /proc/11805/cwd -> /home/ubuntu/
And afterwards
  -rw------- 1 root root 1024 Apr 7 13:40 /home/ubuntu/.rnd

So it fully ignores $HOME

So root cause of the problem is that it wants to access some "$CWD/.rnd", but not where it is supposed to do so.

#2 user swtpm being in /var/lib/swtpm

This showed that this user is good if it would use the right paths.

ubuntu@swtpm-jammy:/var/lib/swtpm$ sudo -u swtpm -E HOME=/var/lib/swtpm /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek b2e69cdcfc19832f9d174ef4c3af14cf9843efed4e986f35d011a4ac0af4a84adf93a24937bf00da5519272a1f722ae3aa33b8efbe44b3bcde8ac2cf781302801643791f379eab400482f0c4b8a9aba1676eb7b0ae45792d39746a82164c247d4d348aecba70025d74f7025d2e1896743617396337f6221bd81429c3498069056635f9ddf288fe32d9759fa6a825665e56d819b5657f5ce828e72db17e6073cf4e4c7f9dfd8ea18eebae28e9cffa6ff406d03a8a15e48a3f5acd7a3cca7d64b9aef250cc40a301132d466f346843f9a3e084bf9e19fe48b31d2512f39ddd6bc324d22db77dad619158efa5680ff4816c7fc645014e6fa03fb11ede6bc720bbd7 --dir /tmp/test --vmid testguest:202a34a9-2ee2-4826-b206-c249f535be90 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Successfully created EK certificate locally.
ubuntu@swtpm-jammy:/var/lib/swtpm$ ll /tmp/test
total 20
drwxrwxr-x 2 swtpm swtpm 4096 Apr 7 13:44 ./
drwxrwxrwt 14 root root 4096 Apr 7 13:44 ../
-rw------- 1 swtpm swtpm 1053 Apr 7 13:44 ek.cert
ubuntu@swtpm-jammy:/var/lib/swtpm$ sudo ls -laF /var/lib/swtpm-localca/
total 56
drwxr-x--- 2 swtpm root 4096 Apr 7 13:44 ./
drwxr-xr-x 44 root root 4096 Apr 7 13:17 ../
-rwxr-xr-x 1 swtpm swtpm 0 Apr 7 10:50 .lock.swtpm-localca*
-rw-rw-r-- 1 swtpm swtpm 5519 Apr 7 13:44 01.pem
-rw-rw-r-- 1 swtpm swtpm 1 Apr 7 13:44 certserial
-rw-rw-r-- 1 swtpm swtpm 48 Apr 7 13:44 index.txt
-rw-rw-r-- 1 swtpm swtpm 21 Apr 7 13:44 index.txt.attr
-rw-rw-r-- 1 swtpm swtpm 0 Apr 7 13:44 index.txt.old
-rw-rw-r-- 1 swtpm swtpm 5519 Apr 7 13:44 issuercert.pem
-rw-rw-r-- 1 swtpm swtpm 3 Apr 7 13:44 serial
-rw-rw-r-- 1 swtpm swtpm 3 Apr 7 13:44 serial.old
-rw-r----- 1 swtpm swtpm 2459 Apr 7 13:44 signkey.pem
-rw-rw-r-- 1 swtpm swtpm 1468 Apr 7 13:44 swtpm-localca-rootca-cert.pem
-rw-r----- 1 swtpm swtpm 2455 Apr 7 13:44 swtpm-localca-rootca-privkey.pem

A new interim summary

Problem:
- debian/patches/openssl-not-certtool.patch adds "RANDFILE = $ENV::HOME/.rnd\n"
- this is not picked up correctly at the time this file is evaluated
- Due to that swtpm-localca tries to access $CWD/.rnd and fails in most cases
- The upstreaming of this Delta has further open questions at [1]

Solution:
- We could brute force:
  "RANDFILE = /var/lib/swtpm/.rnd\n"
  But that is wrong if swtpm-localca is executed by another
  user that might fail just as much.
- We need to find either a working pick up of $HOME or something completely else ...
  Maybe we can make samples/swtpm_localca.c read ENV[HOME] and write the config
  accordingly

[1]: https://github.com/stefanberger/swtpm/pull/620

@paelzer, upstream OpenSSL stopped using RANDFILE a while ago, I've linked a MR to drop that directive from swtpm's patch.

Yes Simon,
that is much better than me trying to fetch home and insert it into the string :-)
Thanks for the reference.

It feels a bit odd seeing myself coming by between meetings all day and make debug progress to then see such a simple solution. Please tell me that my debug helped to make that suggestion :-)

I'll consume and polish it to hopefully solve this!

The fix needed some polishing, but was a great hint.
Test PPA started to build at:
  https://launchpad.net/~paelzer/+archive/ubuntu/lp-1968131-swtpm-rndfile

Your comment #13 is what hinted me. I've been messing with openssl lately and noticed an annoying message about .rnd but only on Bionic machines ;)

I tested the PPA, and it works like a charm now. Thanks Christian and Simon!

For once, kicking some{thing,one} out of their $HOME does something good.. 😀

Install fine:

ubuntu@swtpm-jammy:/var/lib/swtpm$ sudo apt update; sudo apt upgrade
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:3 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:4 http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Get:5 https://ppa.launchpadcontent.net/paelzer/lp-1968131-swtpm-rndfile/ubuntu jammy InRelease [18.1 kB]
Get:6 https://ppa.launchpadcontent.net/paelzer/lp-1968131-swtpm-rndfile/ubuntu jammy/main amd64 Packages [768 B]
Get:7 https://ppa.launchpadcontent.net/paelzer/lp-1968131-swtpm-rndfile/ubuntu jammy/main Translation-en [472 B]
Fetched 19.3 kB in 2s (10.4 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  swtpm swtpm-tools
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 138 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 https://ppa.launchpadcontent.net/paelzer/lp-1968131-swtpm-rndfile/ubuntu jammy/main amd64 swtpm-tools amd64 0.6.3-0ubuntu2~jammyppa1 [90.4 kB]
Get:2 https://ppa.launchpadcontent.net/paelzer/lp-1968131-swtpm-rndfile/ubuntu jammy/main amd64 swtpm amd64 0.6.3-0ubuntu2~jammyppa1 [47.4 kB]
Fetched 138 kB in 2s (85.7 kB/s)
(Reading database ... 113960 files and directories currently installed.)
Preparing to unpack .../swtpm-tools_0.6.3-0ubuntu2~jammyppa1_amd64.deb ...
Unpacking swtpm-tools (0.6.3-0ubuntu2~jammyppa1) over (0.6.3-0ubuntu1) ...
Preparing to unpack .../swtpm_0.6.3-0ubuntu2~jammyppa1_amd64.deb ...
Unpacking swtpm (0.6.3-0ubuntu2~jammyppa1) over (0.6.3-0ubuntu1) ...
Setting up swtpm (0.6.3-0ubuntu2~jammyppa1) ...
Setting up swtpm-tools (0.6.3-0ubuntu2~jammyppa1) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3) ...
Scanning processes...
Scanning linux images...

Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

Now it works:
ubuntu@swtpm-jammy:/var/lib/swtpm$ virsh start testguest
Domain 'testguest' started

P.S. it also made me find that the modified swtpm triggers a non fatal apparmor issue now that we want to fix in another bug

Apr 07 15:02:26 swtpm-jammy kernel: audit: type=1400 audit(1649343746.681:87): apparmor="DENIED" operation=...

Apparmor follow up filed as:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1968187

Uploaded the tested fix for swtpm:
 Uploading swtpm_0.6.3-0ubuntu2.dsc
 Uploading swtpm_0.6.3-0ubuntu2.debian.tar.xz
 Uploading swtpm_0.6.3-0ubuntu2_source.buildinfo
 Uploading swtpm_0.6.3-0ubuntu2_source.changes

This bug was fixed in the package swtpm - 0.6.3-0ubuntu2

---------------
swtpm (0.6.3-0ubuntu2) jammy; urgency=medium

  * d/p/openssl-not-certtool.patch: do not use rnd file (LP: #1968131)
    RANDFILE isn't needed anymore in openssl and furthermore breaks many
    use cases here as HOME isn't resolved and therefore it accessed $CWD/.rnd
    which often ends up in places it isn't able to access the file.
    Thanks to Simon Deziel for the suggested fix!

 -- Christian Ehrhardt <email address hidden> Thu, 07 Apr 2022 16:07:21 +0200