Ten days ago, it came out that a nation state bullied the single lone developer of `xz`. There were some Windows Tools for running Windows on QubesOS. They worked. Windows ran fast even though debug mode had to be enabled which could make it less secure. After Feb 2022, I was very hesitant because the primary developers were in Russia. Even if these Russian primary developers were trustworthy, we have no idea how much bathroom window pressure is put on them and their family members. Not sure if their code is audited by Polish Qubes-OS developers?
The following says the relevant server was decommissioned and the drivers rebuilt from trusted sources. "Xen Security Notice 1 v1 - winpvdrvbuild.xenproject.org potentially compromised <https://lists.xenproject.org/archives/html/xen-announce/2023-07/msg00000.html> " https://lists.xenproject.org/archives/html/xen-announce/2023-07/msg00000.html ACTIONS TAKEN ============= The possibly compromised system has been decommissioned. We have removed all previous binaries from: https://xenbits.xen.org/pvdrivers/win/ A new set of drivers based on the current master branch (9.0-unstable) and built on a trusted environment have been uploaded on the same folder p.s. Loved that CISA.gov article. Ever since the Office of Personnel Management, aka OPM hack, so many other hacks, and again with the SolarWinds supply chain hack, both the entire US government and Microsoft keying material should have been recreated from scratch on trusted systems. On Sun, Apr 14, 2024 at 10:56 AM Steve Coleman <stevenlcolema...@gmail.com> wrote: > > I got used to use safer ways to copy files from my Windows to other qubes > > If there are alternative ways to perform any of these lost operations > without the drivers then this should be documented to at least partially > alleviate the problem. There must be a way even if that requires using a > developer key to self sign a driver. I'm not familiar with that process at > all. > > Off hand the only thing I can think of would be passing a r/w volume using > qvm-start to allow passing files in or out. Is there a file system type > that will not get corrupted? That does not fix cut-and-paste functionality > but there could be a workaround to auto type into the vm using the current > keyboard interface. Using a network app as a proxy? E.g ssh port > forwarding? Just thinking off the top of my head here. > > I have been needing to rebuild my Win10 VM because it refuses to update, > but I also need to upgrade to 4.2.1 and it seems like my own use case for > Windows on Qubes is a showstopper without at least some level of this > functionality. I could be loosing the use of several software licenses if I > can't find a workaround solution when migrating to 4.2.1 > > On Sun, Apr 14, 2024, 9:38 AM Hugo V.C. <skydive...@gmail.com> wrote: > >> Interesting topic. I tried to use QWT long ago and, fortunately, didn't >> worked so since the very beginning I got used to use safer ways to copy >> files from my Windows to other qubes (I prefer not to give details here). >> In the last two years I have been tempted to debug what was happening with >> my QWT and trying to install them, but I always got a "feeling" that having >> those drivers was not a good idea. "Happy" to see I was right... >> >> I think the current protocols for Windows drivers are not trustable thus >> I'll keep not installing them. Some bullet proof protocol should be >> created, otherwise it is impossible to get any trust. And this protocol >> must NOT depend on M$ nor on Qubes (wonderful) team. Something else. >> >> >> >> El dom., 14 abr. 2024 12:15, Gerhard Weck <gerhardweck...@gmail.com> >> escribió: >> >>> I think, here a word of caution is appropriate regarding the use of >>> Microsoft-signed keys. As a current CISA report >>> <https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf> >>> shows, there have been severe security breaches in the Microsft >>> environment, and they are still continuing, as Microsoft does not seem able >>> to kick the Russian Midnight Blizzard hackers out of its network. For this >>> reason, one should not, security-wise, put too much (any?) trust into >>> Mircosoft signatures of crypto keys, while, concerning QWT, their use is >>> clearly convenient, as it removes the need for running Windows qubes with >>> test-signing enabled. >>> >>> But apart from that, I would trust the security management of Qubes >>> itself much more, where the philosophy is based on not trusting the >>> infrastructure, checking the code by the developers themselves and possibly >>> by the community, and not relying on the security of some external agent. >>> >>> Andrew David Wong schrieb am Sonntag, 14. April 2024 um 10:14:20 UTC+2: >>> >>>> On 4/13/24 8:56 AM, jmake2 via qubes-devel wrote: >>>> > [...] >>>> > >>>> > So, am I getting it right that QWT is not deprecated? I was afraid >>>> for a moment. >>>> >>>> As stated in the QSB, the developers are still working on QWT, so it is >>>> not deprecated. >>>> >>>> > As it was discussed previously, the QWT package can be build from >>>> secure and available sources and put to R4.2+ repos with different >>>> signatures, including secure self-signed but not Microsoft-approved key. >>>> Requirement to allow self-signed drivers is not perfect, but still a way >>>> better solution than current situation, to my understanding. >>>> > >>>> > [...] >>>> >>>> I believe this is the relevant issue: >>>> >>>> https://github.com/QubesOS/qubes-issues/issues/9019 >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "qubes-devel" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to qubes-devel+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/qubes-devel/860e2998-42c7-4912-a972-cbe841fa2000n%40googlegroups.com >>> <https://groups.google.com/d/msgid/qubes-devel/860e2998-42c7-4912-a972-cbe841fa2000n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "qubes-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to qubes-devel+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/qubes-devel/CA%2Bi0rxtG5nd0-ghoB_N3Q%3DTf_XrHaCm_Q8PbhMUfomAfNZ1cPg%40mail.gmail.com >> <https://groups.google.com/d/msgid/qubes-devel/CA%2Bi0rxtG5nd0-ghoB_N3Q%3DTf_XrHaCm_Q8PbhMUfomAfNZ1cPg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/CAJ5FDngrkH8FPUNfuebu0C6iA_6Zm_BC83Wj9OdkBANG%2BeU9Lg%40mail.gmail.com > <https://groups.google.com/d/msgid/qubes-devel/CAJ5FDngrkH8FPUNfuebu0C6iA_6Zm_BC83Wj9OdkBANG%2BeU9Lg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CA%2BVdTb_4Pf%2BjHqFdgghZBnDOUn1-FtWY-fBYrg9fhyhQ1XQ3pw%40mail.gmail.com.
