Re: [qubes-users] Feedback request: Incremental file-based backup PoC

[Vít Šesták]

> It almost sounds like you're trying to supply data to the attacker

Good point. I'll rephrase it. Maybe the following is more reasonable:

* Attacker having access to your storage can learn how many VMs you have and 
limited metadata for each VM (see below). They however cannot learn VM names, 
lenghts of VM names (thanks to padding to constant length) or similarities in 
VM names like common prefix (thanks to synthetic IV).
* If attacker with access to your backup storage can store significant amount 
of data to one VM, she will be able to determine what files belong to the 
particular VM.
* Amount of metadata attacker can see for one VM depends on the backup backend. 
With Duplicity, they include backup timestamps and GPG-related metadata.

Ad backups cannot be pruned: You are right, but since even restore is not yet 
implemented, I don't see much point of mentioning prune in limitations. And 
prune seems to be much easier to implement.

Ad performance: This does not correspond to my experience, but you are not the 
first complaining about Duplicity performance, so I'll mention it.

Regards,
Vít Šesták 'v6ak'

-- 
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/5b14261e-1ae4-486f-afe1-8abbab537603%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can somebody explain me how install flux on Qubes OS 3.2 in a fedora Template ?

[Vít Šesták]

You can pass your approximate location to redshift-gtk parameters, which 
eliminates need for geoclue. Of course, this is not going to work well when 
travelling much…

-- 
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/4a4e275c-af2d-4bc0-b48a-35ab3e6243d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Feedback request: Incremental file-based backup PoC

[Chris Laprise]

On 02/26/2017 05:07 PM, Vít Šesták wrote:

Hello,
I'd like to announce my PoC for incremental file-based backup for Qubes VMs. It 
is not a completely new backup system, it just wires together some existing 
software with Qubes principles to provide convenient and secure way to backup 
many VMs with minimum overhead and encrypt them by one password. I have tried 
hard not to expose dom0 to untrusted inputs from VMs. Design is described in 
README, though I will probably break README to multiple parts. Sources are here:

https://github.com/v6ak/qubes-incremental-backup-poc/

Now, I'd like to collect feedback on this. Whether you want to try it or just 
discuss or review the design without trying, you are welcome. Even if you think 
that the design is a complete crap, you are welcome: You might have a good 
point that I would like to know in this early stage.

Short QA:


Thanks, Vit. Qubes needs a way to do incremental backups. I have been 
trying out btrfs-send. Marek expressed interest in a technique using LVM 
thin-provisioning, possibly for R4.


BTW, the place in the Readme where it says "Attacker can obtain some 
reasonably limited metadata about the backup"... this doesn't sound 
correct to my ears. It almost sounds like you're trying to supply data 
to the attacker, which I know is not the case. You may want to re-phrase.


In the list of limitations, you could mention that the backups cannot be 
pruned (old backup sessions deleted independently of the others) since 
that is a feature some users look for. Another downside you may want to 
list is that duplicity (librsync) uses significant processing power to 
compare old contents with new.


Chris

--
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/0dce0ab5-9346-45d9-333e-5f2e67489b8b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] do I really need these packages in dom0 :?

[Oleg Artemiev]

After installing qubes 3.2 looked into dom0 updates.

Found some that I possibly ok to remove:

[olli@dom0 ~]$ rpm -q --whatrequires tigervnc-server-minimal
anaconda-gui-23.19.10-4.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires anaconda-gui
initial-setup-gui-0.3.37-1.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires initial-setup-gui
no package requires initial-setup-gui
[olli@dom0 ~]$

Also, do I really need this in Dom0:

[root@dom0 olli]# rpm -q --whatrequires openssh
openssh-askpass-7.2p2-3.fc23.x86_64
[root@dom0 olli]# rpm -q --whatrequires openssh-askpass
no package requires openssh-askpass
[root@dom0 olli]#

?

Also I've Network Manager in Dom0 - why - it is designed never have
networking. It is left by anaconda - setup program. Why not to delete
it?

lli@dom0 ~]$ rpm -qa |grep -i net
NetworkManager-wifi-1.0.12-2.fc23.x86_64
NetworkManager-libnm-1.0.12-2.fc23.x86_64
NetworkManager-1.0.12-2.fc23.x86_64
NetworkManager-glib-1.0.12-2.fc23.x86_64
glib-networking-2.46.1-1.fc23.x86_64
libnetfilter_conntrack-1.0.4-5.fc23.x86_64
nettle-3.2-1.fc23.x86_64
netcf-libs-0.2.8-3.fc23.x86_64
NetworkManager-team-1.0.12-2.fc23.x86_64
libnfnetlink-1.0.1-7.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires NetworkManager-wifi
anaconda-gui-23.19.10-4.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires NetworkManager-libnm
no package requires NetworkManager-libnm
[olli@dom0 ~]$ rpm -q --whatrequires NetworkManager-glib
anaconda-core-23.19.10-4.fc23.x86_64
nm-connection-editor-1.0.10-1.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires nm-connection-editor
anaconda-gui-23.19.10-4.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires anaconda-core
anaconda-tui-23.19.10-4.fc23.x86_64
anaconda-gui-23.19.10-4.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires anaconda-tui
anaconda-core-23.19.10-4.fc23.x86_64
initial-setup-0.3.37-1.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires initial-setup
initial-setup-gui-0.3.37-1.fc23.x86_64
initial-setup-gui-0.3.37-1.fc23.x86_64
initial-setup-launcher-1.0-1.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires initial-setup-gui
no package requires initial-setup-gui
[olli@dom0 ~]$ rpm -q --whatrequires initial-setup-launcher
no package requires initial-setup-launcher
[olli@dom0 ~]$ rpm -q --whatrequires NetworkManager-team
anaconda-core-23.19.10-4.fc23.x86_64
[olli@dom0 ~]$ rpm -q --whatrequires nettle
no package requires nettle
[olli@dom0 ~]$ rpm -q --whatrequires libnfnetlink
no package requires libnfnetlink
[olli@dom0 ~]$

from above only netcf-libs is required indirectly by xen related
package. So is it safe to drop all other from above w/ rpm -e  ?


-- 
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C  9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

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

[qubes-users] Feedback request: Incremental file-based backup PoC

[Vít Šesták]

Hello,
I'd like to announce my PoC for incremental file-based backup for Qubes VMs. It 
is not a completely new backup system, it just wires together some existing 
software with Qubes principles to provide convenient and secure way to backup 
many VMs with minimum overhead and encrypt them by one password. I have tried 
hard not to expose dom0 to untrusted inputs from VMs. Design is described in 
README, though I will probably break README to multiple parts. Sources are here:

https://github.com/v6ak/qubes-incremental-backup-poc/

Now, I'd like to collect feedback on this. Whether you want to try it or just 
discuss or review the design without trying, you are welcome. Even if you think 
that the design is a complete crap, you are welcome: You might have a good 
point that I would like to know in this early stage.

Short QA:

Q: Why should I prefer this way to current Qubes backup mechanism?
A:
* Efficiency. Incremental backups can lower the backup size dramatically. 
File-based backups skip unused space, so it is even more efficient. And last 
but not least, file-based backup allows you to exclude ~/.cache and other stuff 
you don't want to backup.
* Comfort: The builtin backup does not handle storage. My approach allows you 
to automatically upload it to various storages.

Q: How much is it stable?
A: Well, I just got it working. Don't rely on it too much, please. The backup 
format also might change a bit, so using it in production might require 
reviewing commit messages.

Q: How much is it secure?
A: There was nontrivial effort to design it securely and implement it securely. 
In both areas are some improvable places (e.g., non-processing UTF-8 in dom0 or 
better authentication of files), but I hope it is reasonably secure. There are 
some potential minor leaks, mostly through error messages.

Q: I don't like Duplicity for some reason. Can I use something else instead?
A: Well, the code is modular enough, so that implementing some other backup 
backend should not be hard. On the other hand, no other current backend is 
implemented at the moment. If you have some suggestion, you are welcome. If you 
want to write some other backend, you are also welcome, but maybe you will want 
to wait a while until things are more stable.

Q: What backup backends are suitable for this scheme?
A: The most crucial part is splitting the backup process into two parts. One 
process runs in a DVM, but it does not have the access to the backup storage. 
Second process runs in a BackupStorageVM, but it does not have access to the 
filesystem you want to backup. Those two processes are connected through qrexec.

Q: Can I backup VM that is running?
A: If you have LVM-based private.img, you can. (See README for details.) If you 
have standard file-based private.img, you cannot. I don't plan to implement 
this feature for file-based private.img, because Qubes 4.0 will use LVM, so 
they don't seem to have a long future.

Q: What is the code quality?
A: Short answer: PoC. Long answer: Some parts look like a Bash script rewritten 
to Python (which is in few cases how it actually has happened), but I believe I 
can iteratively improve the suboptimal cases. Especially exception handling is 
something neglected – I am aware of Exceptions and the code expects them to 
some degree (using finally blocks etc.), but they are rarely reported to user 
in a friendly way. They usually bubble to the top level, so stacktrace is 
dumped.

Regards,
Vít Šesták

-- 
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/901b82dc-f781-4c13-ad00-33b4337fc84a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DisplayPort problems -> HowTo driver update?

[Others call me jean]

Hi

I really need help! I'm despairing )-:

First, with Arch Linux and GNOME my hardware configuration worked well.
Now I can't make runnable the same config with Qubes OS (XFCE and KDE).
It freezes with every change or suspend/resume.

My CPU is a Skylake one and therefore I maybe need newer drivers.

So my question: how can I update the Intel driver? (e.g. to mesa 13)

Thanks!

(See the first mail too:
https://groups.google.com/forum/#!msg/qubes-users/W-KAQN_k0Yw/9sNcgk4DAAAJ;context-place=msg/qubes-users/Sh7ckO2SpBk/A5-gQ3FE6pYJ)

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

Re: [qubes-users] Qubes 3.2 + Win 7 (Qubes Tools 3.2.2.3): Can't change display resolution in Windows App VM

[Eva Star]

On 02/23/2017 12:42 AM, pixr...@mail2tor.com wrote:


The only problem I am struggling is, that I can't change the display
resolution in my windows vm.
When I right click on my windows desktop and choose Change Display
Resolution, I can see that the Qubes Video Driver is installed, but I have
only two options to change the resolution:

1) 2560x1546 which is exactly the window size of the the windows VM in
fullscreen
2) 800x600


I'm also have this issue since 3.2.
I use Windows at other virtual desktop to get access to all other App 
windows.



--
Regards

--
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/5e52703f-4ec2-a24a-f000-5e046e94cab5%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Lenovo Thinkpad X1 Carbon 4th gen (20FB)

[Jean-Philippe Ouellet]

In the interest of maximizing list archive utility, I'm attaching a
new HCL here (bumped kernel to 4.8.12-12 & xen to 4.6.4).

I still have issues with suspend/resume. Sometimes it fails to resume,
and sometimes it fails to suspend (leading to a hot backpack and/or
quickly dead battery).

There is now another HCL of the same laptop here [1] which claims that
kernel 4.8.12-12 fixes the suspend-resume issues, but this has not
been the case for me.

[1]: https://groups.google.com/forum/#!msg/qubes-users/kLlBahlTRK0/rInkUwa0FAAJ

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


Qubes-HCL-LENOVO-20FBCTO1WW-20170226-144830.yml
Description: application/yaml

Re: [qubes-users] Two qubes multinoot

[Oleg Artemiev]

On Sat, Feb 25, 2017 at 6:50 PM, john.david.r.smith
 wrote:
> On 25/02/17 04:14, Oleg Artemiev wrote:
>>
>> Hi.
>>
>> If I want to run VMs from one Qubes in another
> why would you even dualboot two qubesversions?
Some activities are useless to encrypt, i.e. social networking and
some other . Encription gives useless overhead.
I want 1 Qubes OS unencrypted and 1 Qubes OS encrypted for everything
else + activities from unencrypted Qubes also enabled.

>> would it be possible to
>> have different coloring for the same VM in different Qubes OS instances?
> here the questions is, what files you would share?
For example:

 /var/lib/qubes/appvms/public-activity-vm/

or if it does any sense I may share files indiividually:
/var/lib/qubes/appvms/public-activity-vm/*

> i am not sure, where the label is saved, but if you only share the images,
> it should work (but i am still not sure what you are trying to do).
run same VM in diffrent boots of Qubes OS on the same computer.

>> Is this possible from a VM to attack Dom0 by altering VM image files  or
>> this is just files and adversary able to rewrite image in one Qubes has no
>> option to appear outside VM when it is loaded in another Qubes OS
>> instance?
> a vm can always only write data inside of an image.
> if a vm can write data in dom0, your system is owned and you need something
> as aem to protect the other instance.
> but even with aem, i think one qubes dom0 A could compromise the other dom0
> B, since A can somehow read and write files of B.
A is not encrypted, B is encrypted, A never used to mount something
from B and has no clue about B luks password.

> but if you assume both dom0 are secure, i don't see a problem.
A is not that secure as B. If A is compromised I'm not glad, but it's
not very important - all accounts I would use from A are already
somewhat public.

It looks that before booting into B I should check bootloader and
/boot consistency of B w/ some sort of usb stick.

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

[qubes-users] Cannot Install R3.2 on MacBookPro11,1

[Chris]

Hi,

I've attempted to install R3.2 via USB pen onto my MacBookPro11,1.

Without doing anything special I can select to boot from the USB pen
using the Apple EFI boot menu, however selecting any of the Qubes
boot menu options will simply cause the boot menu to reappear after
briefly printing "Unsupported device path component".

After reading into this, I tried booting it through legacy support.
And this did work, however during the installation phase I was
informed that no disks were detected on the system and that I should
attach at least one and reboot.

So for some reason the installer (possibly just when booted through
legacy mode) cannot detect my SSD... or even the USB pen that it is
booting from.

Any help would be much appreciated. I tried after this to boot with
UEFI by setting mapbs=1 and noexitboot=1 on the boot menu, and also by
editing xen.cfg; however neither of these had any effect.

Hopefully someone here can guide me.

Thanks,
Chris 

-- 
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/20170226185659.6b50d1ba%40aluminium.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Backup error - where is the log?

[Zbigniew Łukasiak]

If I install a second Qubes system on a different partition - is there
any way to copy the VMs from the first one? Because that was my goal
with the backups. It is possible that the lack of space somehow
corrupted the system - and that is the reason for the problems with
backups - so maybe there is any other way to do that?

Z.

-- 
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_UUvMPW%3D6LteSw_gA3C%2B3jVyNbruc8BvuCRinfjy6c-77BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] updating tor browser in whonix-ws dispvms

[J.M. Porup]

Is anyone else using whonix-ws based dispvms?

Until recently, tor browser received updates via whonix repos. For some
reason that seems to have stopped.

The problem is that every time I open a new whonix-ws based dispvm, I'm
prompted to download a new version of TBB. Doing so a dozen times a day
or more gets a bit tedious.

Per Whonix docs, I've tried running update-torbrowser in the templatevm,
but the command line output tells me not to bother, because the download
will be in /home and won't propagate to dispvms.

I've taken a close look at Qubes and Whonix docs, but nothing is jumping
out at me as a possible solution. Maybe I'm missing something.

Any ideas?

thanks
jmp



-- 
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/20170226145840.GB1149%40fedora-21-dvm.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] XScreenSaver for dom0 pops up

[Opal Raava]

On Friday, November 4, 2016 at 6:34:57 PM UTC+1, John Maher wrote:
> On Thursday, November 3, 2016 at 12:50:13 AM UTC-4, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2016-11-02 08:56, John Maher wrote:
> > > On Thursday, October 27, 2016 at 12:42:18 AM UTC-4, Andrew David Wong 
> > > wrote:
> > > On 2016-10-26 15:53, Gaijin wrote:
> >  On 2016-10-26 13:38, John Maher wrote:
> > > On Wednesday, October 26, 2016 at 9:05:48 AM UTC-4, Gaijin wrote:
> > >> On 2016-10-26 12:43, John Maher wrote:
> > >>> I'm getting the strangest thing on my screen. I'll be working and 
> > >>> the
> > >>> XScreenSaver dialog pops up (indicating the screen is locked) and 
> > >>> the
> > >>> screen goes black. However, the screen is not locked. I have to 
> > >>> move a
> > >>> window around to redraw my screen. This has always happened since I
> > >>> started using Qubes about 3 weeks ago. There appears to be no 
> > >>> pattern
> > >>> that prompts this response. Bizarre! Any thoughts?
> > >>>
> > >>> Thanks.
> > >>>
> > >>> John
> > >>
> > >> Yeah. I had the same thing happen when I upgraded to R3.2 as well. I
> > >> asked the same thing but nobody replied.
> > >> https://groups.google.com/forum/#!topic/qubes-users/xjHi2TcYBAQ
> > >>
> > >> It still happens from time to time. Seems to happen less if I have a 
> > >> lot
> > >> of free memory. Closing down some memory hungry AppVMs seems to 
> > >> lessen
> > >> it, but I haven't been able to specifically replicate it.
> > >
> > > Interesting, because I think I have more than enough memory (32 GB). 
> > > Thanks.
> > 
> >  I've got 16GB myself. It's not that the memory is full, but it seems 
> >  to happen more when I have a lot of VMs open in one desktop. That may 
> >  just be a coincidence though.
> > 
> >  I'm glad to see it wasn't just me though. I never had this happen with 
> >  earlier versions of Qubes on the same hardware. Not sure if it might 
> >  be the XFCE or a video driver issue. (I've never installed the nVidia 
> >  drivers.)
> > 
> > > 
> > > Thank you both for reporting this. Gaijin, I'm sorry I missed your thread.
> > > 
> > > Just to confirm: Are you both using Xfce4?
> > > 
> > > Tracking the issue here:
> > > 
> > > https://github.com/QubesOS/qubes-issues/issues/2399
> > > 
> > > 
> > > Sorry for the delay in responding. I used the default install for 3.2.
> > > 
> > > I also just noticed that it appears that memory is not being purged when 
> > > apps are closed. Today when I "woke up" the screen from one of these odd 
> > > screen saver like issues, it very briefly displayed a browser window with 
> > > a site I was on yesterday. I looked carefully and confirmed that I did 
> > > not actually have that window open on my system. It's as if something 
> > > from yesterday's memory was sent to the screen and then closed. Rather 
> > > disconcerting.
> > > 
> > > John
> > > 
> > 
> > I don't think that should necessarily be disconcerting. The Qubes security 
> > model does not include or rely upon purging memory at any particular time 
> > interval. It assumes that you, the authentic single user, should be the 
> > only one with access to dom0's screen content. So, the fact that you're 
> > allowed to see your screen content from yesterday doesn't constitute any 
> > violation of the security model. You're still the same trusted user as you 
> > were yesterday. (If I've misunderstood your concern, please let me know.)
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJYGsH3AAoJENtN07w5UDAwKtIP/2vblyc4Rf9uwU3M+WGv2K7V
> > T7VoTDfGjB8XWyX6LZW/TrtameFmAj/Rb0bINOrIWpkrP9RdNUm+0/BR10NkcLul
> > FqaxMOcl2u2Tk775VjYtC+Z7y1ycJDQjaMvtqrdDQkeGhMumzcDOHD9RufTFSIRm
> > 8ke7GxfMQBH7R0DJ5E26B7HZJg73k1RKFT5BbpmKrfHxBBEaJTUALeNFZnp2ekl+
> > HrRV4u8+T/Tbwzha5e/iTvJEVTMcMxzD4uziaN+TfiK2Iwp40w0W8IdmRjPzdkLI
> > +PDhAfjpQCEcZIPT/V+u6GsMhUDJo5ABPs/as17YY4b8VMwm9F7/J2Oo6nfwl/Rh
> > gOnwVLFQKUtq3iaNbORDzAjBSEny6wYKlfvpL3IWGAHhH0mbP5j1ivSJoF+navuD
> > qPMvMyAuhFh7hSsTPJ0CTMrDZYTGVlSryLrvXUwl5Lf6zplXRxO6uGu3ruUnepxR
> > 9izVXApPBv/Cc41G3wrCUGN3deE1OpzNSxhQS+NK4B3kJSGAm4+Zi/F/B8yiR6Lt
> > L/DiLI04X1LZ/XW+ZrKKiQbqVKAzeDqkDPW1D4POEckQnEfPqMcc32LzQVf6ORvX
> > Xzjn+UhUcdTzINAuISwYeBdvBTk6Wk80T80nChZJdnSdWi6klvbcof96UNdD3sja
> > swBLAb3aU4hobRxFAcL7
> > =Fv0E
> > -END PGP SIGNATURE-
> 
> If the memory that temporarily renders to the screen is as isolated from 
> other appvms as expected rendered content (like an open windows), then, yes, 
> I'm not concerned about leakage from one environment to another. 
> 
> I will say that it is simply disconcerting to see it display, security 
> implications aside. More important to me, though, is the hope that this 
> "screen 

Re: [qubes-users] Re: How to use a and which mailclient in QUBES (via TOR)?

[Tim W]

On Thursday, February 23, 2017 at 3:57:29 PM UTC-5, pix...@mail2tor.com wrote:
> Hello,
> 
> I tried to install the first parts to get MUTT running, but run into an
> error when launching the make command at the end of the guide.
> 
> > I need to edit: /usr/local/etc/postfix/sender_relay.
> > your.m...@exmaple.com [mail.example.com]:submission
> > your.ot...@mail.com [smtp.mail.com]:smtp
> 
> I have understand that :smtp and :submission are just placeholders for ports.
> As such I have the following entry in my /usr/local/etc/postfix/saslpass:
> 
> [smtp.gmail.com]:587  myusern...@gmail.com:MYPASSWORD
> 
> Strangely I run into an error at the end of the postfix guide
> (https://www.qubes-os.org/doc/postfix/):
> 
> I have copied and pasted the content for the
> "usr/local/etc/postfix/Makefile", but when I enter "sudo make" in
> /usr/local/etc/postfix
>  I get the following error message:
> 
> [user@mail postfix]$ make
> Makefile:2: *** missing separator.  Stop.
> 
> Any idea where to start troubleshooting from this point on?
> 
> I'm running all this command in my App-VM, which is based on the fedora-23
> Template which I have cloned and installed the additional packages as
> suggested in the >Qubes Postfix docu.
> 
> Pixr

Did you get this to work and configured properly?  

  

-- 
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/bbc8ea74-a612-4402-8075-5e8111fd0697%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.