From the subject.
Did anyone install Qubes from.the other medium than USB? How?
Itās an ISO file, you shouldnāt have any trouble burning it to a suitably sized bit of optical media and booting/installing from that.
I usualy do the install from āanotherā processor device. It can be anything like a Music Player with DSP or some Old DVD player etc. I do verify a size at least. You can use Clonezila to get an image from such a device if you want to be more convoluted.
I guess you have internal DVD rom devicesā¦
@enmus already knows about this, but Iām putting it here for anyone else interested:
It creates a Qube called sys-pxe on your existing Qubes OS machine, and turns your ethernet NIC into a DHCP, TFTP, and NFS server, hosting the Qubes OS installer ISO.
You can then essentially plug any other machine that supports network boot into the network that your Qubes machine is on (make sure that you havenāt got another DHCP server on the same LAN, of course), and all machines will essentially boot the Qubes ISO over PXE.
To the end user, the experience is identical to booting as if the Qubes ISO was on a USB flash drive.
You can also specify a Kickstart file, allowing a Qubes OS unattended install.
For more info, check out the thread above (and please contribute if you can 
)
@Syonyk, fully agree with what youāre saying, and definitely true.
Iām fairly certain that @enmus wasnāt having difficulty flashing an ISO. I think this thread is more of a brainstorm for creative ways to get Qubes OS on a machine.
Please correct me if Iām wrong, though
But having said that, thereās definitely a place in this thread for āissues with flashing the ISO onto external mediaā.
I have always been perplexed by the fact that the Windows tool rufus has an option to alter the partition table of an ISO before flashing it.
I still am not sure why youād want to change thisā¦
If the creator of an ISO has already gone out of their way to ensure support for both MBR and UEFI, why would you want to mess with it? Why would you not want to copy the ISO exactly as it has been createdā¦? 
Also, would a āQubes OS ISO generatorā (similar to the Raspberry Pi Imager in the video below) be of any benefit?
Explanation of what the Raspberry Pi Imager is:
Its main use case would be for Windows and MacOS users who have never āpopped the hoodā on their machines, and otherwise wouldnāt know how to flash an ISO (and verify checksums, check for tampering, etc.), I guessā¦
Comments, anyone?
@noti2p, so you turn your external device into a block device, and attach it to the machine via cable (Iām assuming USB), correct?
Thatās an interesting way of doing it. Hiding in plain sight. I like it 
But is there any added benefit of doing it this way, over flashing NAND?
Iāve tried that. You have to use a dual-layered disc (the ISO is about 2-3GB larger than a single-layered disc), and itās a lot slower than NANDā¦
Additional Method I have used successfully - Installing Qubes OS, configuring it, and then using dd
When I have multiple units of identical hardware that require additional configuration that a fresh Qubes OS install directly from the ISO doesnāt have (custom firmware, Xorg config files, additional GRUB parameters, etc.), I have gotten a single install configured with everything working ājust the way I like itā, and then used dd to completely clone entire hard drives (this takes a while, though, because dd will still copy everything on the drive, including the empty spaceā¦).
I mean, are there actually any other ways to install Qubes OSā¦?
I mean, in order to perform an install, all you really need is:
-
An installation target
- Can be local, remote, or a mix of the two
- Can be a physical device, virtual device, image file, or something else (post your suggestions for āsomething elseā)
-
An installation source
- Can be local, remote, or a mix of the two
- Can be packages, individual files, or something else (post your suggestions for āsomething elseā)
-
An OS with enough functionality to perform/facilitate the install
- Loads enough firmware and programs to perform the required functions (copy, erase, compile, etc.)
- Does not use the drive you want to install Qubes OS on
Any creative suggestions on how else to perform an install, anyone?
1 Like
i tried external DVD rom device, with ISO file burned on DVD,
but after Heads flashing, apparently Heads cannot boot from external DVD rom device
hi @Insurgo this is to continue the discussion in firmware backdoor ,
about recommended installation for Qubes + Heads laptop.
i remember, i can install Qubes, into Heads laptop, from USB thumbdrive,
without being accompanied by detached pgp signature,
& the installation was success.
so, how to do the recommended installation above ?
does it mean, we need to import QMSK & release signing key, into Heads ?
thanks & best regards,
@newbie something missing from Step 4 - Installing Qubes and other OSes - Heads - Wiki? Or Step 4 - Installing Qubes and other OSes - Heads - Wiki ?
Hey guys. Thanks for being interested in, just to remind you that this topic is How did you, and not How to.
That would be installing qubes 4.1 entry under Step 4 - Installing Qubes and other OSes - Heads - Wiki as referred previously.
This is standard thin LVM pool over LUKSv2 encrypted container, with fedora template used for qubes, Whonix used for updates (dom0, templates) and disposable sys-firewall, sys-usb and sys-net.
@enmus thanks for the friendly reminder.
1 Like
Could you possibly share how did you install Qubes? From the USB stick? I am genuinely interested in this, how to do it most securely today, with modern computersā¦
Both previous references says that it is directly from iso and detached signature file sitting side by side on an ext3/ext4 partitionā¦ I feel people donāt read.
The qubes section also shows, with screenshots, the booting and iso verification process.
@enmus: what is missing there?
1 Like
I guess you could already guess whatā¦
Thanks again for repeating in order to be more clear to me. Very nice idea though, while I still have concerns about using USB sticks!
1 Like
Release signing key (public key counterpart) is included in the firmware, as documented under the general section of the same page.
This is how Tails, Arch Linux, Qubes OS can boot directly from and ext3/ext4 formatted drive, if iso and iso.asc/iso.sig detached signature are sitting side by side on the USB thumb drive root directory.
If distros were detach signing their iso (Fedora stopped) those distros could also be booted the same way, at the condition of having their distro signing public key added under Heads and present in booted firmware to be able to verify corresponding detached signatures alongside of downloaded isos.
No magic there, the iso.asc/iso.sig detached signature is validated against the distribution public key that is provided under Heads. This is why Heads can validate both integrity and authenticity of those ISOs, just as their webpages describe to do so manually, but automatically under Heads. And since Heads validates those distribution signing public key as part of Heads firmware measured boot, the user can simply drop newer isos and detached signatures files and boot from them confidently.
Bonus, Qubes daily produced QA builds can also be booted the same way, since that corresponding public key is also under Heads since Maximized builds were merged under Heads.
Well, if you dd an image over USB thumb drive, you loose integrity validation. This is a worry-less alternative approach for Heads users.
Also, you could detach sign an ISO yourself from Heads if the distribution do not provide those
- verify integrity manually from Heads recovery shell (mount-usb rw, cd /media, sha256sum distrib.iso, verify hashes manually.)
- detach sign with your own private key (gpg --card-status, gpg --detach-sign distro.iso)
- Sync changes (cd /, umount /media)
- boot your own detached signed iso.
That way, you can trust that the iso is as expected prior of booting into it. Those āpublicā files can sit side by side alongside of other āpublicā (untrusted) files, where heads will verify them prior of mounting them and boot into them.
1 Like
hi @Insurgo
i compare Qubes distro key in heads github repo,
with Qubes 4.1.1 release signing key ,
it looks similar, but actually are different,
Qubes 4.1.1 release signing key, in Qubes download website,
are longer than Qubes distro key, in heads Github repo.
is it expected, or anything wrong ?
Will try to answer factually, which requires me to redo the process.
As you can see on heads/initrd/etc/distro/keys at master Ā· linuxboot/heads Ā· GitHub , the latest time https://github.com/osresearch/heads/blob/master/initrd/etc/distro/keys/qubes-4.key was touched is linked to commit Separate trusted ISO signers from trusted config signers Ā· linuxboot/heads@c1be56c Ā· GitHub which doesnāt give much information on what was applied to the public key to reduce its size 5 years ago.
So letās attempt to replicate the work done there with tails.key which I had to update 10 months ago heads/initrd/etc/distro/keys/tails.key at master Ā· linuxboot/heads Ā· GitHub linked to commit tails.key : merging of new long-term signing key with old one so old ā¦ Ā· linuxboot/heads@7a324bb Ā· GitHub which I left traces for reproducibility under the commit message, pointing to Update Tails public signing distro key (expires on 2022-01-19) by tlaurion Ā· Pull Request #1023 Ā· linuxboot/heads Ā· GitHub
So letās replicate Update Tails public signing distro key (expires on 2022-01-19) by tlaurion Ā· Pull Request #1023 Ā· linuxboot/heads Ā· GitHub with qubes distribution public key (release key) and compare things on a dvm:
[user@disp2326 ~]$ cd /tmp
[user@disp2326 tmp]$ mkdir qubes-key
[user@disp2326 tmp]$ cd qubes-key/
[user@disp2326 qubes-key]$ wget https://keys.qubes-os.org/keys/qubes-release-4-signing-key.asc
--2022-11-16 12:26:43-- https://keys.qubes-os.org/keys/qubes-release-4-signing-key.asc
Resolving keys.qubes-os.org (keys.qubes-os.org)... 147.75.32.1, 2604:1380:4601:1c00::1
Connecting to keys.qubes-os.org (keys.qubes-os.org)|147.75.32.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2379 (2.3K) [application/octet-stream]
Saving to: āqubes-release-4-signing-key.ascā
qubes-release-4-sig 100%[===================>] 2.32K --.-KB/s in 0s
2022-11-16 12:26:44 (49.2 MB/s) - āqubes-release-4-signing-key.ascā saved [2379/2379]
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: keybox '/tmp/qubes-key/pubring.kbx' created
gpg: key 1848792F9E2795E9: 1 signature not checked due to a missing key
gpg: /tmp/qubes-key/trustdb.gpg: trustdb created
gpg: key 1848792F9E2795E9: public key "Qubes OS Release 4 Signing Key" imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: no ultimately trusted keys found
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --edit-key 1848792F9E2795E9
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg (GnuPG) 2.3.7; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/1848792F9E2795E9
created: 2017-03-06 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes OS Release 4 Signing Key
gpg> minimize
User ID "Qubes OS Release 4 Signing Key": 1 signature removed
pub rsa4096/1848792F9E2795E9
created: 2017-03-06 expires: never usage: SC
trust: unknown validity: unknown
[ unknown] (1). Qubes OS Release 4 Signing Key
gpg> quit
Save changes? (y/N) y
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --export --armor 1848792F9E2795E9 > qubes-release-4-signing-key_mod.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
[user@disp2326 qubes-key]$ wget https://raw.githubusercontent.com/osresearch/heads/master/initrd/etc/distro/keys/qubes-4.key
--2022-11-16 12:31:22-- https://raw.githubusercontent.com/osresearch/heads/master/initrd/etc/distro/keys/qubes-4.key
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.109.133, 185.199.110.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1629 (1.6K) [text/plain]
Saving to: āqubes-4.keyā
qubes-4.key 100%[===================>] 1.59K --.-KB/s in 0.001s
2022-11-16 12:31:22 (1.58 MB/s) - āqubes-4.keyā saved [1629/1629]
[user@disp2326 qubes-key]$ ls -al
total 72
drwxr-xr-x 3 user user 200 Nov 16 12:31 .
drwxrwxrwt 13 root root 320 Nov 16 12:29 ..
drwx------ 2 user user 40 Nov 16 12:27 private-keys-v1.d
-rw-r--r-- 1 user user 1312 Nov 16 12:29 pubring.kbx
-rw-r--r-- 1 user user 1890 Nov 16 12:27 pubring.kbx~
-rw-r--r-- 1 user user 1629 Nov 16 12:31 qubes-4.key
-rw-r--r-- 1 user user 2379 Feb 8 2022 qubes-release-4-signing-key.asc
-rw-r--r-- 1 user user 1611 Nov 16 12:30 qubes-release-4-signing-key_mod.asc
-rw-r--r-- 1 user user 49152 Nov 16 12:29 tofu.db
-rw------- 1 user user 1200 Nov 16 12:27 trustdb.gpg
So we see that the 3 keys are different.
Letās see how/why, comparing heads downloaded key with the one we just generated:
[user@disp2326 qubes-key]$ diff qubes-4.key qubes-release-4-signing-key_mod.asc
2d1
< Version: GnuPG v1
Basically, the generated one is the same as the old one, without the GPG v1 header and is considered equal.
Then lestās compare heads downloaded one with the one coming from Qubes OS website:
[user@disp2326 qubes-key]$ diff qubes-4.key qubes-release-4-signing-key.asc
2d1
< Version: GnuPG v1
27,28c26,39
< mqH0I+V+LuMtlE521YHKg0tsB9GVlfWBS10=
< =QN1j
---
> mqH0I+V+LuMtlE521YHKg0tsB9GVlfWBS12JAjMEEAEKAB0WIQRCfxH9D6pLCAEj
> 8Bzd+ho+NoeUlAUCYaQmlwAKCRDd+ho+NoeUlB40D/0YwLGqX5O6tl/q0Vehud2N
> mm5OIpxSZKrpm8vNtf2/rzumBldFSczCtVAkHo4N23hC+IGKHSG7lFZlFue/cng0
> ngopJsfhbj8eAbtdo9lqiqQaiFtUrB8hTd1HgvHjCptBKrSKn4FlJJ91ypLkoyiX
> 27TcfToyEq6qFAWKXXQosYtCzh492WlD7GXXz32/1LnZKMS3TR4x+QfVRc9kn8X5
> HaempDgWw79d7ZAcSDuO4Kb2j/se4aLESTefKtJJ9LuPqhHZ+qGekUCyweiZ+mkR
> ok6XcaOHJEJgsvG1DIGwrGXyKkvqi12W8Q95XAF7y7C98vq4cVyhiLrBCbdgMY4X
> l9vHXIVEL3C032qu4AaeJ2tHZJvl1+nYqam8urQ/APk6pPVs75+IkH7zDfEHh+SF
> m6xAg/0fMKhYDlXB7l3UbiioV8vhBlHEf4XFR/VnnqM1B1TwdjywAbenc9Ev45L0
> 5oqfrerACvYMxUxQVR0WQyrsLjJzinKZjjZW5KYiRn9lO+27rp1kMQHQFhNX1pnj
> oVnJIi0AtwAXumKI78SQpVRMjj6+fqusI/1Zx63XcI9Y8BBZvssYscgt2c9oMtBT
> B/Ng9EaplpSSVCsdcN85VAR7CZT5YPsvsMzSmmUUIRoEb/dHMuMmh0YbBJbBUikP
> dcBETivefvOIZRjSyZYUTg==
> =6A62
[user@disp2326 qubes-key]$
Or more visually through meld:
Basically, gpg āminimizeā operation of the key removed an additional signature (the release key being signed externally) which can be seen:
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key_mod.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: key 1848792F9E2795E9: "Qubes OS Release 4 Signing Key" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
[user@disp2326 qubes-key]$ gpg --home /tmp/qubes-key/ --import qubes-release-4-signing-key.asc
gpg: WARNING: unsafe permissions on homedir '/tmp/qubes-key'
gpg: key 1848792F9E2795E9: 1 signature not checked due to a missing key
gpg: key 1848792F9E2795E9: "Qubes OS Release 4 Signing Key" 1 new signature
gpg: Total number processed: 1
gpg: new signatures: 1
gpg: no ultimately trusted keys found
Under Heads, we keep only the public key used to verify the detached signature. Any other signee which signed the key is not important, since the validity is already considered ātrustedā per Heads committer (which signed his commit) and we try to reduce the size of the public key that are injected in the firmware, removing bloating stuff.
This is not really important in the gained size for Qubes release public key, but as can be seen for tails.key, not having applied gpgās minimize on their ditrribution signing key (release public key) would have bloated us of 2191 additional signee, basically saying that recognisez the validity of the public key by apposing their signatures to itā¦ We do not need that.
In short: Heads simply applied the same minimizing policy to all public key included in the firmware to limit bloating. Public keys are basically high entropy blobs, and are not compressed as part of Heads initrd packing otherwise. And since space is precious, anything that can be removed is removed
Oh.
And if we wanted to replicate the process without the warnings of keys, we would have to follow Verifying signatures | Qubes OS to get rid of the warnings above and add trust to Qubes master key, which is actually the signee we removed from qubes-4.key by above process, and explains the difference in size of the file uploaded under Heads github and used to verify detached signed iso!
1 Like
i see, okay, thanks for information @Insurgo
by the way, since you know a lot about heads, are you part of Heads development ?
i also see, apparently you add verifying installation into Heads documentation.
also, i tried to USB boot from external DVD,
but apparently Heads can only recognize USB thumb drive,
is it possible, for Heads, to USB boot from external DVD ?
if i understand correctly,
the release signing key, under Heads, will be used to verify detached PGP signature,
then the detached PGP signature, will be used to verify Qubes ISO. is it correct ?
but what i donāt understand is, whether it is done automatically by Heads ?
or we have to do it manually in the Heads recovery shell ?
in case the verification fails, will Heads give us kind of warning ?
i.e. release signing key under Heads, fail to verify detached PGP signature, in the media,
or detached PGP signature, fail to verify the ISO.
and then, in case the USB thumb drive we use is infected / compromised,
will it infect heads ?
thanks and regards,
@deeplow: please split the topic from here
Itās about Heads