On Wed, Nov 27, 2019 at 08:16:28AM -0500, Steve Coleman wrote:
You can try this trick when starting your app/vm:
dom0> qvm-run -a AppVM "resource-heavy-app;shutdown -h now"
When the application closes the next command in line is the shutdown
command, and the VM will simply exit. As long as
DispVMs shut down automatically when the launched application closes.
Is it possible to enable this for certain applications in certain AppVMs
as well?
For example I may not want my "resource-heavy-apps-vm" to keep running
after MemoryHungryApp closes, because that ties up half my system RAM.
On Tue, Nov 26, 2019 at 01:05:08PM -0800, Lambda wrote:
Lenovo's 2019 laptop is currently on sale and their CPU selection[1]
includes:
- i7-9750H: no vPro, No Out-of-Band Systems Management
- i7-9850H: vPro, Intel ME Disabled
[--]
I'm aware that for AEM support I would need to have ME and
On Thu, Nov 21, 2019 at 04:12:25AM +0100, tetrahedra via qubes-users wrote:
The built-in Qubes backup functionality is great but it's very easy to
forget to run a backup and end up going days (or weeks, or months...)
without it.
MacOS has a handy feature where it will remind you if it has been
After creating an AppVM, I experimented with making it (the basis of) a
disposable VM, but then un-did the settings and went back to using it as
a regular AppVM.
Unfortunately it's still showing up in the applications launcher menu as
a Disposable VM, and the menu items no longer work for
On Thu, Nov 21, 2019 at 10:04:59AM -0500, Steve Coleman wrote:
However, I am stuck on how to determine how many days it has actually
been since the last backup.
What you are looking for is this command:
qvm-prefs --get $vm backup_timestamp
Perfect, thank you!
--
You received this message
The built-in Qubes backup functionality is great but it's very easy to
forget to run a backup and end up going days (or weeks, or months...)
without it.
MacOS has a handy feature where it will remind you if it has been more
than 10 days since your last backup.
This would be great to have in
On Fri, Nov 01, 2019 at 06:36:20PM -0400, 'Micah Lee' via qubes-users wrote:
In case anyone is interested, I just wrote a blog post about how I
configure Mullvad in Qubes, using NetworkManager, a script to
auto-connect, and the Qubes firewall.
On Thu, Oct 31, 2019 at 11:47:31AM +, Claudia wrote:
There is also the possibility of a physical attacker booting their
own OS that pretends to be your FDE lock prompt as a way to steal
your passphrase.
This all depends on the scenario. Specifically, it assumes an evil
maid attack, where
From Ratliff's "The Mastermind":
"...they were told to close the computer immediately. The TrueCrypt
software would be activated as soon as the laptop lid was shut."
While most Qubes users are probably not interested in starting global
criminal empires, this specific idea seems useful enough.
Expected behavior:
choosing "Disposable: whonix-ws-15 dvm" | Xfce Terminal from the
applications menu opens a terminal window in a new DispVM
Actual behavior:
terminal opens in the whonix-ws-15-dvm template (equivalent to qvm-run
-a)
did I miss something somewhere, or is this a bug?
--
You
On Sun, Oct 20, 2019 at 01:28:29PM +0900, Jin-oh Kang wrote:
I'll submit the correction PR when I get to have some free time for it. I
apologize for not having made this clear. Meanwhile if you'd like to do it
instead -- since you're also the author of the article -- then I'd
appreciate it ;)
On Thu, Oct 17, 2019 at 01:24:00PM -0700, Jin-oh Kang wrote:
The escape sequence crippling is caused by
https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.8/patch-tools-xenconsole-replace-ESC-char-on-xenconsole-outp.patch
, which is reasonable given the Qubes security model.
For interactive
On Thu, Oct 17, 2019 at 01:06:24PM -0700, Jin-oh Kang wrote:
This is what I see from your output:
https://asciinema.org/a/2sMvgiISVELkjTxAjDlfoNP5Z
That's really cool!
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this
On Thu, Oct 17, 2019 at 04:58:00AM +, 'awokd' via qubes-users wrote:
In Qube Settings, is the kernel set to None? If not, it boots from a
kernel provided by Qubes anyways so you don't need grub in that case. It
might be a good idea to qvm-copy out anything you need while you still
can, in
As a result of some issues in a standaloneVM (debian-9), I ended up
using the Xen hypervisor serial console to migrade to debian-9-testing --
part way.
Sadly the hypervisor console does NOT support curses-style modal dialog
boxes, and the process of updating GRUB involves navigating one of
Dom0 device notifications (same style as when attaching a USB stick)
keep popping up, along the lines of:
/tmp/sanity-squashfs-290* (deleted) is available
/tmp/sanity-squashfs-290* (deleted) is removed
As far as I know there is no update process running in the background.
journalctl in dom0
On Sun, Oct 13, 2019 at 01:39:42PM +0100, unman wrote:
The settings are stored in .config/dconf
Configure the template.
Copy .config/dconf to /etc/skel in the template.
Now every new appVM you create will inherit your configuration.
Perfect, just what I wanted.
Added an issue to get this put
Common scenario:
1) create new appVM
2) open terminal
3) "oh no, the color scheme and font and terminal settings are all wrong"
4) spend some time clicking around in menus fixing it
Is there a way to create a template-wide default gnome-terminal profile?
(The terminal profile that I set in the
On Fri, Oct 11, 2019 at 05:44:26PM +0200, tetrahedra via qubes-users wrote:
After the latest round of updates I have started seeing some odd
behavior: VMs will only start once per system boot. This is rather a
problem (it makes Qubes much less usable!), should I also add it to the
Github tracker
After the latest round of updates I have started seeing some odd
behavior: VMs will only start once per system boot. This is rather a
problem (it makes Qubes much less usable!), should I also add it to the
Github tracker?
Further details: After a VM has been shut down, when I try to start it
On Tue, Oct 08, 2019 at 08:26:34PM -0500, Andrew David Wong wrote:
Are you, by any chance, copying into Vi/Vim? That sort of thing happens
when you have "smart indentation" (or similar) enabled in Vim.
Ah, yes, that would explain it. Thanks!
--
You received this message because you are
When copying from AppVM to AppVM, tabs and/or spaces often get mangled
(additional tabs/spaces inserted).
For example, if I have a block of text in one AppVM that looks like:
def my_function():
msg = "foo"
othermsg = "bar"
print(msg + othermsg)
When I Ctrl-C (or Ctrl-Insert) and
On Mon, Sep 30, 2019 at 04:15:26PM +, Claudia wrote:
To make sure IsolateClientAddr is working (as opposed to
IsolateSOCKSAuth), you can run
curl.anondist-orig https://check.torproject.org
in two different whonix-ws VMs at the same time, and make sure they
output different addresses. You
On Mon, Sep 30, 2019 at 04:34:58PM +0200, tetrahedra via qubes-users wrote:
I am trying to duplicate a previously-successful configuration of a
Debian based ProxyVM/'provides network' VM.
However with the new VM (call it proxy2) the client VMs are
unable to reach the proxy (ping returns
On Thu, Sep 26, 2019 at 10:09:04AM -0500, Sven Semmler wrote:
My understanding is that TOR actually runs in the gateway and the the workstation(s) enable typical Qubes style compartmentalization. Meaning that if app-anon-1 is compromised, the sys-whonix and a potential app-anon-2 are not. When I
On Mon, Sep 30, 2019 at 08:05:44AM +, Claudia wrote:
Glad to hear it's working. I guess I should have asked at the
beginning... What brought you to the conclusion they were using the
same circuits? I assumed you were using check.torproject.org or
another "what is my IP" site, but if
I am trying to duplicate a previously-successful configuration of a
Debian based ProxyVM/'provides network' VM.
However with the new VM (call it proxy2) the client VMs are
unable to reach the proxy (ping returns 'Destination Host Unreachable').
The proxy2 VM only shows two network interfaces in
On Sun, Sep 29, 2019 at 02:42:29PM +, Claudia wrote:
You can try viewing your active tor settings in Nyx (preinstalled in
Whonix) rather than from torrc directly. Just in case some setting is
being overridden or something like that. See
https://www.whonix.org/wiki/Tor_Controller and
On Fri, Sep 27, 2019 at 01:37:06PM +, Claudia wrote:
Isolating apps in the same VM is a different issue, but you're saying
traffic from different VMs is appearing to come from the same address?
Hmm, that definitely should not be happening. VM isolation is enabled
out of the box. Different
On Wed, Sep 25, 2019 at 11:32:20PM +, 'awokd' via qubes-users wrote:
Sven Semmler:
On 9/25/19 5:26 PM, 'Jackie' via qubes-users wrote:
even different applications within the same vm, will use different tor circuits.
I know this is true of apps that come with whonix-ws, but is it the
On Sun, Sep 22, 2019 at 02:51:00PM +, 'awokd' via qubes-users wrote:
tetrahedra via qubes-users:
Is there any way to automatically do stream isolation on a per-VM basis?
Right now it appears this is not necessarily the case -- the network
traffic of AppVMs A and B may end up using
Is there any way to automatically do stream isolation on a per-VM basis?
For example:
I start AppVM "A", with networking via Whonix, and interact with the
internet as "Alice"
I start AppVM "B", with networking via Whonix, and interact with the
internet as "Bob"
Naturally I want Alice to
I start working on a project with some untrusted data in a DispVM.
Then I decide the project is bigger or going to take longer than anticipated
and I need to keep the DispVM around, so I don't lose my work prematurely.
Is there a way to turn currently-running DispVM instance into a regular
The docs on template reinstallation indicate that QSB 050 means it is
not safe to automatically reinstall templates:
https://www.qubes-os.org/doc/reinstall-template/
However QSB 050 suggests that patches were pushed out some time ago:
https://www.qubes-os.org/news/2019/07/24/qsb-050/
Indeed
On Fri, Sep 06, 2019 at 09:00:00AM +, Patrick Schleizer wrote:
panina:
On 8/9/19 9:05 AM, Patrick Schleizer wrote:
panina:
Namely, they removed NoScript from the toolbar, so that the
NoScript cannot be used as intended.
We did not. Decision by upstream, The Tor Project.
101 - 136 of 136 matches
Mail list logo
