[qubes-users] How to fix an empty dom0 application menu

2018-03-07 Thread hyperfekt
While trying to reinstall some templates my dom0's application menu just broke, 
with every .desktop file gone.
I wanted to document how to fix this for others - use this command:

sudo qubes-dom0-update --action=reinstall $(rpm -qa | grep 'qubes\|xfce4' | 
grep -v 'template\|kernel')

What it does is the following:
Get a list of installed packages,
filter for those of Qubes or xfce,
filter out any templates or the kernel,
and then reinstall them.

This should restore all the desktop files and with that your application menu.

-- 
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/717d4cf0-d053-4f04-b186-9f432823e226%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-07 Thread sevas
Whoo hoo! 

I went to download qvm-dom0-update and it says no new updates available

-- 
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/f6a9802f-d5d6-4466-a58a-2866f8f57831%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: High spec laptop for Qubes OS

2018-03-07 Thread alexclaytor
I use an Acer Aspire E5-575G-76YK and went to 32GB of the highest speed and 
lowest latency RAM that was compatible. I also went to a Samsung 1TB 850 Pro 
SSD. 

This Acer is well known for being a workhorse but most of all, one of the most 
Linux compatible notebooks out there. I love it. Plan on buying a 2nd as a 
spare. 

-- 
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/e1eb05fe-56e5-47cd-9125-78094a417ef8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: off topic - invite codes to 'riseup'

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 8:11:25 PM UTC+1, Tim W wrote:
> I am sorry what is reason so many people want to get and use a riseup.net 
> account outside political or some other social reason
> 
> They had their canary down for over a year because of gag order from the feds.
> 
> They have totally rewritten there canary statement since which was prior very 
> clear and concise.  Now it looks to be heavily lawyered careful play on 
> words...thus its vague using words that can having wide varying meaning.  
> what is omitted is any speech with the words warrant, gag order, NSL.  If 
> they get any of those it will NOT of itself require them activating the 
> canary protocol.
> 
> Here is their old Canary statement followed by the new one:
> 
> OLD:
> riseup has not received any National Security Letters or FISA court orders, 
> and we have not been subject to any gag order by a FISA court, or any other 
> similar court of any government. Riseup has never placed any backdoors in our 
> hardware or software and has not received any requests to do so. Riseup has 
> never disclosed any user communications to any third party.
> 
> 
> NEW:
> Riseup positively confirms that the integrity of our system is sound. all our 
> infrastructure is in our control, we have not been compromised or suffered a 
> data breach, we have not disclosed any private encryption keys, and we have 
> not been forced to modify our system to allow access or information leakage 
> to a third party.
> 
> 
> Unfortunately we cannot use common sense to read these but they must be read 
> thru the eye of a laywer  I think you really see the effects of the rewritten 
> statement. 
> 
> From what I can tell the system is closed source.  They no longer offer any 
> form of encryption.  I must all be done on your email client.  There is no 
> two factor authentication.  The user name and password to get your into your 
> mailbox from what I can see maybe moot as there is no info on any use of 
> encryption outside users manually or thru a client using gpg.  If that is 
> correct then any mail not gpg encrypted is sitting in the mailbox in 
> cleartext.  Unless there is something like AES 256 protecting the mailbox via 
> your password but then that means thru the recovery passcode system they very 
> well can get back into your mailbox even with lost credentials and no reset 
> alternate email address.
> 
> For a person that plans to gpg encrypt all their emails what does this offer 
> anyone over the other free email accounts.  Sure your contacts are not mined 
> to hell and back but in terms of email content I see no difference and 
> actually lower login security.
> 
> I was looking at the thread and it looks like around 40 people requested 
> referral codes on this thread while the canary was expired.  One person even 
> mentioned it and it went uncommented on.
> 
> Compare this to say protonmail its not even remotely close.  As both can be 
> had for free and without all the need for referrals as its targeted toward 
> liberal/social/anticapital political change groups not sure the point?  
> Elitism?
> 
> I honestly was surprised so many people on this list asking for it and where 
> unphase by the fact the canary was expired and it was known they were under a 
> gag order.  We make a big deal about a close source binary blob for a driver 
> or firmware to a nic or gpu yet a closed source email provider system with a 
> triggered canary and no one misses a beat?  I know the thread was off topic 
> and has been running for years and why I never even read it till now for no 
> other reason than I was wasting time but wow I am surprised.

Had to scratch my head, I didn't even know about them.

But after a quick look, aren't they doing the same as the Libre laptop 
developers (Purism) are doing? Overselling and thereby preying on people's 
feelings to get more security, without actually delivering what they are 
promising? It seems a bit similar in that sense. 

Also using anything U.S. based is a huge No Thanks! We don't even need 
Trump to screw up so badly that he can barely find any more lies to cover it 
up, and as a result make a trade war with the EU (like what happened today). In 
general security business with anything U.S. is a big fat no.

The website also looks like a mix of something meant for 3rd graders and 
something out of the last late century. It isn't very clear what is what when 
you land on the frot page, you have to stare a while to find out rather than 
immediately know what is what that all good websites manage to do. Their 
website is definitely a fail.

e-mail? The technology in and on itself is fail. It's only because people don't 
want to use something else, and there are few e-mail standards to govern the 
security and privacy among the many 100 of thousands of e-mail providers whom 
are still around in 2018. Using riseup wont solve the innate design failure of 
multiple decade old e-mail technology born 

[qubes-users] Re: I broke Qubes with template reinstall...

2018-03-07 Thread hyperfekt
I just had the same problem, and wrote down the fix before I saw your post here.
Take a look: https://groups.google.com/forum/#!topic/qubes-users/iHcWKwGQd-o

On Tuesday, March 6, 2018 at 5:29:30 AM UTC+1, sevas wrote:
> dom0$ sudo qubes-dom0-update --action=reinstall qubes-template-debian-9
> 
> Now my dom0 menu is gone. No more terminal. No more Qubes Manager. No more... 
> anything... 
> 
> 
> I gave up immediately and thought I would reinstall Qubes. 
> 
> Well, that was a fail too. Qubes installer freezes when I click Continue on 
> the first page. 
> 
> Any suggestions??

-- 
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/9f1e92c7-f7d1-4bfd-9c72-183164b6cb38%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: off topic - invite codes to 'riseup'

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 8:11:25 PM UTC+1, Tim W wrote:
> I am sorry what is reason so many people want to get and use a riseup.net 
> account outside political or some other social reason
> 
> They had their canary down for over a year because of gag order from the feds.
> 
> They have totally rewritten there canary statement since which was prior very 
> clear and concise.  Now it looks to be heavily lawyered careful play on 
> words...thus its vague using words that can having wide varying meaning.  
> what is omitted is any speech with the words warrant, gag order, NSL.  If 
> they get any of those it will NOT of itself require them activating the 
> canary protocol.
> 
> Here is their old Canary statement followed by the new one:
> 
> OLD:
> riseup has not received any National Security Letters or FISA court orders, 
> and we have not been subject to any gag order by a FISA court, or any other 
> similar court of any government. Riseup has never placed any backdoors in our 
> hardware or software and has not received any requests to do so. Riseup has 
> never disclosed any user communications to any third party.
> 
> 
> NEW:
> Riseup positively confirms that the integrity of our system is sound. all our 
> infrastructure is in our control, we have not been compromised or suffered a 
> data breach, we have not disclosed any private encryption keys, and we have 
> not been forced to modify our system to allow access or information leakage 
> to a third party.
> 
> 
> Unfortunately we cannot use common sense to read these but they must be read 
> thru the eye of a laywer  I think you really see the effects of the rewritten 
> statement. 
> 
> From what I can tell the system is closed source.  They no longer offer any 
> form of encryption.  I must all be done on your email client.  There is no 
> two factor authentication.  The user name and password to get your into your 
> mailbox from what I can see maybe moot as there is no info on any use of 
> encryption outside users manually or thru a client using gpg.  If that is 
> correct then any mail not gpg encrypted is sitting in the mailbox in 
> cleartext.  Unless there is something like AES 256 protecting the mailbox via 
> your password but then that means thru the recovery passcode system they very 
> well can get back into your mailbox even with lost credentials and no reset 
> alternate email address.
> 
> For a person that plans to gpg encrypt all their emails what does this offer 
> anyone over the other free email accounts.  Sure your contacts are not mined 
> to hell and back but in terms of email content I see no difference and 
> actually lower login security.
> 
> I was looking at the thread and it looks like around 40 people requested 
> referral codes on this thread while the canary was expired.  One person even 
> mentioned it and it went uncommented on.
> 
> Compare this to say protonmail its not even remotely close.  As both can be 
> had for free and without all the need for referrals as its targeted toward 
> liberal/social/anticapital political change groups not sure the point?  
> Elitism?
> 
> I honestly was surprised so many people on this list asking for it and where 
> unphase by the fact the canary was expired and it was known they were under a 
> gag order.  We make a big deal about a close source binary blob for a driver 
> or firmware to a nic or gpu yet a closed source email provider system with a 
> triggered canary and no one misses a beat?  I know the thread was off topic 
> and has been running for years and why I never even read it till now for no 
> other reason than I was wasting time but wow I am surprised.

excuse my tired quick math on the decades, 7 to 8 should be 5 to 6. I was 
thinking back to the 40s lmao

-- 
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/b5caf3bc-1d67-4f16-9388-9eb160c10a06%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to fix an empty dom0 application menu

2018-03-07 Thread Unman
On Wed, Mar 07, 2018 at 08:19:09PM -, 'awokd' via qubes-users wrote:
> On Wed, March 7, 2018 6:59 pm, hyperfekt wrote:
> > While trying to reinstall some templates my dom0's application menu just
> > broke, with every .desktop file gone. I wanted to document how to fix this
> > for others - use this command:
> >
> > sudo qubes-dom0-update --action=reinstall $(rpm -qa | grep 'qubes\|xfce4'
> > | grep -v 'template\|kernel')
> >
> >
> > What it does is the following:
> > Get a list of installed packages,
> > filter for those of Qubes or xfce, filter out any templates or the kernel,
> > and then reinstall them.
> >
> > This should restore all the desktop files and with that your application
> > menu.
> 
> Could you provide more details of what exactly you did when it broke? Like
> Qubes version, if you're on current or testing, what VM/template you're
> using as your UpdateVM, what template you re-installed and how, etc. Could
> be something worth filing as an issue, especially if multiple people are
> hitting it.
> 

This problem (and it's solution) crops up many times on the list. So
there's an argument that it should reach the FAQ.
But it also shows a problem - that people dont search (and research)
problems before posting. (I exclude OP from this because s/he found a
solution for themselves.) Many times you'll see problems raised that are
covered on the list or in the docs, or could be solved with a minor
search.
The list could be treated as a cumulative source of knowledge - the
proposed userspace on github could incorporate such things. I'm just
worried that it will be yet another place that people dont look.

-- 
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/20180307203615.nxworfzhqth5hpeb%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Install Android-x86 on HVM

2018-03-07 Thread Yuraeitha
On Tuesday, March 6, 2018 at 7:38:56 AM UTC+1, msg...@gmail.com wrote:
> On Tuesday, March 6, 2018 at 12:40:13 PM UTC+7, Tim W wrote:
> > On Thursday, March 1, 2018 at 11:17:25 AM UTC-5, msg...@gmail.com wrote:
> > > On Thursday, March 1, 2018 at 7:50:44 PM UTC+7, Yuraeitha wrote:
> > > > On Thursday, March 1, 2018 at 11:11:44 AM UTC+1, msg...@gmail.com wrote:
> > > > > Hello,
> > > > > 
> > > > > I want to install Android-x86 on Qubes OS 4.0rc4 StandaloneVM (HVM), 
> > > > > but the Android installer can't recognize the VM drives.
> > > > > I can run the Android Live from the iso and it works.
> > > > > I've tried to install Android-x86 7.1-rc1/6.0-rc3/4.4-rc5 but they 
> > > > > can't recognize the VM drives.
> > > > > Based on some messages from mailing list/github issues, it was 
> > > > > possible to install Android-x86 on HVM in Qubes OS 3.2 (or pre 
> > > > > 4.0rc4?) but I can't do it in Qubes 4.0rc4.
> > > > > Maybe someone have some clues on how to make the Android-x86 
> > > > > installer recognize VM drives?
> > > > 
> > > > Could it be because of the kernel is loaded in a similar way to how it 
> > > > for example prevents Windows to install? I'd guess any standalone 
> > > > shares this issue in Qubes 4 and not just Windows. Linux or not, if it 
> > > > tries to use its own kernel rather than the one provided by dom0, then 
> > > > it would probably not work. 
> > > > 
> > > > This should disable the VM's kernel, though I never used it my self, 
> > > > try adjust if the citation marks are different.
> > > > qvm-prefs android-vm-name kernel ''
> > > > 
> > > > I can confirm from personal experience that Android remix was possible 
> > > > to be installed during Qubes 3.2., though I didn't try on Qubes 4 yet. 
> > > > Generally it should work though, you probably just need to bypass some 
> > > > issues, like the kernel issue above, and perhaps you need to adjust the 
> > > > virt_mode too qvm-prefs android-vm-name virt_mode. Try change it to HVM 
> > > > if it isn't already. I'm not sure if the GUI VM Settings has been fixed 
> > > > for the Virt_mode, otherwise just use the dom0 terminal with above 
> > > > command to change it.
> > > 
> > > I've already set the kernel to '', virt_mode to HVM, disabled memory 
> > > balancing and set memory to 4GB, it didn't help.
> > > I've installed Windows 7/10 without any problems on this same Qubes OS 
> > > 4.0rc4 but I can't install Android-x86 with the same config.
> > 
> > I do not think the mouse  behavior issue has ever been able to be 
> > addressed.  It is mentioned in most of the android attempt threads.  There 
> > have been numerous requests for actual android auppprt but without fully 
> > functional mouse behavior it prevents proper use function.  As far as I 
> > know it has been an issue in ever successful install of android on qubes 
> > but I could be wrong.
> 
> Yes, I know about this issue, but with the changed vm mouse config from 
>  to type='mouse' I can more or less work in 
> the Android even with the mouse acceleration problem.
> The main reason why I wanted to install Android in Qubes is to use telegram 
> with secret chat so I don't really need the mouse that much.
> Right now I can't install Android-x86/CM-x86 because android installer can't 
> detect the xen drive.
> Also the network is not working in Android-x86 Live (tried Android-x86 
> 7/6/4.4 and CM-x86 14.1).

I did a bit of searching on Qubes 4 changes from Qubes 3.2., based on the drive 
issue you mention, I found this 
"Flexible VM volume manager (easy to keep VMs on external drives, or in 
memory-only)" source: 
https://blog.invisiblethings.org/2017/07/31/qubes-40-rc1.html

It's a speculative possible culprit since it involves changes to the virtual 
drives are handled in VM's. Maybe it can bring forth ideas as to why it won't 
work. Unfortunately I don't have the insight or skills to look at the details 
here, but it may be a clue nonetheless.


Do you still have a Qubes 3.2. available, i.e. another computer? You could try 
install Android on Qubes 3.2., then back it up with qvm-backup, and restore it 
on Qubes 4. In the beginning of early Qubes 4 I solved Win7 that way, worked 
decently with some slight QWT issues, it might work for Android too especially 
considering it has no Qubes tools anyhow.

-- 
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/b7215135-d849-4ade-8f17-58069eab415c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: How to fix an empty dom0 application menu

2018-03-07 Thread sevas
Thanks! Im making a note! 

+1

-- 
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/530860bb-0b5f-4e92-8a66-38042912e2fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread Yuraeitha
On Tuesday, March 6, 2018 at 7:42:40 PM UTC+1, sevas wrote:
> I wasnt going to say anything... lol. But I was leaning towards debian. But 
> fedora. Thats Red Hat. They are the leading administrative suite as far as I 
> know. Or were. They must have good security or whos going to throw up a 
> server?
> 
> >In particular, Fedora's downfall is that its one of the very few distros
> >that don't sign/secure their overall software manifest; a MITM attacker
> >can prevent you from receiving specific bug fixes without you realizing
> 
> The above statement reminded me that it says that in the docs. And that does 
> seem like a make or break statement for template choices. Key signing is a 
> fine implementation on qubes. 
> 
> ha, I did read that one too about the ugly kde. 
> 
> @Yuraeitha
>  I havent quite tackled the security through compartmentalization part yet. I 
> have put some thought into it though, and after dividing my attack surface 
> between functions (keyring, passwords, misc files, etc) I realized that each 
> function has only one app to go with it. So I may as well just have one app 
> running in each VM. Or in the case of splitVMs, multiple apps for each 
> program!
> 
> I would love to hear how you divide your VMs up. I was looking for examples 
> online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
> But starting easy and growing is good advice. 
> 
> >In particular, Fedora's downfall is that its one of the very few distros
> >that don't sign/secure their overall software manifest; a MITM attacker
> >can prevent you from receiving specific bug fixes without you realizing
> 
> The above statement reminded me that it says that in the docs. And that does 
> seem like a make or break statement for template choices. Key signing is a 
> fine implementation on qubes. 
> 
> @Tim W
> >Correct.  I have had both on and functioned fine.
> Thats good to know. I know I read somewhere that it was buggy with 3.2, I 
> think?
> 
> As far a attack surface goes, I like using konsole better than xterm or 
> uxterm and when installing that on debian or fedora, it required many 
> dependencies. I removed it, but Im going to take a second look.

> I would love to hear how you divide your VMs up. I was looking for examples 
> online, but I couldnt find any; aside from an (ITL?) essay I read last year. 
> But starting easy and growing is good advice. 

Sure :)

Before that I should probably mention how I initiate them too. From the 
beginning of using Qubes, I transitioned from the default Qubes XFCE4 menu to 
the Whisker menu, and then finally from the Whisker menu to a handful of 
Launcher plugins. I still use the Whisker menu, but only lightly for things I 
didn't put in the launchers. Both the XFCE4 launcher and the XFCE4 whisker menu 
plugins are included in Qubes 4 RC-2 and RC-3. I'm not sure about RC-4 and 
RC-5, but it's probably there too. Qubes 3.2. doesn't include Whisker menu, but 
it includes the Launcher. Also both Whisker menu and Launcher allows you to 
change icons, name and even the path to files. This gives you a LOT of 
flexibility. You can also easily add scripts to launchers or the whisker menu, 
but it's even more easy with the launcher because it essentially creates copies 
rather than linking to the original shortcuts. So if you for example take a 
random shortcut in launcher, and you edit it by changing the icon, name or the 
path, then it will not change the original shortcut. This is one of the reasons 
I like launcher's so much, though, not the only reason. It can also be done in 
a way that it looks very stylish if you're creative with it, and it's also much 
quicker to access your various of apps. Furthermore it's easier to keep track 
of all the Apps you use this way. Some of these might be subjective taste, 
others may apply to everyone. But give launchers or even whisker menu a try and 
see if it fits you after you modified them to fit your needs.

I put some 6 to 7 launchers next to each others at the upper left corner. There 
are different ways to do this with Qubes in mind, for example two clean methods 
are to either put a single AppVM or similar AppVM's in a single launcher and 
then have multiple of launchers for different AppVM's, or instead put all 
browsers in a single launcher, all file-managers in another, all system tools 
and various VM terminals in another, music players and things like these in a 
mix launcher, work tools like libreoffice and similar in yet another one. To 
add a finish to it, I changed the color to dark, and found some cool looking 
stylish icons free to download and use, i.e. from devianart. Only get the png 
or jpg formats, preferably png though. Moved them to an offline AppVM, and then 
selected some 15 at a time, and right clicked and used the convert to trusted 
img. Which is like using the qvm-convert-img command. This way you can remove 
exploits that might be hiding in pictures, and since it's an offline VM without 

[qubes-users] Re: I broke Qubes with template reinstall...

2018-03-07 Thread hyperfekt
I just had the same problem, and wrote down the fix before I saw your post here.
Take a look: https://groups.google.com/forum/#!topic/qubes-users/iHcWKwGQd-o

-- 
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/0a2d0a51-4757-46fe-a5b6-9a727c7a8da0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: I broke Qubes with template reinstall...

2018-03-07 Thread hyperfekt
On Tuesday, March 6, 2018 at 5:29:30 AM UTC+1, sevas wrote:
> dom0$ sudo qubes-dom0-update --action=reinstall qubes-template-debian-9
> 
> Now my dom0 menu is gone. No more terminal. No more Qubes Manager. No more... 
> anything... 
> 
> 
> I gave up immediately and thought I would reinstall Qubes. 
> 
> Well, that was a fail too. Qubes installer freezes when I click Continue on 
> the first page. 
> 
> Any suggestions??

I just had the same problem, and wrote down the fix before I saw your post here.
Take a look: https://groups.google.com/forum/#!topic/qubes-users/iHcWKwGQd-o

-- 
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/aadc45f3-38cf-4b17-aec3-03f1d3d58b2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Installing qubes on Razer stealth 2017 edition

2018-03-07 Thread randallrbaker
Hi all  I'm trying to install qubes on an external hard drive to test and get 
it working before I put it on my main machine, but it won't seem to get past 
this screen. Can someone help me out as I'm new to cubes and won't understand 
everything. This is the message that popups.


Xen 4.6.1 (c/s) EFI loader
Using configuration  file 'xen.cfg'
Vmlinuz: 0x0ppp70781000-0x70780660 initrd.img: 
0x0p006f1f4000-0x70780660 -

Thanks- randall


-- 
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/b982793b-9b7b-4ca4-97a5-c18cdf10c054%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Recommended laptop

2018-03-07 Thread '我' via qubes-users
I decided to buy Lenovo G505s.
Thank you very much.

The hardware selection tree has become a big help I've decided.

-- 
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/7ROFAgePwqfCsWnQm7uD2zNNDQFFpXCPQ4fcJP-0wk22iFUfs_K19DEGI3nuk_eBAJ4tiH36KgNTR3WxaaPgbUYDlyGGyTri1dy6515oEME%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 9:05:51 PM UTC+1, sevas wrote:
> Cool. That gave me some ideas. Thanks for sharing your setup. 
> 
> So, another infosec question Im trying to figure out...
> 
> Templates Vs AppVMs. 
> 
> I find myself with, currently, 8 templates and growing. 
> This is because I am installing different programs in different VMs
> and Im not wanting to install all my programs into a single VM. 
> 
> Of course, one solution is to install all my programs into a single 
> templateVM and only enable the programs I need in the AppVM. 
> 
> But it seems more secure to me if I keep different templates for 
> different needs and then create a AppVM to run them in. Is this 
> good or am I wasting my time and hard drive space?
> 
> For instance I have a template specifically for one set of 
> sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
> And another the vault and more to come.

I also made a launcher for all my Qubes scripts that I didn't keybind. They are 
definitely valuable for purposes like that as well :) You can also make scripts 
that sends commands into an AppVM from dom0, so essentially, you can securely 
control it from a secure domain, but also at the same time link keybinds in 
AppVM's to your keyboard or XFCE4 shortcuts. Scripting in Qubes is awesome. But 
be mindful of running dangerous or unknown scripts, they can do a lot of harm, 
in particular in dom0.

I suspect at some point we might be able to move scripts out of dom0 though, 
actually, it might even be possible now with USB keyboards? I'm not sure, I 
have to check that one day, it would definitely make scripts that control 
AppVM's more secure. But the issue here is probably the few scripts that 
control actions within dom0 though. For example changing screen resolution and 
move the screen to left or right, i.e. when plugging in an extra HDMI TV 
monitor or projector. This too might change in Qubes 4.1. as well when how 
graphics works in Qubes is changed. Well, there is definitely a lot of things 
to think about and reflect on, but that too in and on itself can be fun if you 
enjoy solving small puzzles like these.

-- 
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/9c1dd311-42a6-4f62-a631-9dd78bb1f1cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Recommended laptop

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 1:31:11 PM UTC+1, awokd wrote:
> On Wed, March 7, 2018 7:46 am, awokd wrote:
> 
> > There's https://www.qubes-os.org/doc/#choosing-your-hardware in the docs
> > and FAQ links to same but maybe some type of decision tree?
> 
> Here's my first attempt at one. Links don't work in its current location,
> but it should be easy to follow. I'm not entirely sure this belongs on
> Qubes' site so I threw in a disclaimer.
> 
> https://github.com/awokd/qubes-doc/blob/hardwaretree/hardware/hardware-tree.md

That is pretty awesome project awokd! It'd be amazing if you can finish and 
polish it, it's definitely very useful work.

-- 
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/a54f5695-49eb-4543-97c0-f3b20c929e57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread [799]
On 03/07 06:48, Yuraeitha wrote:

> It seems like a good way to do it, I like it. What does others think about 
> it? 

agreed. 

> Does anyone disagree with the idea of making an initial first step with a 
> second repository with an associated 
> Community doc page, as discussed? We can always look at forums and other 
> platforms later on, it's probably best not 
> to do everything at once, especially now when the Qubes staff is busy, it 
> might be best to start where the least 
> work is needed from the Qubes staff. A second repository and assigning 
> volunteer moderator(s) should be straight 
> forward less than 5 minutes task [...]

as you mentioned let's do it this way and if we find out this was a bad idea, 
we can fix it later on.
the alternative could also be just start a new repository on our own accounts.
Honestly I think that only a few users will contribute, but that's fine.

[799]

-- 
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/20180307185609.h2s4abfp3a3fp4gk%40my-privmail.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: off topic - invite codes to 'riseup'

2018-03-07 Thread Tim W
I am sorry what is reason so many people want to get and use a riseup.net 
account outside political or some other social reason

They had their canary down for over a year because of gag order from the feds.

They have totally rewritten there canary statement since which was prior very 
clear and concise.  Now it looks to be heavily lawyered careful play on 
words...thus its vague using words that can having wide varying meaning.  what 
is omitted is any speech with the words warrant, gag order, NSL.  If they get 
any of those it will NOT of itself require them activating the canary protocol.

Here is their old Canary statement followed by the new one:

OLD:
riseup has not received any National Security Letters or FISA court orders, and 
we have not been subject to any gag order by a FISA court, or any other similar 
court of any government. Riseup has never placed any backdoors in our hardware 
or software and has not received any requests to do so. Riseup has never 
disclosed any user communications to any third party.


NEW:
Riseup positively confirms that the integrity of our system is sound. all our 
infrastructure is in our control, we have not been compromised or suffered a 
data breach, we have not disclosed any private encryption keys, and we have not 
been forced to modify our system to allow access or information leakage to a 
third party.


Unfortunately we cannot use common sense to read these but they must be read 
thru the eye of a laywer  I think you really see the effects of the rewritten 
statement. 

>From what I can tell the system is closed source.  They no longer offer any 
>form of encryption.  I must all be done on your email client.  There is no two 
>factor authentication.  The user name and password to get your into your 
>mailbox from what I can see maybe moot as there is no info on any use of 
>encryption outside users manually or thru a client using gpg.  If that is 
>correct then any mail not gpg encrypted is sitting in the mailbox in 
>cleartext.  Unless there is something like AES 256 protecting the mailbox via 
>your password but then that means thru the recovery passcode system they very 
>well can get back into your mailbox even with lost credentials and no reset 
>alternate email address.

For a person that plans to gpg encrypt all their emails what does this offer 
anyone over the other free email accounts.  Sure your contacts are not mined to 
hell and back but in terms of email content I see no difference and actually 
lower login security.

I was looking at the thread and it looks like around 40 people requested 
referral codes on this thread while the canary was expired.  One person even 
mentioned it and it went uncommented on.

Compare this to say protonmail its not even remotely close.  As both can be had 
for free and without all the need for referrals as its targeted toward 
liberal/social/anticapital political change groups not sure the point?  Elitism?

I honestly was surprised so many people on this list asking for it and where 
unphase by the fact the canary was expired and it was known they were under a 
gag order.  We make a big deal about a close source binary blob for a driver or 
firmware to a nic or gpu yet a closed source email provider system with a 
triggered canary and no one misses a beat?  I know the thread was off topic and 
has been running for years and why I never even read it till now for no other 
reason than I was wasting time but wow I am surprised.

-- 
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/9edf4fe4-2233-4ebd-9ea0-5b58fd728107%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to fix an empty dom0 application menu

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 6:59 pm, hyperfekt wrote:
> While trying to reinstall some templates my dom0's application menu just
> broke, with every .desktop file gone. I wanted to document how to fix this
> for others - use this command:
>
> sudo qubes-dom0-update --action=reinstall $(rpm -qa | grep 'qubes\|xfce4'
> | grep -v 'template\|kernel')
>
>
> What it does is the following:
> Get a list of installed packages,
> filter for those of Qubes or xfce, filter out any templates or the kernel,
> and then reinstall them.
>
> This should restore all the desktop files and with that your application
> menu.

Could you provide more details of what exactly you did when it broke? Like
Qubes version, if you're on current or testing, what VM/template you're
using as your UpdateVM, what template you re-installed and how, etc. Could
be something worth filing as an issue, especially if multiple people are
hitting 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/0e3fa36bea7f7b62c3a5bf5425a4e20f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Recommended laptop

2018-03-07 Thread taii...@gmx.com

On 03/07/2018 03:03 PM, '我' via qubes-users wrote:


I decided to buy Lenovo G505s.
Thank you very much.

The hardware selection tree has become a big help I've decided.

Ah you have made a good choice, I hope you have gotten the one with the 
A10 and the dedicated graphics as it is much faster.
It is the freest best relatively modern laptop out there, the novena is 
freer but it has no IOMMU.


In terms of freedom hardware with desktops/workstations/servers you have 
real options, let me know if you want to get one and I will help you :D


--
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/e37de087-767f-03ff-5c07-83e6868fad45%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: qubes-dom0-update (3.2) failing with error message

2018-03-07 Thread sevas
I think I *maybe!* had this problem and fixed it. 

Im no specialist, but try this. It wont hurt.

qubes-dom0-update --clean
qubes-dom0-update kernel-qubes-vm kernel qubes-core-dom0*

restart. 

Probably wont work, but give it a shot. 

-- 
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/32d06e65-9382-44b4-92f0-a9afe507cc05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] funny "bug"

2018-03-07 Thread haaber
on my Q4rc5 install I get the little black notification "Domain .. is
halting" when I actually start it. I guess this is just a copy-paste
thing inside a script ...  cheees, Bernhard

-- 
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/5962d20b-5ed4-9b8c-2a2c-2751bb595c23%40web.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 8:05 pm, sevas wrote:


> Of course, one solution is to install all my programs into a single
> templateVM and only enable the programs I need in the AppVM.
>
> But it seems more secure to me if I keep different templates for
> different needs and then create a AppVM to run them in. Is this good or am
> I wasting my time and hard drive space?

Excluding standalone, development, and Whonix VMs, I like a small, medium,
large approach to TemplateVMs.

Small- doesn't even need a desktop manager like GNOME; xterm only;
required utilities only for sys-* VMs

Medium- the standard fedora-26 or debian-9 template with a handful of
small utilities for password mgmt. etc., for most non-sys-* AppVMs

Large- Medium plus Java, Libreoffice, photo editing etc. AppVMs based on
this never get a network connection and are used for document mgmt.


-- 
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/cfe076599089b53bcfc1ac036fdcf834.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: High spec laptop for Qubes OS

2018-03-07 Thread Yuraeitha
Well the day a proper secure, user owned laptop hardware, which is something 
not looking like it came from the last decade, has proper thunderbolt and 
similar tech only available on modern laptops (which I need, in all 
seriousness), I'll immediately buy and never look back.

Seriously all these scumbag laptop companies out there the moment a proper 
company comes out and offers proper user controlled laptops which also provides 
a variation of specs and types of laptops, it's byebye to these manipulative 
scumbag companies.

While many people don't care at all, the amount of people getting fed up with 
these companies are mounting and increasing as well. It's dangerous if they 
keep making people unhappy, and it'll only get worse as technology becomes 
increasingly closer to our brains, and at some point even integrated into our 
brain, which will undoubtedly happen, and maybe even (probably likely) become 
mainstream.

So who wants a proprietary, backdoored, error-prone, computer in their brain in 
contrast to open source, open hardware, which can be trusted? Even before all 
this, some people who didn't care before, are starting to care now when 
technology is increasingly getting closer to their lives. Like The Amazon Echo, 
which is always listening to its environment, and now it's happening to TV's 
and many other gadgets as well. Eventually even toasters can spy on us.

It'll probably only be a question of time before people smack down on large 
corporations demanding major change. The question is probably more "when" it'll 
happen. At which point is enough enough?

Seemingly it also has a cultural effect, like the Chinese people are 
essentially just rolling over allowing their iron tight government to use new 
technology to become never before seen scary Big Brother v.2. 

But the western world probably won't let it go that far. There are many 
ignorant people, but at some point, the film will have to crack. We're building 
a dys-topian society here, and more and more people are starting to realize 
just that.

Heck we might even see an Elon Musk in open hardware one day, if the problem 
keeps growing. But right now, laptop hardware choices are rather moot and quite 
frankly, impossible to find something that serves all primary needs (not even 
getting to the secondary needs).

-- 
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/f9fe0424-a01d-457d-ba91-7751f861c1ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread sevas
Cool. That gave me some ideas. Thanks for sharing your setup. 

So, another infosec question Im trying to figure out...

Templates Vs AppVMs. 

I find myself with, currently, 8 templates and growing. 
This is because I am installing different programs in different VMs
and Im not wanting to install all my programs into a single VM. 

Of course, one solution is to install all my programs into a single 
templateVM and only enable the programs I need in the AppVM. 

But it seems more secure to me if I keep different templates for 
different needs and then create a AppVM to run them in. Is this 
good or am I wasting my time and hard drive space?

For instance I have a template specifically for one set of 
sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
And another the vault and more to come. 

-- 
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/4a6275f8-6b6b-4ce4-89d6-a7a450162b98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to fix an empty dom0 application menu

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 8:36 pm, Unman wrote:
> On Wed, Mar 07, 2018 at 08:19:09PM -, 'awokd' via qubes-users wrote:
>
>> On Wed, March 7, 2018 6:59 pm, hyperfekt wrote:
>>
>>> While trying to reinstall some templates my dom0's application menu
>>> just broke, with every .desktop file gone. I wanted to document how to
>>> fix this for others - use this command:
>>>
>>> sudo qubes-dom0-update --action=reinstall $(rpm -qa | grep
>>> 'qubes\|xfce4'
>>> | grep -v 'template\|kernel')
>>>
>>>
>>>
>>> What it does is the following:
>>> Get a list of installed packages,
>>> filter for those of Qubes or xfce, filter out any templates or the
>>> kernel, and then reinstall them.
>>>
>>> This should restore all the desktop files and with that your
>>> application menu.
>>
>> Could you provide more details of what exactly you did when it broke?
>> Like
>> Qubes version, if you're on current or testing, what VM/template you're
>> using as your UpdateVM, what template you re-installed and how, etc.
>> Could
>> be something worth filing as an issue, especially if multiple people are
>>  hitting it.
>>
>
> This problem (and it's solution) crops up many times on the list. So
> there's an argument that it should reach the FAQ. But it also shows a
> problem - that people dont search (and research) problems before posting.
> (I exclude OP from this because s/he found a
> solution for themselves.) Many times you'll see problems raised that are
> covered on the list or in the docs, or could be solved with a minor
> search. The list could be treated as a cumulative source of knowledge -
> the proposed userspace on github could incorporate such things. I'm just
> worried that it will be yet another place that people dont look.

If multiple people are experiencing something unexpected like their dom0
application menu getting wiped on a template reinstall, doesn't that make
it a bug/Issue even if a work-around is available? Looks like it is
already a known issue, though:
https://github.com/QubesOS/qubes-issues/issues/3294



-- 
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/7521b238b8b09757b93ad5be4bde85a1.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: off topic - invite codes to 'riseup'

2018-03-07 Thread [799]

On Wednesday, March 7, 2018 at 8:11:25 PM UTC+1, Tim W wrote:
>
> Compare this to say protonmail its not even remotely close.  As both can be 
> had for free and without all the need for referrals as its 
> targeted toward liberal/social/anticapital political change groups not sure 
> the point?  Elitism?

The problem with Protonmail is, that there is no IMAP support and therof it 
seems impossible to store data offline.
https://protonmail.com/support/knowledge-base/imap-smtp-and-pop3-setup/

There seems to be a workarround with the Protonmail Bridge but it will only 
work for Windows & Mac.

[...] The Bridge release for Linux, which will include a command-line interface 
version, is scheduled for early 2018. [...]

Thereof the best option might be to use email-encryption.

[799]

-- 
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/20180307202046.seqidmn5ohrhmgnu%40my-privmail.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Semi-crosspost to qubes-users. Windows HVM dual-headed use on Qubes R3.2 issues/experiences

2018-03-07 Thread carolinemcgrath86
Hello!
Just posting into qubes-users to ask if anyone was able to get it to work 
properly (as two separate windows emulating two separate monitors under windows)

I was able to do that ALMOST acceptably by doing the steps described here:
https://github.com/QubesOS/qubes-issues/issues/3480

But just as the person reporting there I am being thwarted by a nasty "ghost 
mouse/click" bug.

Has anyone ever found a workaround for this issue? Is there perhaps a better 
way to do a dual-head (maybe we could get both "screen-windows" originate from 
QGA.exe?)

P.S.: I initially posted about this in qubes-devel in hopes that maybe someone 
there would know a workaround for this. Posting here in hope that maybe someone 
also tried to do a dual-head in windows under Qubes and figured out workaround 
for issue currently plaguing me.

-- 
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/9b7c25ac-f468-41f2-961a-74c7b8626aab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to fix an empty dom0 application menu

2018-03-07 Thread Unman
On Wed, Mar 07, 2018 at 08:59:32PM -, 'awokd' via qubes-users wrote:
> On Wed, March 7, 2018 8:36 pm, Unman wrote:
> > On Wed, Mar 07, 2018 at 08:19:09PM -, 'awokd' via qubes-users wrote:
> >
> >> On Wed, March 7, 2018 6:59 pm, hyperfekt wrote:
> >>
> >>> While trying to reinstall some templates my dom0's application menu
> >>> just broke, with every .desktop file gone. I wanted to document how to
> >>> fix this for others - use this command:
> >>>
> >>> sudo qubes-dom0-update --action=reinstall $(rpm -qa | grep
> >>> 'qubes\|xfce4'
> >>> | grep -v 'template\|kernel')
> >>>
> >>>
> >>>
> >>> What it does is the following:
> >>> Get a list of installed packages,
> >>> filter for those of Qubes or xfce, filter out any templates or the
> >>> kernel, and then reinstall them.
> >>>
> >>> This should restore all the desktop files and with that your
> >>> application menu.
> >>
> >> Could you provide more details of what exactly you did when it broke?
> >> Like
> >> Qubes version, if you're on current or testing, what VM/template you're
> >> using as your UpdateVM, what template you re-installed and how, etc.
> >> Could
> >> be something worth filing as an issue, especially if multiple people are
> >>  hitting it.
> >>
> >
> > This problem (and it's solution) crops up many times on the list. So
> > there's an argument that it should reach the FAQ. But it also shows a
> > problem - that people dont search (and research) problems before posting.
> > (I exclude OP from this because s/he found a
> > solution for themselves.) Many times you'll see problems raised that are
> > covered on the list or in the docs, or could be solved with a minor
> > search. The list could be treated as a cumulative source of knowledge -
> > the proposed userspace on github could incorporate such things. I'm just
> > worried that it will be yet another place that people dont look.
> 
> If multiple people are experiencing something unexpected like their dom0
> application menu getting wiped on a template reinstall, doesn't that make
> it a bug/Issue even if a work-around is available? Looks like it is
> already a known issue, though:
> https://github.com/QubesOS/qubes-issues/issues/3294
> 
It is a known issue, and one solution is linked from there, and the
source of the bug identified.
Other workrounds have been put forward on this list (many times).
Which sort of proves my point.

-- 
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/20180307215223.t35drqlgxovkrwz5%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-07 Thread Chris Laprise
Having just upgraded dom0 with qubes*testing, I noticed that nearly all 
of my running VMs are being displayed by the 'Q' widget as if they were 
in a pre-started or pre-halted state. The spinner icon is spinning 
beside each of them, and the menus are populated with *Log and Kill 
options, not shutdown.


--

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/9c9e06d3-bd03-ff42-0fb3-78a837892ab5%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 9:05:51 PM UTC+1, sevas wrote:
> Cool. That gave me some ideas. Thanks for sharing your setup. 
> 
> So, another infosec question Im trying to figure out...
> 
> Templates Vs AppVMs. 
> 
> I find myself with, currently, 8 templates and growing. 
> This is because I am installing different programs in different VMs
> and Im not wanting to install all my programs into a single VM. 
> 
> Of course, one solution is to install all my programs into a single 
> templateVM and only enable the programs I need in the AppVM. 
> 
> But it seems more secure to me if I keep different templates for 
> different needs and then create a AppVM to run them in. Is this 
> good or am I wasting my time and hard drive space?
> 
> For instance I have a template specifically for one set of 
> sys-net/sys-firewall and another template for sys-net2/sys-firewall2. 
> And another the vault and more to come.

heck even dating is becoming a new huge business these days, especially with 
all these new tools and algorithms to pair people. It makes sense to make an 
AppVM for stuff like that too, don't use your phone for it, and stay clear of 
the advanced dating sites. 

This is a good example of data mining, where people might forget their privacy. 
It's essentially a gold mine for data mining, and we're probably gonna see huge 
industries in the coming years, privacy traded for love. It's a sad 
development. Nevertheless, AppVM's serves as a good use here too to minimize 
the profiling companies whom seek to profile everyone and know everything about 
you, so that they can sell your profile for profit to anyone who wants to buy.

-- 
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/e520a080-e584-420c-85e2-4cec51e1eb2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] control boot line in installer?

2018-03-07 Thread Nathan Myers
I am trying to install on an ASUS ZenBook UV501 (Skylake, HD530, NV960M, 
NVME SSD). The installer kernel OOPSes because it loads the nouveau 
driver module, and gets confused by the bumblebee/optimus hardware 
arrangement.


I have installed Debian 9.3 on this machine, and it works if I blacklist 
the nouveau module during boot. (I.e. the i915 module needs to load 
first.)  But I don't see any way to control the boot line during 
installation.  ("E" only shows me a chainloader command line.)


Also, when choosing where to install, the installer seems to offer only 
the whole disk, but I have partitions already in place, currently 
formatted for swap and ext4, that I would like for the installer to 
overwrite.  How do I tell the Qubes installer to use those?


Might the 4.0 beta installer deal better with these details?

Thanks,

Nathan Myers

--
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/p7qkhm%24g4l%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes 4 rc3 unpacking errors durint installation

2018-03-07 Thread randallrbaker
Hey bud where you able to find a resolution? With qubes its either you know 
what your doing or good luck finding an answer let alone even a response back. 
I have the new raser 2017 and i simply want to test it on a harddrive to get it 
working properly and i have the same errors you had.

-- 
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/cf74f0f1-a04c-40ab-b5cb-73c76806b9d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2018-03-07 08:48, Yuraeitha wrote:
> It might be a good idea to have some finished thoughts /
> discussions ready for Andrew, it'd be inhuman to expect him to read
> everything (it's a lot to read).

Thanks. I appreciate that. :)

> it might be best to start where the least work is needed from the 
> Qubes staff.

Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
way it currently is and have the new system be completely autonomous
and community-run without any involvement from the Qubes staff. By way
of analogy, think of the official system as a command-line tool and
the community system as a user-friendly GUI frontend for that tool.
People who either don't know how or don't want to use the command-line
tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
(i.e., submit content, ideas, and suggestions in any format, which the
community then turns into proper PRs).

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqgnJcACgkQ203TvDlQ
MDA1XBAAs8dC9Ue4kwLToYNRWTIpY+se2pn8RCQ8gqfKNgVDPNO7Qb3z7lw8kERF
KLAktV4HL4NCz8jTJTKh0bMTB2lERytYm6uenx/fYT+fACFRAB7gg7o8D4lE+g7m
zedYznKQHg9x2Ehi+KfVDtbEHdfagDfOW5SSWixDUyK60ZYXHDivAzZkWytMc8b8
yZq3hZZsq8GcXAoMpxWOLl9sx5TiVHN+7WVphPEXYe0wCiCwPlwY3hDznzWAFWq2
2h+aYjnwRKVkvMAbcxrmfSXK0Bwr+Ccr29vBzzQ/eOgWcXwjt6oShkOoFTPLSvla
G3JAzm+15r/7KeKItQuuXVQECGJhCqaZVs6DJFsSLAxTsfg449y3i+EFZC7hkOrM
3glht/vfSOsFY0LChcTc+99sCZnwN/0Q7weXd/86+nn18Qh3Ce7I77nHA1PaXMt7
+/IUM+ZB7RY9dTUsdO3Mw2/GDtOohz8Ofmywuc7yhpzLgn+pPX+WP60jKZzRIkcw
dpvxSzYYGy5Mhc0TyjKTTqRXbZFWCyveOcfLG4r65iEkjN/Fvtr2CGhlcgaDxHN4
J2+h4dM15AH55PqCRvKuNMfeJP+KTgDBI8X3fo/zN0bHo/bmZjr737MZkr/R+mSO
veELCoGf0lA4iskF+dUQEsLw73PLBK0dUI7zU8WWLg4CMzJjjG4=
=IUpz
-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/1b62e64c-6855-7f56-6435-8f643318b4fb%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Thursday, March 8, 2018 at 3:15:13 AM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-07 08:48, Yuraeitha wrote:
> > It might be a good idea to have some finished thoughts /
> > discussions ready for Andrew, it'd be inhuman to expect him to read
> > everything (it's a lot to read).
> 
> Thanks. I appreciate that. :)
> 
> > it might be best to start where the least work is needed from the 
> > Qubes staff.
> 
> Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
> way it currently is and have the new system be completely autonomous
> and community-run without any involvement from the Qubes staff. By way
> of analogy, think of the official system as a command-line tool and
> the community system as a user-friendly GUI frontend for that tool.
> People who either don't know how or don't want to use the command-line
> tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
> (i.e., submit content, ideas, and suggestions in any format, which the
> community then turns into proper PRs).
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqgnJcACgkQ203TvDlQ
> MDA1XBAAs8dC9Ue4kwLToYNRWTIpY+se2pn8RCQ8gqfKNgVDPNO7Qb3z7lw8kERF
> KLAktV4HL4NCz8jTJTKh0bMTB2lERytYm6uenx/fYT+fACFRAB7gg7o8D4lE+g7m
> zedYznKQHg9x2Ehi+KfVDtbEHdfagDfOW5SSWixDUyK60ZYXHDivAzZkWytMc8b8
> yZq3hZZsq8GcXAoMpxWOLl9sx5TiVHN+7WVphPEXYe0wCiCwPlwY3hDznzWAFWq2
> 2h+aYjnwRKVkvMAbcxrmfSXK0Bwr+Ccr29vBzzQ/eOgWcXwjt6oShkOoFTPLSvla
> G3JAzm+15r/7KeKItQuuXVQECGJhCqaZVs6DJFsSLAxTsfg449y3i+EFZC7hkOrM
> 3glht/vfSOsFY0LChcTc+99sCZnwN/0Q7weXd/86+nn18Qh3Ce7I77nHA1PaXMt7
> +/IUM+ZB7RY9dTUsdO3Mw2/GDtOohz8Ofmywuc7yhpzLgn+pPX+WP60jKZzRIkcw
> dpvxSzYYGy5Mhc0TyjKTTqRXbZFWCyveOcfLG4r65iEkjN/Fvtr2CGhlcgaDxHN4
> J2+h4dM15AH55PqCRvKuNMfeJP+KTgDBI8X3fo/zN0bHo/bmZjr737MZkr/R+mSO
> veELCoGf0lA4iskF+dUQEsLw73PLBK0dUI7zU8WWLg4CMzJjjG4=
> =IUpz
> -END PGP SIGNATURE-

It would feel bad if causing you trouble rather than helping, I hope we will be 
able to provide help :) I can only speak for my self, but I believe others feel 
the same, feel free to correct us if we're doing something wrong with this 
community project. <-- when I say "us", it is based on my belief, but as said I 
can't speak for everyone. I mean, it would be horrible if we impacted Qubes in 
a way that you guys didn't like, after all the amazing work you guys did with 
Qubes over all these years, you guys essentially poured your souls into this. 
Consider to bring out that whip if something is off!

If I interpreted this correctly, my understanding is that it's preferred that a 
community like this to have an inviting GUI platform, so that it can easier 
gain traction and build up users, and include more people? i.e. github is not 
desired for the central community environment?

Maybe we could beta-run a volunteer run GUI based platform first before you 
decide if it should be made official on i.e. recognized on the Qubes website 
with a link? testing the waters a bit by dipping the toe in, before taking a 
full dive. With only some platform volunteers aware of it at first to test it? 
If it works, then we can always scale it up, or if it should fail, then change 
direction or start-over with a new discussion. Something like that, a beta run 
could be insightful before any final decisions are made.

I hesitate to use the forum word here, perhaps a new fresh discussion is 
warranted as for which platform to use? But if GUI is an important factor to 
include, then a forum might be the most suitable? There will always be some who 
don't like every platform though. But did I understand it correctly that the 
Qubes staff actually likes the idea of a forum, but just doesn't have the 
man-power to run it? i.e. if you had the volunteers, then this is a desired 
platform/direction seen by the Qubes staff to go? Maybe preserving the 
mailing-lists, but integrating a forum where a forum makes sense, and then keep 
the mailing-lists as they are now and have them coexist?

-- 
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/42238610-a1e0-4533-b627-25e2587a49d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread 799
Hello Yuraeutha,

On 03/07 08:59, Yuraeitha wrote:

> [...]
> If I interpreted this correctly, my understanding is that it's preferred
that a community like this to have an inviting
> GUI platform, so that it can easier gain traction and build up users, and
include more people? i.e. github is not desired
> for the central community environment?
>
> Maybe we could beta-run a volunteer run GUI based platform first before
you decide if it should be made official on i.e.
> recognized on the Qubes website with a link? testing the waters a bit by
dipping the toe in, before taking a full dive.
> [...]

I won't agree, as content is the most important thing.
Content first -> presentation later.

Let's just start with using GitHub and evolve from there.
What do you think?

[799]

-- 
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/CAJ3yz2uEWmnEAhKuezusMgUwQuGxNVbSPs7_Ks-o%3DRZQn%2BDOxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Offtopic Amazon Echo // Re: [qubes-users] Re: High spec laptop for Qubes OS

2018-03-07 Thread 799
Am 07.03.2018 8:08 nachm. schrieb "Yuraeitha" :

(...)
So who wants a proprietary, backdoored, error-prone, computer in their
brain in contrast to open source, open hardware, which can be trusted? Even
before all this, some people who didn't care before, are starting to care
now when technology is increasingly getting closer to their lives. Like The
Amazon Echo, which is always listening to its environment, and now it's
happening to TV's and many other gadgets as well. Eventually even toasters
can spy on us.


To be fair:
The problem is not that it is always listening, as this is only be done to
simplify the use as you can say Alexa  without having to wait for
until the the echo is ready.
As soon as it recognized "Alexa" it will use the part afterwards as command.

More details in the FAQ:
https://www.amazon.com/gp/help/customer/display.html?nodeId=201602230

[...] 2. How does Alexa hands-free on my Fire tablet recognize the wake
word?

Alexa on your Fire tablet uses on-device keyword spotting to detect the
wake word, even when your device is in standby mode. When the wake word is
detected, Alexa on your Fire tablet streams audio to the Cloud, including a
fraction of a second of audio before the wake word [...]

What is much worse:
In the default configuration it storing every command you have ever said at
Amazon. With this data you can create a perfect profile and this shouldn't
be enabled by default.
The regarded voice command should be transferred to the voice recognition
server for analysis and the data should then be deleted as there is no
technical reason to store it.
I have doubts that they only do so in order to improve their service by
analyzing the voice data to give more accurate results.
This should be something that is done via opt-in and maybe with a reward:
"thank you for being completely transparent, you'll get a 10eur Amazon
Voucher and a free copy of '1984'".

I agree that it is dangerous to have such a device at home which doesn't
have a hardware kill-switch for the microphone.
But much worse is what they're already got doing without hiding it from
their users.
I was shocked when a friend showed me his Amazon echo and then said:
"Here look at the list about every command I have used so far, isn't this
cool?"

The danger is clearly the user who even agrees and likes this kind of
"feature" and the usability of those products is so easy, that everything
with adds more security feels complex.

That's a main motivation for me willing to contribute documentation so that
Qubes is easy to use do use, for those who are interested in privacy but
are not technical experts / Linux powerusers.

[799]

-- 
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/CAJ3yz2synoy3Wvsi2WCDqoLQ6f-d9duQcvyi0D4G6GBM_PH_ZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-07 Thread 799
Hello,

Am 08.03.2018 2:01 vorm. schrieb "Chris Laprise" :

Having just upgraded dom0 with qubes*testing, I noticed that nearly all of
my running VMs are being displayed by the 'Q' widget as if they were in a
pre-started or pre-halted state.


Wouldn't it makes sense to create one GitHub page for each new release,
where users can provide a quick feedback when there testing the new release.
I know it is also possible to raise an issue but it takes more time and is
not that convenient for users to look at and the list of open topics could
be placed on the Qubes Website, so that a user has a single go-to-place to
find out if he wants to take the chance testing out the new release.

I am currently reading all posts to make a decision, should I upgrade yet?
Having a bullet point list on a GitHub page would be nice, maybe later
referencing to the issue-tracker and deleted as soon the problem is fixed?
Could also be maintained by the community with a disclaimer (Warning:
blaba..)

[799]

-- 
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/CAJ3yz2uRBm5LxP9s5dwxmitXkzYFjHujugqUk95H%3DF3nTZSCdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-07 Thread Chris Laprise

On 03/07/2018 09:32 PM, 799 wrote:

Hello,

Am 08.03.2018 2:01 vorm. schrieb "Chris Laprise" >:


Having just upgraded dom0 with qubes*testing, I noticed that nearly
all of my running VMs are being displayed by the 'Q' widget as if
they were in a pre-started or pre-halted state.


Wouldn't it makes sense to create one GitHub page for each new release, 
where users can provide a quick feedback when there testing the new release.
I know it is also possible to raise an issue but it takes more time and 
is not that convenient for users to look at and the list of open topics 
could be placed on the Qubes Website, so that a user has a single 
go-to-place to find out if he wants to take the chance testing out the 
new release.


I am currently reading all posts to make a decision, should I upgrade yet?
Having a bullet point list on a GitHub page would be nice, maybe later 
referencing to the issue-tracker and deleted as soon the problem is fixed?
Could also be maintained by the community with a disclaimer (Warning: 
blaba..)


[799]



I'm using the testing repo, not the regular rc5 release. I don't think 
this would impact you if you upgraded to rc5.


--

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/3cd11407-8961-1cbb-3f2b-2984f1bed971%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-07 Thread Chris Laprise

On 03/07/2018 10:24 PM, Yuraeitha wrote:

On Thursday, March 8, 2018 at 3:53:48 AM UTC+1, Chris Laprise wrote:

On 03/07/2018 09:32 PM, 799 wrote:

Hello,

Am 08.03.2018 2:01 vorm. schrieb "Chris Laprise" >:

 Having just upgraded dom0 with qubes*testing, I noticed that nearly
 all of my running VMs are being displayed by the 'Q' widget as if
 they were in a pre-started or pre-halted state.


Wouldn't it makes sense to create one GitHub page for each new release,
where users can provide a quick feedback when there testing the new release.
I know it is also possible to raise an issue but it takes more time and
is not that convenient for users to look at and the list of open topics
could be placed on the Qubes Website, so that a user has a single
go-to-place to find out if he wants to take the chance testing out the
new release.

I am currently reading all posts to make a decision, should I upgrade yet?
Having a bullet point list on a GitHub page would be nice, maybe later
referencing to the issue-tracker and deleted as soon the problem is fixed?
Could also be maintained by the community with a disclaimer (Warning:
blaba..)

[799]



I'm using the testing repo, not the regular rc5 release. I don't think
this would impact you if you upgraded to rc5.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


Same experience as this? https://github.com/QubesOS/qubes-issues/issues/3660
It's from RC-3 to RC-5, maybe as you suggested a pure RC-5 re-install doesn't 
have this issue? Albeit this particular bug seems to be a visual issue, did you 
find anything else bugging?



Thanks for the link. That appears to be it.

Its a bit more than visual, since my menus choices are adversely 
affected (i.e. I should have 'Shutdown' available). Maybe this is the 
kick I need to adapt my keyboard shortcut VM shutdown script.


--

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/d5f46d46-bf62-f7f8-8f95-22b868939e76%40posteo.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-07 Thread ThierryIT
Le mercredi 7 mars 2018 22:21:58 UTC+2, sevas a écrit :
> Whoo hoo! 
> 
> I went to download qvm-dom0-update and it says no new updates available

Same thing for me ...

-- 
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/47a2824b-378f-4784-8aeb-b7afdf1fe4ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-07 Thread 799
Hello,

Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman"

Because the SMTP infrastructure was not designed with compartmentalization
in mind, and I only get my one email account to work with, this single
"email" VM is highly isolated. It gets its own software locked down
configuration and is firewalled with a default-deny network policy. The
only services that this VM can get to on the network is the required SMTP
services, network authentication, and the necessary  signing key
management.  No internal websites, no external sites, only the email App
runs here. Well, Ok, the calendar too. Anyway, there should be no "phoning
home" from here, other than through per use 2fa outbound email. Should any
rouge malware be received, all attachments are first scanned and "tested"
in a DVM instance before being separated and pushed across to the
appropriate project VM for storage management. All project related
historical emails are then migrated to an off-line but searchable storage
by project. This specialized email VM essentially sorts, filters,
prioritizes, and bins any incoming data/mail for easy processing.


Do you mind writing some more details as I am interested how other people
solve the email problem.
Are you really separating email in different AppVMs?
Even when you said, that the VM can only connect per SMTP I assume that you
are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and
then moving emails from the incoming mail VM to the offline mail VM?
You have one VM which makes both IMAP and SMTP correct?
Which email/calendar client are you using and how do you move mails to
your  offline email VM?

My setup:
Dedicated Email VM with Davmail installed. Davmail connects per OWA to our
corporate Microsoft Exchange Server and acts as some kind of gateway to
provide local SMTP/IMAP/CardDAV/CalDAV connections.
For emails I am running offlineimap which connects locally to Davmail and
downloads all emails and creates a local maildir-repository.
Contacts and calendar entries are downloaded via vdirsyncer.
All content is now locally available in this Email-AppVM and can now also
be used offline.
Within this VM I have setup:
For plaintext work:
- neomutt - email client
- khal - calendar
- khard - adressbook
- notmuch - fast search

And as GUI email clients (connecting to the Davmail gateway / not using the
maildir-repository)
- Evolution
- Thunderbird

Unfortunately not everything works with the Davmail Gateway:
I can see the exchange Calendar in Thunderbird, but not the calendars of my
colleques. If I open a calendar entry I get an error.
On Evolution calendar is working much better as I can open and view the
details of an calendar entry, I can create and edit calendar entries -
everything is synced per Davmail to our corporate Exchange.
Strangely I can not delete calendar entries in Evolution.

With khal I can also view/edit my  calendar entries in the terminal.
Same for khard with my contacts.

Todo:
1) Check why I can add/edit calendar entries but not delete them

2) optimize handling of attachments that PDFs / Office documents / Weblinks
are always opened in a DVM.
I have been able to do this for Thunderbird but not yet for neomutt and
Evolution.

3) I'd like to integrate email and calendar into emacs org-mode, which I am
more and more using for PIM.

4) lock down EmailAppVM so that it can only access the Microsoft Exchange
Mailserver nothing more.
I would do so by running IPtables within the VM with a default
incoming/outgoing DROP policy only adding what is absolutely necessary to
get mail/contacts/calendar working with the Exchange server

I have also thought about separating email into more AppVMs but the
usability trade-off seems to high without gaining that much security.
As the Email AppVM only is used for email/calendar it should have the same
security level like our Exchange Server. If it gets compromise it doesn't
make a difference what I have setup in Qubes.

[799]

-- 
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/CAJ3yz2txubQV8-Btuxje%2BFvfT5aq8aLHdxjnBRhVBRkFOLz6bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Changing Template Name: error this was installed by system

2018-03-07 Thread sevas
Can I not change the name of my system installed template names? 

I really want to change them. 

I want to change them to original-debian-9 - original-fedora-26

I am having trouble remembering not to edit the actual original templates 
and I find myself often wanting to revert my changes. However Im afraid to 
use the qvm command because it put me through a lot of stress last time. 

-- 
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/c158c4c6-d616-4199-8163-87066f524d3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-07 Thread Yuraeitha
On Thursday, March 8, 2018 at 3:53:48 AM UTC+1, Chris Laprise wrote:
> On 03/07/2018 09:32 PM, 799 wrote:
> > Hello,
> > 
> > Am 08.03.2018 2:01 vorm. schrieb "Chris Laprise"  > >:
> > 
> > Having just upgraded dom0 with qubes*testing, I noticed that nearly
> > all of my running VMs are being displayed by the 'Q' widget as if
> > they were in a pre-started or pre-halted state.
> > 
> > 
> > Wouldn't it makes sense to create one GitHub page for each new release, 
> > where users can provide a quick feedback when there testing the new release.
> > I know it is also possible to raise an issue but it takes more time and 
> > is not that convenient for users to look at and the list of open topics 
> > could be placed on the Qubes Website, so that a user has a single 
> > go-to-place to find out if he wants to take the chance testing out the 
> > new release.
> > 
> > I am currently reading all posts to make a decision, should I upgrade yet?
> > Having a bullet point list on a GitHub page would be nice, maybe later 
> > referencing to the issue-tracker and deleted as soon the problem is fixed?
> > Could also be maintained by the community with a disclaimer (Warning: 
> > blaba..)
> > 
> > [799]
> > 
> 
> I'm using the testing repo, not the regular rc5 release. I don't think 
> this would impact you if you upgraded to rc5.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Same experience as this? https://github.com/QubesOS/qubes-issues/issues/3660
It's from RC-3 to RC-5, maybe as you suggested a pure RC-5 re-install doesn't 
have this issue? Albeit this particular bug seems to be a visual issue, did you 
find anything else bugging?

-- 
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/b5153d2e-8f30-4a93-8710-89eb1f659faa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] R4.0 drops USB data

2018-03-07 Thread Glen H
Hi,

I'm using R4 (having never used R3) and trying to get my scanner working but it 
stops scanning a page half way through.  After debugging with the author of the 
scanner software they say the program asks for 128 KBytes of data and the first 
256 bytes of this data is dropped (lost).

To fix this I've tried:
1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an option as 
all the external ports are disabled).  It doesn't revert back to USB 2.0
2) Set the ports to USB 2.0 via setpci:

```
lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 
-d @ d0.l=0
```

Unfortunately neither of those made a difference.  Using the scanner/software 
in Windows on a different computer works.


I'm currently running a Qubes backup and then I'll try installing Ubuntu and 
see if that works.  If so would seem to be related to Qubes.

Does anyone have any ideas?  My laptop is a Dell e7440 with the latest BIOS.

Thanks,

Glen

-- 
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/4e95eda0-6f8b-46b6-b787-f3d15f174eff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Ivan Mitev


On 03/08/2018 06:59 AM, Yuraeitha wrote:
> On Thursday, March 8, 2018 at 3:15:13 AM UTC+1, Andrew David Wong wrote:
> On 2018-03-07 08:48, Yuraeitha wrote:
 It might be a good idea to have some finished thoughts /
 discussions ready for Andrew, it'd be inhuman to expect him to read
 everything (it's a lot to read).
> 
> Thanks. I appreciate that. :)
> 
 it might be best to start where the least work is needed from the 
 Qubes staff.
> 
> Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
> way it currently is and have the new system be completely autonomous
> and community-run without any involvement from the Qubes staff. By way
> of analogy, think of the official system as a command-line tool and
> the community system as a user-friendly GUI frontend for that tool.
> People who either don't know how or don't want to use the command-line
> tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
> (i.e., submit content, ideas, and suggestions in any format, which the
> community then turns into proper PRs).
> 
> 
> It would feel bad if causing you trouble rather than helping, I hope we will 
> be able to provide help :) I can only speak for my self, but I believe others 
> feel the same, feel free to correct us if we're doing something wrong with 
> this community project. <-- when I say "us", it is based on my belief, but as 
> said I can't speak for everyone. I mean, it would be horrible if we impacted 
> Qubes in a way that you guys didn't like, after all the amazing work you guys 
> did with Qubes over all these years, you guys essentially poured your souls 
> into this. Consider to bring out that whip if something is off!
> 
> If I interpreted this correctly, my understanding is that it's preferred that 
> a community like this to have an inviting GUI platform, so that it can easier 
> gain traction and build up users, and include more people? i.e. github is not 
> desired for the central community environment?

The GUI / command line distinction was an analogy. Here's another: we're
given a powerful car but its user manual is targeting experienced
drivers. The community here could help with:
* lowering the difficulty for casual drivers to send improvements to the
official user guide
* centralizing "tuning" tips unsupported by the car's manufacturer
because the car could become dangerous to drive if you don't know what
you are doing.

Let's go ahead with awokd's suggestion of a wiki + repo.

Andrew: what's your position about mentioning this community effort
somewhere in the official qubes site ? (maybe as a news post with the
proper disclaimer + modifying the "contribute to the docs" page) ?
Without visibility only a few people would know about this community
effort and the project will quickly stall.


> Maybe we could beta-run a volunteer run GUI based platform first before you 
> decide if it should be made official on i.e. recognized on the Qubes website 
> with a link? testing the waters a bit by dipping the toe in, before taking a 
> full dive. With only some platform volunteers aware of it at first to test 
> it? If it works, then we can always scale it up, or if it should fail, then 
> change direction or start-over with a new discussion. Something like that, a 
> beta run could be insightful before any final decisions are made.
> 
> I hesitate to use the forum word here, perhaps a new fresh discussion is 
> warranted as for which platform to use? But if GUI is an important factor to 
> include, then a forum might be the most suitable? There will always be some 
> who don't like every platform though. But did I understand it correctly that 
> the Qubes staff actually likes the idea of a forum, but just doesn't have the 
> man-power to run it? i.e. if you had the volunteers, then this is a desired 
> platform/direction seen by the Qubes staff to go? Maybe preserving the 
> mailing-lists, but integrating a forum where a forum makes sense, and then 
> keep the mailing-lists as they are now and have them coexist?



-- 
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/ac67bc57-7d45-d470-647a-3e7e6c3a1265%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-07 Thread haaber
> Le mercredi 7 mars 2018 22:21:58 UTC+2, sevas a écrit :
>> Whoo hoo! 
>>
>> I went to download qvm-dom0-update and it says no new updates available
> 
> Same thing for me ...
> 
and   sudo qubes-dom0-update --enablerepo=qubes*testing ?

-- 
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/1961d5fc-5bf2-6b96-7718-b3c82f96bf13%40web.de.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] DNS propagation in Qubes

2018-03-07 Thread Unman
On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> about this [1]).
> 
> I've got this successfully working in sys-net by running a local DNS server 
> on udp 53 that forwards DNS requests to a remote DNS server over TLS, and 
> then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've 
> confirmed that this works great in sys-net -- all of my DNS requests are 
> encrypted to my remote DNS server, and none are plaintext.
> 
> The problem is when I do this, DNS in other downstream VMs all fail. The 
> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> about how to make this set up work. Any ideas? Thanks!
> 
> [1] https://dnsprivacy.org/wiki/
> [2] https://www.qubes-os.org/doc/networking/
> 

Which Qubes version are you using Micah?

-- 
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/2018030717.hawe2u54neblst5q%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] DNS propagation in Qubes

2018-03-07 Thread Micah Lee
Qubes 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/X1juIg1dY5HqEdgRRiliD8belJfZZE8Zt-UAwN3VNsQETPt6oVLAVSRCgd8H0Zq_LvFJz6fWTeYPMKPGjolws8qqCHF8RsbhrtuNz1FpOVc%3D%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qubes-dom0-update (3.2) failing with error message

2018-03-07 Thread Doug Hill
Hi,

When executing "sudo qubes-dom0-update" in dom0, I'm receiving the
following error:

tar: /var/lib/qubes/dom0-updates: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Dom0 updates dir does not exists: /var/lib/qubes/dom0-updates

I can confirm that the directory does not exist.  I do have a backup of
dom0.  Any pitfalls around restoring dom0?

Any help is greatly appreciated.

Be well!

Doug

-- 
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/7b2918b2-a1f8-49c2-cf1f-5728a202b492%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] DNS propagation in Qubes

2018-03-07 Thread Unman
On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> about this [1]).
> 
> I've got this successfully working in sys-net by running a local DNS server 
> on udp 53 that forwards DNS requests to a remote DNS server over TLS, and 
> then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've 
> confirmed that this works great in sys-net -- all of my DNS requests are 
> encrypted to my remote DNS server, and none are plaintext.
> 
> The problem is when I do this, DNS in other downstream VMs all fail. The 
> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> about how to make this set up work. Any ideas? Thanks!
> 
> [1] https://dnsprivacy.org/wiki/
> [2] https://www.qubes-os.org/doc/networking/
> 

In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server. 
You'll also need to open the udp port to inbound traffic.

-- 
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/20180307174022.u5dknqjh3oimwfq3%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote:
> On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2018-03-05 16:28, Alex Dubois wrote:
> > >> On 5 Mar 2018, at 21:07, 799  wrote:
> > >> 
> > >> Hello,
> > >> 
> > > On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just 
> > > create a new "community" repo where Pull request get 
> > > reviewed by us but finally approved by more experienced 
> > > Power Users (this group can include Qubes OS Team, but also
> > > experienced community members selected by the Qubes 
> > > Team/David)?
> >  
> >  On 4 Mar 2018, at 21:44, awokd  wrote: I
> >  wouldn't mind helping out on reviews on something like this,
> >  as well as contributing my own half-baked ideas.
> > >>> 
> > >>> On 5 March 2018 at 08:57, Alex Dubois  
> > >>> wrote: True we could have sandbox per person, or each person 
> > >>> fork (the fork) and we have a page with list of forks Once idea
> > >>> is ready, do a PR to the community fork...
> > >>> 
> > >>> This is the spirit of git
> > >> 
> > >> can't we just start to fork qubes-doc to qubes-community-doc and
> > >>  start there. If we think we need to rearrange the content or get
> > >>  rid of it, because it just doesn't make sense, we can still do 
> > >> so.
> > >> 
> > >> In the main qubes-doc repository it seems that some skilled users
> > >> are able to approve Pull Requests, I don't know enough about
> > >> github how this works? Are those special permissions for trusted
> > >> users or can it be anyone? I would like to see Andrew David Wong
> > >> or marmarek as power users supporting this - by at least maybe
> > >> giving feedback. If there are any other skilled persons which are
> > >> happy to gibr feedback to improve the scripts which are collected
> > >> there, this is even better - just mentioned those two as they
> > >> were super helpfull when I wrote my first Qubes Docs hey, ho -
> > >> let's go.
> > > 
> > > Give David a bit of time. His schedule might be busy, he may need 
> > > to sync with a number of other persons, they may discuss what’s 
> > > best. There is no rush. He is doing a great work as community 
> > > manager.
> > > 
> > 
> > Thanks. :}
> > 
> > Currently, qubes-doc PRs have to be approved by a member of the Qubes
> > team before being merged into the master branch, which is the live
> > version. (Usually, I'm the one who does the merge. In those cases, if
> > you don't see explicit approval from another member of the team, it
> > just means that I'm the one who has reviewed and approved the PR.)
> > This system is great for maintaining high standards of security (as a
> > first priority) and quality (as a second priority) for the docs.
> > However, it's very time-consuming, since (at least) one of us has to
> > review every single PR that gets merged (as well as many of those that
> > ultimately get rejected, which are a small minority).
> > 
> > Currently, we barely have enough time to keep up with the stream of
> > PRs that get submitted to qubes-doc, so it's very unlikely that we'd
> > also have time to review or provide substantive feedback on PRs for a
> > second, community-run version of qubes-doc that receives even more PRs
> > (if I'm understanding the proposal correctly).
> > 
> > However, I do like the sound of a fully-community-run version that
> > serves to collaboratively improve content before it is submitted to
> > qubes-doc. Currently, most contributors just submit their work
> > directly to qubes-doc, and the quality tends to vary. Perhaps the
> > community-run version could be an optional (but recommended,
> > especially for first-time contributors) place where work is polished
> > up with feedback from the community before it's submitted as a PR to
> > qubes-doc to be reviewed by the team. This could make things easier
> > for contributors, improve the quality of the docs, and save the team's
> > time.
> > 
> > 
> > P.S. - You can call me "Andrew." "David" is my middle name. :)
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > 
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ
> > MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E
> > PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2
> > rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9
> > quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k
> > 0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9
> > +pFQu2ShBZgOFyNQ+itDPW70r/1Jfc0mpRu16Dz85/VTew/ROrdOlizLqHtbS6L4
> > i0ZG6vbFAw0H4/kPzOWz3xxRukbXtOWBL6kx1a8Sj+JZSs5B5mbSGkg5S4vOEXrg
> > p+PBzt5jfuwg9ZrJCqBOWy56JfPqpmb37ooqC94oTYeXX2utRFQg8QyA/NRMgduM
> > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote:
> On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote:
> > On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > On 2018-03-05 16:28, Alex Dubois wrote:
> > > >> On 5 Mar 2018, at 21:07, 799  wrote:
> > > >> 
> > > >> Hello,
> > > >> 
> > > > On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just 
> > > > create a new "community" repo where Pull request get 
> > > > reviewed by us but finally approved by more experienced 
> > > > Power Users (this group can include Qubes OS Team, but also
> > > > experienced community members selected by the Qubes 
> > > > Team/David)?
> > >  
> > >  On 4 Mar 2018, at 21:44, awokd  wrote: I
> > >  wouldn't mind helping out on reviews on something like this,
> > >  as well as contributing my own half-baked ideas.
> > > >>> 
> > > >>> On 5 March 2018 at 08:57, Alex Dubois  
> > > >>> wrote: True we could have sandbox per person, or each person 
> > > >>> fork (the fork) and we have a page with list of forks Once idea
> > > >>> is ready, do a PR to the community fork...
> > > >>> 
> > > >>> This is the spirit of git
> > > >> 
> > > >> can't we just start to fork qubes-doc to qubes-community-doc and
> > > >>  start there. If we think we need to rearrange the content or get
> > > >>  rid of it, because it just doesn't make sense, we can still do 
> > > >> so.
> > > >> 
> > > >> In the main qubes-doc repository it seems that some skilled users
> > > >> are able to approve Pull Requests, I don't know enough about
> > > >> github how this works? Are those special permissions for trusted
> > > >> users or can it be anyone? I would like to see Andrew David Wong
> > > >> or marmarek as power users supporting this - by at least maybe
> > > >> giving feedback. If there are any other skilled persons which are
> > > >> happy to gibr feedback to improve the scripts which are collected
> > > >> there, this is even better - just mentioned those two as they
> > > >> were super helpfull when I wrote my first Qubes Docs hey, ho -
> > > >> let's go.
> > > > 
> > > > Give David a bit of time. His schedule might be busy, he may need 
> > > > to sync with a number of other persons, they may discuss what’s 
> > > > best. There is no rush. He is doing a great work as community 
> > > > manager.
> > > > 
> > > 
> > > Thanks. :}
> > > 
> > > Currently, qubes-doc PRs have to be approved by a member of the Qubes
> > > team before being merged into the master branch, which is the live
> > > version. (Usually, I'm the one who does the merge. In those cases, if
> > > you don't see explicit approval from another member of the team, it
> > > just means that I'm the one who has reviewed and approved the PR.)
> > > This system is great for maintaining high standards of security (as a
> > > first priority) and quality (as a second priority) for the docs.
> > > However, it's very time-consuming, since (at least) one of us has to
> > > review every single PR that gets merged (as well as many of those that
> > > ultimately get rejected, which are a small minority).
> > > 
> > > Currently, we barely have enough time to keep up with the stream of
> > > PRs that get submitted to qubes-doc, so it's very unlikely that we'd
> > > also have time to review or provide substantive feedback on PRs for a
> > > second, community-run version of qubes-doc that receives even more PRs
> > > (if I'm understanding the proposal correctly).
> > > 
> > > However, I do like the sound of a fully-community-run version that
> > > serves to collaboratively improve content before it is submitted to
> > > qubes-doc. Currently, most contributors just submit their work
> > > directly to qubes-doc, and the quality tends to vary. Perhaps the
> > > community-run version could be an optional (but recommended,
> > > especially for first-time contributors) place where work is polished
> > > up with feedback from the community before it's submitted as a PR to
> > > qubes-doc to be reviewed by the team. This could make things easier
> > > for contributors, improve the quality of the docs, and save the team's
> > > time.
> > > 
> > > 
> > > P.S. - You can call me "Andrew." "David" is my middle name. :)
> > > 
> > > - -- 
> > > Andrew David Wong (Axon)
> > > Community Manager, Qubes OS
> > > https://www.qubes-os.org
> > > 
> > > -BEGIN PGP SIGNATURE-
> > > 
> > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ
> > > MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E
> > > PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2
> > > rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9
> > > quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k
> > > 0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9
> > 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Tuesday, March 6, 2018 at 2:28:25 AM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-05 16:28, Alex Dubois wrote:
> >> On 5 Mar 2018, at 21:07, 799  wrote:
> >> 
> >> Hello,
> >> 
> > On Sun, March 4, 2018 8:04 pm, 799 wrote: Can't we just 
> > create a new "community" repo where Pull request get 
> > reviewed by us but finally approved by more experienced 
> > Power Users (this group can include Qubes OS Team, but also
> > experienced community members selected by the Qubes 
> > Team/David)?
>  
>  On 4 Mar 2018, at 21:44, awokd  wrote: I
>  wouldn't mind helping out on reviews on something like this,
>  as well as contributing my own half-baked ideas.
> >>> 
> >>> On 5 March 2018 at 08:57, Alex Dubois  
> >>> wrote: True we could have sandbox per person, or each person 
> >>> fork (the fork) and we have a page with list of forks Once idea
> >>> is ready, do a PR to the community fork...
> >>> 
> >>> This is the spirit of git
> >> 
> >> can't we just start to fork qubes-doc to qubes-community-doc and
> >>  start there. If we think we need to rearrange the content or get
> >>  rid of it, because it just doesn't make sense, we can still do 
> >> so.
> >> 
> >> In the main qubes-doc repository it seems that some skilled users
> >> are able to approve Pull Requests, I don't know enough about
> >> github how this works? Are those special permissions for trusted
> >> users or can it be anyone? I would like to see Andrew David Wong
> >> or marmarek as power users supporting this - by at least maybe
> >> giving feedback. If there are any other skilled persons which are
> >> happy to gibr feedback to improve the scripts which are collected
> >> there, this is even better - just mentioned those two as they
> >> were super helpfull when I wrote my first Qubes Docs hey, ho -
> >> let's go.
> > 
> > Give David a bit of time. His schedule might be busy, he may need 
> > to sync with a number of other persons, they may discuss what’s 
> > best. There is no rush. He is doing a great work as community 
> > manager.
> > 
> 
> Thanks. :}
> 
> Currently, qubes-doc PRs have to be approved by a member of the Qubes
> team before being merged into the master branch, which is the live
> version. (Usually, I'm the one who does the merge. In those cases, if
> you don't see explicit approval from another member of the team, it
> just means that I'm the one who has reviewed and approved the PR.)
> This system is great for maintaining high standards of security (as a
> first priority) and quality (as a second priority) for the docs.
> However, it's very time-consuming, since (at least) one of us has to
> review every single PR that gets merged (as well as many of those that
> ultimately get rejected, which are a small minority).
> 
> Currently, we barely have enough time to keep up with the stream of
> PRs that get submitted to qubes-doc, so it's very unlikely that we'd
> also have time to review or provide substantive feedback on PRs for a
> second, community-run version of qubes-doc that receives even more PRs
> (if I'm understanding the proposal correctly).
> 
> However, I do like the sound of a fully-community-run version that
> serves to collaboratively improve content before it is submitted to
> qubes-doc. Currently, most contributors just submit their work
> directly to qubes-doc, and the quality tends to vary. Perhaps the
> community-run version could be an optional (but recommended,
> especially for first-time contributors) place where work is polished
> up with feedback from the community before it's submitted as a PR to
> qubes-doc to be reviewed by the team. This could make things easier
> for contributors, improve the quality of the docs, and save the team's
> time.
> 
> 
> P.S. - You can call me "Andrew." "David" is my middle name. :)
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqd7psACgkQ203TvDlQ
> MDDzqRAAlppp00e/YixAnaLJgyNEYbZgxA9ZlVABBxUJwUX7Ede0MAHeiLHLiR0E
> PqdvVBSBi1rt0XYROka44IJ8amj1pM3tc5UroE4rhG8yxY7TPnul0tAHeTH5rTk2
> rCPOsHLSuv/nwqdzhvcCK2cC9SKYgJF7IGdgtRnaMg56JEYkn7HISKFxMfL6m8L9
> quU4dRdBJnWEk16lYHxQBd3JtVeBtHjCppHh9CFn5XYdbPvbPd8qYwOVMdSOaG0k
> 0adeue8gI8G6Mkf3pzJt7Etjr8xjlHB4JKaMy7VCN7PekdkrITbQCwPH24PLQHP9
> +pFQu2ShBZgOFyNQ+itDPW70r/1Jfc0mpRu16Dz85/VTew/ROrdOlizLqHtbS6L4
> i0ZG6vbFAw0H4/kPzOWz3xxRukbXtOWBL6kx1a8Sj+JZSs5B5mbSGkg5S4vOEXrg
> p+PBzt5jfuwg9ZrJCqBOWy56JfPqpmb37ooqC94oTYeXX2utRFQg8QyA/NRMgduM
> pkRNOVOpO81OIiUYvzM9eY2zYhWa3LUY4x0OdkiO9hcZ7tVQ17iurgBE8KFy6drj
> dKd4nLPiXUMF6mGXt+6fksaKhhSAxyMcWSUb094PXhZjcqiMKEaP+7hd0tZeNSE8
> R/zFQJyd6VPaervecyKvcMw9mXt2Mal/OBRlyMHbJcyNqLpucLs=
> =WFKk
> -END PGP SIGNATURE-

To extend on [799]'s idea of a new Community doc page, and combine the idea to 
make a 

[qubes-users] Cannot copy installation image to USB

2018-03-07 Thread Zbigniew Łukasiak
I tried two usb sticks with 16GB and 64GB and on both I was getting this:

user@personal:~/Downloads$ sudo dd if=Qubes-R4.0-rc5-x86_64.iso
of=/dev/xdvi && sync
dd: writing to ‘/dev/xdvi’: No space left on device
2891865+0 records in
2891864+0 records out
1480634368 bytes (1.5 GB) copied, 13.1412 s, 113 MB/s

That was on a debian VM.

I solved that problem for me by using my ubuntu machine - but
reporting just in case.


-- 
Zbigniew Lukasiak
https://medium.com/@zby
http://brudnopis.blogspot.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 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/CAGL_UUuE67D6aD3Q2HztOMXOdFrmcQtgdeGg_QehYFaBtj1RYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: repo qubes-dom0-current-testing broke copy between AppVM

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 5:11:30 AM UTC+1, Glen H wrote:
> Hi,
> 
> I wanted to update from 4 RC4 to RC5 so I ran:
> 
> sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
> 
> But that seems to have broken copy to another AppVM (from Nautilus).  Perhaps 
> I need to update the templates too but I'm not sure if I should be syncing up 
> to "qubes-dom0-current-testing" or "qubes-dom0-current", please clarify (I 
> want to be on RC5).
> 
> For FYI, is there anyway to downgrade back to "qubes-dom0-current" (or 
> whatever state I was in before I updated)?  
> 
> Thanks,
> 
> Glen


I agree with [799], and this particular issue with out of sync VM's causing 
qvm-copy to stop working is also known too, so you can probably be reasonably 
sure what [799] suggested is correct, your updates are out of sync. So 
everything works as it's supposed, but you need to get everything back in sync 
in order to get it working.

I don't think it's a good idea to downgrade unless someone steps in to tell you 
exactly what to do, or if you find a very detailed guide (I don't think there 
is one available, and it would be tricky when it's different packages and 
different complexities, such a guide would have to cover many complex areas to 
be sure to cover everything). As [799] suggested, it's a very good idea to 
crate a backup before you run current-testing updates.

You could just download new clean templates and phase them out, but it requires 
moving all your AppVM's a few times to phase it all out, it'll take some work 
to do. But your issue is that dom0 still has the updates, and as long you can't 
revert dom0 changes, then downloading new clean templates won't work.

You can of course still backup all your AppVm's and perform a clean install, 
with new fresh dom0 and domU's (templates), this way you can get back to stable 
quite easily, and it'll probably be quicker at any rate, irregardless if you 
try to downgrade or not, and considering downgrading probably carries more risk 
than to go forwards and use current-resting once more, well, it isn't worth it.

In other words, your only solution is probably just that, forwards. Either 
backup AppVM's and re-install, or sync all the current-testing repo's at least 
once, before you go back to stable repositories (you have two choices, imho 
going the current-testing route is fine, but backup first anyway, it's always a 
good idea). So you can sync all your dom0 / domU's (templates) with 
current-testing, and then after that only run stable repository to slowly 
out-phase current-testing. Current-testing is typically maximum 14 days, so you 
should be back to normal after 14 days (in theory, I'm not an expert but a 
learner).

You also need to be careful about non-expired 48 hour caches, since you mixed 
up the repositories here, your cache expiration is probably not the same across 
the dom0 / domU's, so you need to take precaution against any complexities 
here. You can do that with the --refresh flag which ensures your cache is 
up-to-date with the online repository. I'm not sure why this isn't working in 
dom0 though, but as an alternative you can run --clean instead in dom0, which 
will do the same (and more, a bigger cleanup).

in dom0, run;
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --clean

in all fedora templates, run;
sudo dnf update --enablerepo=qubes-vm-*-current-testing --refresh

in all debian and whonix templates, edit this file
/etc/apt/sources.list.d/qubes-r*.list
and then update with 
sudo apt-get update && sudo apt-get dist-upgrade

Once you did that, everything should then be in sync, restart your Qubes system 
fully, and then after that only use stable again (until you one day decide to 
use current-testing, but remember they will come to you within 14 days anyway, 
assuming the updates work as intended). 

Remember to revert the files in debian and whonix templates when you go back to 
stable repositories again.

Always, always, ALWAYS! <--- stressed! run the same repositories across the 
board of Qubes. The dom0 and domU's must use the same Qubes repositories. You 
just experienced first hand the consequences of not doing that, although it was 
a light issue and you can easily recover from it by sync'ing the repositories 
again.

Let us know if it works or not :)

-- 
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/1ca8e024-b076-4f9e-9de0-7e2b12164935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 9:00 am, Yuraeitha wrote:
> On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote:
>
>> On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote:
>>

>>>
>>> To extend on [799]'s idea of a new Community doc page, and combine
>>> the idea to make a stepping stone development progress system, and
>>> combine it with the issue with the lack of time for the Qubes staff,
>>> perhaps we could make a third repository, for testing and reviewing,
>>> before sending it to a more official Community doc page, which then
>>> could later forward high quality content to the Official Qubes doc
>>> page?
>>>
>>> This suggestion is only to get it started, we can always look to
>>> expand this later on with other platforms, be it forums or something
>>> else. In a nutshell, starting out small, and then scale it all up
>>> later on as the small gains success, and from there pick a direction
>>> (for example preferred platforms, community style and layouts, goals
>>> and directions, targets, etc.).
>>>
>>> So to start small, with minimum time taken from the Qubes staff as
>>> far possible, something like this?
>>>
>>> - Hidden Qubes trial grounds - Hidden away from normal users, so that
>>> only volunteer testers and reviewers can easily find it. Have a
>>> minimum time or a minimum amount of people read and review it, before
>>> the person who will be in charge to publish it to the Official Qubes
>>> Community doc page, where another volunteer can be in charge of
>>> quality checks.
>>>
>>> - Official Qubes Community doc's - less quality, but still
>>> good/decent. Security and system reliability must always be top
>>> priority though. Then the volunteers here, if they find some
>>> guides/doc's to be outstanding or really good, could then forward
>>> this guide to Qubes Official doc page.
>>>
>>> - Official Qubes doc's - keep working like normal. Only high quality
>>> docs/guides are accepted. Less clutter is received by having two
>>> system checks before arriving to the Qubes doc page, saving Qubes
>>> staff time.
>>>
>>> By doing something like this, we're still staying neutral to big
>>> decisions, but we can start doing the community guides quality
>>> checks, and then reduce the amount of work arriving to the Qubes
>>> staff. This could then later on evolve further into many different
>>> things, keeping all those decisions for later in time.
>>>
>>> What I also think is good about this, is that we start out small,
>>> nothing too complex, and then only proceed and build on-top of it
>>> once this small step is successful. The goal is to merge the
>>> community doc page idea with saving Qubes staff time and to increase
>>> the quality of the final Qubes doc page further.
>>>
>>> This shouldn't take much time to setup either? We could clone the
>>> current Qubes doc page system and do it like that for the other two
>>> systems? So the trial grounds is like a gateway collecting work from
>>> the many different GitHub pages, and the community page then retains
>>> all the guides and docs which are not wrong, but also not high in
>>> quality, but also forwards the high quality to the Qubes doc page,
>>> acting as a system check to the final high quality Qubes doc content.
>>>
>>>
>>> This also allows volunteers to step in and take a second or third
>>> look at the Community doc's to see if they can help increase the
>>> quality of it.
>>
>> I want to underline that this suggestion is to start out as small as
>> possible, while still starting out the primary idea of community work
>> by the community.
>>
>> Since this can take any shape later on, it will not negate any of the
>> ideas in this thread, it'll only serve as a small starting point, or a
>> testing grounds before expanding it, while at the same time starting to
>> save Qubes staff's time on the Qubes doc page.
>
> Qubes staff could also take the Qubes doc commits that came to them
> directly, and instead forward them backwards to the Qubes Community doc
> or trial grounds, if it does not have enough quality or needs
> improvements, or in case it is a busy time period and it can't be
> reviewed.
>
> Furthermore in busy times, the bridge to carry over docs from Community
> doc's to Qubes doc's can be minimized to slow down the commits, as a
> dynamic to help the Qubes staff to better manage their own time.

Two repos mean twice the administration; not sure that's the best approach
to start out with. I poked around Github settings a bit. The permission
controls are very limited (maybe granular settings are available in the
paid version), but the following might fit most of your model:

- one Github site
- only a single owner permitted
- Wiki with editing permitted to any logged in Github user (your
scratch/development area)
- collaborators by individual Github name appear to have push/write access
to full repo
- Code section could contain the more formal contents, would have to be a
collaborator to contribute directly or 

Re: [qubes-users] Recommended laptop

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 7:46 am, awokd wrote:

> There's https://www.qubes-os.org/doc/#choosing-your-hardware in the docs
> and FAQ links to same but maybe some type of decision tree?

Here's my first attempt at one. Links don't work in its current location,
but it should be easy to follow. I'm not entirely sure this belongs on
Qubes' site so I threw in a disclaimer.

https://github.com/awokd/qubes-doc/blob/hardwaretree/hardware/hardware-tree.md


-- 
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/455b28b4f92e2914b3ab9e93b0963c65.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
@awokd

On Wednesday, March 7, 2018 at 10:45:42 AM UTC+1, awokd wrote:
> On Wed, March 7, 2018 9:00 am, Yuraeitha wrote:
> > On Wednesday, March 7, 2018 at 9:50:13 AM UTC+1, Yuraeitha wrote:
> >
> >> On Wednesday, March 7, 2018 at 9:37:00 AM UTC+1, Yuraeitha wrote:
> >>
> 
> >>>
> >>> To extend on [799]'s idea of a new Community doc page, and combine
> >>> the idea to make a stepping stone development progress system, and
> >>> combine it with the issue with the lack of time for the Qubes staff,
> >>> perhaps we could make a third repository, for testing and reviewing,
> >>> before sending it to a more official Community doc page, which then
> >>> could later forward high quality content to the Official Qubes doc
> >>> page?
> >>>
> >>> This suggestion is only to get it started, we can always look to
> >>> expand this later on with other platforms, be it forums or something
> >>> else. In a nutshell, starting out small, and then scale it all up
> >>> later on as the small gains success, and from there pick a direction
> >>> (for example preferred platforms, community style and layouts, goals
> >>> and directions, targets, etc.).
> >>>
> >>> So to start small, with minimum time taken from the Qubes staff as
> >>> far possible, something like this?
> >>>
> >>> - Hidden Qubes trial grounds - Hidden away from normal users, so that
> >>> only volunteer testers and reviewers can easily find it. Have a
> >>> minimum time or a minimum amount of people read and review it, before
> >>> the person who will be in charge to publish it to the Official Qubes
> >>> Community doc page, where another volunteer can be in charge of
> >>> quality checks.
> >>>
> >>> - Official Qubes Community doc's - less quality, but still
> >>> good/decent. Security and system reliability must always be top
> >>> priority though. Then the volunteers here, if they find some
> >>> guides/doc's to be outstanding or really good, could then forward
> >>> this guide to Qubes Official doc page.
> >>>
> >>> - Official Qubes doc's - keep working like normal. Only high quality
> >>> docs/guides are accepted. Less clutter is received by having two
> >>> system checks before arriving to the Qubes doc page, saving Qubes
> >>> staff time.
> >>>
> >>> By doing something like this, we're still staying neutral to big
> >>> decisions, but we can start doing the community guides quality
> >>> checks, and then reduce the amount of work arriving to the Qubes
> >>> staff. This could then later on evolve further into many different
> >>> things, keeping all those decisions for later in time.
> >>>
> >>> What I also think is good about this, is that we start out small,
> >>> nothing too complex, and then only proceed and build on-top of it
> >>> once this small step is successful. The goal is to merge the
> >>> community doc page idea with saving Qubes staff time and to increase
> >>> the quality of the final Qubes doc page further.
> >>>
> >>> This shouldn't take much time to setup either? We could clone the
> >>> current Qubes doc page system and do it like that for the other two
> >>> systems? So the trial grounds is like a gateway collecting work from
> >>> the many different GitHub pages, and the community page then retains
> >>> all the guides and docs which are not wrong, but also not high in
> >>> quality, but also forwards the high quality to the Qubes doc page,
> >>> acting as a system check to the final high quality Qubes doc content.
> >>>
> >>>
> >>> This also allows volunteers to step in and take a second or third
> >>> look at the Community doc's to see if they can help increase the
> >>> quality of it.
> >>
> >> I want to underline that this suggestion is to start out as small as
> >> possible, while still starting out the primary idea of community work
> >> by the community.
> >>
> >> Since this can take any shape later on, it will not negate any of the
> >> ideas in this thread, it'll only serve as a small starting point, or a
> >> testing grounds before expanding it, while at the same time starting to
> >> save Qubes staff's time on the Qubes doc page.
> >
> > Qubes staff could also take the Qubes doc commits that came to them
> > directly, and instead forward them backwards to the Qubes Community doc
> > or trial grounds, if it does not have enough quality or needs
> > improvements, or in case it is a busy time period and it can't be
> > reviewed.
> >
> > Furthermore in busy times, the bridge to carry over docs from Community
> > doc's to Qubes doc's can be minimized to slow down the commits, as a
> > dynamic to help the Qubes staff to better manage their own time.
> 
> Two repos mean twice the administration; not sure that's the best approach
> to start out with. I poked around Github settings a bit. The permission
> controls are very limited (maybe granular settings are available in the
> paid version), but the following might fit most of your model:
> 
> - one Github site
> - only a single owner permitted
> - Wiki with editing permitted to 

Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:

> Let me know if I misunderstood you. I'm still grasping the proper
> terminology, as well the limits and possibilities of Github, so it might
> be easy to misunderstand.

Github is easy for me to misunderstand too. :)

You had 2 community repos in addition to the official Qubes repo. I'm
suggesting only 1 community repo with the following settings, and not
touching the official repo at all. I don't know how to address migrating
content, so I'm not sure it's a possibility.

>> - one Github site
>> - only a single owner permitted
>> - Wiki with editing permitted to any logged in Github user (your
>> scratch/development area)
>> - collaborators by individual Github name
>> appear to have push/write access to full repo
>> - Code section could
>> contain the more formal contents, would have to be a collaborator to
>> contribute directly or approve submissions
>> - unclear on how documents
>> would migrate from here to qubes-doc unless as a copy/paste, but that
>> would lose attribution and I imagine most would like their own name on
>> their commit!
>>


-- 
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/ba0a3fa3473ecb083b9a37262d9bd648.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Cannot copy installation image to USB

2018-03-07 Thread Unman
On Wed, Mar 07, 2018 at 05:02:33AM -0500, Zbigniew Łukasiak wrote:
> I tried two usb sticks with 16GB and 64GB and on both I was getting this:
> 
> user@personal:~/Downloads$ sudo dd if=Qubes-R4.0-rc5-x86_64.iso
> of=/dev/xdvi && sync
> dd: writing to ‘/dev/xdvi’: No space left on device
> 2891865+0 records in
> 2891864+0 records out
> 1480634368 bytes (1.5 GB) copied, 13.1412 s, 113 MB/s
> 
> That was on a debian VM.
> 
> I solved that problem for me by using my ubuntu machine - but
> reporting just in case.

Unless you typed that out by hand,there there was a typo in your
command- the USB stick would be at /dev/xvdi - you used /dev/xdvi which
created a file, and filled /dev.

-- 
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/20180307111457.l7exsyqhm7e74vpt%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-07 Thread amilton
Thanks for the great news Andrew.
Congratulations to the team.

Em terça-feira, 6 de março de 2018 22:03:05 UTC-3, Andrew David Wong  escreveu:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> We're pleased to announce the fifth release candidate for Qubes 4.0!
> This release contains bug fixes for the issues discovered in the
> [previous release candidate][4.0-rc4]. A full list of the Qubes 4.0
> issues closed so far is available [here][closed-issues]. Further
> details about this release, including full installation instructions,
> are available in the [Qubes 4.0 release notes][release-notes]. The new
> installation image is available on the [Downloads] page.
> 
> As always, we're immensely grateful to our community of testers for
> taking the time to [discover and report bugs]. Thanks to your efforts,
> we're able to fix these bugs *before* the final release of Qubes 4.0. We
> encourage you to continue diligently testing this fourth release
> candidate so that we can work together to improve Qubes 4.0 before the
> stable release.
> 
> The Qubes 4.0 stable release
> - 
> 
> If the testing of 4.0-rc5 does not reveal any major problems, we hope to
> declare it the stable 4.0 release without any further significant
> changes. In this scenario, any bugs discovered during the testing
> process would be fixed in subsequent updates.
> 
> If, on the other hand, a major issue is discovered, we will continue
> with the standard [release schedule], and Qubes 4.0 stable will be a
> separate, later release.
> 
> Current Qubes 4.0 Users
> - ---
> 
> Current users of Qubes 4.0-rc4 can upgrade in-place by downloading the
> latest updates from the testing repositories in both
> [dom0][dom0-testing] and [TemplateVMs][domU-testing].
> 
> 
> [4.0-rc4]: https://www.qubes-os.org/news/2018/01/31/qubes-40-rc4/
> [closed-issues]: 
> https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed
> [release-notes]: https://www.qubes-os.org/doc/releases/4.0/release-notes/
> [Downloads]: https://www.qubes-os.org/downloads/
> [discover and report bugs]: https://www.qubes-os.org/doc/reporting-bugs/
> [release schedule]: 
> https://www.qubes-os.org/doc/version-scheme/#release-schedule
> [dom0-testing]: 
> https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories
> [domU-testing]: 
> https://www.qubes-os.org/doc/software-update-vm/#testing-repositories
> 
> This announcement is also available on the Qubes website:
> https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqfOjgACgkQ203TvDlQ
> MDD85w/+NXqtxDpaC84CeETA/1/HK6WcbYoNmt1ZjRouKJmmrW2pxyUsYo7vZNsN
> +qgupvvHkE+AFhKuwRrQJq8k6fHPzaY2GWvLpJGQ/bEFqO8fWnrvFzR0OzQb/sYI
> NfRZoSA9lKyt05QJPfxG3aHqAXJeVwslj337arE/lhws6zsVS0zhtHxCyB9w/Wag
> c+YWy2BrWjzujlJZC1SDGFrD0bdd+voD2GTOcUrCSXOP4IxH9ym/VWVtD8O5Tssx
> WIU1qvSumpMaIWN2GsbVIQXqjxv2+AvtNg28neAyAoudpqq4EmX3/ugNe9ngVV0U
> 8wAKGnRAm5keV7tNV48Kqrsd26N95kkB/0U3AYLG5o1ZwTV2dId5ERxj1hkE8/FC
> TDIlFcC3S94N39pUwfMcE0wFr6q8m6Mt7XJdDjII2OCrhxbpgoPRrCeUOH0Vkj5d
> F8VETME1w1taoPjoVIO7jclgaBWChgLLBRjelYUj0fYFIRu3WCQDG1l86ZFWa96q
> qHLBPSdddzMxdj9G2MQFRamv4cmefUHZx9XbDLK5tjZcX8lfKPS96avNg1iAa3x8
> wZGwkk96Lo5MoapH+ZlYde0oTacyssmDSvDw4qmhSAyRbM1TrFlCCtv2TMNkLFHW
> DaN4GgYeh1XSmw0M7fAf/TmBjjKVxz0oMOgaGhjrmK0vmH29C0w=
> =BkQO
> -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/f7ee59a2-1c1a-4a36-b247-9ff71c52e82f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote:
> On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:
> 
> > Let me know if I misunderstood you. I'm still grasping the proper
> > terminology, as well the limits and possibilities of Github, so it might
> > be easy to misunderstand.
> 
> Github is easy for me to misunderstand too. :)
> 
> You had 2 community repos in addition to the official Qubes repo. I'm
> suggesting only 1 community repo with the following settings, and not
> touching the official repo at all. I don't know how to address migrating
> content, so I'm not sure it's a possibility.
> 
> >> - one Github site
> >> - only a single owner permitted
> >> - Wiki with editing permitted to any logged in Github user (your
> >> scratch/development area)
> >> - collaborators by individual Github name
> >> appear to have push/write access to full repo
> >> - Code section could
> >> contain the more formal contents, would have to be a collaborator to
> >> contribute directly or approve submissions
> >> - unclear on how documents
> >> would migrate from here to qubes-doc unless as a copy/paste, but that
> >> would lose attribution and I imagine most would like their own name on
> >> their commit!
> >>

We gotta conquer GitHub! :)

So the suggestion is having all the volunteer stuff on a separate repository, 
but the two sub-set volunteer categories to be separated within that 
repository? Making it more cut and clean etc.?

I believe it should be easy to move between repositories on a local drive, but 
I only experimented with this for a short time the other week, so I'm not 100% 
sure on how it works yet. But essentially we can download all GitHub content to 
our drives, perform changes, and then commit it back up to GitHub again.

I believe this can be done even to GitHub repositories one has no authority 
over, but it'll instead be a, pull request? On the other hand, if one has the 
authority, then it'll immediately change the GitHub content. We can login via 
the terminal too, and keep our GPG keys on a SplitGPG AppVM.

So by having two different repositories on our local drives, it should be as 
simple as copy/paste the whole folder/file structure, or individual 
files/folders, from one repository to another repository?

Maybe this can be done online too on GitHub? But it seems we can do more if 
it's taken down to the drive, another example is changing the Home wiki page, 
which is more flexible if done on the local drive. I think maybe moving between 
the repositories, might be one of those better done on a local machine too?

I'll have to get back to that experimentation sometime soon. Maybe someone else 
can confirm if that is how it works in-between then though?

-- 
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/3d0d5e23-3c17-4076-82ba-803bc90d8d2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote:
> On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:
> 
> > Let me know if I misunderstood you. I'm still grasping the proper
> > terminology, as well the limits and possibilities of Github, so it might
> > be easy to misunderstand.
> 
> Github is easy for me to misunderstand too. :)
> 
> You had 2 community repos in addition to the official Qubes repo. I'm
> suggesting only 1 community repo with the following settings, and not
> touching the official repo at all. I don't know how to address migrating
> content, so I'm not sure it's a possibility.
> 
> >> - one Github site
> >> - only a single owner permitted
> >> - Wiki with editing permitted to any logged in Github user (your
> >> scratch/development area)
> >> - collaborators by individual Github name
> >> appear to have push/write access to full repo
> >> - Code section could
> >> contain the more formal contents, would have to be a collaborator to
> >> contribute directly or approve submissions
> >> - unclear on how documents
> >> would migrate from here to qubes-doc unless as a copy/paste, but that
> >> would lose attribution and I imagine most would like their own name on
> >> their commit!
> >>

Using this guide as a common ground 
https://help.github.com/articles/about-pull-requests/

Pull requests could serve as a trial and testing grounds on a volunteer 
repository? Maybe this is what you meant all along and I misunderstood. But 
that does indeed make it much more simple.

-- 
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/2ba64415-5371-4d66-ab43-569c3783e993%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 11:48 am, Yuraeitha wrote:
> On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote:
>
>> On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:
>>
>>
>>> Let me know if I misunderstood you. I'm still grasping the proper
>>> terminology, as well the limits and possibilities of Github, so it
>>> might be easy to misunderstand.
>>
>> Github is easy for me to misunderstand too. :)
>>
>>
>> You had 2 community repos in addition to the official Qubes repo. I'm
>> suggesting only 1 community repo with the following settings, and not
>> touching the official repo at all. I don't know how to address
>> migrating content, so I'm not sure it's a possibility.
>>
 - one Github site
 - only a single owner permitted
 - Wiki with editing permitted to any logged in Github user (your
 scratch/development area) - collaborators by individual Github name
 appear to have push/write access to full repo - Code section could
 contain the more formal contents, would have to be a collaborator to
  contribute directly or approve submissions - unclear on how
 documents would migrate from here to qubes-doc unless as a
 copy/paste, but that would lose attribution and I imagine most would
 like their own name on their commit!

>
> Using this guide as a common ground
> https://help.github.com/articles/about-pull-requests/
>
>
> Pull requests could serve as a trial and testing grounds on a volunteer
> repository? Maybe this is what you meant all along and I misunderstood.
> But that does indeed make it much more simple.

Yes, one community repo with both a wiki and code section. Everyone with a
Github account could edit the community wiki to collaborate on documents.
Once it's roughly finished, the doc. owner could submit to the (same)
community code repo with a PR (which would require the repo owner or one
of the Collaborators to approve, IIUC). From there, magic would happen and
it would somehow get submitted to the official qubes-doc repo.



-- 
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/38f51eeab6accf3a42154c8ee9e375b0.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: I broke Qubes with template reinstall...

2018-03-07 Thread Tim W
On Tuesday, March 6, 2018 at 1:53:37 AM UTC-5, sevas wrote:
> Reference:
> https://groups.google.com/forum/#!topic/qubes-users/5eJF__5UBAc
> 
> Apparently many people suffer from this problem. 
> After reinstalling the a few dire programs, everything seems to be working.
> Only problem is that the dom0 applications menu is gone. 
> Possible solution here:
> https://groups.google.com/forum/#!topic/qubes-users/lsED7b1qVjw
> 
> Im not messing with it. 
> I reinstalled.
> 
> Qubes Installation media does not (and did not previously) like partitions 
> with things on them. A quik trip over to the bash prompt and a little fdisk 
> and mkfs.ext4 and were right as rain!
> 
> reinstalling templates seem very unstable... Im not doing that .ever. again.


Yes I have always wiped all partitions and do a secure overwrite of all space.  
Sorry forgot about it when I mentioned doing a full reinstall.  I also only 
bkup data not the actual templates for the same issues and possible problems.

-- 
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/0886392b-a602-4c5a-9223-4f81b7fb2694%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Wednesday, March 7, 2018 at 1:37:06 PM UTC+1, awokd wrote:
> On Wed, March 7, 2018 11:48 am, Yuraeitha wrote:
> > On Wednesday, March 7, 2018 at 12:17:09 PM UTC+1, awokd wrote:
> >
> >> On Wed, March 7, 2018 11:06 am, Yuraeitha wrote:
> >>
> >>
> >>> Let me know if I misunderstood you. I'm still grasping the proper
> >>> terminology, as well the limits and possibilities of Github, so it
> >>> might be easy to misunderstand.
> >>
> >> Github is easy for me to misunderstand too. :)
> >>
> >>
> >> You had 2 community repos in addition to the official Qubes repo. I'm
> >> suggesting only 1 community repo with the following settings, and not
> >> touching the official repo at all. I don't know how to address
> >> migrating content, so I'm not sure it's a possibility.
> >>
>  - one Github site
>  - only a single owner permitted
>  - Wiki with editing permitted to any logged in Github user (your
>  scratch/development area) - collaborators by individual Github name
>  appear to have push/write access to full repo - Code section could
>  contain the more formal contents, would have to be a collaborator to
>   contribute directly or approve submissions - unclear on how
>  documents would migrate from here to qubes-doc unless as a
>  copy/paste, but that would lose attribution and I imagine most would
>  like their own name on their commit!
> 
> >
> > Using this guide as a common ground
> > https://help.github.com/articles/about-pull-requests/
> >
> >
> > Pull requests could serve as a trial and testing grounds on a volunteer
> > repository? Maybe this is what you meant all along and I misunderstood.
> > But that does indeed make it much more simple.
> 
> Yes, one community repo with both a wiki and code section. Everyone with a
> Github account could edit the community wiki to collaborate on documents.
> Once it's roughly finished, the doc. owner could submit to the (same)
> community code repo with a PR (which would require the repo owner or one
> of the Collaborators to approve, IIUC). From there, magic would happen and
> it would somehow get submitted to the official qubes-doc repo.

It seems like a good way to do it, I like it. What does others think about it? 
It might be a good idea to have some finished thoughts / discussions ready for 
Andrew, it'd be inhuman to expect him to read everything (it's a lot to read). 
Does anyone disagree with the idea of making an initial first step with a 
second repository with an associated Community doc page, as discussed? We can 
always look at forums and other platforms later on, it's probably best not to 
do everything at once, especially now when the Qubes staff is busy, it might be 
best to start where the least work is needed from the Qubes staff. A second 
repository and assigning volunteer moderator(s) should be straight forward less 
than 5 minutes task (This is assuming this is also approved by the Qubes staff 
of course).

-- 
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/cbd1f82c-c611-45a1-836f-03259b3370ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Cannot copy installation image to USB

2018-03-07 Thread 'awokd' via qubes-users
On Wed, March 7, 2018 10:02 am, Zbigniew Łukasiak wrote:
> I tried two usb sticks with 16GB and 64GB and on both I was getting this:
>
>
> user@personal:~/Downloads$ sudo dd if=Qubes-R4.0-rc5-x86_64.iso
> of=/dev/xdvi && sync dd: writing to ‘/dev/xdvi’: No space left on device
> 2891865+0 records in
> 2891864+0 records out
> 1480634368 bytes (1.5 GB) copied, 13.1412 s, 113 MB/s
>
>
> That was on a debian VM.
>
>
> I solved that problem for me by using my ubuntu machine - but
> reporting just in case.

"xdvi" is likely a typo and the cause of your problem- "xvdi" is more
typical.

-- 
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/084678680e41fddc024e45e0459a79c8.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HCL - Dell Precision M6800

2018-03-07 Thread 1xabbu
Dear Richard,

did you try to install Qubes 4.0-rc5?
If so, is it full working?

Kind regards,
Sören

-- 
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/0a383d85-d8fb-417c-bedc-814e147c9925%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] DNS propagation in Qubes

2018-03-07 Thread Micah Lee
I'm trying to make all DNS requests in Qubes go over TLS (more information 
about this [1]).

I've got this successfully working in sys-net by running a local DNS server on 
udp 53 that forwards DNS requests to a remote DNS server over TLS, and then 
setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed 
that this works great in sys-net -- all of my DNS requests are encrypted to my 
remote DNS server, and none are plaintext.

The problem is when I do this, DNS in other downstream VMs all fail. The Qubes 
networking docs [2] explain how DNS works in Qubes, but I'm confused about how 
to make this set up work. Any ideas? Thanks!

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/

​​


-- 
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/9XVz-7viQEqd-6MPx8NvR4Fnk502VgBDJUYogFE056xaFr-k76ApY7WmEbi3oH6yQZQ7MEHbuqYbwCZInJ8LE9lysw_e3w8Dw93FrISL2hU%3D%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.