I am trying to test 4.2 on a librem 14 laptop, but have no access to post in the testing group, so while I want to contribute, I am not really able to. I’m been using qubes for a little over a year and I am a habitual alpha/beta tester so I’d be happy to help.
My first run at 4.2 didn’t last long though, because after install the laptop just gets stuck in an infinite loop immediately following the blue qubes boot screen, so I’m back to 4.1 for now until I figure out what is going on.
The latest weekly build, Qubes-4.2.202308260643-x86_64.iso, doesn’t recognize my AX201 WiFi card. And I don’t have access to a LAN to check a wired connection. fyi
This is a personal repo, no obligation that anything works on it, that’s the whole point of “testing”.
If you want Qubes 4.2, download the torrent file from the official website.
That would be a CoC violation with intent and announcement: instaban.
Ask nicely or do something to improve the situation yourself. Entitled foul mouths are not welcome and won’t be tolerated. This is an official warning.
Would it be possible @deeplow@marmarek for the Weekly Builds Signing Key to be signed by the (Ultimately trusted) Qubes Master Signing Key? Or any other key connected to the Qubes project?
Now that Testing new releases and updates | Qubes OS is recommended on the Qubes website, this would encourage good security practices around distrusting the infrastructure. Esp. since qubes.notset.fr distributes both the .iso files and the signing .key, and doesn’t even use HTTPS
@qc0 I can confirm this. The redirection is not automatic on the first visit, but if you ask for HTTPS, you get it: https://qubes.notset.fr/
And HSTS is enabled, so your browser should upgrade to HTTPS automatically on subsequent visits. (source)
Note that I don’t think any of this makes your point moot! (Even if I suspect that the solution you propose may not be practical, but I’ll let folks who know, rather than suppose answer that.)
By the QMSK? No. They are images built outwith the build infrastructure
AFAIK. fepitre has been clear about the build infrastructure and risks.
They are , however, signed by fepitre-bot.
okay, thank you for the thoughtful replies! FYI @fepitre the current weekly build key is not signed by fepitre-bot (the previous weekly key is, however).
clarifying the risks in the top post I think would be helpful, as would making the signing key (or its fingerprint) available on github.