R4.1: qvm-create-windows-qube


For your information I’m currently refactoring the work done in https://github.com/elliotkillick/qvm-create-windows-qube to be used only in an AdminVM called windows-mgmt. This management VM is automatically setup with Salt formula provided in https://github.com/fepitre/qubes-mgmt-salt-windows-mgmt. Current WIP: https://github.com/fepitre/qvm-create-windows-qube I’ve also cherry picked update of Microsoft download links keys from @wind.gmbh commits.

Please note this is currently WIP and I’m testing part by part the tool. Notably, I don’t have a working QWT iso to test the last installation part. See: Testing Windows and QWT in R4.1.

Stay tuned :slight_smile:


Hi @fepitre

thanks for including my commits into your work. The intention of my pull request that updated HTTP Public Key Pinning (HPKP) keys was to fix the script for users without introducing any changes.

Because a redesign is about to be done I raise the question whether mandatory enforcement of HPKP is really a good idea.
Due to industry changes there are no more TLS Domain Certificates issued for multiple years. This means that the TLS Certificate will certainly be switched at some unknown point of time in every upcoming year .
We risk that we destroy the user experience with the program being broken for at least once a year for a time frame until the program’s key pins are updated.

Because the program already verifies the hash of an image, I do raise the question whether transport security must be enforced in a way that it will break the program regularly.

Of course I acknowledge the problem that there is (at least to my knowledge) no official and comprehensive list of hashes for Microsoft’s products. That means that our way of obtaining correct hashes must be even more trustable and/ or easy to verify if HPKP would be totally left out of the equation.

What are your thoughts?

1 Like