Testing Windows and QWT in R4.1

one-eye-pirate · December 17, 2020, 12:22pm

Rebuilt the qwt utilities again, it works for me 100%

[user@new-qwt-builder qubes-builder]$ history
    1  git clone https://github.com/QubesOS/qubes-builder
    2  cd qubes-builder/
    3  cd
    4  wget https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
    5  gpg --import qubes-master-signing-key.asc 
    6  gpg --edit-key 36879494
    7  wget https://keys.qubes-os.org/keys/qubes-developers-keys.asc
    8  gpg --import qubes-developers-keys.asc
    9  cd qubes-builder/
   10  git tag -v `git describe`
   11  mkdir -p keyrings/git
   12  cp ~/.gnupg/pubring.kbx ~/.gnupg/trustdb.gpg keyrings/git
   13  sudo dnf install gnupg git createrepo rpm-build make wget rpmdevtools python3-sh dialog rpm-sign dpkg-dev debootstrap python3-pyyaml devscripts perl-Digest-MD5 perl-Digest-SHA
   14  ln -s example-configs/qubes-os-master.conf builder.conf
   15  make install-deps get-sources COMPONENTS='$(BUILDER_PLUGINS) qwt-crossbuild' GIT_URL_qwt_crossbuild=https://github.com/fepitre/qwt-crossbuild INSECURE_SKIP_CHECKING="qwt-crossbuild"
   16  make qubes-dom0 COMPONENTS="qwt-crossbuild"
   17  make remount
   18  make qubes-dom0 COMPONENTS="qwt-crossbuild"
   19  history

-> Installing package groups...-> Building qwt-crossbuild (qubes-windows-tools.spec) for fc32 dom0 (logfile: build-logs/qwt-crossbuild-dom0-fc32.log)
--> Done:
      qubes-src/qwt-crossbuild/pkgs/dom0-fc32/noarch/qubes-windows-tools-4.1-1.noarch.rpm
make[1]: Leaving directory '/home/user/qubes-builder'

GWeck · December 17, 2020, 12:25pm

With the developers’ keys imported, the error stays the same. It seems to be a problem of the rpm-File.

I repeated make get-sources again, and got an additional error there:

[user@fedora-32 qubes-builder]$ make get-sources
-> Updating sources for builder...
--> Fetching from https://github.com/QubesOS/qubes-builder.git master...
--> Verifying tags...
---> No valid signed tag found!
---> One invalid tag: 284f4b7eac69eccf36e904485726151b62d56160
make: *** [Makefile:217: builder.get-sources] Fehler 1

I’ll retry now with the commands of your history.

GWeck · December 17, 2020, 12:32pm

The error remains. Is there an option to ignore the fact that the rpm is not signed?

one-eye-pirate · December 17, 2020, 12:34pm

Do you ultimate trust to qubes-master-signing-key ?
I have also fully updated fedora-32 host.

gpg --edit-key 36879494
fpr
trust
5
y
q

-> Updating sources for builder-rpm...
--> Fetching from https://github.com/QubesOS/qubes-builder-rpm.git master...
--> Verifying tags...
gpg: keybox '/home/user/qubes-builder/keyrings/git/builder-rpm/pubring.kbx' created
gpg: key E2A783B8C37BB66B: 1 signature not checked due to a missing key
gpg: /home/user/qubes-builder/keyrings/git/builder-rpm/trustdb.gpg: trustdb created
gpg: key E2A783B8C37BB66B: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key C235DF9A1E30A75D: 1 signature not checked due to a missing key
gpg: key C235DF9A1E30A75D: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key A14B0A7874EADABC: 1 signature not checked due to a missing key
gpg: key A14B0A7874EADABC: public key "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" imported
gpg: key F2804017B298547C: 1 signature not checked due to a missing key
gpg: key F2804017B298547C: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@mimuw.edu.pl>" imported
gpg: key 928DD427AB5EEF90: 1 signature not checked due to a missing key
gpg: key 928DD427AB5EEF90: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key FB5DAEE165EF29CA: 1 signature not checked due to a missing key
gpg: key FB5DAEE165EF29CA: public key "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" imported
gpg: key EE570349A603BCB6: 1 signature not checked due to a missing key
gpg: key EE570349A603BCB6: public key "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key DDFA1A3E36879494: public key "Qubes Master Signing Key" imported
gpg: key 7397C8B034898310: public key "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" imported
gpg: key 063938BA42CFA724: public key "Marek Marczykowski-Górecki (Qubes OS signing key) <marmarek@invisiblethingslab.com>" imported
gpg: key 5BA92D6DAF975A7D: 1 signature not checked due to a missing key
gpg: key 5BA92D6DAF975A7D: public key "Wojciech Zygmunt Porczyk (Qubes OS signing key) <wojciech@porczyk.eu>" imported
gpg: key 045A13284C85173A: 1 signature not checked due to a missing key
gpg: key 045A13284C85173A: public key "Rafał Wojdyła (Qubes OS signing key) <omeg@invisiblethingslab.com>" imported
gpg: key 70483D0A15CE40BF: 1 signature not checked due to a missing key
gpg: key 70483D0A15CE40BF: public key "Wojciech Zygmunt Porczyk (Qubes OS signing key) <woju@invisiblethingslab.com>" imported
gpg: key C92A047EF2CD312B: public key "Wojtek Porczyk (Qubes OS signing key) <woju@invisiblethingslab.com>" imported
gpg: key DA0434BC706E1FCF: public key "Simon Gaiser (Qubes OS signing key) <simon@invisiblethingslab.com>" imported
gpg: Total number processed: 15
gpg:               imported: 15
gpg: no ultimately trusted keys found
gpg: inserting ownertrust of 6
gpg: key E2A783B8C37BB66B: "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" not changed
gpg: key C235DF9A1E30A75D: "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" not changed
gpg: key A14B0A7874EADABC: "Joanna Rutkowska (Qubes OS signing key) <joanna@invisiblethingslab.com>" not changed
gpg: key F2804017B298547C: "Marek Marczykowski (Qubes OS signing key) <marmarek@mimuw.edu.pl>" not changed
gpg: key 928DD427AB5EEF90: "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" not changed
gpg: key FB5DAEE165EF29CA: "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" not changed
gpg: key EE570349A603BCB6: "Marek Marczykowski (Qubes OS signing key) <marmarek@invisiblethingslab.com>" not changed
gpg: key DDFA1A3E36879494: "Qubes Master Signing Key" not changed
gpg: key 7397C8B034898310: "Joanna Rutkowska (Qubes OS Signing Key) <joanna@invisiblethingslab.com>" not changed
gpg: key 063938BA42CFA724: "Marek Marczykowski-Górecki (Qubes OS signing key) <marmarek@invisiblethingslab.com>" not changed
gpg: key 5BA92D6DAF975A7D: 1 signature not checked due to a missing key
gpg: key 5BA92D6DAF975A7D: "Wojciech Zygmunt Porczyk (Qubes OS signing key) <wojciech@porczyk.eu>" not changed
gpg: key 045A13284C85173A: 1 signature not checked due to a missing key
gpg: key 045A13284C85173A: "Rafał Wojdyła (Qubes OS signing key) <omeg@invisiblethingslab.com>" not changed
gpg: key 70483D0A15CE40BF: 1 signature not checked due to a missing key
gpg: key 70483D0A15CE40BF: "Wojciech Zygmunt Porczyk (Qubes OS signing key) <woju@invisiblethingslab.com>" not changed
gpg: key C92A047EF2CD312B: "Wojtek Porczyk (Qubes OS signing key) <woju@invisiblethingslab.com>" not changed
gpg: key DA0434BC706E1FCF: "Simon Gaiser (Qubes OS signing key) <simon@invisiblethingslab.com>" not changed
gpg: Total number processed: 15
gpg:              unchanged: 15
---> Good tag 40c6d2547fdb8756c9424c366613105296e99961

GWeck · December 17, 2020, 12:47pm

Retrying - will take some time …

GWeck · December 17, 2020, 2:03pm

No change, the error stays the same - all developers’ keys installed, so I suppose that it is a problem of the rpm file. Maybe there are different versions of this file?

one-eye-pirate · December 17, 2020, 4:39pm

@fepitre did you test a seamless mode?
is it possible to make this option work?
Also net doesn’t work too.
I have not read build scripts yet,
but most likely for 4.1 everything needs to be changed (new qubes policy, python)
trying to reinstall manually with extracted iso from qwt rpm
i can only cmd from dom0

fepitre · December 17, 2020, 5:44pm

Please check the README instructions. I’ve explicitly added an option to ignore signed tag while make get-sources. I don’ want to add signed tags on current dev/untrusted component. My commits are signed. In case you have properly added the option to ignore check on tags for this component, ensure to have pulled latest qubes-builder master branch. Marek fixed something yesterday about not checking tags.

fepitre · December 17, 2020, 5:47pm

As I said, it’s only “nogui” version meaning the gui-agent-windows is not here (no seamless then). I’m focusing on reviving our own component which at the end will result in some analogous qwt-crossbuild component but with all the source verification steps included.

BTW, I do have network working, at least I remember to have downloaded and used Firefox without tools. Ensure to have a netvm before starting your Windows qube.

GWeck · December 19, 2020, 5:09pm

I am afraid I still get the is not signed message, although I just loaded everything new. I there any way to tell the make command not to check for signatures?

fepitre · December 19, 2020, 9:52pm

@GWeck: normally it is:

$ git clone https://github.com/QubesOS/qubes-builder
$ cd qubes-builder
$ ln -s example-configs/qubes-os-master.conf builder.conf
$ make install-deps get-sources COMPONENTS='$(BUILDER_PLUGINS) qwt-crossbuild' GIT_URL_qwt_crossbuild=https://github.com/fepitre/qwt-crossbuild INSECURE_SKIP_CHECKING="qwt-crossbuild"
$ make qubes-dom0 COMPONENTS="qwt-crossbuild"

where INSECURE_SKIP_CHECKING="qwt-crossbuild" is to be added to the make call (like above) or builder.conf. I’ve just ran the above 5 commands in a Fedora 32 dvm without any issue. It just says "NOT verifying tags` and continue.

GWeck · December 20, 2020, 12:21pm

@fepitre First of all, thank you for your patience!

There seems to be a problem with my Fedora-32 template VM, because the error remained. So I created a new Fedora-31 template and executed the commands in a dispvm based on that template. There the commands ran to the end and created the file qubes-windows-toold-4.1-1.noarch.rpm, which I will test now.

I suppose it’s the best to recreate the Fedora-32 template. Perhaps the problems come from the history of the current template, which I used for the experiments with the docker solution???

wind.gmbh · December 21, 2020, 10:56am

I can report that the build did work without any issues following the provided instructions.
The Qubes Windows Tools installation did work (except Seamless Mode, as expected).

That may work. I rarely make any changes to TemplateVMs, so that could be the difference.

GWeck · December 21, 2020, 12:25pm

I tried to install the file qubes-windows-tools-4.1-1.noarch.rpm in Qubes R4.1 and use it to install Qubes Windows Tools in Windows 7 (Professional, SP1 fully updated) and Windows 10 (Professional, Version 1909). The results are quite encouraging. Here are the steps performed, with sonme comments on the results:

– Copy the rpm file to dom0: qvm-run --pass-io <dispXXXX> 'cat /path_in_<dispXXXX>/qubes-windows-tools-4.1-1.noarch.rpm' > /path_in_dom0/qubes-windows-tools-4.1-1.noarch.rpm

– Install the rpm file in dom0: sudo dnf install /path_in_dom0/qubes-windows-tools-4.1-1.noarch.rpm

– Prepare the Windows VM (created as template VM without installation of a previous version of Qubes Windows Tools:

In the Windows VM, execute bcdedit /set testsigning on (not sure if this is necessary in Windows 10, but in Windows 7, the drivers will not install without this setting)
In a terminal in dom0, set:
qvm-features <VMname> gui 1
qvm-prefs <VMname> default_user <username>
qvm-prefs <VMname> qrexec_timeout 600 (necessary if the option Move user profiles is selected, see later)

– Install Qubes Windows Tools:

In a terminal in dom0, execute qvm-start <VMname> --install-windows-tools
In the Windows VM, copy the file qubes-tools-x64.msi from the virtual CDROM displayed (usually drive D:) to a local directory
Execute the file qubes-tools-x64.msi and ignore any warnings about unknown supplier of this file
There is no need to select the installation of the PV network driver in order get networking - just use the default selection provided by the installer
For Windows 10, better not select the option move user profiles; if this option is selected, the user files are copied, like in Windows 7, to a newly created disk Q:, but they still remain on disk C:, additionally, and the link still points to the directory on drive C:, which may lead to confusion. Also, a lot of error messages is produced, resulting from inconsistencies in the NTFS structure used by Windows 10. For Windows 7, the option works correctly.

– In order to have networking enabled in the Windows VM, the networking option of this VM has to be set to sys-firewall before starting the VM. Otherwise, the VM is started without a network adapter.

– If the PV network driver option was selected was selected during QWT installation, the DHCP address setting does not work. In this case, in Windows set the network adapter address to the address displayed in Qube Manager for the Windows VM and the gateway address to the address of sys-firewall. This may be the cause of problems, if the address auf sys-firewall changes.

– For Windows 10, screen resolution is preset to 1024 x 768, other allowed values are 800 x 600 and the resolution of the physical screen. For Windows 7, a long list of possible screen resolutions is displayed. Changing the resolution to one of these values works.

– Enabling seamless display in Qube manager for these VMs leads to trouble: For Windows 7, Qube Manager crashes, while for Windows 10, it hangs.

– When starting the Windows VM, a pop-up with the message Failed to execute qubes.NotifyTools from <VMname> to dom0 is displayed, but so far, it does not seem to cause any trouble.

– In my case, Windows 7 showed no trouble and worked, while Windows 10 needed several reboots, but then worked, too. The following functions were tested and worked:

clipboard copy to/from another VM
file copy to/from another VM

So the qrexec communication seems to be o.k.

I will now check AppVMs based on these Windows templates, and see if the installation works in Qubes R4.0, too. So stay tuned!

GWeck · December 21, 2020, 1:39pm

I repeated the build with a dispvm based on a new Fedora-32 template instead of the Fedora-31 template I used yesterday, and the error reappeared ! ???

GWeck · December 22, 2020, 1:00pm

More good news: The qrexec communication works with Qubes R4.0.3, too. Installation of this new vesion 4.1.1 of Qubes Windows Tools is also possible for Windows 7 and 10, and the resulting systems behave nearly as under Qubes R4.1, with some minor differences:

The installation option Move user profiles seems to be ignored here for both Windows 7 and 10.
Windows 10 allows to set screen resolution to many diffeerent values, not just the three ones presented under Qubes R4.1.
Selecting Seamless mode is just ignored (tested only with Windows 10), and Qube manager does not block.

File and clipboard copy both work in both directions for both versions of Windows. So the qrexec communication seems o.k. As far as I understand it, this means that the Xen drivers are compatible with both Qubes versions. Network communication using the original network driver, not the optional Xen PV driver, works too (tested with Windows 10).

GWeck · December 23, 2020, 11:08am

@fepitre @wind.gmbh The problem with aborting the build in the second make statement arises from a version change of rpm. In Fedora-32, the version is 4.15.1, while it is still expected to be 4.14.0. The command rpm --version returns a differently formatted string, and the result string of rpm --checksig has changed, too, such that the check for a correct signature fails.

In order to make the check successful, the following changes have to be applied to the script qubes-builder/qubes-src/builder-rpm/prepare-chroot-base:

Line 16:
RPM_VERSION="$(rpm --version | awk '{print $3}')"
change to
RPM_VERSION="$(rpm --version | awk '{print $2}')"
Line 18:
if [ "$(printf '%s\n' "$RPM_VERSION" "4.14.0" | sort -V | head -n1)" = "4.14.0" ]; then
change to
if [ "$(printf '%s\n' "$RPM_VERSION" "4.15.1" | sort -V | head -n1)" = "4.15.1" ]; then
Line 20:
PGP_SIGNED=' signatures OK'
change to
PGP_SIGNED=' digests signatures OK'

The second make statement works then.

Caution: If these changes are applied, the build works only for rpm version 14.5.1. If it is required to work for both versions 14.4.0 and 14.5.1, more complex changes are needed at that point.

This problem is related to the Qubes issue #5526, where the same situation occured during the build of an R4.1 iso.

Generally speaking, the signature check is somewhat fragile, depending on a version string and parsing of text output of version-dependent rpm commands, but I must confess that I have no better idea.

GWeck · December 23, 2020, 12:35pm

Starting AppVMs based on the Windows templates gives very mixed results. Partially, they look somewhat queer, and the qrexec communication does not seem to work correctly. I think, there is still a lot more research needed …

ooooooooo · December 25, 2020, 8:38pm

Finally everything works (GUI, Audio, Network) in Qubes 4.1

qubes-windows-tools-4.1-65.iso

Bishop · December 29, 2020, 8:03pm

Is there a way to get the iso without setting up all the builing environment?

Thanks