Re: [qubes-users] Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-09 Thread Catacombs
Which side are you.   Techi Geek type?   Or some type Investigator?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/17bd2d1a-f9fa-4fbf-9211-13d21d95297e%40googlegroups.com.


Re: [qubes-users] Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-09 Thread Steve Coleman
On Fri, May 8, 2020 at 7:13 PM Catacombs  wrote:

> A Journalist or a Human Rights investigator, I think are more comfortable
> with ease of use, not secure.
>

There is always a trade-off between security and usability for sure. One
trade-off for the non geek users is to enable networking in the software
template so that you can run the "Software" application to pick and choose
your required desktop applications.  The journalist may not know how to use
DNF at the command line but the Software installer will clearly let them
pick and choose from several decent word processors. If only the Software
application used the same proxy method to search the repository for
packages then turning on the networking would not be necessary. The average
desktop user would have a much easier time installing what they need.

The main thing for them to *not do* is to run any applications in the
template VM itself. Never test things in the template unless you absolutely
need to pre-configure something, and if so, do it with networking turned
off if you have that choice. Clearly this is not easy for a non-geek, but
it can be made a little easier.

So, I bet this has been talked about before.  As I was doing the upgrade to
> Fedora 31, I realized a Journalist is not likely to be very happy doing
> that.  After that, I had to search to find a Text Editor, (Gedit is what I
> used)  A Journalist would expect that the things
>

LibreOffice is what you want for journalists.

Then I tried to watch a Video.   Gee guys, a Journalist just expects this
> stuff to work.  I , on the other hand, am concerned our mythical
> investigator not realizing the possible security implications of opening
> what kind of app, when.
>

If you enable rpmfusion repos you will be able to access more video codecs,
but again that is a security trade-off.

What you can do is have one template with all the DRMed codecs providing
for one or two AppVMs or DVMs that can run the videos, while keeping the
remaining AppVMs for investigations more secure without all the extra risky
additions. You just have to train them how to open the video URLs in one of
the special VMs.


Tech people do not think like Journalists of Human Rights Workers, nor vice
> versa.
>

Perhaps not, but very likely we are trainable.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAJ5FDnh2HXSmn1CZM%3D7DN9McvtTWUHw%2BcEtVRGeQa_f68bpFyA%40mail.gmail.com.


[qubes-users] Re: Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-09 Thread pixel fairy
You should look up Micah Lee. He's a journalist and programmer with a 
strong interest in privacy. Here is his yt 
https://www.youtube.com/channel/UCOslhuBKMmHrk_iHc0rgYuw

On Friday, May 8, 2020 at 4:12:57 PM UTC-7, Catacombs wrote:
>
> To be clear, the folks who have put together and developed QUBE's have 
> done a fantastic job.  A great accomplishment.   
>
> I bet this has been discussed before.   Much of what I have experienced is 
> that QUBE's users should be more like techy geeky people.  A Journalist or 
> a Human Rights investigator, I think are more comfortable with ease of use, 
> not secure.  
>
> So, I bet this has been talked about before.  As I was doing the upgrade 
> to Fedora 31, I realized a Journalist is not likely to be very happy doing 
> that.  After that, I had to search to find a Text Editor, (Gedit is what I 
> used)  A Journalist would expect that the things he/she does all the time 
> would be right there, ready for use.   I would think a Journalist would 
> have 12 different ongoing projects, which he might realize should be in 
> separate QUBE's, and might not have the presence of memory to realize what 
> to save, where, something an investigator would need to do often.   I would 
> think the investigator might not realize to create a number of encrypted 
> partitions, to further protect information distinct to a particular, 
> specific investigation.
>
> Then I tried to watch a Video.   Gee guys, a Journalist just expects this 
> stuff to work.  I , on the other hand, am concerned our mythical 
> investigator not realizing the possible security implications of opening 
> what kind of app, when.
>
> It is not my intention to provide a list of things to put in the basic OS 
> for an Investigator who is not what I would term, a techno geek, nor who 
> does not want to be.  It is to find out what has been discussed in the past 
> about this subject, and for some of you, who are more experienced with 
> QUBE's, and investigators, to put that list together, and perhaps build 
> that list into the basic Install of QUBE's.   
>
> Once again, I deeply respect what the QUBE's developers have 
> accomplished.  So this is not intended as a criticism of the folks who have 
> put in thousands of hours getting this project to this point.  Thank you 
> for what you have done.  
>
> Tech people do not think like Journalists of Human Rights Workers, nor 
> vice versa.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6df85b9e-1e7d-487b-beec-18aedb4ccd4c%40googlegroups.com.


Re: [qubes-users] Re: HCL - Latitude E6230

2020-05-09 Thread rkd777

Kaleb

Here's what I have done so far and should get you started down the right 
road while I figure out the rest.

Disable Wireless card and Secure Boot in BIOS
Use the Ethernet port to install
All is setup and works perfect this way and allows you to install and 
upgrade needed packages later
Update all the qubes and the system
I plan to backup the state it's in before continuing

I haven't completed this yet but I've figured out a lot of it
The wireless can now be reenabled in BIOS
It must be attached to the correct qube (internet qube) with the qvm-pci 
command (it seems to need the --permissive setting when doing this)
My chip is the Broadcom BCM43228 
>From what I can tell so far it may need the firmware files to be added to 
/lib/firmware/
And the b43 driver
Folllow these links:
https://wireless.wiki.kernel.org/en/users/drivers/b43
http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/#firmware
https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx#b43%20-%20No%20Internet%20access
https://launchpad.net/ubuntu/+source/b43-fwcutter
You should be close to getting it sorted with that info although I haven't 
got there yet,




On Thursday, May 7, 2020 at 2:36:21 PM UTC+1, Kaleb C Tilley wrote:
>
> rkd777,
>
> I'm beginning to think that the embedded NIC for the system I purchased 
> doesn't match the embedded link used to verify this architecture as valid 
> for the QubesOS.  I feel as if I've wasted my money on this one .. oh well 
> .. :-(
>
> Kaleb
>
> --
> Age doesn't always bring Wisdom...
> ... Sometimes Age comes alone.
>
>
> On Wed, May 6, 2020 at 7:56 PM > wrote:
>
>>
>> I am hanging at network as well...any advice appreciated
>>
>>
>> On Sunday, November 17, 2019 at 9:29:35 PM UTC, cany...@gmail.com wrote:
>>>
>>> Mike,
>>>
>>> I'm just starting to attempt loading Qubes4.8 onto a Dell Latitude 
>>> E6230.  It installs up to the point where it reboots onto the disk install, 
>>> and continues building the qube VMs.  At that point, it eventually hangs .. 
>>> apparently while configuring the network.  I think there may be an issue in 
>>> detecting the network device.  Did you have any difficulties during your 
>>> install?
>>>
>>> Thanks for any assistance you can provide.
>>>
>>> Kaleb
>>>
>>> On Saturday, June 2, 2018 at 1:47:26 AM UTC-4, Michael McShane wrote:

 AEM was a difficult only because I had a 128gb SSD but it configured 
 anyway. Everything just works.
 Mike

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "qubes-users" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/qubes-users/7ktqAG6Up3U/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> qubes...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/qubes-users/2017f159-6696-456d-923f-d424fc3c08af%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8e4990a1-c441-438c-9740-b158bdad128b%40googlegroups.com.


Re: [qubes-users] Qubes better dove tailed for Journalists, and Human Rights Workers.

2020-05-09 Thread donovang
- On May 9, 2020, at 4:02 PM, Steve Coleman  
wrote: 

> On Fri, May 8, 2020 at 7:13 PM Catacombs < ggg...@gmail.com > wrote:

>> A Journalist or a Human Rights investigator, I think are more comfortable 
>> with
>> ease of use, not secure.

> There is always a trade-off between security and usability for sure. One
> trade-off for the non geek users is to enable networking in the software
> template so that you can run the "Software" application to pick and choose 
> your
> required desktop applications. The journalist may not know how to use DNF at
> the command line but the Software installer will clearly let them pick and
> choose from several decent word processors. If only the Software application
> used the same proxy method to search the repository for packages then turning
> on the networking would not be necessary. The average desktop user would have 
> a
> much easier time installing what they need.

> The main thing for them to *not do* is to run any applications in the template
> VM itself. Never test things in the template unless you absolutely need to
> pre-configure something, and if so, do it with networking turned off if you
> have that choice. Clearly this is not easy for a non-geek, but it can be made 
> a
> little easier.

>> So, I bet this has been talked about before. As I was doing the upgrade to
>> Fedora 31, I realized a Journalist is not likely to be very happy doing that.
>> After that, I had to search to find a Text Editor, (Gedit is what I used) A
>> Journalist would expect that the things

> LibreOffice is what you want for journalists.

>> Then I tried to watch a Video. Gee guys, a Journalist just expects this 
>> stuff to
>> work. I , on the other hand, am concerned our mythical investigator not
>> realizing the possible security implications of opening what kind of app, 
>> when.

> If you enable rpmfusion repos you will be able to access more video codecs, 
> but
> again that is a security trade-off.

> What you can do is have one template with all the DRMed codecs providing for 
> one
> or two AppVMs or DVMs that can run the videos, while keeping the remaining
> AppVMs for investigations more secure without all the extra risky additions.
> You just have to train them how to open the video URLs in one of the special
> VMs.

>> Tech people do not think like Journalists of Human Rights Workers, nor vice
>> versa.

> Perhaps not, but very likely we are trainable.

There are some that are both tech and investigators. I personally found Qubes 
to be a solution I wish I had found long before I did. In fact, for me it was 
easier to move from Windows (and DOS before that) to Linux as my primary work 
environment via Qubes rather than just a standalone linux box or VM because it 
provided two solutions in one - move away from Windows and provide multiple 
more secure and isolated environments for my work. The technology landscape and 
associated threat vectors are very fluid and Qubes is part of the foundation 
for dealing with that. I even go so far as to suggest that Qubes should 
actually be the default OS for any computer user, but that is unrealistic of 
course. 

I cringe at the occasional post that suggests or implies that Qubes is 
difficult. My background is almost exclusively M$ with the odd *nix appliance 
thrown in, hardly the foundation for moving essentially cold-turkey to Qubes 
that, for me, is based on an unfamiliar hypervisor and linux vms. It is a tool, 
albeit one that is a bit specialized to emphasize security. And like any tool, 
you have to learn how to use it to maximize its intended purpose. It's not 
rocket surgery or brain science, but it's also not a toaster. That said, I 
personally feel that moving to LibreOffice and Thunderbird in the Windows 
environment many years ago made the transition much easier and more familiar. 
My prior profession also required that I maintain some level of proficiency at 
the command/terminal prompt. That can be a big hurdle for people considering 
the transition to Qubes from Windows. That said, I still struggle with some 
tasks in Linux for which I have not developed any "muscle memory" for - yet. 
But it gets easier daily. 

I see a lot of posters attempting to use Qubes in much the same manner as they 
might a standalone box and sometimes with less than sterling results. All of 
that adds to the knowledge base of Qubes, but everything that I have read tells 
me that being a reasonably secure OS on a computer in a connected, 
information-centric production environment (as in, making a living) is the 
primary purpose for its creation. It serves that purpose well in my view. It'll 
likely not be a gaming box, a screaming video or CAD rendering beast or even 
support bleeding-edge hardware. 

Qubes is a serious tool in the very serious and uncompromising world where the 
bar for what is considered dangerous information is lowered on a daily basis. 

-- 
You received this message because you are subscribed to the 

Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread unman
On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:
> Just shutdown a qube. Not my PC
> 
> On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:
> > 
> > On 2020-05-09 13:05, Logan wrote:
> > > Is there a way to configure Qubes so that when I close the last AppvM 
> > > belonging to a TemplateBasedVM/Domain it auto shuts down?
> > By auto shuts down you mean poweroff your computer?
> > 
> > I think it's pretty easy to do it by writing your own Qubes core-admin 
> > addon extension. I would write function catching domain shutdown and 
> > looking if it remains running VM else poweroff.
> > 
> > Here are examples of core-admin addon extension: 
> > https://github.com/QubesOS/qubes-core-admin-addon-whonix 
> > https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device
> > > I have been dreaming of this for some time but haven't been able to find 
> > > a solution.
> > > 
> > > Logan
> > > 
> > Fr??d??ric
> > 


The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

I'm not clear on what you want to do - do you mean shutdown a qube when
the last *window* is closed? You can use `qubes-app-shutdown-idle` for
that.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200509122009.GB3908%40thirdeyesecurity.org.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Mike Keehan

On 5/9/20 1:20 PM, unman wrote:

On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:

Just shutdown a qube. Not my PC

On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:


On 2020-05-09 13:05, Logan wrote:

Is there a way to configure Qubes so that when I close the last AppvM belonging 
to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device

I have been dreaming of this for some time but haven't been able to find a 
solution.

Logan


Fr??d??ric




The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

I'm not clear on what you want to do - do you mean shutdown a qube when
the last *window* is closed? You can use `qubes-app-shutdown-idle` for
that.

unman



What is that?  dnf list doesn't show it, and neither does qvm-prefs.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3badfe64-578d-d566-d569-ffb977b9c454%40keehan.net.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread unman
On Sat, May 09, 2020 at 01:44:10PM +0100, Mike Keehan wrote:
> On 5/9/20 1:20 PM, unman wrote:
> > On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:
> > > Just shutdown a qube. Not my PC
> > > 
> > > On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:
> > > > 
> > > > On 2020-05-09 13:05, Logan wrote:
> > > > > Is there a way to configure Qubes so that when I close the last AppvM 
> > > > > belonging to a TemplateBasedVM/Domain it auto shuts down?
> > > > By auto shuts down you mean poweroff your computer?
> > > > 
> > > > I think it's pretty easy to do it by writing your own Qubes core-admin 
> > > > addon extension. I would write function catching domain shutdown and 
> > > > looking if it remains running VM else poweroff.
> > > > 
> > > > Here are examples of core-admin addon extension: 
> > > > https://github.com/QubesOS/qubes-core-admin-addon-whonix 
> > > > https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device
> > > > > I have been dreaming of this for some time but haven't been able to 
> > > > > find a solution.
> > > > > 
> > > > > Logan
> > > > > 
> > > > Fr??d??ric
> > > > 
> > 
> > 
> > The convention here is not to top-post.
> > Please scroll to the bottom of the message before you start typing. Or
> > reply inline.
> > It only takes you seconds, makes it much easier to follow threads, and
> > cumulatively saves your fellow users hours.
> > 
> > I'm not clear on what you want to do - do you mean shutdown a qube when
> > the last *window* is closed? You can use `qubes-app-shutdown-idle` for
> > that.
> > 
> > unman
> > 
> 
> What is that?  dnf list doesn't show it, and neither does qvm-prefs.
> 

In Fedora, it's qubes-idle.
1. In a fedora-31 template type "sudo dnf install qubes-idle"
1b. In a Debian template type "sudo apt install qubes-app-shutdown-idle"
2. Create a Template based qube called "shutdown"
3. Shutdown's "Qubes Setting" -> Services -> Type "shutdown-idle" in the bar 
and click on +
4. Open a terminal in the qube called 'shutdown' and close it.
6. After 15 minutes (without any windows open) the qubes 'shutdown' should 
automatically shutdown :-)


You can check the service is running by :
`ps aux | grep qubes-idle-watcher`

The timeout is set at default 15 mins in:
/usr/lib/python3/dist-packages/qubesidle/idleness_monitor.py
You can change the default as you wish - you'll need bind-dirs to alter
this on a per qube basis

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200509141742.GA4433%40thirdeyesecurity.org.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Frédéric Pierret


On 2020-05-09 13:05, Logan wrote:
> Is there a way to configure Qubes so that when I close the last AppvM 
> belonging to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device
 
> I have been dreaming of this for some time but haven't been able to find a 
> solution.
> 
> Logan
> 

Frédéric

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0c445039-8c32-e93d-a26c-c35d524846b1%40qubes-os.org.


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Making AppVMs Open in Specific Workspaces

2020-05-09 Thread unman
On Sat, May 09, 2020 at 07:28:37AM +0200, airelemental via qubes-users wrote:
> You can install devilspie2 in dom0 (available from fedora repos).
> 
> > AppVMs of Domain 1 (Personal) always open in Workspace 2
> 
> vm = get_window_property("_QUBES_VMNAME")
> if (vm == 'personal') then
>  set_window_workspace(2)
>  change_workspace(2)
>  focus_window()
> end
> 
> May 8, 2020, 15:19 by lo...@threatmodel.io:
> 
> > Is it possible to specify a particular workspace for each domain/qube ?
> >
> > Example:
> >
> > AppVMs of Domain 1 (Personal) always open in Workspace 2
> > AppVMs of Domain 2 (Anon-Whonix) open in Workspace 3
> >
> > I have tried setting XFCE profiles without any success. The apps reopen as 
> > expected, but all get glommed together in Workspace 1 when I login again.
> >
> > Thanks,
> > Logan
> >

The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.
Thanks.

If you use KDE you can leverage KDE Applications and win rules to enforce
exactly this behaviour. 
Create Applications under KDE, Right click on Window Title Bar, and
select More Actions -> Special Window Settings.
You can match window by substring, and force such Windows to appear in
specific Applications.

Each Application also has a specific UUID, and it's therefore simple to
use that in scripts to change to the Application, before opening relevant
window.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200509121601.GA3908%40thirdeyesecurity.org.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Mike Keehan

On 5/9/20 3:17 PM, unman wrote:

On Sat, May 09, 2020 at 01:44:10PM +0100, Mike Keehan wrote:

On 5/9/20 1:20 PM, unman wrote:

On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:

Just shutdown a qube. Not my PC

On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:


On 2020-05-09 13:05, Logan wrote:

Is there a way to configure Qubes so that when I close the last AppvM belonging 
to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device

I have been dreaming of this for some time but haven't been able to find a 
solution.

Logan


Fr??d??ric




The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

I'm not clear on what you want to do - do you mean shutdown a qube when
the last *window* is closed? You can use `qubes-app-shutdown-idle` for
that.

unman



What is that?  dnf list doesn't show it, and neither does qvm-prefs.



In Fedora, it's qubes-idle.
1. In a fedora-31 template type "sudo dnf install qubes-idle"
1b. In a Debian template type "sudo apt install qubes-app-shutdown-idle"
2. Create a Template based qube called "shutdown"
3. Shutdown's "Qubes Setting" -> Services -> Type "shutdown-idle" in the bar 
and click on +
4. Open a terminal in the qube called 'shutdown' and close it.
6. After 15 minutes (without any windows open) the qubes 'shutdown' should 
automatically shutdown :-)


You can check the service is running by :
`ps aux | grep qubes-idle-watcher`

The timeout is set at default 15 mins in:
/usr/lib/python3/dist-packages/qubesidle/idleness_monitor.py
You can change the default as you wish - you'll need bind-dirs to alter
this on a per qube basis

unman


Thanks unman!

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/54f64b63-18fe-3f03-29c6-09ce211fad7f%40keehan.net.


[qubes-users] Consider making tax deductable donations possible in the EU

2020-05-09 Thread Lorenzo Lamas
Whonix Project has partnered up with the CCT (Center for the Cultivation of 
Technology, which is a charitable non-profit host organization in Germany 
for international Free Software projects.)
This makes it possible for all EU citizens to deduct donations from 500 EUR 
and up from their taxes. If Qubes project does the same, it may result in 
more donations for the project.

 
https://forums.whonix.org/t/european-union-eu-wide-tax-deductible-donations-to-whonix-are-now-possible/9389
https://www.whonix.org/wiki/Donate/Tax-Deductible

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/01c2cd56-e4bc-4043-9ec2-61c8abafa422%40googlegroups.com.


[qubes-users] Using Zoom in Qubes

2020-05-09 Thread malalasilva via qubes-users
Hi!
Qubes 4.'0 is a really amazing piece of software. Even though I feel absolutely 
safe, I can still do pretty much the same as with an unprotected system.
The only thing I cannot do is screen sharing in Zoom. Screen sharing works fine 
in MS Teams, but on Zoom the shared sceed turns white, and only the zoom 
buttons appear. Everithing else is not shown. If I drag a window to the screen, 
it is not shown. The system resumes its normal behaviour when I stop sharing.
Has anyone had this problem? How can I solve it?

Regards!

-- 
 Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: 
 https://tutanota.com

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/M6ulBnr--3-2%40tutanota.com.


Re: [qubes-users] Kali rolling template can't find source to update.

2020-05-09 Thread unman
On Fri, May 08, 2020 at 06:18:43PM +, Logan wrote:
Screeds and screeds of horrible HTML- any chance you can just send
plain text?

>   Hit:6  href="https://deb.qubes-os.org/r4.0/vm;>https://deb.qubes-os.org/r4.0/vm 
> bullseye-securitytesting
>   InRelease
>   Err:7  href="http://deb.debian.org/debian-security;>http://deb.debian.org/debian-security
>  bullseye Release
>   ?? 404?? Not Found [IP: 127.0.0.1 8082]

404 tells you page not found - so you should be inspecting the sources
list to see what's wrong.

The Debian announcement of this change (referred to IN THE MESSAGE YOU
QUOTED) said - 


over the last years we had people getting confused over -updates
(recommended updates) and /updates (security updates). Starting
with Debian 11 "bullseye" we have therefore renamed the suite including
the security updates to -security.

An entry in sources.list should look like

deb http://security.debian.org/debian-security bullseye-security main



That isn't what you have - but I'm guessing you blindly applied a sed
command without trying to understand what it was doing, or what effect
it 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20200509120430.GA3834%40thirdeyesecurity.org.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Logan

Just shutdown a qube. Not my PC

On 5/9/20 12:09 PM, Frédéric Pierret wrote:


On 2020-05-09 13:05, Logan wrote:

Is there a way to configure Qubes so that when I close the last AppvM belonging 
to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device
  

I have been dreaming of this for some time but haven't been able to find a 
solution.

Logan


Frédéric



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d5e62be-c2e0-4f34-bb4a-246c3deb7f67%40threatmodel.io.


publickey - logan@threatmodel.io.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature


[qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Logan
Is there a way to configure Qubes so that when I close the last AppvM 
belonging to a TemplateBasedVM/Domain it auto shuts down?


I have been dreaming of this for some time but haven't been able to find 
a solution.


Logan

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/182b32a3-367a-6681-5d4c-675c068d742d%40threatmodel.io.


publickey - logan@threatmodel.io.asc.pgp
Description: application/pgp-key


signature.asc
Description: OpenPGP digital signature