Re: [qubes-users] Time sync isn't working

2019-12-09 Thread 'Oli Sturm' via qubes-users
On Monday, December 9, 2019 3:05 PM, Mike Keehan  wrote:

> systemd-timesyncd is running on my Qubes sys-net vm. I'm assuming
> that it is part of the standard installation. You need to investigate
> why it is not working on your machine I think.

Thank you, this got me on the right track. I'm sure I read in an old issue on 
GitHub that timesyncd wasn't supposed to be running - so  I saw its commented 
configuration as confirmation of this and didn't look at timesyncd further. I 
guess things might have changed. 


Now I searched GitHub for "timesyncd" and immediately found 
https://github.com/QubesOS/qubes-issues/issues/4939 - my sys-net didn't have 
the "clocksync" service assigned, just as described in that issue. I never 
removed that entry, so I wonder how that happened... incidentally I had 
stumbled upon this service a couple of hours ago, but qvm-service never seemed 
to show anything for any VM and I disregarded it... I guess that's a different 
question for a different thread.

For posterity: in December 2019, the ClockVM should be running 
systemd-timesyncd, and this happens magically as long as the "clocksync" 
service is correctly assigned to the VM (and in spite of the fact that 
/etc/systemd/timesyncd.conf looks like all options have been disabled).

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


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Time sync isn't working

2019-12-09 Thread 'Oli Sturm' via qubes-users
On Monday, December 9, 2019 2:40 PM, Mike Keehan  wrote:

> I suspect you need to investigate systemd's timesyncd stuff. Good luck!

I believe I would just need to switch that on to activate it. But I believe 
time sync should work in Qubes out of the box - I remember reading that 
somewhere in the docs. Maybe my expectations are wrong here?

Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature


[qubes-users] Time sync isn't working

2019-12-09 Thread 'Oli Sturm' via qubes-users
Hi,

I'm running 4.0 with all current updates. I'm trying to figure out why I don't 
get synchronized time anywhere in the system. I have found various old issues 
and discussions about similar problems, but unfortunately none of the scenarios 
described there seem to be up-to-date anymore.

As I understand, my sys-net VM is the "ClockVM". I have confirmed that it is 
configured as such in Qubes settings (using the UI dialog in Qube Manager). 
However, it seems that this VM is not set up to sync time with an NTP server. I 
see that all entries in the "Time" block in /etc/systemd/timesyncd.conf are 
commented. "ntpdate" is not installed. Is there some other NTP sync mechanism 
installed in this VM? If so, where is it? In any case it's clearly not working.

Further, it appears that sync between VMs is also not working. I installed 
ntpdate in sys-net and executed it manually, thereby changing sys-net time. 
Then I manually executed qvm-sync-clock in dom0 (since I found it was being 
started by cron there). This worked correctly, and dom0 updated to the time 
from sys-net.

However, other VMs are not updating. There is no cron entry for qvm-sync-clock 
in the cron configuration of the fedora-29 template. Am I wrong to expect these 
other VMs to update automatically? If I'm not wrong, how is that expected to 
work?

I have confirmed that if I run qvm-sync-clock manually in my VMs, the time 
updates correctly.

To summarize, there seem to be two problems in my system:

1. The configured ClockVM sys-net isn't set up for NTP.
2. Automatic time sync (with the ClockVM) isn't enabled for VMs other than dom0.

Any feedback is appreciated!

Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] Unicode text in clipboard

2019-10-04 Thread 'Oli Sturm' via qubes-users
On Friday, October 4, 2019 12:43 AM, Andrew David Wong  
wrote:

> On 2019-10-03 11:42 AM, 'awokd' via qubes-users wrote:
> 

> > 'Oli Sturm' via qubes-users:
> > 

> > > Hi,
> > > I found a problem yesterday: I had some markdown text rendered to
> > > HTML with the smartypants option to replace "--" with a long
> > > dash. The generated file contained a unicode entity for that
> > > character, I copied it to the clipboard, then did Ctrl-Shift-C
> > > and Ctrl-Shift-V, then pasted in another VM. Suddenly the unicode
> > > character was gone - the only difference as far as I could tell.
> > > Are there known problems in that area? I don't know which
> > > software package is responsible for this - I'm on R4.0 with
> > > recent updates.
> > 

> > https://github.com/QubesOS/qubes-issues/issues/236 says unicode is
> > supported. If you can recreate it, might be worth submitting a new
> > issue referencing that one?
> 

> Possibly related:https://github.com/QubesOS/qubes-issues/issues/2845

Agreed, that sounds like the same problem. I did a search but I didn't imagine 
the issue to be so specific to dashes - I was using search terms like "unicode" 
and didn't come up with anything.

Meanwhile it doesn't look like these issues (#2845 and 
https://github.com/QubesOS/qubes-issues/issues/4739) are going anywhere. Can we 
do anything to analyze the problem more, or are additional use cases required 
to reproduce? I think this is quite important, not just for the purpose of 
copying dashes, but also because broken confidence in the clipboard transfer 
process makes life a lot harder...

Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature


[qubes-users] Unicode text in clipboard

2019-10-03 Thread 'Oli Sturm' via qubes-users
Hi,

I found a problem yesterday: I had some markdown text rendered to HTML with the 
smartypants option to replace "--" with a long dash. The generated file 
contained a unicode entity for that character, I copied it to the clipboard, 
then did Ctrl-Shift-C and Ctrl-Shift-V, then pasted in another VM. Suddenly the 
unicode character was gone - the only difference as far as I could tell.

Are there known problems in that area? I don't know which software package is 
responsible for this - I'm on R4.0 with recent updates.

Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] qvm-open-in-vm behavior with URLs

2019-09-18 Thread 'Oli Sturm' via qubes-users
> On Wednesday, September 18, 2019 2:14 PM, unman un...@thirdeyesecurity.org 
> wrote:
> 

> > 2.  Cant help you with brave.
> > There's obviously something wrong with your browser/firefox
> > configuration in "untrusted"."x-www-browser: command not found" is
> > obviously wrong. 


I looked into this. It's complicated. At the core of it however is Brave - you 
were right about that. Turns out Brave has a segfault bug that comes up when a 
window is already open: https://github.com/brave/brave-browser/issues/4142

In a nutshell, the RPC process ends up in xdg-open, which has a million 
fallbacks - and the segfault results in a non-zero exit code, so xdg-open keeps 
looking. 


Here are steps to work around the issue, until they fix that bug:

1. x-www-browser isn't really needed, but I thought it couldn't hurt to have 
it. So I created one in /usr/local/bin/x-www-browser:

#!/bin/sh
/usr/bin/brave-browser-stable $@ || true

As you can see, this ignores the error result from the segfault bug.

2. I created a copy of the Brave .desktop file:

sudo cp /usr/share/applications/brave-browser.desktop 
/usr/local/share/applications

3. I edited that clone and replaced calls to 
/usr/local/bin/brave-browser-stable with calls to /usr/local/bin/x-www-browser

Now everything works. Since all my changes are in /usr/local, they can be 
applied in VMs or TemplateVMs.

Cheers
Oli

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


signature.asc
Description: OpenPGP digital signature


Re: [qubes-users] qvm-open-in-vm behavior with URLs

2019-09-18 Thread 'Oli Sturm' via qubes-users
On Wednesday, September 18, 2019 2:14 PM, unman  
wrote:

> 1.  It's a security feature, asking for confirmation.
> If you dont want it -
> Set in /etc/qubes-rpc/policy/qubes.OpenURL:
> whatever $anyvm allow,target=untrusted
> 

> This will set untrusted as default handler for URLs with no prompt at
> all.

Right, thanks. I would personally prefer it if the argument passed to 
qvm-open-in-vm was used to pre-select. Not a big thing though.

> 2.  Cant help you with brave.
> There's obviously something wrong with your browser/firefox
> configuration in "untrusted"."x-www-browser: command not found" is
> obviously wrong. Try fixing that and setting to brave.
> It works as intended in Debian-10 with chromium, with no spurious
> firefox entries. Give it a try.

Fair enough. I wasn't assuming that the issue was specific to Brave, but who 
knows. 


Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature


[qubes-users] qvm-open-in-vm behavior with URLs

2019-09-18 Thread 'Oli Sturm' via qubes-users
Hi,

I'm trying to set up URL handling along the lines of 
https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/ 
for my email vm. However, the qvm-open-in-vm command behaves strangely in two 
different ways.

1. Much less important than (2) but still irritating: I execute "qvm-open-in-vm 
untrusted http://example.com;, where "untrusted" is of course the name of my 
VM. The confirmation dialog pops up and requires me to select or type 
"untrusted" a second time before I can open the URL. I found that if I pass a 
string that is not the name of a VM, the command doesn't even execute - so is 
this an additional security feature? Or rather a bug? Shouldn't "untrusted" by 
preselected in the confirmation dialog?

2. In the "untrusted" VM, the default browser is Brave:

[user@untrusted]~% xdg-settings get default-web-browser
brave-browser.desktop

When I execute the command qvm-open-in-vm untrusted http://example.com in my 
email VM and confirm the operation, three things happen:

a. The running Brave browser in "untrusted" shows a new tab for 
http://example.com - excellent, that's the idea.
b. A new window opens for Firefox running in "untrusted", also showing 
http://example.com - this is rather unexpected and inexplicable to me.
c. The console shows various warnings, errors and crashes:

[user@sensitive]~% qvm-open-in-vm untrusted http://example.com

[3800:3800:0918/122055.414677:ERROR:sandbox_linux.cc(369)] InitializeSandbox() 
called with multiple threads in process gpu-process.

/usr/bin/xdg-open: line 756:  3769 Segmentation fault  (core dumped) 
"$command_exec" "$@"

/usr/bin/xdg-open: line 881: x-www-browser: command not found

[Parent 3923, Gecko_IOThread] WARNING: pipe error (45): Connection reset by 
peer: file 
/builddir/build/BUILD/firefox-68.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc,
 line 358

Any ideas what's going wrong here? My setup is R4.0 with all updates installed 
today. Both VMs used in my tests are based on Fedora 29.

Thanks
Oli

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


signature.asc
Description: OpenPGP digital signature