Re: [qubes-users] Qubes 4.0-rc3

2020-04-16 Thread Manuel Amador (Rudd-O)
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

2020-04-16 Thread Manuel Amador (Rudd-O)
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

2018-01-27 Thread joeh9617
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

2018-01-27 Thread 'awokd' via qubes-users
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

2018-01-27 Thread Yuraeitha
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

2018-01-27 Thread 'awokd' via qubes-users
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

2018-01-12 Thread Andrew David Wong
-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

2018-01-12 Thread Andrew David Wong
-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

2018-01-12 Thread 'awokd' via qubes-users
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

2018-01-12 Thread 'awokd' via qubes-users
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

2018-01-12 Thread 'Tom Zander' via qubes-users
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

2018-01-12 Thread Holger Levsen
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?


-- 
cheers,
Holger

-- 
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/20180112130935.vubd6qu7kcfqzepe%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature


Re: [qubes-users] Qubes 4.0-rc3

2018-01-12 Thread 'Tom Zander' via qubes-users
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

2018-01-12 Thread 'awokd' via qubes-users
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

2018-01-11 Thread Chris Laprise
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

2018-01-11 Thread Andrew David Wong
-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

2018-01-11 Thread Andrew David Wong
-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

2018-01-11 Thread 'Tom Zander' via qubes-users
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

2018-01-11 Thread Chris Laprise
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

2018-01-11 Thread Chris Laprise
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

2018-01-11 Thread Unman
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

2018-01-11 Thread 'Tom Zander' via qubes-users
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

2018-01-10 Thread Andrew David Wong
-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

2018-01-10 Thread Connor Page
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

2018-01-10 Thread Chris Laprise

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

2018-01-07 Thread Marek Marczykowski-Górecki
-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

2018-01-07 Thread Yuraeitha
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

2018-01-07 Thread Yuraeitha
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

2018-01-07 Thread Fabrizio Romano Genovese
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

2018-01-06 Thread 'awokd' via qubes-users
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

2018-01-05 Thread Fabrizio Romano Genovese
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

2018-01-05 Thread 'awokd' via qubes-users
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

2018-01-04 Thread 'Tom Zander' via qubes-users
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)

2017-12-02 Thread Andrew David Wong
-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)

2017-11-29 Thread genevieve . c . gauthier
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)

2017-11-29 Thread Unman
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)

2017-11-29 Thread 'Tom Zander' via qubes-users
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)

2017-11-29 Thread 'Tom Zander' via qubes-users
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)

2017-11-28 Thread '[799]' via qubes-users
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)

2017-11-28 Thread Genevieve Gauthier
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)

2017-11-28 Thread Unman
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.