[qubes-users] Re: Open in Qube 3.0 beta released!

[Yethal]

W dniu piątek, 14 września 2018 20:31:24 UTC+2 użytkownik John S.Recdep napisał:
> On 09/14/2018 07:02 AM, 'Raffaele Florio' via qubes-users wrote:
> > Dear Qubes community,
> > I've released a new version of "Open in Qube" (aka qubes-url-redirector) 
> > [v3.0_beta]. The repository is at [repo].
> > This is a browser extension inspired by [gsoc idea] and it's written using 
> > standard WebExtension APIs. Each customization is done via the browser 
> > because it's highly integrated in it.
> > 
> > ### What does it do
> > The extension allows you to choose which URLs are whitelisted in the 
> > browser, with a lot of flexibility. Indeed you can specify allowed URLs 
> > also with regular expression. Non whitelisted URLs are treated in a custom 
> > way: you can choose to block them only, or to block and redirect them to a 
> > specific/disposable qube. In this way unwanted/malicious URLs will not be 
> > opened in the current browser, so in the current qube.
> > Furthermore there are three context menu entry ([menu issue]) through which 
> > you can choose how to handle specific link. Then there is the toolbar's 
> > popup that allows you to whitelist a **specific** resource currently 
> > blocked in the **active** tab. In the popup is indicated the URL and the 
> > type (i.e. image, stylesheet, script, xhr and so on..) of each resource.
> > In the repo there are some screenshot and other infos. Furthermore after 
> > the first installation the browser will open a welcome page whose will 
> > guide you.
> > 
> > ### Installation
> > Installation is really easy and it's covered in the [repo]. As you can see 
> > in [contrib issue] its integration in Qubes OS is scheduled for the 4.1 
> > release.
> > 
> > I hope that it will be useful to a lot of us and for whatever issue don't 
> > hesitate to contact me! :D
> > 
> > [v3.0_beta] = 
> > https://github.com/raffaeleflorio/qubes-url-redirector/releases/tag/v3.0_beta
> > [gsoc idea] = 
> > https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
> > [menu issue] = https://github.com/QubesOS/qubes-issues/issues/4105
> > [contrib_issue] = https://github.com/QubesOS/qubes-issues/issues/3152
> > [repo] = https://github.com/raffaeleflorio/qubes-url-redirector/
> > 
> > Best Regards,
> > Raffaele.
> > 
> > 
> 
> Nice.
> 
> Can't quite understand how or why this would be used, though..?  am
> sure it makes sense to the smart folks :)
> 
> 
> here's my vote for whatever "gsoc idea" is , 'cause:
> 
> I wish I could click on a URL in ThunderbirdVM  and have it open a
> whonix-dvm  by default  .  afaik there is no current way to do that.

No, but there is a way to do that in chrome or firefox now

-- 
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/337f72c6-b331-4924-bd30-88285db74137%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] [proposing new feature] Edit in VM: an idea that can improve security when managing documents

[Sven Semmler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/14/18 10:41 PM, airelemen...@tutanota.com wrote:
> a) Documents that "link" other documents. [...]

Yes, that's a corner case that needs manual steps (e.g. start dispvm,
copy all files in, copy them back out before closing vm)

> b) Can't save progress. qvm-copy-to-vm only copies back the edits
> after the VM shuts down, right? So what if the system crashes in
> the meantime?

Sure, that's true. Personally if I work on something larger, I just
close the VM every hour or so and open a fresh one to calm my nerves.
Although I've never experienced a crash in Qubes. But I get your point.

To me these are worthwhile trade offs, your situation / judgment might
differ.

/Sven
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlucmNkACgkQ2m4We49U
H7Ybhg//Xeo/z2AcPUJEVBtkjCdyCKSd7vrQPmS+h1+vvoCB2lt66SdZZ2/q9wRc
pifRaMGz0ZFI+PNK9VwG66t6A29Y/791jxk0EiI1xDUEVI4A6RuYWar2br1v4PD7
Yv6YegPHJUU7V3zn+1t6KAel3BBGPgaMXYPWnkRs4L2rtQzDEBXI/Fh3JLvHlRcX
RvpnieSoWrq3pGswwtHM2MwZu4rUm7L7d1N/P0bAcqGIDi8c0P4Q9kJA0nTUdPFY
UKRD9B0gErVajdqKI/SLvKtTFT6gpdakzuI6W3CAxcUSl0F6W0jMKss0bf7gZn+y
99bdRhouy7amJ3QiHpqHG+mCysr6SLJPkJF5VN4SAL0OAVXg3ddZXoPkrm/ib43U
VKIq+Ms5QFlcVg3lkw1jtJNwG4l9MtS4FnoW+Ulce2ODpAEcHV1Z4h5KeIoiOoiY
lfzhX9oX7eFy6SvABvsnFXz5WOuHVkfJbpM3jrd0NNiJZWGVGkJUXoomL0MB/Kfl
FzSqEa8fo9G0Oj5ho5mEKMBnCnlzi8O2m6QcaD31WGaUxNx1ElrFjfWM6aW9BN2v
kTozPwz37g7QuFSjOW4A65DO30eiwSU2d/gF56RZJkVR25896PcRdJUCAnJRsxvU
QAkPfmoq5DXJngQHLSF6lp0ncopIlJzIVX2uIZZMrjqeEaEWza4=
=NGjl
-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/9d719d3f-e5e7-19d7-3655-4a3048396953%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Gaming with qubes

[David Schissler]

On Friday, September 14, 2018 at 12:34:10 PM UTC-5, car...@cypher.fi wrote:
> Hey. 
> I recently built new pc with Asus PRIME Z370-P, i7-8700k and gtx 1060. I care 
> about privacy and security, but i would also like to game (mainly rainbow six 
> siege and pubg).
> Is my hardware even compatible? 
> Is it possible to game in windows 10 vm without sacrificing performance too 
> much? 
> If someone has done this please post your experience and tutorial. 
> Thanks in advance.


It seems that its technically possible to pass a notebook dGPU into a VM but in 
practice very few seem to be able to do it and projects like this don't appear 
to be very interested in making that a turn key operation.  I estimate that its 
just too many niches coming together for it to be easy.

-- 
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/6fd853b8-a665-488d-8e23-42ace8d5f6ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Compatibility Lenovo P52

[David Schissler]

On Saturday, September 8, 2018 at 9:25:40 AM UTC-5, cr33d...@gmail.com wrote:
> Hi Frank, 
> 
> considered to take an X1 Extreme? 
> It will be upgradable to upto 64GB of RAM nd powered by an i7 too - don't 
> know which exactly atm, but you may want to have a look here:
> 
> https://www.lenovo.com/gb/en/laptops/thinkpad/x-series/ThinkPad-X1-Extreme/p/22TP2TXX1E1
> 
> cheers,
> Jonny


Oh yeah, the X1E is going to be a super popular model.  I hope that they made 
it correctly and enough of them.

-- 
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/be7ab470-71b7-4037-80cc-0ecfce40f4e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Gaming with qubes

[David Schissler]

What is IOMMU-GFX?  I can't find any references to the GFX part.

-- 
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/10dc224e-492e-4c8f-ba22-9df9e3fb21e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] [proposing new feature] Edit in VM: an idea that can improve security when managing documents

[airelemental]

15. Sep 2018 00:14 by un...@thirdeyesecurity.org 
:


> On Fri, Sep 14, 2018 at 04:13:53PM -0500, Sven Semmler wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 9/14/18 2:16 PM, Matteo wrote:
>> > there is a docx in the "documents vm" but you open it in a special 
>> > vm that allows you to edit it safely (kind of dispvm), all this
>> > with just double click.
>>
>> You can already do this. All you have to do is set the default handler
>> in your "documents vm" to use qvm-open-in-dispvm.
>>
>> You can even go a step further and hook up qvm-open-in-vm via a
>> desktop shortcut (to provide an ignored vm parameter) and then change
>> the policy in dom0 to always show you the dialog of all VMs to choose
>> which one to open it in.
>>
>> Ivan Mitev explained the details to me back in May:
>> https://groups.google.com/d/msg/qubes-devel/0CpN7ol1ZdM/0cBPvwc6CgAJ 
>> 
>>
>> So in my setup:
>>
>> - -> whenever I click a web link I get a dialog and can choose to either
>> open a new online dispvm or tor dispvm or open in an already running
>> (disp) vm
>>
>> - -> whenever I open a document I get a dialog and I can choose to open
>> in an offline disp vm or an already running offline disp vm
>>
>> ... in other words: everything I ever open (links and documents) is
>> always in a disp vm and I can choose on the fly whether offline,
>> online or with TOR. Since changes to a document in a dispvm propagate
>> back to the calling VM this also works great for document I work on.
>>
>> If it wouldn't require customization of the guest vm (the default
>> handler and the desktop shortcut), I would promote this to be the
>> default behavior. But I should probably write it all up nicely and
>> submit to the Qubes documentation. It's really powerful.
>>
>> Cheers,
>> Sven
>>
>> -BEGIN PGP SIGNATURE-
>>
>> iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlucJJIACgkQ2m4We49U
>> H7b7nQ/9HGyOn2Z1XWhvquuWAzBQPuJgE85cZ9IKCLK1OwjXpcUnej0/Dwa3jjL8
>> J6g2UVtsRx9/5jt0+tifRzFAlfOuFjvh/R80P335hnc4R+UceLq95dfnFaPFtLZk
>> +TelcKnJ5haSIsO/XErKPs+OqA4L5Ukdf7Wym36zIOm5TGU5QnrXHlIYr/Dpyjdt
>> sEG3gzk2itnTyEL4GOwK652tqMWHrzkc8ZnYLSmOOOdRCRJy/SCM+DV/DOSHrsvH
>> SZr5HpnCVLFWHn8WZ2af7h28g+foautDpsHGDfoU6hC/GU21nmCYKchKWUeuE7jM
>> sQCiVTv36MLgFD6WJg3hRZxr0x/T75V0iOAbS5rWZ+IRJaIoOF26ZrskYRfi5I62
>> MaeXgBFCMgvQr01pL6GUMMCrCIu01LViuJT8DsXW0vbxAI34gq1XexaUPaBWZJo5
>> rns+5oIixBUfuvROZPy3vwSKHxKdwFecHWkmVldFHcetnC9Q3rPveSRdAvhkNdQv
>> JpiFeCy/3n20cU7yOAJhEhs1xnRA1XH7VhyW6Dn4T1MgHWh74eVaEqQOUyl9Q+J1
>> p8HGONz8zSsPO+o9e+OCa2fMaPA8nfrTo1VjazMP1OmW5xLWedJb915aG+nxEfCy
>> ray1zbl2O8nCoOvtOOeJG1NeD7tv46m50Sv3SqbIXUOxS2KfLNs=
>> =zISj
>> -END PGP SIGNATURE-
>
> You dont say this, but if you use a minimal template for the document
> vm, then you minimise the risk of inadvertently opening a file there by
> mistake.
> You can, in fact, strip out almost any application other than a
> qubesopen tool, or pdf and img-convert.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to > qubes-devel+unsubscr...@googlegroups.com 
> > .
> To post to this group, send email to > qubes-de...@googlegroups.com 
> > .
> To view this discussion on the web visit > 
> https://groups.google.com/d/msgid/qubes-devel/20180915001411.7sl6jgcz3azv35g5%40thirdeyesecurity.org
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .




Something similar is the sd-svs in SecureDrop-on-Qubes, see 
https://github.com/freedomofpress/securedrop-workstation 





Anyway, it seems like there could be some issues:

a) Documents that "link" other documents. For example: html pages that 
reference locally-downloaded images/css, Inkscape docs with linked images, bash 
scripts that source other scripts. Unfortunately qvm-open-in-vm currently only 
copies just one file, so all links are broken in the dispvm.


b) Can't save progress. qvm-copy-to-vm only copies back the edits after the VM 
shuts down, right? So what if the system crashes in the meantime?



-- 
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/LMQJKiD--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

[Anac]

On 09/15/2018 05:07 AM, 22...@tutamail.com wrote:

Thanks Chris...I understand now. I just tried it again and below are my logs, while I 
don't get the "Operation not permitted (code=1)" error I still get the TLS 
error

Fri Sep 14 16:55:06 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: My username
Enter Auth Password: **
Fri Sep 14 16:55:35 2018 TCP/UDP: Preserving recently used remote address: 
[AF_INET]208.X.x.x ; port xx
Fri Sep 14 16:55:35 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 16:55:35 2018 UDP link local: (not bound)
Fri Sep 14 16:55:35 2018 UDP link remote: [AF_INET]208.x.x.x: port xx
Fri Sep 14 16:56:36 2018 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Fri Sep 14 16:56:36 2018 TLS Error: TLS handshake failed
Fri Sep 14 16:56:36 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 16:56:36 2018 Restart pause, 5 second(s)

Looks like the connection type is still set as UDP in your OpenVPN 
configuration file (.ovpn or .conf). Did you try to set it to TCP and 
according ports?


--
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/aab36350-bd17-8322-a4ea-6a3f603df7a4%40rbox.co.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] New to Qubes having issues logging into my vpn service despite following the Qubes instructions

[Wolf moon]

Hi guys New to Qubes ( which is an amazing feat of cyber security engineering ) 
all working fine and learning my way around it. 

My only issue is logging into my vpn service. 

I have followed the Qubes instructions ( which the images are different to 
Qubes 4.0 and after searching the net on this matter someone said that this is 
a shot of the previous Qubes so not helpful there ) I also contacted my vpn 
service on the matter. They read up on the Qubes instructions and emailed me 
back a step by step guide but still no joy. 

My vpn service works well on my Raspberry Pi 3 in the command line ( which I 
found simple instructions for elsewhere on the internet ) and works fine on my 
windows 10 system as its got an app interface you download.

Its just Qubes I am having issues with. I am by no means a hardcore techy, I am 
learning and not afraid or unfamiliar using the command line in linux. 

I have contacted the Qubes team after trying my best effort to resolve this on 
my own as I know they are a small team of 5 or so last time I checked.

Any help and advice would be greatly appreciated.

Best,

Wolf Moon

-- 
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/cab9d7b8-3224-42bf-8982-8db4f7fed32a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] syncing config across qubes

[unman]

On Fri, Sep 14, 2018 at 04:43:45PM -0500, Sven Semmler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 9/14/18 4:31 PM, Daniel Allcock wrote:
> > But I feel like maybe they are all wrong and I am overlooking 
> > something obvious.
> 
> You could have one "work qube" with your vim/emacs environment and use
> qvm-open-in-vm in all other qubes to open documents with the work qube.
> 
> /Sven

Better still, make the "work qube" a Template for DisposableVMs, and use
those disposableVMs from the other qubes. 

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

Re: [qubes-users] Gaming with qubes

[taii...@gmx.com]

On 09/14/2018 01:34 PM, card...@cypher.fi wrote:
> Hey. 
> I recently built new pc with Asus PRIME Z370-P, i7-8700k and gtx 1060. I care 
> about privacy and security

If you really do next time don't buy a blobbed and ME'ed PC along with a
graphics card from the anti-freedom nvidia that actively prevents the
development of the nouveau open source drivers (vs amd making their own)
and adds "bugs" to prevent people from using IOMMU-GFX with geforce
cards (which wasted me 4 hours when I had a geforce card)

> but i would also like to game (mainly rainbow six siege and pubg).

Still possible.

I play the latest games at max settings in a VM with my libreboot
firmware KGPE-D16 with a RX580 (must get an 8gb+ gfx card) and 6328 cpu
(with a gpu bottleneck) The KCMA-D8 and KGPE-D16 server/workstation
boards work well with qubes 4.0 and they support
coreboot-libre+libreboot, OpenBMC[1] and of course IOMMU-GFX

They even theoretically support Crossfire xDMA in a VM, one of the cool
things that can be done is to normally use crossfire but if a friend
comes over assign the second graphics card to another VM so you can game
at the same time on the same machine.

While computing freedom is dead on x86 (new hardware is not owner
controlled) some day there will be games ported to POWER - already
people with the owner controlled libre-firmware TALOS 2 are playing
multiplayer games together on linux.

People said there would never be linux gaming - now many AAA games
support linux native!

[1](the facebook version of OpenBMC not the better ibm version found on
the OpenPOWER machines like the talos 2 but still quite usable for
secure owner controlled foss lights out remote access) note the kcma-d8
does not come with the module required to install openbmc it must be
purchased separately.

> Is my hardware even compatible? 
No idea maybe, most consumer boards lack IOMMU support or it is broken.

> Is it possible to game in windows 10 vm without sacrificing performance too 
> much?

Sure if done right it is not noticeable (ie: no stuttering or w/e) and
you only lose 1-3 FPS.

> If someone has done this please post your experience and tutorial. 
I suggest reading the tutorials and information on the xen wiki or for
kvm/qemu on the vfio blog. (qubes uses xen)

I would suggest however gaming in a VM on a separate computer rather
than your qubes computer for performance, security and the fact that it
is harder to get it working on qubes apparently.

If you have any difficult questions you can't find the answer to
anywhere else let me know - I enjoy answering the hard questions.

-- 
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/0fa47323-9e17-75a7-f181-800bd7e6c46b%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Intel Releases New BSD-Licensed Open-Source Firmware Implementation

[taii...@gmx.com]

On 09/14/2018 06:20 PM, taii...@gmx.com wrote:
> On 09/14/2018 03:01 PM, David Schissler wrote:
>> https://www.phoronix.com/scan.php?page=news_item&px=Intel-Slimbootloader
>>
>> This could be an improvement if someone takes the firmware and deletes tons 
>> of unnecessary stuff.  Hopefully this will be rolled out over many lines.
>>
> 
> It is nothing new!
> 
> This is NOT "Open Source Firmware" it is shimboot coreboot - all the
> hardware initiation work is done via FSP and coreboot is just there as a
> wrapper layer for FSP.
> 
> More misdirection from intel trying to strangle their IBM OpenPOWER
> competitors in the crib now that they see there is a real market for
> owner controlled hardware.
> 
> Buy a TALOS 2 if you want legitimately owner controlled, real FOSS,
> libre, "open source firmware" hardware that is both fast and brand new.

I always assume people know the difference but I figure I should mention
that unfortunately qubes/xen does not yet support the POWER arch as
there is a bit of an impasse in the developer community - thus your best
choice if you must have qubes is the KCMA-D8/KGPE-D16 libre firmware
available workstation/server boards or the g505s coreboot open cpu/ram
init laptop all of which are pre-PSP AMD and while comparatively slow
the kcma-d8 with a 4386 can max out the latest games on libreboot with a
suitable graphics card such as a rx580 8gb.

I would however argue that an OpenPOWER machine with
POWER-KVM/POWER-IOMMU virt is more secure than xen running on blobbed
propriatary wintel junk that soon won't allow you to install linux at all.

I am old enough to remember the fact that smartphones didn't used to be
walled gardens, soon that anti-feature concept will come to desktop
computers and one will only be able to install linux or their non-MS
"approved" programs if they pay for a "developer edition" computer. MS
already tests the waters with their ARM PC's that have full "secure"
boot (aka secure from you the owner) locking you out from removing
windows or even installing a new version of windows.

Every time someone purchases a new non-owner controlled blobbed
intel/amd hardware you support future DRM efforts, even if someone
figures out a ME jailbreak some day intel will quickly patch it and with
every release their methods of preventing jailbreaking get better and
better.

-- 
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/fc4e9079-9cef-de44-c01e-ba78dcccb7c5%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL - Purism Librem 13 v2

[taii...@gmx.com]

Everyone please be aware that purism's marketing is dishonest.

Their products do not have open source firmware[1] and the ME is not
disabled (the kernel still runs along with mask roms and the me hw init
code)

Intel chips or any new x86 for that matter do NOT respect your privacy!

[1]Their coreboot is simply a shim loader layer for Intel's FSP binary
blob that performs the hardware initiation - these days coreboot doesn't
necessarily mean open source firmware.

In terms of laptops it is much better to purchase for instance an owner
controlled pre-PSP AMD G505S[2] which has open cpu/ram init via coreboot
or one of the ivy/sandy thinkpads which while not owner controlled are
significantly more free than puri.crap as they have open cpu/ram/gpu
init via coreboot and their ME can be nerfed down to the BUP layer which
while is not at all equivilant to not having an ME at all such as on
non-x86 arches or pre-PSP AMD it is still much better.

All of my laptop recommendations here work great with Qubes 4.0 and
there is a nice little qubes g505s community.

[2](for the best user experience make sure to get the highest end quad
core A10 model if you buy one - although the less expensive A6 quad core
models are still quite usable)


I do not have an issue with purism selling non-free laptops - I have an
issue with them being dishonest.

-- 
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/b706b02b-6461-3461-7a6b-19b8ebdb9a8f%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] syncing config across qubes

[Chris Laprise]

On 09/14/2018 05:31 PM, Daniel Allcock wrote:

Dear all,

I am wondering how you all deal with (for example) having an elaborate vim
or emacs environment built up over several decades, and being able
to use it in all of your regular everyday qubes (personal, work, untrusted, etc,
probably leave vault out).  Of course, you expect it to keep evolving as you
figure out how some package solves a problem for you, or you write some
vimscript or elisp to stop an annoyance.

What is the qubes way to do this?  I've considered several solutions from
the simple to the baroque:

(simple) do the common config in the template vm (but not in /home
or /rw or /usr/local) and replace the relevant config files/dirs in the 
actual-work
vm's with symlinks to them.

(also simple) have a "config" qube where you keep the configs you want to sync,
but do no actual work there and have no net access.  Set up a script to copy 
the relevant files/dirs to your working qubes.  When you find an annoyance, fix 
it there, and then run the script.

(rather complicated) set up a git server (say in its own dvm)
and have your qubes push commits to it when
you make changes to one of the files-to-sync.  That way you can make your
tweaks wherever you happen to be working at the time, and later accept
those changes on the server.  Then you can download the updated version
on your working qubes (perhaps by a script).

All of these have different convenience levels and data-flow implications.
But I feel like maybe they are all wrong and I am overlooking something 
obvious.  Any thoughts appreciated!
Daniel



It gets more complicated if you want to keep settings in /home/user 
updated. Otherwise, updating configs only in templates isn't hard.


The server idea would be OK if it were coordinated by a dom0 program and 
used qvm-copy or sending via qvm-run+tar. An actual networked server 
seems both more complicated and a security risk.


Another way you could keep /home/user settings updated is to stash the 
settings somewhere in '/' and have a VM startup script copy the files 
into home. You can already do this with the service in 
Qubes-VM-hardening since it can deploy files from template to anywhere 
in /rw at the moment the appVM mounts it... 
https://github.com/tasket/Qubes-VM-hardening


--

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/2399b718-e727-4baa-eb2c-42aac658b354%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Intel Releases New BSD-Licensed Open-Source Firmware Implementation

[taii...@gmx.com]

On 09/14/2018 03:01 PM, David Schissler wrote:
> https://www.phoronix.com/scan.php?page=news_item&px=Intel-Slimbootloader
> 
> This could be an improvement if someone takes the firmware and deletes tons 
> of unnecessary stuff.  Hopefully this will be rolled out over many lines.
> 

It is nothing new!

This is NOT "Open Source Firmware" it is shimboot coreboot - all the
hardware initiation work is done via FSP and coreboot is just there as a
wrapper layer for FSP.

More misdirection from intel trying to strangle their IBM OpenPOWER
competitors in the crib now that they see there is a real market for
owner controlled hardware.

Buy a TALOS 2 if you want legitimately owner controlled, real FOSS,
libre, "open source firmware" hardware that is both fast and brand new.

-- 
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/7dec5f5b-4233-56a4-52fd-6b19be0e4745%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ANN: Testing new VPN code for Qubes

[22rip]

Thanks Chris...I understand now. I just tried it again and below are my logs, 
while I don't get the "Operation not permitted (code=1)" error I still get the 
TLS error

Fri Sep 14 16:55:06 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: My username
Enter Auth Password: **
Fri Sep 14 16:55:35 2018 TCP/UDP: Preserving recently used remote address: 
[AF_INET]208.X.x.x ; port xx
Fri Sep 14 16:55:35 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 16:55:35 2018 UDP link local: (not bound)
Fri Sep 14 16:55:35 2018 UDP link remote: [AF_INET]208.x.x.x: port xx
Fri Sep 14 16:56:36 2018 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Fri Sep 14 16:56:36 2018 TLS Error: TLS handshake failed
Fri Sep 14 16:56:36 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 16:56:36 2018 Restart pause, 5 second(s)

-- 
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/227e07f2-09a9-4608-8910-4c678cdf6e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] syncing config across qubes

[Kyle Rankin]

On Fri, Sep 14, 2018 at 04:31:19PM -0500, Daniel Allcock wrote:
> Dear all,
> 
> I am wondering how you all deal with (for example) having an elaborate vim
> or emacs environment built up over several decades, and being able
> to use it in all of your regular everyday qubes (personal, work, untrusted, 
> etc,
> probably leave vault out).  Of course, you expect it to keep evolving as you
> figure out how some package solves a problem for you, or you write some
> vimscript or elisp to stop an annoyance.
> 
> What is the qubes way to do this?  I've considered several solutions from
> the simple to the baroque:
> 
> (simple) do the common config in the template vm (but not in /home
> or /rw or /usr/local) and replace the relevant config files/dirs in the 
> actual-work
> vm's with symlinks to them.

Most tools that allow a customized local config in /home also have an area
for global configuration (for instance /etc/vim/vimrc). So since Qubes acts
more like a single-user system you could just store your settings,
plugins, etc. in their global location in the appropriate template. This
has the added advantage that you could still override your global
preferences in a particular qube if you needed to by setting things in
/home.

I follow the pattern where you clone the "default" provided templates to
create ones that you customize with custom packages anyway. The default
Qubes-provided templates just get package updates. That way backup/restore
is a bit cleaner as you don't have a conflict when the fresh install has a
brand new debian-9 template, for instance. So following this pattern you'd
change that customized template and leave the default Qubes-provided ones
for system qubes and vault, etc.

-Kyle

> 
> (also simple) have a "config" qube where you keep the configs you want to 
> sync,
> but do no actual work there and have no net access.  Set up a script to copy 
> the relevant files/dirs to your working qubes.  When you find an annoyance, 
> fix it there, and then run the script.
> 
> (rather complicated) set up a git server (say in its own dvm)
> and have your qubes push commits to it when
> you make changes to one of the files-to-sync.  That way you can make your
> tweaks wherever you happen to be working at the time, and later accept 
> those changes on the server.  Then you can download the updated version
> on your working qubes (perhaps by a script).
> 
> All of these have different convenience levels and data-flow implications.
> But I feel like maybe they are all wrong and I am overlooking something 
> obvious.  Any thoughts appreciated!
> Daniel
> 
> -- 
> 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/DF890AFA-A2CC-4033-9532-56F905DF8714%40allcock.org.
> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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/20180914220109.GO20469%40greenfly.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] syncing config across qubes

[Sven Semmler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 9/14/18 4:31 PM, Daniel Allcock wrote:
> But I feel like maybe they are all wrong and I am overlooking 
> something obvious.

You could have one "work qube" with your vim/emacs environment and use
qvm-open-in-vm in all other qubes to open documents with the work qube.

/Sven
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlucK5IACgkQ2m4We49U
H7ZwWg//dOKD++4cYTmjOFbNATxTYiSgkrr+x/UVaGZvs4qbCaiCO7WBS0IT7XF3
7I2ZWRSCK1vrgZy1vFrL2y+4qVjVmRE7JFTIlkXsn2oUdH7HhjCCueuKBAg+089E
/ER4b1+s7T5yGxdHV37tlehYcim2Z0CAAFhDbyslGTeHAmRVcomf1N8k9gEX/v5C
NQXV88QlJNMhGf4J/pN8h0ugamKqR9Z11zaF2quqWUNh/ebHxnSunwH7WGplyczG
JtX8KIap/ICqbJHRhxTn772qUcCBvTwoi4GF0aaObsl/+uTJFJYE5iz0bNrwK+9o
UixJK3ZyUXC/IIdiyXHTfuxTuyj11N985QrUIJp+3FiOruXwpDq/Vfw0a5MxWSM/
lQt+9bgwYdQ9JF8Z2xOghgQp19su2tqvVxXoBujj4ZhlB7MEAFQGQ3XBVqLuOyH0
tsTWogIN6f/tCSdpOm6TjjFqReopGTZ10/CZOco3NOBlvtfcGCnmwfUeQVRLvUBV
7QFl/waoebiI/ps5YaWZ2X+PNHlnhHtSqEYinWXzgp0H0xR3ulYGTP+DRb6YfBwn
sZLT94S2z+NsN6gQ5IiVzusnLrezOIEPy1VeJnMGk3/+V5wvvG/nbhp+ZLQeINOr
LlNUIPJzOZ4plAiBNCxQ1c4u1lRLNsrzowmIXkLOwQxYxsen9Og=
=Oz3W
-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/c5a41e5d-e1f7-0bbb-7db4-1cb4a2b31906%40SvenSemmler.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ANN: Testing new VPN code for Qubes

[Chris Laprise]

On 09/14/2018 03:25 PM, 22...@tutamail.com wrote:

Thank you Anac and Chris, appreciate your suggestions:

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that?

I did check this...opened the connection to Any/Any but this didn't seem to be 
the issue. I also eliminated TOR for testing and connected directly to the 
sys-net(to also eliminate any sys-firewall potential issues)

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template.

I tried with fedora-28 but also had the same TLS connection error. I ran the 
tests in step 3 as suggested and recieved the following errors with both the 
Debian and Fedora setup:

Fri Sep 14 10:30:53 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Sep 14 10:30:53 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: My user name
Enter Auth Password: **
Fri Sep 14 10:32:34 2018 TCP/UDP: Preserving recently used remote address: 
[AF_INET]208.167.254.76:1198
Fri Sep 14 10:32:34 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 10:32:34 2018 UDP link local: (not bound)
Fri Sep 14 10:32:34 2018 UDP link remote: [AF_INET]208.x.x.x:port xx
Fri Sep 14 10:32:34 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:36 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:40 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:48 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:04 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:34 2018 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Fri Sep 14 10:33:34 2018 TLS Error: TLS handshake failed
Fri Sep 14 10:33:34 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 10:33:34 2018 Restart pause, 5 second(s)

Definitely strange considering it was working great for a few months...the good 
news is the kill switch functionality with this solution worked.

Any insight with the errors I recieved? If not I think a reinstall is my best 
course...


You would normally get operation not permitted if the internal firewall 
script is in effect, which is why this step comes before any scripts are 
added (i.e. its performed in a fresh VM).


You can either disable the firewall script in 
/rw/config/qubes-firewall.d and reboot, or try the test in a new VM 
connected to sys-net.



--

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/a48bdd20-e74d-20ea-ac6d-003ce44a4957%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] syncing config across qubes

[Daniel Allcock]

Dear all,

I am wondering how you all deal with (for example) having an elaborate vim
or emacs environment built up over several decades, and being able
to use it in all of your regular everyday qubes (personal, work, untrusted, etc,
probably leave vault out).  Of course, you expect it to keep evolving as you
figure out how some package solves a problem for you, or you write some
vimscript or elisp to stop an annoyance.

What is the qubes way to do this?  I've considered several solutions from
the simple to the baroque:

(simple) do the common config in the template vm (but not in /home
or /rw or /usr/local) and replace the relevant config files/dirs in the 
actual-work
vm's with symlinks to them.

(also simple) have a "config" qube where you keep the configs you want to sync,
but do no actual work there and have no net access.  Set up a script to copy 
the relevant files/dirs to your working qubes.  When you find an annoyance, fix 
it there, and then run the script.

(rather complicated) set up a git server (say in its own dvm)
and have your qubes push commits to it when
you make changes to one of the files-to-sync.  That way you can make your
tweaks wherever you happen to be working at the time, and later accept 
those changes on the server.  Then you can download the updated version
on your working qubes (perhaps by a script).

All of these have different convenience levels and data-flow implications.
But I feel like maybe they are all wrong and I am overlooking something 
obvious.  Any thoughts appreciated!
Daniel

-- 
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/DF890AFA-A2CC-4033-9532-56F905DF8714%40allcock.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ANN: Testing new VPN code for Qubes

[22rip]

Thank you Anac and Chris, appreciate your suggestions:

You said that Tor was running. When combining Tor with VPN, the VPN's
connection type should be TCP, not UDP. Did you check that? 

I did check this...opened the connection to Any/Any but this didn't seem to be 
the issue. I also eliminated TOR for testing and connected directly to the 
sys-net(to also eliminate any sys-firewall potential issues)

Before you go through the trouble of a whole reinstall, you could try
setting your VPN VM to use Fedora 28 instead to see if it works. You can
also perform a reinstall of the Debian template. 

I tried with fedora-28 but also had the same TLS connection error. I ran the 
tests in step 3 as suggested and recieved the following errors with both the 
Debian and Fedora setup:

Fri Sep 14 10:30:53 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Sep 14 10:30:53 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Enter Auth Username: My user name
Enter Auth Password: **
Fri Sep 14 10:32:34 2018 TCP/UDP: Preserving recently used remote address: 
[AF_INET]208.167.254.76:1198
Fri Sep 14 10:32:34 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 14 10:32:34 2018 UDP link local: (not bound)
Fri Sep 14 10:32:34 2018 UDP link remote: [AF_INET]208.x.x.x:port xx
Fri Sep 14 10:32:34 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:36 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:40 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:32:48 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:04 2018 write UDP: Operation not permitted (code=1)
Fri Sep 14 10:33:34 2018 TLS Error: TLS key negotiation failed to occur within 
60 seconds (check your network connectivity)
Fri Sep 14 10:33:34 2018 TLS Error: TLS handshake failed
Fri Sep 14 10:33:34 2018 SIGUSR1[soft,tls-error] received, process restarting
Fri Sep 14 10:33:34 2018 Restart pause, 5 second(s)

Definitely strange considering it was working great for a few months...the good 
news is the kill switch functionality with this solution worked.

Any insight with the errors I recieved? If not I think a reinstall is my best 
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/12b288bb-8b29-415f-8aa4-560661cfbba1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Intel Releases New BSD-Licensed Open-Source Firmware Implementation

[David Schissler]

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Slimbootloader

This could be an improvement if someone takes the firmware and deletes tons of 
unnecessary stuff.  Hopefully this will be rolled out over many lines.

-- 
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/7827a558-7217-4402-a1b9-1f7b19653673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Open in Qube 3.0 beta released!

[John S.Recdep]

On 09/14/2018 07:02 AM, 'Raffaele Florio' via qubes-users wrote:
> Dear Qubes community,
> I've released a new version of "Open in Qube" (aka qubes-url-redirector) 
> [v3.0_beta]. The repository is at [repo].
> This is a browser extension inspired by [gsoc idea] and it's written using 
> standard WebExtension APIs. Each customization is done via the browser 
> because it's highly integrated in it.
> 
> ### What does it do
> The extension allows you to choose which URLs are whitelisted in the browser, 
> with a lot of flexibility. Indeed you can specify allowed URLs also with 
> regular expression. Non whitelisted URLs are treated in a custom way: you can 
> choose to block them only, or to block and redirect them to a 
> specific/disposable qube. In this way unwanted/malicious URLs will not be 
> opened in the current browser, so in the current qube.
> Furthermore there are three context menu entry ([menu issue]) through which 
> you can choose how to handle specific link. Then there is the toolbar's popup 
> that allows you to whitelist a **specific** resource currently blocked in the 
> **active** tab. In the popup is indicated the URL and the type (i.e. image, 
> stylesheet, script, xhr and so on..) of each resource.
> In the repo there are some screenshot and other infos. Furthermore after the 
> first installation the browser will open a welcome page whose will guide you.
> 
> ### Installation
> Installation is really easy and it's covered in the [repo]. As you can see in 
> [contrib issue] its integration in Qubes OS is scheduled for the 4.1 release.
> 
> I hope that it will be useful to a lot of us and for whatever issue don't 
> hesitate to contact me! :D
> 
> [v3.0_beta] = 
> https://github.com/raffaeleflorio/qubes-url-redirector/releases/tag/v3.0_beta
> [gsoc idea] = 
> https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
> [menu issue] = https://github.com/QubesOS/qubes-issues/issues/4105
> [contrib_issue] = https://github.com/QubesOS/qubes-issues/issues/3152
> [repo] = https://github.com/raffaeleflorio/qubes-url-redirector/
> 
> Best Regards,
> Raffaele.
> 
> 

Nice.

Can't quite understand how or why this would be used, though..?  am
sure it makes sense to the smart folks :)


here's my vote for whatever "gsoc idea" is , 'cause:

I wish I could click on a URL in ThunderbirdVM  and have it open a
whonix-dvm  by default  .  afaik there is no current way to do that.

-- 
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/4856f04f-8761-0c74-dcf5-63293134b3e4%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Introducing the Qubes U2F Proxy" by Wojtek Porczyk

[John S.Recdep]

On 09/12/2018 04:08 AM, Ivan Mitev wrote:
> 
> 
> On 9/12/18 4:33 PM, Sergio Matta wrote:
>> Em terça-feira, 11 de setembro de 2018 13:38:09 UTC-3, Brendan Hoar  
>> escreveu:
>>> On Tuesday, September 11, 2018 at 5:18:49 AM UTC-4, Andrew David Wong wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Dear Qubes Community,

 Wojtek Porczyk has just published a new article titled "Introducing
 the Qubes U2F Proxy." The article is available on the Qubes website:

 https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
>>>
>>> *FANTASTIC*. Thanks, this is very useful.
>>>
>>> Brendan
>> Good news, thank you. But sudo dnf install qubes-u2f results not found on 
>> fedora-28 repo. Please check.
> 
> It is in the current-testing repo:
> 
> dnf --enablerepo=qubes-vm-r4.0-current-testing install qubes-u2f
> 
> (same goes for dom0 - only the current testing repo name is different)
> 


...and it will move out of "testing"  in about 2 weeks to the main
repo  like security updates ?

...so for the cautious what till then ?

-- 
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/f30c2eec-29f8-0b93-737b-ea5cedf05385%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL - Purism Librem 13 v2

[Kyle Rankin]

Install works out of the box with no warnings. I haven't run into any
issues with hardware compatibility--hardware in general works (video,
audio, all ports, Fn keys). Hardware Kill Switches work as expected within
Qubes.  Suspend/resume works.

By default it works with the standard included coreboot BIOS but I've also
tested it with Heads using the TPM and that works as well.

-- 
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/20180914181059.fkt3blxd3heez54s%40work.
For more options, visit https://groups.google.com/d/optout.
---
layout:
  'hcl'
type:
  'laptop'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  ''
remap:
  'yes'
brand: |
  Purism
model: |
  Librem 13 v2
bios: |
  4.7-Purism-4-heads
cpu: |
  Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host 
Bridge/DRAM Registers [8086:1904] (rev 08)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation HD Graphics 520 [8086:1916] (rev 07) (prog-if 00 [VGA 
controller])
  Intel Corporation Device [8086:9d24] (rev 21)
gpu-short: |
  FIXME
network: |
  Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
memory: |
  16298
scsi: |
  Samsung SSD 850  Rev: 2B6Q
  Samsung SSD 850  Rev: 1B6Q
usb: |
  1
versions:

- works:
'FIXME:yes|no|partial'
  qubes: |
R4.0
  xen: |
4.8.4
  kernel: |
4.14.57-2
  remark: |
FIXME
  credit: |
FIXAUTHOR
  link: |
FIXLINK

---

[qubes-users] Gaming with qubes

[cardiak]

Hey. 
I recently built new pc with Asus PRIME Z370-P, i7-8700k and gtx 1060. I care 
about privacy and security, but i would also like to game (mainly rainbow six 
siege and pubg).
Is my hardware even compatible? 
Is it possible to game in windows 10 vm without sacrificing performance too 
much? 
If someone has done this please post your experience and tutorial. 
Thanks in advance. 

-- 
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/206fd7e7-026d-4193-b897-0f1d54d11a8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Open in Qube 3.0 beta released!

['Raffaele Florio' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes community,
I've released a new version of "Open in Qube" (aka qubes-url-redirector) 
[v3.0_beta]. The repository is at [repo].
This is a browser extension inspired by [gsoc idea] and it's written using 
standard WebExtension APIs. Each customization is done via the browser because 
it's highly integrated in it.

### What does it do
The extension allows you to choose which URLs are whitelisted in the browser, 
with a lot of flexibility. Indeed you can specify allowed URLs also with 
regular expression. Non whitelisted URLs are treated in a custom way: you can 
choose to block them only, or to block and redirect them to a 
specific/disposable qube. In this way unwanted/malicious URLs will not be 
opened in the current browser, so in the current qube.
Furthermore there are three context menu entry ([menu issue]) through which you 
can choose how to handle specific link. Then there is the toolbar's popup that 
allows you to whitelist a **specific** resource currently blocked in the 
**active** tab. In the popup is indicated the URL and the type (i.e. image, 
stylesheet, script, xhr and so on..) of each resource.
In the repo there are some screenshot and other infos. Furthermore after the 
first installation the browser will open a welcome page whose will guide you.

### Installation
Installation is really easy and it's covered in the [repo]. As you can see in 
[contrib issue] its integration in Qubes OS is scheduled for the 4.1 release.

I hope that it will be useful to a lot of us and for whatever issue don't 
hesitate to contact me! :D

[v3.0_beta] = 
https://github.com/raffaeleflorio/qubes-url-redirector/releases/tag/v3.0_beta
[gsoc idea] = 
https://www.qubes-os.org/gsoc/#thunderbird-firefox-and-chrome-extensions
[menu issue] = https://github.com/QubesOS/qubes-issues/issues/4105
[contrib_issue] = https://github.com/QubesOS/qubes-issues/issues/3152
[repo] = https://github.com/raffaeleflorio/qubes-url-redirector/

Best Regards,
Raffaele.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEXw2ov1HEFPFo+AVy07vJZYtrAOMFAlub6M0ACgkQ07vJZYtr
AOP5aA//XX9JjfdsgMB06XWEcNHSNLVa31Ut9Xm2ecSztb2G10NvFNYkv6R11woQ
E49IDHmMR62wqXUec2GKbXimR4Qc0+ohN82uepM1o264SvHDVg9IUETFvkQQU608
GnzJOBPsCIdmuvzhwwWUEdjJHfPahLCQS8SnVbVPO9UA8E7zLfviV5F0rY2mz3Sp
n8HxKjAyVeByM+cEib12zSI7IQpA7hORwatFXErXkNMQ5TMTGfP5Zj/LVRqnSHVa
Yr4j358pgW+PgzjMHKHTY8Swh7R74xV4T7JSqBF2U4ZjJuho3nRT7UIPA0/468FN
k0k/oHUYoLzca13ns3upBPA32ybgdrDYb0dIeeI78xyzqyHz5GoWpkial2+yjyyF
KN8ClJxRm1GAor4KZKgXKen7mWWN1cxTjpLGObD0WSm+k6sz2oSAQN2QsdskgKcD
dI3shJnB53c/b/SRdlz0lnxGutfADu9EYQ8HUWazGCA4rkn/Vy9ErpwH89suzLGf
E61OpjX5p3dbNfOeFJeNU43yOiJg0izmCVjI2nJGBhPZ5+faop1BoNXnzC6PnWz3
CihG00xgte6vCeRbhQBAA3q5EUzuQDCWTH7goPCQCLMwgIvxqRlskq2TdFfSTJVM
/4OsYJpDrR26j18uJA1yqbqkoK75oR2h/e6eqlfdS+zj/aU8mq4=
=eP+x
-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/yyTXXgmv3CAuqaCiozjS--LsokUer96neW7sYi4CnobGASMbwwO32Crricy_0fIVCW2FT5gtGsW_ScHE9M-ajA2Dz3lHiEecMCFuXyEWapU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Forbidding VM create/delete/edit network settings from within dom0 for enterprise use-case

[Yethal]

W dniu piątek, 14 września 2018 13:21:14 UTC+2 użytkownik Nils Amiet napisał:
> Hi everyone,
> 
> I would like to lock-down Qubes OS so that VMs can't be created or deleted, 
> nor edited (e.g. modify the associated NetVM).
> 
> I already read documentation about qrexec policies, the Admin API and 
> qubes-core-admin extensions.
> 
> If I understand correctly, the Admin API cannot be used to prevent the user 
> from creating a VM from dom0. For example, from the dom0 terminal I tried 
> adding the following line to `/etc/qubes-rpc/policy/admin.vm.Create.AppVM`:
> 
> ```
> $adminvm $adminvm deny
> ```
> 
> But then I am still able to run `qvm-create test --label blue`. Is there 
> something I am missing here or is the policy not being honored on dom0? Why 
> is that?
> 
> I also noticed that the Qubes extensions fire some events and it is possible 
> to write hooks for those events 
> (https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html). 
> Would it be possible to write a Qubes extension that hooks to some event that 
> is fired whenever a VM is created and use that mechanism to block VM creation?
> 
> Would the GUI domain that is planned for Qubes OS 4.1 change the situation or 
> help implementing this at all?
> 
> The workaround I'm thinking about is to run Xfce4 in kiosk mode, remove 
> application menu entries, keyboard shortcuts, desktop right click menu to 
> prevent access to dom0 but this is just a workaround and it probably we can't 
> be sure that it will work with upcoming Qubes OS releases. Any thoughts on 
> that?
> 
> Thank you,
> 
> Nils

Wait for 4.1. The plan is that users will not have direct access to dom0. 
Instead gui domain will have api access to management functions and it will be 
possible to restrict it for corporate use case.

-- 
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/d9ef4c0d-ba2c-4c1f-9ddd-a675d6851919%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] suspend to ram, r8169, networking in sys-net not working after resume

[GDRUB]

Le 10/09/2018 à 22:38, Alex a écrit :
> On 9/10/18 10:34 PM, gdru...@gmail.com wrote:
>>> My issue:
>>>
>>> On qubes version r4.0 after resuming from suspend networking isn't
>>> working. On qubes r3.2 this wasn't an issue.
>>>
>>> [...]
>> Hi,
>>
>> In 4.0, I have the same issue.
>> [...]
>>
>> Help !! how can I fix it ?
>>
> This also happens to me; I'm using realtek ethernet adapter too. With
> R3.2 this happened rarely, but with R4.0 this happens nearly every time
> the computer resumes from sleep.
>
> As of now, I just issue a direct "shutdown now" to the sys-net, and then
> just restart the VM. As soon as network is available again, all the
> other Qubes reach it too - in R3.2 I had to shut them ALL down and then
> bring them up in sequence, with R4.0 I can just powercycle sys-net and
> it somehow works.
>
> Still, it's a bit of a problem...
>
Hi,

I tried that but it didn't help.

I replaced my network card TP-Link TG-3468 with a StarTech.com (port PCI) card. 
Now, it seems to work well.

-- 
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/b894edff-2b21-dc2d-05b7-9c3619dc7be2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Forbidding VM create/delete/edit network settings from within dom0 for enterprise use-case

[Nils Amiet]

Hi everyone,

I would like to lock-down Qubes OS so that VMs can't be created or deleted, nor 
edited (e.g. modify the associated NetVM).

I already read documentation about qrexec policies, the Admin API and 
qubes-core-admin extensions.

If I understand correctly, the Admin API cannot be used to prevent the user 
from creating a VM from dom0. For example, from the dom0 terminal I tried 
adding the following line to `/etc/qubes-rpc/policy/admin.vm.Create.AppVM`:

```
$adminvm $adminvm deny
```

But then I am still able to run `qvm-create test --label blue`. Is there 
something I am missing here or is the policy not being honored on dom0? Why is 
that?

I also noticed that the Qubes extensions fire some events and it is possible to 
write hooks for those events 
(https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-ext.html). Would 
it be possible to write a Qubes extension that hooks to some event that is 
fired whenever a VM is created and use that mechanism to block VM creation?

Would the GUI domain that is planned for Qubes OS 4.1 change the situation or 
help implementing this at all?

The workaround I'm thinking about is to run Xfce4 in kiosk mode, remove 
application menu entries, keyboard shortcuts, desktop right click menu to 
prevent access to dom0 but this is just a workaround and it probably we can't 
be sure that it will work with upcoming Qubes OS releases. Any thoughts on that?

Thank you,

Nils

-- 
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/e7328347-ca9b-411f-8bbd-ff82336c8d77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] Whonix version support policy

[Holger Levsen]

On Thu, Sep 13, 2018 at 09:00:40PM -0500, Andrew David Wong wrote:
>  * One month after a new stable version of Qubes OS is released, Whonix
>TemplateVMs will no longer be supported on any older version of Qubes
>OS. 

I'm quite disappointed by this.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

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


signature.asc
Description: PGP signature

Re: [qubes-users] Re: Qubes locks up half the time on startup with filenotfound error trying to run qubes manager

[Marcus Linsner]

On Thursday, September 13, 2018 at 7:43:57 PM UTC+2, Guy Frank wrote:
> On Tuesday, September 11, 2018 at 5:12:00 PM UTC-5, Guy Frank wrote:
> > On Tuesday, September 11, 2018 at 4:29:02 PM UTC-5, awokd wrote:
> > > On Tue, September 11, 2018 7:10 pm, Guy Frank wrote:
> > > > On Tuesday, September 11, 2018 at 1:44:13 PM UTC-5, Guy Frank wrote:
> > > >
> > > >> Was a bit premature thinking that my qubes installation was stable.
> > > >> About half the time I start the system, it locks up and I am only able
> > > >> to access Dom0 (qubes manager will not open, nor will any qubes, even
> > > >> from command line).  The system gives a serious 'filenotfound' error
> > > >> msg.  I've looked at previous posts on problems like this, but my
> > > >> problem doesn't seem to fit what others reported--qubes.xml is not
> > > >> empty and disk utilization is minimal (or near 50% in one case).  The
> > > >> error message is:
> > > >>
> > > >> #
> > > >> Whoops.  A critical error has occurred.  This is most likely a bug in
> > > >> Qubes Manager
> > > >> FileNotFoundError:  [Errno 2]
> > > >> No such file or directory
> > > >> at line 9 of file /usr/bin/qubes-qube-manager #
> > > >>
> > > >>
> > > >> Line 9 reads:  load_entry_point('qubesmanager==4.0.16',
> > > >> 'console_scripts', 'qubes-qube-manager')()
> > > >>
> > > >>
> > > >> Ok, so the weird thing is that this works fine half the time.  On half
> > > >> of my boot ups, I don't encounter this problem.  So if there is no such
> > > >> file or directory, it's not there half the time.  qubes.xml looks good
> > > >> (to my untrained eyes), and df -h shows nothing at more than 1%
> > > >> utilization except for /dev/nvme0n1p1 mounted on /boot/efi which is 56%
> > > >> of 200MB.  nvme0n1p1 is, I believe, the GPT table?
> > > >>
> > > >> I'm worried about coming to rely on this installation if at some point
> > > >> the error doesn't go away every other reboot and becomes permanent.  Am
> > > >> trying updates now--maybe that will help.
> > > >>
> > > >> Guy
> > > >>
> > > >
> > > > Updating the software in dom0 doesn't make the problem disappear, though
> > > > now the main error message is:
> > > >
> > > > QubesDaemonCommunicationError: Failed to connect to qubesd service:
> > > > [Errno 2] No such file or directory
> > > > at line 9 of file /usr/bin/qubes-qube-manager
> > > 
> > > Nothing related earlier in the "sudo journalctl -e" log? Try "sudo
> > > systemctl restart qubesd"?
> > 
> > Thanks awokd!  I'll give these a try next time I run into the problem
> 
> Ok, so on my next reboot, it ran into this problem again.  I made a copy of 
> the journalctl log and tried to restart qubesd, to no effect.  
> 
> The attached file, jnlctlErr.txt, if you scroll down to 09:24:43, I think you 
> can see where the Qubes OS daemon fails.  It is immediately preceded by the 
> 1d.2 pci device worker failing, suggesting that something about this failure 
> is causing the daemon from starting (which occurs below the blank line I 
> added to the log). 1d.2 is a PCI Bridge, Intel Corp Device a332.  No idea 
> what exactly this is or how to find out (not a hardware person).  
> 
> One thing I thought of is the fact that there's a PS/2 card in the machine to 
> which a PS/2 keyboard & mouse are attached.  Neither has ever worked in Qubes 
> (though they worked in Windows), so maybe that's what's triggering the 
> problem?  Will do some testing.
> 
> When I attempt to start qubes daemon w/ sudo systemctl restart qubesd, 
> journalctl log shows other errors.  The qubes daemon doesn't get started and 
> I can't use the system.
> 
> What I can do is reboot.  And about every other time, Qubes comes up and is 
> fine.  My concern is that at some point it'll stop doing this, so I'd really 
> like to figure out how to solve this problem.
> 
> Guy

Looking the the relevant errors, in context (and the time between them):

...
Sep 13 09:20:23 localhost kernel: usb 1-10.1: New USB device found, 
idVendor=413c, idProduct=2002
Sep 13 09:20:23 localhost kernel: usb 1-10.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=0
Sep 13 09:20:23 localhost kernel: usb 1-10.1: Product: Dell USB Keyboard Hub
Sep 13 09:20:23 localhost kernel: usb 1-10.1: Manufacturer: Dell
Sep 13 09:20:23 localhost kernel: input: Dell Dell USB Keyboard Hub as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10.1/1-10.1:1.0/0003:413C:2002.0001/input/input3
Sep 13 09:20:23 localhost kernel: hid-generic 0003:413C:2002.0001: 
input,hidraw0: USB HID v1.10 Keyboard [Dell Dell USB Keyboard Hub] on 
usb-:00:14.0-10.1/input0
Sep 13 09:20:23 localhost kernel: input: Dell Dell USB Keyboard Hub as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10.1/1-10.1:1.1/0003:413C:2002.0002/input/input4
Sep 13 09:20:23 localhost kernel: usb 4-3: new low-speed USB device number 2 
using ohci-pci
...
Sep 13 09:20:23 localhost kernel: hid-generic 0003:413C:2002.0002: 
input,hidraw1: USB HID v1.10 Device [Dell Dell USB Keyboard Hub] on 
usb-:00:1

Re: [qubes-users] Qubes 3.2 Whonix-14?

['awokd' via qubes-users]

On Fri, September 14, 2018 3:36 am, Stuart Perkins wrote:
> I deleted the whonix vms and went to install whonix-14 and it won't work.
> The salt command continues to say that the community repo is unknown.
> What am I missing?

Did you "Sometimes the Qubes Community Templates repository must also be
enabled by editing /etc/yum.repos.d/qubes-templates.repo and setting
enabled = 1 in the [qubes-templates-community] section." per
https://www.whonix.org/wiki/Qubes/Install?


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

Re: [qubes-users] Re: application icons not displayed in panel in xenial

['awokd' via qubes-users]

On Thu, September 13, 2018 11:38 pm, Guy Frank wrote:
> On Thursday, September 13, 2018 at 12:29:22 PM UTC-5, Guy Frank wrote:
>
>> On Wednesday, September 12, 2018 at 6:52:48 PM UTC-5, Guy Frank wrote:
>>
>>> I created a template for Xenial.  Things work well w/ the AppVM based
>>> on this, but there's one hitch:  most of the icons for applications
>>> do not display in the panel.  The odd thing is that the icons show
>>> just fine in the Applications launcher and in Whiskers.  But on the
>>> desktop panel, they just show as a lock.  It gets quite difficult to
>>> find windows after a bunch have been opened without icons to clue me
>>> in.  Not sure what's causing this problem because evidently the
>>> .desktop files work fine for the launcher and Whiskers.
>>>
>>>
>>> Guy
>>>
>>
>> Hi folks:  Sorry, false alarm!  I was quite concerned about this issue
>> because it made Qubes potentially to difficult for me to use because I
>> need a lot of software and files open at once, so being able to see
>> icons is important for me.  Turns out the problem resolved itself when
>> I rebooted the system.  I've been reluctant to reboot because I had a
>> number of things open I needed to address.
>>
>> Guy
>>
>
> Whoops, have to take that back.  More icons are now showing in the panel,
> but far from all.  Particularly important icons such as for various
> Libreoffice document types are not showing.

Might be related to https://github.com/QubesOS/qubes-issues/issues/1495.


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