Re: [qubes-users] Qubes 4.0-rc3
On 13/01/2018 03.34, Andrew David Wong wrote:
> On 2018-01-12 08:00, 'awokd' via qubes-users wrote:
> > On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote:
>
> >> I'm not so sure, why not use git branches?
>
>
> One reason that comes to mind:
>
> Segregating the documentation into two different branches would mean
> that contributions that apply to both Qubes versions would only end up
> in one branch, unless someone remembers to manually submit the same
> thing to the other branch and actually makes the effort to do so. Most
> of the time, this won't happen. When it does, it means a second pull
> request that has to be reviewed. Over time, the different branches
> will diverge in non-version-specific content. Good general content
> that was submitted only to the 3.2 branch will effectively disappear
> once 3.2 is deprecated. (Even if it's still on the website, no one
> will look at it, since it'll explicitly be in the subdirectory of a
> deprecated version. And there will be a motivation to remove it from
> the website so that search results aren't populated with out-of-date
> information.)
That ought to be part of the review process, don't you think? ("Have
you opened PRs for these other branches?")
--
Rudd-O
http://rudd-o.com/
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/ae6779fd-2cfb-bcbb-273e-2c8536cf0fb0%40rudd-o.com.
Re: [qubes-users] Qubes 4.0-rc3
On 12/01/2018 14.09, Holger Levsen wrote: > On Fri, Jan 12, 2018 at 01:04:23PM +, 'Tom Zander' via qubes-users wrote: >> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote: >>> Would it be of value if I went through the published Docs and added these >>> version headers? Should newer versions be added at the top (so 4.0 before >>> 3.2 content)? 4.0 might just be "TBD". >> I think that would be wonderful, > I'm not so sure, why not use git branches? This ought to be the chosen solution. Mount the release 4.0 branch on doc/ and the older releases on doc/, then provide links at the top (Doc for / <3.2>). -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4e04b5cb-6366-e1de-4c27-2218f522e02a%40rudd-o.com.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sunday, January 28, 2018 at 10:30:47 AM UTC+8, awokd wrote: > On Sun, January 28, 2018 2:13 am, xxx wrote: > > I burned the ISO to USB stick then started to install Qubes but got the > > following: > > > > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > > Exception: AE_NOT_FOUND, During name lookup/catalog > > (20170531/psobject-252) > > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > > get size: 0x800e [ 137.216201] dracut-initqueue[566]: > > Looks like a buggy firmware. See if your manufacturer has a bios update. > Could maybe try turning off power saving since some messages sort of sound > related. If you don't care about EFI, you could disable it and boot and > install in legacy mode. If you want EFI, could try booting Refind, then > the installer from there. I just updated the BIOS yesterday through the Lenovo Avantage program. Starting Windows doesn't present any problems. I'll check out your other suggestions, thanks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/df3606ee-3eb1-4c6b-8f9d-a715622ac32b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sun, January 28, 2018 2:33 am, Yuraeitha wrote: > > Awkward same-time posting x) > But listen to awokd, he has more experience than I do. Not that much more! Unfortunately, on these boot issues most come down to trial and error like you said... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/785a33dcc7e6cd626f7585bd9e485e08.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sunday, January 28, 2018 at 3:30:47 AM UTC+1, awokd wrote: > On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote: > > I burned the ISO to USB stick then started to install Qubes but got the > > following: > > > > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > > Exception: AE_NOT_FOUND, During name lookup/catalog > > (20170531/psobject-252) > > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > > get size: 0x800e [ 137.216201] dracut-initqueue[566]: > > Looks like a buggy firmware. See if your manufacturer has a bios update. > Could maybe try turning off power saving since some messages sort of sound > related. If you don't care about EFI, you could disable it and boot and > install in legacy mode. If you want EFI, could try booting Refind, then > the installer from there. Awkward same-time posting x) But listen to awokd, he has more experience than I do. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1e71125b-25fc-47f8-8bac-e77bd9131743%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote: > I burned the ISO to USB stick then started to install Qubes but got the > following: > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > Exception: AE_NOT_FOUND, During name lookup/catalog > (20170531/psobject-252) > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > get size: 0x800e [ 137.216201] dracut-initqueue[566]: Looks like a buggy firmware. See if your manufacturer has a bios update. Could maybe try turning off power saving since some messages sort of sound related. If you don't care about EFI, you could disable it and boot and install in legacy mode. If you want EFI, could try booting Refind, then the installer from there. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3899d232c9b8d69f53a3a43bdf9ed6e8.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-12 07:58, awokd wrote: > On Fri, January 12, 2018 1:04 pm, Tom Zander wrote: >> On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users >> wrote: >> >>> Would it be of value if I went through the published Docs and >>> added these version headers? Should newer versions be added at >>> the top (so 4.0 before 3.2 content)? 4.0 might just be "TBD". >>> >> >> I think that would be wonderful, >> >> >> my main issue is with the not knowing if the current docs are >> actually applicable still. If someone could do as much as flag >> known out of date content as 3.2 only, this would be a huge >> help. >> >> The problem of knowing / identifying what isn't actually >> applicable anymore is the main one that I think is causing pain >> right now. > > I have a relatively good amount of experience so should be able to > call out which is which on sight. If not, I can I point that out > too in the 4.0 TBD section. > That would be very helpful! Thank you! > To your point, some of these docs are pretty version specific. > https://www.qubes-os.org/doc/qubes-r3-building/ as a possibly bad > example. It's similar to the 4.0 build procedure but at least the > name should be generalized then. I think I agree with you those > should be separated. I'll plan on skipping them for now. > > I'm a bit concerned it's going to result in ugly looking documents > too, but at least by splitting out the contents now it will be > easier in the future to move into separate documents if we go that > route. > Doing this will provide evidence that helps us decide which system to us. For example, if it turns out that nearly every document has to be split into two sections, that might be a strong indication that there should just be two sets of documents. But if it's only 30%, or if it's usually just certain sections *within* documents, for example, then it might make more sense to stick with the current system. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZcjIACgkQ203TvDlQ MDBB8hAAhuP4K0RtpYbTQoDRSKjomgx7q3TWZUziYNJ7TE2MCgDiGCqs7Bdh8Pk7 4PgNlkOOTVUEgq4ehOgCXbTEL/Gofaat2vrxdPDcXl94Gd4Oi9dhN6c2SGBEAhkL nkyjY6iXxTRBd0+duqI4jN5CIAUcxOPqV+D/naQaLS2uiRX73rwJkAYDHOhiRUY1 hjd+iLK1AzGjjqJs7yBn2UshxwIMZnEHn7GnwzbI1at+vFOIXLaMk5xIEUiekICL +9NeC4ijbOVYIni6UjiJ4Dtr1sGk0Nm8XNHKve5/YOlQEDcciXDFk158yZmYUcR+ h9XwV4afPpSe17p+SZiZLG4UkYjner1GSPY5GhbqHM5+FpYEeWmCbkiSBI9HAEiZ 6PMSUwY2yLJ9V7jQHhzbCqYeLDKcsssn/VmNrcH8aPjrs8dDAxmSYHt+Q0O3mn5G Ka4zgCt6t91PUxYIE2HqAQB3mOSLtKd8gp3rmgkR/HcawSxQfy8Oh6atYMnTu2fG 5G3g407cwwXWedSO9CrqkNz9anCt2MjVKnTXy5j0q0OQtkC7n8GwOz7Q8nPAnH27 WGUlp+0dG6PlLn/MqiR66JdxFMmfv37ATwXj03Zol0JY51B3kczeXzsB5ky6zi2T T9YjFN0oiJFA3fxCt4iMc51vSB56ufYG5yROCnhbdsfksYU59sQ= =EGor -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d4c9f2f6-d3ed-e018-c4f0-ed281b1434ab%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-12 08:00, 'awokd' via qubes-users wrote: > On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote: > >> I'm not so sure, why not use git branches? > One reason that comes to mind: Segregating the documentation into two different branches would mean that contributions that apply to both Qubes versions would only end up in one branch, unless someone remembers to manually submit the same thing to the other branch and actually makes the effort to do so. Most of the time, this won't happen. When it does, it means a second pull request that has to be reviewed. Over time, the different branches will diverge in non-version-specific content. Good general content that was submitted only to the 3.2 branch will effectively disappear once 3.2 is deprecated. (Even if it's still on the website, no one will look at it, since it'll explicitly be in the subdirectory of a deprecated version. And there will be a motivation to remove it from the website so that search results aren't populated with out-of-date information.) > It doesn't sound like that's the route the Qubes team wants to > take right now, Not necessarily. We want to take whichever route is best. We just want to be sure it would be a big enough improvement to be worth the associated costs. As I wrote above: "If there turn out to be significant, compelling reasons to make completely separate sets of docs (one for 3.2 and one for 4.x), of course I'd be happy to do that. We should weigh the costs and benefits, and choose whichever system is best. From a maintainability perspective, it seems simpler and easier just to have a single set of docs, and that's what Qubes has always had, so that's why it's the default system right now. That's not set in stone, but I think an alternative system should deliver significant benefits for it be worthwhile for us to move from the default system. So far, it seems like the objections to sticking with the default system and simply having separate sections within the existing docs rest on misunderstandings about how that system would work, but I'd be happy to be convinced otherwise. :)" > but at least splitting the content on the same page would make it > easier to migrate to that approach if they change their minds! > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZcEkACgkQ203TvDlQ MDCcZBAAnmAlCRfKluzVBd36jqGoXGsk9efWDJSSSIS2OUsebk6Tv+cwvDcOfzA6 HhevMmP6iMB637NkHfDe/aMLbmLfq+401g1Ob5JLzvZ008K3Cb88da0VTUmtQ/k1 DKAusV0j/eNGNg9UM9hpRu2XLHdt7fAovIllARKc2hoDLeNA5uxzb0y2ByArpNib UpaNRZPTPAOCMl2RqjWQIBVhez0Ve8chTqrEx6RHF1NoIBD2FZxJw331z7YLwNUL iLBtpD928mywhk3VeOZtipP4W6W5l3cgxprYGzU/unxKltOb4D1T5iD+dzkBftFr euGg07OY5w/lqr9FBONqtgtKLWNrOsT1Ko60eCOuXLA2oBGcV4wIB2Zb22J0JPgW rCqTn2vhF4wLLW/h0hhMdmj9abxQoShrLoLiUfJa8i+R8yyxWImiY6VbCP7gjAF+ kMHmA88i3yroQawJBwmfnfgGtEpBcFo3+L2uYSUnIQGt3BIW7HYNV1EHKvlA/PIN xUZGAQkPeaCni3GhsVcGBg3YQcYyrcEn5KyRXQYwvHDUBfA5LDmXH26HCDA6el0F MOoZk408Mg0QUZD/Tk72K50c5/XzNC9TF7f9JLWtZ+i2ClJu62OORMpYx4ncaq+e sg6rrSrTZkeZejXh0XbraHNs8WiZVt50kV0JGAFhzSHExnp3Xio= =WcO8 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bec819c3-c695-ff06-3bca-edbcc79b257e%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Fri, January 12, 2018 1:09 pm, Holger Levsen wrote: > I'm not so sure, why not use git branches? It doesn't sound like that's the route the Qubes team wants to take right now, but at least splitting the content on the same page would make it easier to migrate to that approach if they change their minds! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b6546209d17b77cc1b22250b1ae8a4be.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Fri, January 12, 2018 1:04 pm, Tom Zander wrote: > On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote: > >> Would it be of value if I went through the published Docs and added >> these version headers? Should newer versions be added at the top (so 4.0 >> before 3.2 content)? 4.0 might just be "TBD". >> > > I think that would be wonderful, > > > my main issue is with the not knowing if the current docs are actually > applicable still. If someone could do as much as flag known out of date > content as 3.2 only, this would be a huge help. > > The problem of knowing / identifying what isn't actually applicable > anymore is the main one that I think is causing pain right now. I have a relatively good amount of experience so should be able to call out which is which on sight. If not, I can I point that out too in the 4.0 TBD section. To your point, some of these docs are pretty version specific. https://www.qubes-os.org/doc/qubes-r3-building/ as a possibly bad example. It's similar to the 4.0 build procedure but at least the name should be generalized then. I think I agree with you those should be separated. I'll plan on skipping them for now. I'm a bit concerned it's going to result in ugly looking documents too, but at least by splitting out the contents now it will be easier in the future to move into separate documents if we go that route. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2e113eb73c9fd9f04b452ed23c231242.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Friday, 12 January 2018 13:09:35 GMT Holger Levsen wrote: > I'm not so sure, why not use git branches? That has my preference still, but I'm ok for any workable solution. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/22624025.OBojS6ySok%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Friday, 12 January 2018 11:18:19 GMT 'awokd' via qubes-users wrote: > Would it be of value if I went through the published Docs and added these > version headers? Should newer versions be added at the top (so 4.0 before > 3.2 content)? 4.0 might just be "TBD". I think that would be wonderful, my main issue is with the not knowing if the current docs are actually applicable still. If someone could do as much as flag known out of date content as 3.2 only, this would be a huge help. The problem of knowing / identifying what isn't actually applicable anymore is the main one that I think is causing pain right now. Thanks! -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1727079.pSIrDA7H5a%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Fri, January 12, 2018 4:20 am, Andrew David Wong wrote: > It shouldn't require much effort. In most cases, all you have to add > is `## Qubes 3.2` above the existing documentation, shift the rest of the > headers down one by adding a `#` in front of each one, then add `## Qubes > 4.0` above the 4.0 content you want to add. It might be > slightly trickier if the current headings use the underlining syntax. This > requires basic familiarity with Markdown, but that's already required for > most doc contributions. Only one person has to do this for each document, > and many documents will not even require this because the content applies > to both 3.2 and 4.0. Would it be of value if I went through the published Docs and added these version headers? Should newer versions be added at the top (so 4.0 before 3.2 content)? 4.0 might just be "TBD". -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/89c7fa47e95e74b13e9c21e1d721a636.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On 01/11/2018 10:31 PM, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 2018-01-11 14:41, Chris Laprise wrote: >> >> At least no section repetition for the scripts should be necessary. But >> doing this for the dialogs still adds a lot to an already long doc. >> > > Is it bad for a doc to be long when it's immediately obvious which > half you can ignore because it's not the version you're using? Not necessarily for a reader, except in the case where the instructions are long to begin with and the reader happens to scroll into the section for a different version... without a floating page element that always keeps the heading visible, the reader might inadvertently mix directions from the two version-sections. > >> I feel that, apart from making some docs look deceptively long and less >> readable, the most significant downside to melding 3.x/4.x instructions >> together would be to discourage contributions from users. It makes the >> thought of every potential edit seem like a slog through extra markdown, >> and many will think "I don't have time to install 3.2 to write up that >> version". >> > > I don't understand. Why would this be the case? If you want to make a > small edit that pertains only to 4.0, you can simply make that small > edit in the 4.0 section, or add such a section if one doesn't yet > exist, which would only be a few extra characters. A 4.0 user who > wants to add some true fact about 4.0 to the docs doesn't even have to > think about 3.2, much less install it. If they don't have to think about 3.2, that's fine. But I'd expect queries/requests for "3.2 version" would appear in the PRs about some new fixes, info or approaches the users are trying to introduce into the document(s). Making an edit "that pertains only to 4.0" isn't going to be the mental context of the user-contributor in most cases. They will just have new info that they are unsure whether it applies to 3.2 (or if it does, how). And I'm sure even advanced users will be feeling the uncertainty and friction before long. Tom Zander makes some good points, too. OTOH, I don't want to belabor the issue -- and I'm far from certain anyway, this is about psychology. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b7b21880-4ecf-fd0f-bf87-3b67b3affda7%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-11 16:11, 'Tom Zander' via qubes-users wrote: > On Thursday, 11 January 2018 18:16:04 GMT Unman wrote: >> On the VPN case your own comment confirms that it would be >> better to provide a separate section, rather than trying to put >> "exceptions" in to the existing text. > > Thank you for explaining that unman, much clearer indeed. > > While I agree on the general statement above, I feel its not the > best solution in this case where 4.0 have massive changes in all > layers of the technology. A lot of changes, sure, but I wonder whether there are more similarities than differences overall (thinking about fundamental things like the use of Xen and TemplateVMs). > In many cases the about half of the text will be duplicated > between the 3.2 and the 4.x sections, albeit with major changes. > This will not help the reader much. Why is that? Just because many docs will be longer, since they'll have a section for 3.2 and a section for 4.0? > More importantly, I fear that the new users (potential > contributors) that have not used 3.2 will have a hard time > deciding what to do with information that clearly doesn't represent > the current state of technology. > Why will this be a problem? If the section is clearly labeled "Qubes 3.2," but they use 4.0, are you concerned that they won't realize the section doesn't apply to them? If they can't make that distinction, though, why expect them to be any more successful at distinguishing between two sets docs? > Asking people to put a lot of effort into reformatting > documentation It shouldn't require much effort. In most cases, all you have to add is `## Qubes 3.2` above the existing documentation, shift the rest of the headers down one by adding a `#` in front of each one, then add `## Qubes 4.0` above the 4.0 content you want to add. It might be slightly trickier if the current headings use the underlining syntax. This requires basic familiarity with Markdown, but that's already required for most doc contributions. Only one person has to do this for each document, and many documents will not even require this because the content applies to both 3.2 and 4.0. > that may or may not actually be useful to anyone using an older > version Wait, why wouldn't 3.2 documentation be useful to anyone using 3.2? The majority of users are on 3.2 right now: https://www.qubes-os.org/statistics/ And 3.2.1 will be supported for a full year after the stable release of 4.0: https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/ > is a big ask in a volunteer project. >> I personally prefer the solution where a git repo is cloned for >> 3.2 as > "legacy" which is then attached to the website under a > subdirectory and people can edit that for maintainance and fixes. > http://qubes-os.org/doc/3/ or somesuch. > If I understand this proposal correctly, all the current documentation would initially exist in the 4.0 documentation set. But a lot of it, as you've pointed out, only applies to 3.2. So, who's going to go through and remove all the content that no longer applies in 4.0? That's a lot more difficult than formatting a few headings, so it strikes me as a much bigger ask. Alternatively, we could start with an empty directory for 4.0. Then no one has to sort through all the 3.2 documentation to see what still applies. But now we have an even bigger problem: *all* the documentation has to be written (or selectively copy/pasted)! This seems like an even bigger ask the previous one. Is there some third way you have in mind that I'm missing? > The majority of changes would then be in the 'master' branch which > people can edit and they can add references to the github issues > concerning known bugs. We can mark known issues with the pages > like the VPN one I described and people reading the docs will > actually be aware of pitt-falls. > You can (and are encouraged) to do exactly this under the current system. There's nothing stopping you from doing this, and there are a lot of examples where this has already been done in the existing documentation. > In my opinion there is only one thing worse than no documentation, > it is official looking documentation that is wrong. > I agree, but I don't see why having clearly-labeled sections where there are version differences would result in this. If there's some official documentation in a section called "Qubes 3.2," it's not "wrong." It applies to 3.2. Maybe the concern is that, *before* someone gets around to adding the "Qubes 3.2" heading, a 4.0 user will see it and be misled. That's a legitimate concern, but how would your alternative proposal avoid it? If we simply clone the documentation into two separate sets -- one for 3.2 and one for 4.0 -- we have the exact same problem. The 4.0 clone still has stuff in it that's only true in 3.2, and until someone gets around to deleting it, a 4.0 user who sees it could be
Re: [qubes-users] Qubes 4.0-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-11 14:41, Chris Laprise wrote: > On 01/11/2018 01:16 PM, Unman wrote: >> On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote: >>> On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote: On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote: >>> > I poked the Qubes guys about providing a separate dir on the website to > make it clear what is 3.x and what is 4.x specific, but they stated we > should instead put notices about exceptions in the document pages. That's not exactly right. Please see: >>> .. In other words, do not just add notices in the text about exceptions. Instead, make clearly-labeled sections for 3.x and 4.x so that users can easily find the right information no matter which version of Qubes they're using. > So I guess things like ProxyVMs should be mentioned to be old and AppVM > is the new. >>> >>> Ok, I am having problem seeing your solution and my explanation of it as >>> any >>> different, in practice. >>> Maybe I'm missing the obvious, I'm just not seeing it. >>> >>> In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/ >>> * in v.4 there is no "NetVM". >>> * There is no "ProxyVM" >>> * The create qubes screenshot is considerably different. >>> * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK). >>> * does not use iptables anymore. >>> >>> Ok, going to stop now. I got to half the page and some 80% of the text and >>> screenshots are wrong for v4. >>> >>> How would you solve that in line with the QubesOS policy? >> >> The difference is between this style: >> >> You can attach a disk image to a qube using qvm-block : >> qvm-block -A [qube:] >> (This syntax is not available in 4.0) >> >> and this: >> 3.0 >> You can attach a disk image to a qube using qvm-block : >> qvm-block -A [qube:] >> >> 4.0 >> You cannot attach a disk image to a qube using qvm-block. >> >> >> The advantage of using labelled sections is that it should be easier >> for users to find the material relevant to the version they are using. >> Also, that once 3.0 is retired, it will be simple to remove the 3.0 >> relevant material, rather than filleting our bits from each page. >> >> On the VPN case your own comment confirms that it would be better to >> provide a separate section, rather than trying to put "exceptions" in to >> the existing text. >> > > At least no section repetition for the scripts should be necessary. But > doing this for the dialogs still adds a lot to an already long doc. > Is it bad for a doc to be long when it's immediately obvious which half you can ignore because it's not the version you're using? > I feel that, apart from making some docs look deceptively long and less > readable, the most significant downside to melding 3.x/4.x instructions > together would be to discourage contributions from users. It makes the > thought of every potential edit seem like a slog through extra markdown, > and many will think "I don't have time to install 3.2 to write up that > version". > I don't understand. Why would this be the case? If you want to make a small edit that pertains only to 4.0, you can simply make that small edit in the 4.0 section, or add such a section if one doesn't yet exist, which would only be a few extra characters. A 4.0 user who wants to add some true fact about 4.0 to the docs doesn't even have to think about 3.2, much less install it. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpYK/4ACgkQ203TvDlQ MDCO5g//X83cUUXJ+wC3PbbyXFcPnryX+po4wpscNtzjN9XEY3isKFpbzWph2iPD E365gKrhZCPn5Rmcum2cTtEdtoP9AOzMTgaZGF8xkkq0XZmZsAppAbfEhNHHkcdT 1WMkGvnYsFmt+Q8m0EgRmuKsU+STyrm7b5ZGI2ilweqYyBRMNtbOQl+PaPX4A6dY snHECZ7yZ9wLQGPJaVV7uxirxEnxq0jtc55jbEou6Pk3yMY3hCKeYzlTi9DMJ8hh kuVVoH58dXu0R2C7CunpfZ46Z5PRiV3+8Tm5pRBMZHhEomKLIv9VkVZ2JBw9kbmj FMOmk3XTsYZAFfYpmlKM9yNM0s9ZrHniCZMA6cTlZpqVFlGnsZGso3fqapBayijy zuGcwYPa0dIw+eWqnz+wbfOPrBxV5U0O3y9hM7HO6RDG0nrBLHO2QKO+wUugCmX0 DkKRkmN5a0oueIDf2DAdeXGLCBnSy9zdcyrtXDtbDh7Rlwg9ko9f82ZZoZM6alIb 7J0J73el8KjLiJEtJPu8vGTYq6EIhoflvXDMzXwd/49Oeoqb7MeJ7qo14iad3bp0 nu3z2n9MSa2VP71p6db9aKOGYb+chHMA6l09vd/Fab4mIQVl/LA2DpEDFV7wOgwv VJ/Q5VuidOZ0lxw7jpmmeqFC07g98qdxnbP+TXVCsio2JbhcbZA= =w/TA -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/029619de-90c6-bdfd-ad38-4ce5f5beb739%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Thursday, 11 January 2018 18:16:04 GMT Unman wrote: > On the VPN case your own comment confirms that it would be better to > provide a separate section, rather than trying to put "exceptions" in to > the existing text. Thank you for explaining that unman, much clearer indeed. While I agree on the general statement above, I feel its not the best solution in this case where 4.0 have massive changes in all layers of the technology. In many cases the about half of the text will be duplicated between the 3.2 and the 4.x sections, albeit with major changes. This will not help the reader much. More importantly, I fear that the new users (potential contributors) that have not used 3.2 will have a hard time deciding what to do with information that clearly doesn't represent the current state of technology. Asking people to put a lot of effort into reformatting documentation that may or may not actually be useful to anyone using an older version is a big ask in a volunteer project. I personally prefer the solution where a git repo is cloned for 3.2 as "legacy" which is then attached to the website under a subdirectory and people can edit that for maintainance and fixes. http://qubes-os.org/doc/3/ or somesuch. The majority of changes would then be in the 'master' branch which people can edit and they can add references to the github issues concerning known bugs. We can mark known issues with the pages like the VPN one I described and people reading the docs will actually be aware of pitt-falls. In my opinion there is only one thing worse than no documentation, it is official looking documentation that is wrong. > Also, that once 3.0 is retired, it will be simple to remove the 3.0 > relevant material, rather than filleting our bits from each page. This would be even better, if qubes ever wants to they can just remove the subrepository. What do others think? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11311960.j3zXc7upma%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On 01/10/2018 03:47 PM, Connor Page wrote: > The official templates use nftables so shouldn’t be mixed with iptables. I > didn’t have time to learn about nftables, so just removed nftables package > from debian 9 template. YMMV. > Hmmm, I was just thinking how Qubes' own guest scripts still use iptables even in fedora-26. IIUC, iptables and nft are two different interfaces to netfilter. I don't know if it really matters, at least for the R4.0 window. I'd prefer to put the syntax change (for docs) off until a later release. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3ff66d44-d508-db8a-92cc-afaa16940560%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On 01/11/2018 01:16 PM, Unman wrote: > On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote: >> On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote: >>> On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote: >> I poked the Qubes guys about providing a separate dir on the website to make it clear what is 3.x and what is 4.x specific, but they stated we should instead put notices about exceptions in the document pages. >>> >>> That's not exactly right. Please see: >> .. >>> >>> In other words, do not just add notices in the text about exceptions. >>> Instead, make clearly-labeled sections for 3.x and 4.x so that users >>> can easily find the right information no matter which version of Qubes >>> they're using. >>> So I guess things like ProxyVMs should be mentioned to be old and AppVM is the new. >> >> Ok, I am having problem seeing your solution and my explanation of it as any >> different, in practice. >> Maybe I'm missing the obvious, I'm just not seeing it. >> >> In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/ >> * in v.4 there is no "NetVM". >> * There is no "ProxyVM" >> * The create qubes screenshot is considerably different. >> * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK). >> * does not use iptables anymore. >> >> Ok, going to stop now. I got to half the page and some 80% of the text and >> screenshots are wrong for v4. >> >> How would you solve that in line with the QubesOS policy? > > The difference is between this style: > > You can attach a disk image to a qube using qvm-block : > qvm-block -A [qube:] > (This syntax is not available in 4.0) > > and this: > 3.0 > You can attach a disk image to a qube using qvm-block : > qvm-block -A [qube:] > > 4.0 > You cannot attach a disk image to a qube using qvm-block. > > > The advantage of using labelled sections is that it should be easier > for users to find the material relevant to the version they are using. > Also, that once 3.0 is retired, it will be simple to remove the 3.0 > relevant material, rather than filleting our bits from each page. > > On the VPN case your own comment confirms that it would be better to > provide a separate section, rather than trying to put "exceptions" in to > the existing text. > At least no section repetition for the scripts should be necessary. But doing this for the dialogs still adds a lot to an already long doc. I feel that, apart from making some docs look deceptively long and less readable, the most significant downside to melding 3.x/4.x instructions together would be to discourage contributions from users. It makes the thought of every potential edit seem like a slog through extra markdown, and many will think "I don't have time to install 3.2 to write up that version". -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c01a27b7-4f52-1764-9e26-ed0c0721832d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Thu, Jan 11, 2018 at 09:18:46AM +, 'Tom Zander' via qubes-users wrote: > On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote: > > On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote: > > > > I poked the Qubes guys about providing a separate dir on the website to > > > make it clear what is 3.x and what is 4.x specific, but they stated we > > > should instead put notices about exceptions in the document pages. > > > > That's not exactly right. Please see: > .. > > > > In other words, do not just add notices in the text about exceptions. > > Instead, make clearly-labeled sections for 3.x and 4.x so that users > > can easily find the right information no matter which version of Qubes > > they're using. > > > > > So I guess things like ProxyVMs should be mentioned to be old and AppVM > > > is the new. > > Ok, I am having problem seeing your solution and my explanation of it as any > different, in practice. > Maybe I'm missing the obvious, I'm just not seeing it. > > In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/ > * in v.4 there is no "NetVM". > * There is no "ProxyVM" > * The create qubes screenshot is considerably different. > * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK). > * does not use iptables anymore. > > Ok, going to stop now. I got to half the page and some 80% of the text and > screenshots are wrong for v4. > > How would you solve that in line with the QubesOS policy? The difference is between this style: You can attach a disk image to a qube using qvm-block : qvm-block -A [qube:] (This syntax is not available in 4.0) and this: 3.0 You can attach a disk image to a qube using qvm-block : qvm-block -A [qube:] 4.0 You cannot attach a disk image to a qube using qvm-block. The advantage of using labelled sections is that it should be easier for users to find the material relevant to the version they are using. Also, that once 3.0 is retired, it will be simple to remove the 3.0 relevant material, rather than filleting our bits from each page. On the VPN case your own comment confirms that it would be better to provide a separate section, rather than trying to put "exceptions" in to the existing text. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2018081604.kpydxfvgvn636xqw%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On Thursday, 11 January 2018 03:42:11 GMT Andrew David Wong wrote: > On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote: > > I poked the Qubes guys about providing a separate dir on the website to > > make it clear what is 3.x and what is 4.x specific, but they stated we > > should instead put notices about exceptions in the document pages. > > That's not exactly right. Please see: .. > > In other words, do not just add notices in the text about exceptions. > Instead, make clearly-labeled sections for 3.x and 4.x so that users > can easily find the right information no matter which version of Qubes > they're using. > > > So I guess things like ProxyVMs should be mentioned to be old and AppVM > > is the new. Ok, I am having problem seeing your solution and my explanation of it as any different, in practice. Maybe I'm missing the obvious, I'm just not seeing it. In this specific case of the VPN page. https://www.qubes-os.org/doc/vpn/ * in v.4 there is no "NetVM". * There is no "ProxyVM" * The create qubes screenshot is considerably different. * adding 'meminfo-writer' and 'network-manager' are not needed (AFAIK). * does not use iptables anymore. Ok, going to stop now. I got to half the page and some 80% of the text and screenshots are wrong for v4. How would you solve that in line with the QubesOS policy? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/15007549.cTkGlXaZ1X%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-10 12:53, 'Tom Zander' via qubes-users wrote: > On Wednesday, 10 January 2018 18:32:39 GMT Chris Laprise wrote: >> I also have a download-able project that makes the scripted/antileak >> setup fairly simple in Qubes R4.0: > > Please consider updating the docs repo with this :-) > > I poked the Qubes guys about providing a separate dir on the website to make > it clear what is 3.x and what is 4.x specific, but they stated we should > instead put notices about exceptions in the document pages. > That's not exactly right. Please see: https://www.qubes-os.org/doc/doc-guidelines/#version-specific-documentation Specifically: "In cases where a documentation page covers functionality that differs considerably between Qubes OS versions, the page should be subdivided into clearly-labeled sections that cover the different functionality in different versions." In other words, do not just add notices in the text about exceptions. Instead, make clearly-labeled sections for 3.x and 4.x so that users can easily find the right information no matter which version of Qubes they're using. > So I guess things like ProxyVMs should be mentioned to be old and AppVM is > the new. > - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpW3QcACgkQ203TvDlQ MDBFPxAAh14g5TA1GxOnWL+uBQIJLVgz63/j18j5hWD6lA9VaqGZkYm6yd1Ctd2E OoGVqbIdPtXnlB53E25tCSn0+iRiFeZ+XfmdMGxP8UQ96Cdl/dc/JZQeMMpcuGbH 17HdtXhNGPkg1g0/kG04Eggc43ZdjcBGn94Rv3InPGJiLUQutPXrS6g3kp+N6OL4 iH8Vn/P8PUUlGHfuhMjRAxQPlTzIPt6DA/eivjRDZ3IR6Zw/LCFxyZ6IZf5Cxdet gX+5TIrkmDBc/MqkW+xQWdYYfQao0hwqhWRXmrNMXaG4Q/yTC+/GmesY+3RU7T/7 tMPPcPjZ+I0MjDq81YSz/C7bcwgE5k6jLplUmZV43xHM2+JLPWGQf0d0Qf//VdJr Y9oASEPbOoSweOAGRd7n7oNaqPgarGRvPdRIecDckXAK25mVed/da7FZZ1EL+HKc ij/Zpw/X9ZKG3XbCvUlYOPkExlerIHvj6rZC4PuGYB45K4nxKELoGEIJakjHkSel VPOPiZBPwUqSCtwNox5APivbpM8Jm5oKEIAm768KwHhHZC+WZQq/ir2j9Fcxqb3O fg5NgNFaJ0WsIs9hAZAF1ALC7focKsB2wre8qy0vRKzYuhD3FRCPcuOeGkW6eCA7 BNOvbDYhMiLDyXnRnlO3/CVHqnioWWEAUP7pFrxtpp+xTdJBbRo= =cxLl -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8e0a355b-17b1-a766-492a-2727696c8399%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3c4f1c36-44f1-4363-931f-07462dadf83c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3
On 01/10/2018 01:53 PM, 'Tom Zander' via qubes-users wrote: On Wednesday, 10 January 2018 18:32:39 GMT Chris Laprise wrote: I also have a download-able project that makes the scripted/antileak setup fairly simple in Qubes R4.0: Please consider updating the docs repo with this :-) I poked the Qubes guys about providing a separate dir on the website to make it clear what is 3.x and what is 4.x specific, but they stated we should instead put notices about exceptions in the document pages. So I guess things like ProxyVMs should be mentioned to be old and AppVM is the new. Of course, there is very little R4.0 documentation at this point. There is also a blocking issue that leaves the behavior of firewall scripts undetermined for now; The update for the VPN doc will be done when that issue is closed. Yes, "AppVM supplying networking" would be a replacement term for ProxyVM. I prefer a separate area for R4 docs as well. The command line tools and GUI have changed enough to warrant it, IMHO, and its off-putting to be faced with documenting a lot of "do-this-or-that". -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9768ff0b-6502-da9a-0e65-eed595110113%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3 boot and performance is quite slow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jan 07, 2018 at 04:59:44AM -0800, Fabrizio Romano Genovese wrote: > Ok, I dug a bit deeper into this. It doesn't look like a problem of how much > memory I give to VMs. Essentially, my QubesOS boots in two different ways: > > - When QubesOS is happy, it starts in ~1 min (yup, starting up all the VMs > still takes a while). The overall system is very reactive, for instance if I > type qvm-ls I obtain some output straight away. Moreover, if I start a VM the > notification "VM blabla is starting" is displayed immediately. > > - When QubesOS is not happy, it starts in ~3mins. The overall system is very > slow, qvm-ls takes 3-4 seconds to display output, and starting a VM takes up > to 20 seconds. Even the notification "VM blabla is starting" is displayed 4-5 > seconds after the command is issued. Moreover the battery is drained much > much quicker (200% quicker give or take). > > What makes Qubes happy or not happy to start seems to be completely random. I > have a slight suspect that this may depend on booting the laptop while > plugged/unplugged, but I cannot confirm this. > Essentially my Qubes experience atm can be exemplified as follows: "At boot, > throw a coin. If it's heads then it's fine, otherwise it's fubar". Any > suggestion (or report of similar behavior) would be greatly appreciated! Is it Dell Latitute by a chance? I have very similar problem on such system, regardless of Qubes version: when it is on AC power, performance is normal, but on battery it is significantly slower. Some workaround is to change CPU scaling governor, by executing in dom0: xenpm set-scaling-governor performance - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpSuRQACgkQ24/THMrX 1yyUiQgAhD98/UgCgmUIhyu77ShIccLqV0WqE+pPnFmC8uAije3wRztS6JE83ioP /KI0GuCiGMgSDy/zodPkeh9CTG5pRE8K6qvkN6Xp0jBKWdvoV+DUyFw/Fx1ZX/yz UpvMFdmIZCeF6HNndKI4jWTsJS/ypg8H8mZQ4odRtFXUiYaiRt1mbp6zS10cmMpB kl0OQM8z3JBCrVaytYCGHEGvNoDU/fXnd485S35Nu4W00/1f2vIhDvsDPpk/PVa2 AxRC6LnWxxmO1UTEo30m7VJOE8ylezd0ZwwtahMGUUN8NyBWgstJA3UUQL9bVUuE F1kXEZ7iAW9YvxQHPFpm18BAHxfaaA== =r0ng -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180108001932.GB12450%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3 boot and performance is quite slow
On Sunday, January 7, 2018 at 1:59:45 PM UTC+1, Fabrizio Romano Genovese wrote: > Ok, I dug a bit deeper into this. It doesn't look like a problem of how much > memory I give to VMs. Essentially, my QubesOS boots in two different ways: > > - When QubesOS is happy, it starts in ~1 min (yup, starting up all the VMs > still takes a while). The overall system is very reactive, for instance if I > type qvm-ls I obtain some output straight away. Moreover, if I start a VM the > notification "VM blabla is starting" is displayed immediately. > > - When QubesOS is not happy, it starts in ~3mins. The overall system is very > slow, qvm-ls takes 3-4 seconds to display output, and starting a VM takes up > to 20 seconds. Even the notification "VM blabla is starting" is displayed 4-5 > seconds after the command is issued. Moreover the battery is drained much > much quicker (200% quicker give or take). > > What makes Qubes happy or not happy to start seems to be completely random. I > have a slight suspect that this may depend on booting the laptop while > plugged/unplugged, but I cannot confirm this. > Essentially my Qubes experience atm can be exemplified as follows: "At boot, > throw a coin. If it's heads then it's fine, otherwise it's fubar". Any > suggestion (or report of similar behavior) would be greatly appreciated! > > Cheers, > Fab The battery issue, btw, as far as I recall is nothing new in Qubes 4. It's not something specifc to your system, and if it gets fixed, it'll probably be an update to fix all the Qubes 4 systems out there. But maybe there are settings you can flip to fix it manually, however it's not something I've checked. Make sure the VM's that start at boot, are starting just as slow (or quick) as if you started them on an already running Qubes system. If the speed is similar, then at least you can assume it has nothing to do with the actual booting process. It sounds weird that it happens randomly, maybe a few more clues are needed to hunt down the actual reason as to why it happens, unless someone with better insight drops by. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8eb9e2cd-8f34-457b-b238-238d95d23fe0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3 boot and performance is quite slow
On Sunday, January 7, 2018 at 1:59:45 PM UTC+1, Fabrizio Romano Genovese wrote: > Ok, I dug a bit deeper into this. It doesn't look like a problem of how much > memory I give to VMs. Essentially, my QubesOS boots in two different ways: > > - When QubesOS is happy, it starts in ~1 min (yup, starting up all the VMs > still takes a while). The overall system is very reactive, for instance if I > type qvm-ls I obtain some output straight away. Moreover, if I start a VM the > notification "VM blabla is starting" is displayed immediately. > > - When QubesOS is not happy, it starts in ~3mins. The overall system is very > slow, qvm-ls takes 3-4 seconds to display output, and starting a VM takes up > to 20 seconds. Even the notification "VM blabla is starting" is displayed 4-5 > seconds after the command is issued. Moreover the battery is drained much > much quicker (200% quicker give or take). > > What makes Qubes happy or not happy to start seems to be completely random. I > have a slight suspect that this may depend on booting the laptop while > plugged/unplugged, but I cannot confirm this. > Essentially my Qubes experience atm can be exemplified as follows: "At boot, > throw a coin. If it's heads then it's fine, otherwise it's fubar". Any > suggestion (or report of similar behavior) would be greatly appreciated! > > Cheers, > Fab After you type in your drive encryption password, followup by typing F1 key on your keyboard. This way you can follow the booting process in details as it happens. If any booting processes are hanging, you'll be able to take note "which one", and thereby narrow down the possible culprit. You can also do a "sudo journalctl --boot" or akin to that, after booting. But remember to do so after a fresh bootup, unless you want a mountain of extra unneeded information. Also, if the booting is slow before you type in your drive encryption, then you know it's related to settings or features EFI/UEFI or Legacy-Boot/BIOS. It could also possibly be because you got a thumb-drive or external-harddrive sitting in your USB; which on some systems can make the booting process significantly slower as the system tries to identify bootable systems on the extra external-drives/thumb-drives. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2969094e-6594-4f75-90c3-65c5869ba631%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3 boot and performance is quite slow
Ok, I dug a bit deeper into this. It doesn't look like a problem of how much memory I give to VMs. Essentially, my QubesOS boots in two different ways: - When QubesOS is happy, it starts in ~1 min (yup, starting up all the VMs still takes a while). The overall system is very reactive, for instance if I type qvm-ls I obtain some output straight away. Moreover, if I start a VM the notification "VM blabla is starting" is displayed immediately. - When QubesOS is not happy, it starts in ~3mins. The overall system is very slow, qvm-ls takes 3-4 seconds to display output, and starting a VM takes up to 20 seconds. Even the notification "VM blabla is starting" is displayed 4-5 seconds after the command is issued. Moreover the battery is drained much much quicker (200% quicker give or take). What makes Qubes happy or not happy to start seems to be completely random. I have a slight suspect that this may depend on booting the laptop while plugged/unplugged, but I cannot confirm this. Essentially my Qubes experience atm can be exemplified as follows: "At boot, throw a coin. If it's heads then it's fine, otherwise it's fubar". Any suggestion (or report of similar behavior) would be greatly appreciated! Cheers, Fab -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/938de199-7b6f-4132-983e-0720f1929720%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3, Whonix template: update-command-not-found
On Sat, January 6, 2018 1:19 am, Fabrizio Romano Genovese wrote: > Yup, if you type curl it works, but you can't curl anything out of it OK, I see what you mean. What are you trying to accomplish? If it's just a one time file copy, you could use qvm-copy-to-vm to copy it to your template from another VM that does have network access. If it's a curl you want to run on every startup of a disposable VM, there should be some way to script that. Be careful to not customize it too much though, because if you make a change that affects Tor browser itself you might make it easily fingerprintable. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bbe4a25f9111bd23d38e9de8473b43f8.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3, Whonix template: update-command-not-found
Yup, if you type curl it works, but you can't curl anything out of it because you don't have connection. To reproduce what I'm talking about, open a terminal in whonix-ws/gw and type some random stuff (like "sdshgow"). Press enter. Whonix will tell you "Could not find the database of available applications, run update-command-not-found as root to fix this" Equivalently, you may just directly try to type 'update-command-not-found' and find that the template tries to curl some files without success... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8561b5a9-7229-4035-ba65-05c40f298be4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3, Whonix template: update-command-not-found
On Fri, January 5, 2018 11:11 pm, Fabrizio Romano Genovese wrote: > > This very very annoying thing happened to me also on Qubes 3.2. > Essentially, on a whonix-based template, (whonix-ws or whonix-gw, doesn't > really matter), every time I type something (aside of some basic commands > such as sudo, firefox, ls etc) I receive the message: > > "Could not find the database of available applications, run > update-command-not-found as root to fix this" In 3.2, I opened a terminal on my whonix-ws template, typed "curl" and it worked right away. If yours doesn't, you might want to reinstall the template. Also, on 3.2 double-check to see if you whonix-ws and whonix-gw templates are set to use sys-whonix for their netvm. (Does not apply to 4.0). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/bc9e27fdea3f47138947f1ddac03f240.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 rc3 boot and performance is quite slow
On Thursday, 4 January 2018 11:49:45 GMT Fabrizio Romano Genovese wrote: > Looking at the console messages at startup, it looks like the problem is > that Qubes takes more than one minute to boot sys-net, sys-firewall, > sys-usb and sys-whonix. That was not the case in 3.2. > > Also, when giving > qvm-start someVM > the startup time is again quite slow. Could it be that my VMs are based on > Fedora26? Can you try giving your VMs more initial memory? I saw that the default of 400MB is causing VMs to swap like crazy on startup. I change it to 1000MB and stuff starts significantly faster. I also removed swap in fstab on all templates, the only effect this has had so far is show that the memory balancer is in need of work. It fails to give hosts memory when they use significantly more than others. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4469951.fVkcPeMF00%40mail. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-11-29 15:03, genevieve.c.gauth...@gmail.com wrote: > On Wed, 2017-11-29 at 15:59 +, Unman wrote: >> In the Fedora documentation there ARE methods described for >> getting bug reports out of the install process, but they require >> active intervention from the user (copy to another drive or scp >> across network). There's no suggestion that these reports would >> be automatically submitted. >> >> I've had a quick look through the code and i dont see any >> mechanism for passing on bug reports - but it was a very quick >> look. > > Interesting & very good to know this but that would have surprise > me a lot from a Qubes OS installation. Have you learned if it is > specific to Qubes 4.0 rc3 (perhaps the installation part has been > there for a long time before this release) ? > > 3-4 questions remains for me. If you can learn those answer in the > future, I believe this issue would have been truly investigated for > me. > > With an "active" intervention from the user (or if I had connected > to the internet and submitted my report from my computer to the > computer receiving those reports) > > 1.1 : Does my passphrase would have been transmitted ? YES/NO ? > 1.2 encrypted along the way ? YES/NO ? 2.1 : If YES 1.1, where/who > does the passphrase would have been transmitted/ transmitted to > 2.2 : Who would have had access to this information ? > > > I am not looking for an immediate answer. However, I am still > curious about all this. Such a strange 'Bug Report' to see it > like this.. Seems complicated to use those information to comprise > the whole system via dom0 (that's good) > Hi all, After checking with the Qubes Security Team, I'm happy to report that there is no cause for alarm here: 1. For security, networking is always disabled in the Qubes OS installer, so you would not be able to send that bug report (or anything else, for that matter), even if you wanted to. Disabling networking during installation is necessary for Qubes to protect itself before it creates a NetVM (and hence before the network stack has been isolated). 2. We agree that sensitive user data, especially passwords, should never be included in bug reports. The last thing we want is for any third party (least of all us) to see a Qubes user's private data. In fact, you can think of the entire Qubes OS Project as working to ensure the exact opposite. :) 3. Qubes OS uses an installer called Anaconda [1], which generated the bug report you saw. After it performs an installation, Anaconda saves the data from that installation in /root/anaconda-ks.cfg. We have verified that the LUKS (disk encryption) password is not stored in this file. Only a hash of the user account / screen locker password is stored there (not the password itself, and not even a hash of the LUKS password is stored there). We have also filed an upstream bug report with Fedora about Anaconda including the LUKS password in the bug report. [2] [1] https://en.wikipedia.org/wiki/Anaconda_(installer) [2] https://bugzilla.redhat.com/show_bug.cgi?id=1519895 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJaI0jZAAoJENtN07w5UDAwYMsQAKkgoqP4VzitWKissQr9ls2c kYpXuOCD9WWj9toAg2weK82W8YvCqMBhuuZfO7UUR1qyYE1d3F8g79dvKBDj1tGD JiNXoaJSPpsjyOpGEMcZAF+5dLtDfZqrfdY6LewpRQ18aIsRy/j3fLOVsnWNTATv 2g1RVRij1Z4nZn4kjr5oP99k+u9z/IBMR9QFo6L4D8+Mxb3mGXOCQqOxVkXuDojP 5vw7b5ICEPbmQRVbylmbuXA2RpQ/I6LPsNR7vELtMoQGyEHN7JHnHlU4sM0tkh8V qiqG5u6g1cqoZs+SvspFz9xd1idrtx8zFvlZFtAXWDsM7M5pfJCbtTPnKRlk4iEQ dGabpRYco/+E9fos7k+ypsP3iqh/sLB8mHxkMPcdDdmJTLZYqj7pRUqOX3e+AiRs QAZ8oOKFMEhmVmKbNWoArE9WNiT7w1zjzywUPuxWN/4nOVcm0TTqnOGGNHP2Ys8C wqOZ7bOnA089mPR8WNYN8JSHiAqd2JpLJQlmSjUUp4kQWfczaCiRh7CodgInihL9 +R++lcCNAQ2c+T9LeUwwa0ibXYiOHWVewMP9tg1K7fVa7nDZXzn3O7LSyw31FcXF 2eoFusB7Ot+GKeDWTPMlRELy2iEaa46oQc1veE3FoU6s9biYw7wrIKRpwEO5Gpu7 wTfnq1qL23hv5QbnlE/E =I7ZH -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/26fe33d1-3233-c946-cb2d-6e6af9887163%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
On Wed, 2017-11-29 at 15:59 +, Unman wrote: > In the Fedora documentation there ARE methods described for getting > bug > reports out of the install process, but they require active > intervention > from the user (copy to another drive or scp across network). There's > no > suggestion that these reports would be automatically submitted. > > I've had a quick look through the code and i dont see any mechanism > for > passing on bug reports - but it was a very quick look. Interesting & very good to know this but that would have surprise me a lot from a Qubes OS installation. Have you learned if it is specific to Qubes 4.0 rc3 (perhaps the installation part has been there for a long time before this release) ? 3-4 questions remains for me. If you can learn those answer in the future, I believe this issue would have been truly investigated for me. With an "active" intervention from the user (or if I had connected to the internet and submitted my report from my computer to the computer receiving those reports) 1.1 : Does my passphrase would have been transmitted ? YES/NO ? 1.2 encrypted along the way ? YES/NO ? 2.1 : If YES 1.1, where/who does the passphrase would have been transmitted/ transmitted to 2.2 : Who would have had access to this information ? I am not looking for an immediate answer. However, I am still curious about all this. Such a strange 'Bug Report' to see it like this.. Seems complicated to use those information to comprise the whole system via dom0 (that's good) P-S & It means, I can continue my own little project of giving Qubes usb stick to people around me so they can access their bank account online without having to worry about being on their "vulnerable" (or even worst compromised win10 OS) windows OS. Futhermore, I feel you have made a great job at Qubes OS so it would be simple for me to teach people how to open a disposable-vm for this purpose and this purpose only (without really having to learn about Dom0 or about this fascinating architecture if they are not interessed). Love the Qubes "color code" BTW. It will make my life very easy when I'll explain to people which color they must see on their browser to feel more secure without having to teach to any grandparents about VM, Xen Hypervisor and Dom0 interaction lol) Just using a linux distro would be superior I think.. but Qubes and a disposable-vm seems perfect to be just to "go to the bank online" if you are old and know little about computers. The cost of this is idea is minimal too (really just having a 32gb usb media lying around). I do not think those would have been targeted Qubes user. Qubes does not even need any modification for this project. I will be able to teach to many people in less than <30 minutes I think with one demonstration during the holidays. Better safe than sorry and with no money ! Agree ? :-) Take Care & Thank you -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1511989413.14418.54.camel%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
On Wed, Nov 29, 2017 at 02:51:33AM -0500, '[799]' via qubes-users wrote: > Hello Unman, > > >> It's perfectly possible that the installer (not principally written by > >> Qubes) could mistakenly include a passphrase string. > > As far as I have understand, the problem is not that the password is shown, > but that the report with this error mistake and the password could get > transferred. I don't want that my password gets transferred in some part of > an error report. > > >> I've seen similar stuff included in all sorts of error reports in the past. > > This might be true, but this doesn't make this less harmless, if the password > is really bundled in an error report that gets transferered somewhere. > > >> It doesn't mean that Qubes "can't be trusted" > > Wait, it's not (!) about blaming the Qubes team. > If my understanding is correct, and the password is included in an error > report that gets transferred to a 3rd party, this is a really bad thing as > something like this should not happen from my understanding. > > [799] > > >> Also, since this is an installation error, let's not over egg the problem > > - cant be trusted" quote came from your previous comment. I dont think there's any evidence that the error report DOES get sent to a 3rd party is there? (Qubes? Fedora? NSA?) There are install logs in /tmp which are stored in RAM, and disappear after the installation process ends/aborts. The same would likely appply to this report. In the Fedora documentation there ARE methods described for getting bug reports out of the install process, but they require active intervention from the user (copy to another drive or scp across network). There's no suggestion that these reports would be automatically submitted. I've had a quick look through the code and i dont see any mechanism for passing on bug reports - but it was a very quick look. I havent seen a bug report from anaconda, but looking at the install logs there is material that privacy minded individuals might object to including in there. Until there's some evidence that the bug report is actually sent off the system I continue to think this is over egged. Even if it is transferred to dom0 (IF), it doesnt pose a huge security risk. IF it were copied to unencrypted /boot that would be an issue. But just preparing a report that includes a password doesnt seem in itself to be a major issue. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171129155956.3xl6w5daevtuwovb%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
On Wednesday, 29 November 2017 02:40:01 CET Genevieve Gauthier wrote: > What do you need me to do ? Please expain in a little more detail what versions of the software you were using, what steps we might follow to reproduce the problem. For instance which screen was the last thing that was on before this error popped up. Cheers! -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5092306.yHsbj7elGM%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
On Wednesday, 29 November 2017 08:51:33 CET '[799]' via qubes-users wrote: > As far as I have understand, the problem is not that the password is > shown, but that the report with this error mistake and the password could > get transferred. I don't want that my password gets transferred in some > part of an error report. Thats not what the guy wrote. He said that it was showing on screen in an error dialog. The problem seems to be that the password is requested from the user and then kept in memory to be passed to specific tools that do the work while the installation is ongoing. Then if the installation goes wrong it prints the log of what has happened so far, and that contains the password. I have seen no indication that the password is kept after the installation has completed and operations are given over to Qubes-OS. I agree its rather sloppy, but as far as I know the installer has no option of reporting issues. I don’t even think you connect to the network at all (did you type your wifi password, I never did). So, lets allow the devs to fix this without making this into a bigger thing than it is. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2706301.yDkeRr7QO1%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
Hello Unman, >> It's perfectly possible that the installer (not principally written by >> Qubes) could mistakenly include a passphrase string. As far as I have understand, the problem is not that the password is shown, but that the report with this error mistake and the password could get transferred. I don't want that my password gets transferred in some part of an error report. >> I've seen similar stuff included in all sorts of error reports in the past. This might be true, but this doesn't make this less harmless, if the password is really bundled in an error report that gets transferered somewhere. >> It doesn't mean that Qubes "can't be trusted" Wait, it's not (!) about blaming the Qubes team. If my understanding is correct, and the password is included in an error report that gets transferred to a 3rd party, this is a really bad thing as something like this should not happen from my understanding. [799] >> Also, since this is an installation error, let's not over egg the problem -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2vKwbiORCF0Y-jH7FmGByGR2KjUE_uWWB7aM37w1BGKIBhobDyrJ99ult90ahUXjt0CrPMr0WDuOBIHTPwB7XlTjkwSqE5RmPisTB3A5Ycw%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
I do not know how to help you. I have taken a picture without removing the
geotag (authentic picture /w geotag in my own living room. the picture
(one of many) is in my iphone but my own finger is hiding MY OWN
PASSPHRASE... I could see it 20/20.. I still have everything I used (my
own laptop), my 8gb usbstick (installer) & a 32gb usbstick. I have removed
the tag with exiftool -gps:all -xmp:all crazy.JPG ... as I intended to
provide proof without everyone seeing where I am living .. but it shows my
finger on my passphrase... :(
1)Now my laptop (the one I have used to copy from one usb with installer to
the other) is still there "intact" ..
2) The usb installer I used I have reformated it to reinstall (because of
this bug) .. but it tested fine. (so any media that tested fine should be
ok)
3) The usbstick that I intended to install it on (the 32gb) is still there
...
What do you need me to do ? I do not expect my authentic/original (with my
finger) in front of my password would convince you ...
Should I need to focus on recreating the same condition that produce the
bug (my own) in the first place and take an original picture without my
finger to hide this problem (using another password like what?
Than I am sure with all you superior computer skills you could authenticate
my picture as unaltered ... However, are you able to create ANY
installation ERROR ?? This would validate with your OWN EYES what I have
seen! (100% to authenticate for you)
2nd option : I believe someone with any strong programming skills should
look carefully at the part in Qubes 4.0 rc3 where ANY ERROR in the
installation of Qubes 4.0 rc3 and the lines that created this splash screen
('report bug'). This would in my opinion be a far more SUPERIOR way to
confirm what I have seen ... (unless you are able to create your own
installation error and see it 1ST OPTION)
I could be lying as anyone could be lying. The only way for you to know for
sure is to investigate this! I cannot do this myself because I have stopped
programming a couple of years ago and my skills are too "limited" to review
the code...
3rd option : (try recreating my bug on your/any system to see it for
yourself)
As far as my intuition goes.. the bug happened several times (still the
same report to Qubes where I could see my drive PASSWORD ) .. my 8gb tested
100%
my system is a dell laptop (but that should not have created the problem)
I try to install from my 8gb 100%tested media to my 32gb usbstick (sandisk
32gb). My 32gb sandisk was full. I have numerous pictures because I
intended to create a step by step guide to help my friend install Qubes.
3rd option (my technical date) I can see on another picture Local Standard
Data : 28.64gb SanDisk Ultra Fit sdb / 0 B free
I have another picture with the content of this usb stick (partition) :
Unknown Iso9660 sdb
I tried to automatically configure partitioning.
I do not have a picture of this but I remember there was a problem. So, I
switched to "I will configure partitioning" (this is where I have a picture
of this Iso9660 which I do not even know what it is .. :(
Then I remember and have a picture of trying to press the "-" button after
clicking on this strange partition on my Sandisk 32gb usbstick
I know I had problem because I have a picture of showing "Click here to
create them automatically" but it never worked
then this splash screen appeared to report this unknown error. ( I have a
picture but my finger is hiding the proof itself!)
I do not know a lot about computer but I have a 20/20 vision. I tried to
read everything so I could understand howto fix it ... then I saw my own
PASSWORD after the autopart --encrypted --passphrase (as described)
You would need to provide me guidance .. however, this is the best I can
do. Are you able to create a "full usbstick" like mine with this type of
partition (Iso9660) ?? Perhaps if you try to do as I did, you will have the
same result and this would be 100% proof.
Sorry, my computer skills themselves are too low to be able to know where
in the code is hidden the report bug of the install in the code itself..
However, with the information I have provided .. I can tell you that I do
not have the skills to even know how the programmers themselves programmed
this report !
If you provide me with simple step and simple questions to try to recreate
what I did, I will answer them as well as I can but there is no way to
check the code for myself because even if I were to see it I would not know
what I would be looking at .. Sorry :(
I hope this is enough so you can try to "FORCE" a error and see this
MEGA-HUGE flaw with your own eyes. This way, you would believe it without
having to rely on "untrusted" data on a qubes-users google group.
Have a nice day. I need to get some sleep but I try to answer you if you
have any question (please explain everything if you need something too
technical from me to make your own experiment!)
p-s my sata was disabled on my
Re: [qubes-users] Qubes 4.0 RC3 (installation) MEGA-HUGE security flaw! (report the bug below or quit the program)
On Tue, Nov 28, 2017 at 07:48:49PM -0500, '[799]' via qubes-users wrote: > Hello, > > Original-Nachricht > An 29. Nov. 2017, 00:48, schrieb: > Sorry but I almost fainted ! (I even took a picture ! I could not believe > this MEGA-HUGE security flaw right in front of my eyes ) > (...) > Sorry, you are supposed to be good and security expert but you are asking me > (THE dumb USER) to report MY OWN PASSPHRASE AS A STRING to help you?? > (...) > -- > > Honestly I can't believe that this is true, until you prove this, which might > be hard, as even a picture can be simple "ASCII Art". > > If you are correct, this would of course mean that Qubes OS can't be trusted. > There should never be the option that a passphrase will be shown unencrypted. > > Even worse including this passphrase in an error report which gets saved or > transferred to a 3rd party (even if it the Qubes Team) is an absolute no-go. > > As mentioned, I don't believe this. > > Can you provide more guidance what you have done and what hardware you are > using, so that someone can verify this problem, if it is reproducable? > > Please also include all hardware specs, so that can also take this in account. > > If you are right and if Qubes is Open Source the source code should be > analyzed to find this "hidden feature". > > But as mentioned, I think this is BS. > > [799] I don't see any grounds for this response. It's perfectly possible that the installer (not principally written by Qubes) could mistakenly include a passphrase string. I've seen similar stuff included in all sorts of error reports in the past. It doesn't mean that Qubes "can't be trusted" Also, since this is an installation error, let's not over egg the problem - it's not as if you're using that password anywhere else, or that you will use the same password the next time you try to install, is it? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171129011055.hbv4csobzomxbdxb%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
