Re: [qubes-users] Re: whonix tor browser customization

[g80vmgmsqw]

Matthew Finkel:
> On Fri, Aug 23, 2019 at 7:59 PM  wrote:
>> panina:
>>> On 7/31/19 5:35 PM, 'awokd' via qubes-users wrote:
 panina:
> Hello.
>
>
> I've been looking for how to fix some bad default settings in the whonix
> tor browser. Namely, they removed NoScript from the toolbar, so that the
> NoScript cannot be used as intended.
>
> Since it's not adviced (and not easily possible) to start the browser in
> the template, I have to do this manually each time I start a whonix dvm.
> Since this is cumbersome, I'm not using the NoScript plugin as intended.
>
> Does anyone know how to get this plugin into the toolbar for each dvm? I
> realize that this is a Whonix issue, but all of the affected users are
> on this list...

 You might be able to hack it like in 14-
 https://forums.whonix.org/t/how-do-i-customise-tor-browser-in-a-whonix-templatebased-dvm-in-whonix-14/5580/27.
 Note it may compromise anonymity by making your browser unique or at
 least less generic.

>>>
>>> Can't seem to get this working. I get confused by how the dvm's work,
>>> and am not succeeding in starting any applications in the dvm template.
>>>
>>>
>>>
>>> On 8/9/19 9:05 AM, Patrick Schleizer wrote:
> panina:
> Namely, they removed NoScript from the toolbar, so that the
> NoScript cannot be used as intended.


 We did not. Decision by upstream, The Tor Project.


>>> https://forums.whonix.org/t/workstation-15-dropped-both-noscript-and-https/7733
>>>
>>> Thanks, duly noted. Is there any chance to get them to add a setting for
>>> this? Or re-think their decision?
>>>
>>> <3
>>> /panina
>>>
>>
>>> Thanks, duly noted. Is there any chance to get them to add a setting for
>>> this? Or re-think their decision?
>>
>> Please see:
>> https://trac.torproject.org/projects/tor/ticket/30600
>> https://trac.torproject.org/projects/tor/ticket/30570
>>
>> TL;DR The TBB developers pushed out some half-baked changes that
>> compromise UX, are hostile to the idea of reverting those changes, and,
>> three months later, apparently have zero interest in fully baking those
>> changes.
>>
>> ¯\_(ツ)_/¯
> 
> That's a little harsh, isn't it? Saying there is no interest is
> ignoring the fact that Tor Browser is maintained by a team of 10
> people for four different operating systems. Tor Browser is useless
> (and actively harmful) if users are confused about which settings they
> should change (due to careful design choices) and which settings they
> shouldn't change. The Noscript and https-everywhere buttons on the
> toolbar allowed people to tweak the settings easily, and this was not
> something a normal user should do. If someone really needs to change
> these settings, then they can go through a more complicated procedure
> for accomplishing that.
> 
> The team will finish implementing this, but (in particular) the
> highest priority task right now is migrating the Tor Browser patches
> and build system from Firefox 60esr to 68esr within the next few
> weeks.
> 

We're getting off-topic here, and I also don't wish to bring Tor Project
politics into this list.

That said:
> That's a little harsh, isn't it? Saying there is no interest is
> ignoring the fact that Tor Browser is maintained by a team of 10
> people for four different operating systems.

No, it is frankly not harsh enough.

Available developer time to finish implementing the half-baked changes
is irrelevant.  The correct way to do this would have been to wait until
the changes were fully baked (i.e. until Proposal 101 was fully
implemented, including per-site security settings), rather than
half-assing them, pushing them out the door, then three months later
thinking about maybe getting around to finishing up sometime in the
future after higher priority tasks are done.

> [...] this was not something a normal user should do.

Well, I don't know how things *should* be, but an awful lot of TBB users
have found these controls essential.  I personally have had to explain
to multiple non-technical TBB users in meatspace how to re-access the
NoScript widget, which they all have found essential to using TBB.

Regardless of available developer time and priorities, breaking a
feature many users find essential without any warning, not giving any
explanation of how to access that essential feature, and then forgetting
about un-breaking that feature for months is simply piss-poor project
management.

-- 
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/27bec4ce-662a-fa69-3902-7dc1f5016cc4%40riseup.net.

Re: [qubes-users] Re: whonix tor browser customization

[g80vmgmsqw]

panina:
> 
> 
> On 7/31/19 5:35 PM, 'awokd' via qubes-users wrote:
>> panina:
>>> Hello.
>>>
>>>
>>> I've been looking for how to fix some bad default settings in the whonix
>>> tor browser. Namely, they removed NoScript from the toolbar, so that the
>>> NoScript cannot be used as intended.
>>>
>>> Since it's not adviced (and not easily possible) to start the browser in
>>> the template, I have to do this manually each time I start a whonix dvm.
>>> Since this is cumbersome, I'm not using the NoScript plugin as intended.
>>>
>>> Does anyone know how to get this plugin into the toolbar for each dvm? I
>>> realize that this is a Whonix issue, but all of the affected users are
>>> on this list...
>>
>> You might be able to hack it like in 14-
>> https://forums.whonix.org/t/how-do-i-customise-tor-browser-in-a-whonix-templatebased-dvm-in-whonix-14/5580/27.
>> Note it may compromise anonymity by making your browser unique or at
>> least less generic.
>>
> 
> Can't seem to get this working. I get confused by how the dvm's work,
> and am not succeeding in starting any applications in the dvm template.
> 
> 
> 
> On 8/9/19 9:05 AM, Patrick Schleizer wrote:
>>> panina:
>>> Namely, they removed NoScript from the toolbar, so that the
>>> NoScript cannot be used as intended.
>>
>>
>> We did not. Decision by upstream, The Tor Project.
>>
>>
> https://forums.whonix.org/t/workstation-15-dropped-both-noscript-and-https/7733
> 
> Thanks, duly noted. Is there any chance to get them to add a setting for
> this? Or re-think their decision?
> 
> <3
> /panina
> 

> Thanks, duly noted. Is there any chance to get them to add a setting for
> this? Or re-think their decision?

Please see:
https://trac.torproject.org/projects/tor/ticket/30600
https://trac.torproject.org/projects/tor/ticket/30570

TL;DR The TBB developers pushed out some half-baked changes that
compromise UX, are hostile to the idea of reverting those changes, and,
three months later, apparently have zero interest in fully baking those
changes.

¯\_(ツ)_/¯

-- 
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/ef7db2fe-f12d-ad36-7b54-5339deb4c902%40riseup.net.

Re: [qubes-users] whonix tor browser noscript button missing?

[g80vmgmsqw]

mossy:
> Hello Qubes Community,
> 
> Has anyone noticed the blue/white noscript S button is missing since a
> recent whonix-torbrowser update?  AFAIK this is needed use javascript in
> whonix.
> 
> Anyone notice this or have a workaround?
> 
> thx!
> 
> -m0ssy
> 

See https://trac.torproject.org/projects/tor/ticket/30600 .

It's a pretty contentious issue, with Tor Browser devs closing as
WONTFIX because they plan to introduce a new permissions UI sometime in
the future.

The NoScript widget still exists, and in fact its use is apparently
still necessary for some sites to work, but you'll have to manually add
the widget back to the toolbar (Settings button > Customize... >
Right-click NoScript > Add to Toolbar).

-- 
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/f921a240-bfee-ca49-800f-525a7e7009e5%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] After last update system DEAD

[g80vmgmsqw]

evas...@firemail.cc:
> Hello,
> Oh no... :(
> After last update (kernel&xen) system almost dead!
> It can boot and I have access to dom0 console, but mouse not work and
> there is 100% cpu usage by (1.xvdb-1 / 7.xvdc-1) and other processes
> eating to much cpu
> How to remove last update? How to recover now?
> Data is urgent. I have too old backups :( Please, help :(((
> 
> I guess now it's not possible to reinstall, because any full update wll
> break the system again. And also my data. How to recover it? It's SSH
> M.2 drive and I don't have other machine with M.2 slot to recover. Or
> how to do this? :( :( :(
> Thanks.
> 
> (new email because no access to my password and data :( )
> 

Don't touch your existing M.2 drive.  Get a spare drive (spinning rust
is OK) at least as large as your M.2 drive and that you can attach to
your machine (e.g. with a USB SATA dock).

Download Tails to a USB stick.  Boot your machine into Tails.  Connect
your spare drive.  `fdisk -l` to be sure you have the right device names
for all your disks.  `dd` your M.2 to the spare drive.  Now `sync` the
disk and detach it.  You now have a backup of your current state.

If you _need_ to access some VM data now, you can (with major negative
security implications) decrypt your M.2 disk manually with `cryptsetup`,
navigate to /var/lib/qubes/appvms/ and use `losetup` to
help mount the VM's data disk in Tails so you can copy off whatever data
you urgently need.

-- 
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/a5939499-0fbf-f337-4dae-de863375d755%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] [bug] Backup restore: Modal success dialog should not use "Warning" icon

[g80vmgmsqw]

When restoring from backup, successful completion results in a modal
dialog labeled, "Finished successfully!".  This dialog uses an
exclamation point-style "Warning" icon.  This icon gives the user the
wrong impression.  Instead, the icon should be a green checkmark or
something similarly recognizable as an indicator of success.

-- 
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/c920baf2-5135-9ff7-2d3b-b2558bb59407%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[g80vmgmsqw]

Ilpo Järvinen:
> On Thu, 16 May 2019, g80vmgm...@riseup.net wrote:
> 
>> From XSA297:
>> """
>> Work is ongoing on xen-devel to develop core-aware scheduling, which
>> will mitigate the cross-domain leak by ensuring that vcpus from
>> different domains are never concurrently scheduled on sibling threads.
>> However, this alone will not prevent cross-privilege level leakage from
>> within the same domain, including leakage from Xen.
>> """
>>
>> I'm sorry, I'm not subscribed to xen-devel and am too lazy to go through
>> its archives.  Is anyone from the Qubes team monitoring this--or better,
>> participating in it?
>>
>> I can imagine a few Qubes-specific mitigations that might use some Xen
>> scheduling features to defend against future types of side-channel info
>> leaks in CPUs:
>>
>> 1) Schedule each domain in a given security label ('color') on a
>> specific CPU.  If there are not enough CPUs, make clear to the user
>> which colors might be scheduled on the same physical CPU core.
>>
>> 2) Most (all?) CPUs that support Qubes have at least 2 cores.  Assign
>> the first core the 'high' security label.  Assign all other cores the
>> 'low' security label.  Assign dom0, possible future AdminVM, and any
>> user-designated VMs the 'high' security label.  Schedule high-labeled
>> VMs exclusively on high-labeled CPU cores, and never schedule a
>> low-labeled VM on a high-labeled CPU core.
>>
>> Information could still leak through e.g. shared caches, and special
>> attention obviously must be paid there, but this might be a useful
>> mitigation for similar kinds of attacks discovered in the future.
>>
>> It could be worthwhile to sketch out what kinds of features Qubes might
>> need from Xen in order to accomplish this kind of thing and work with
>> them while they develop this new scheduler.
> 
> There is also some L3 cache region masking feature (CAT, which is also 
> supported by Xen) onwards from Broadwell (but it might be only available 
> for Xeons). And whether it could really close the L3 side-channels or 
> not probably depends on internal L3 architecture (if an off-masked L3 
> region contains the attacked data, whether it is retrieved by CPU or not).
> 
> 

Interesting.  I have not heard of this feature before.  I'll look into
it.  Thanks!

I think it's also time to seriously consider deploying something like
TRESOR[1], especially in combination with 2) above.  It must be
carefully designed so it doesn't leave the keys _more_ exposed to leaks,
though.

[1]: Tilo Mueller, Felix C. Freiling, Andreas Dewald. "TRESOR Runs
Encryption Securely Outside RAM".
https://www1.informatik.uni-erlangen.de/filepool/projects/tresor/tresor.pdf

-- 
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/7a059aff-8806-5cc2-d963-a7342c029654%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] QSB #49: Microarchitectural Data Sampling speculative side channel (XSA-297)

[g80vmgmsqw]

Marek Marczykowski-Górecki:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #49: Microarchitectural
> Data Sampling speculative side channel (XSA-297).
> The text of this QSB is reproduced below.
> This QSB and its accompanying signatures will always be available in
> the Qubes Security Pack (qubes-secpack).
> 
> View QSB #49 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and read
> it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> ```
> 
> 
>  ---===[ Qubes Security Bulletin #49 ]===---
> 
>  2019-05-15
> 
> 
> Microarchitectural Data Sampling speculative side channel (XSA-297)
> 
> Summary
> 
> 
> On 2018-05-14, the Xen Security Team published Xen Security Advisory
> 297 (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091 /
> XSA-297) [1] with the following description:
> 
> | Microarchitectural Data Sampling refers to a group of speculative
> | sidechannels vulnerabilities.  They consist of:
> | 
> |  * CVE-2018-12126 - MSBDS - Microarchitectural Store Buffer Data Sampling
> |  * CVE-2018-12127 - MLPDS - Microarchitectural Load Port Data Sampling
> |  * CVE-2018-12130 - MFBDS - Microarchitectural Fill Buffer Data Sampling
> |  * CVE-2019-11091 - MDSUM - Microarchitectural Data Sampling Uncacheable 
> Memory
> | 
> | These issues pertain to the Load Ports, Store Buffers and Fill Buffers
> | in the pipeline.  The Load Ports are used to service all memory reads.
> | The Store Buffers service all in-flight speculative writes (including
> | IO Port writes), while the Fill Buffers service all memory writes
> | which are post-retirement, and no longer speculative.
> | 
> | Under certain circumstances, a later load which takes a fault or
> | assist (an internal condition to processor e.g. setting a pagetable
> | Access or Dirty bit) may be forwarded stale data from these buffers
> | during speculative execution, which may then be leaked via a
> | sidechannel.
> | 
> | MDSUM (Uncacheable Memory) is a special case of the other three.
> | Previously, the use of uncacheable memory was believed to be safe
> | against speculative sidechannels.
> | 
> | For more details, see:
> |   
> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html
> | 
> | An attacker, which could include a malicious untrusted user process on
> | a trusted guest, or an untrusted guest, can sample the content of
> | recently-used memory operands and IO Port writes.
> | 
> | This can include data from:
> | 
> |  * A previously executing context (process, or guest, or
> |hypervisor/toolstack) at the same privilege level.
> |  * A higher privilege context (kernel, hypervisor, SMM) which
> |interrupted the attacker's execution.
> | 
> | Vulnerable data is that on the same physical core as the attacker.
> | This includes, when hyper-threading is enabled, adjacent threads.
> | 
> | An attacker cannot use this vulnerability to target specific data.
> | An attack would likely require sampling over a period of time and the
> | application of statistical methods to reconstruct interesting data.
> 
> This is yet another CPU hardware bug related to speculative execution.
> 
> Only Intel processors are affected.
> 
> Patching
> =
> 
> The Xen Project has provided patches that mitigate this issue. A CPU
> microcode update is required to take advantage of them. Note that
> microcode updates may not be available for older CPUs. (See the Intel
> advisory linked above for details.)
> 
> The specific packages that resolve the problems discussed in this
> bulletin are as follows:
> 
>   For Qubes 4.0:
>   - Xen packages, version 4.8.5-6
>   - microcode_ctl 2.1-28.qubes1
>   - kernel-qubes-vm package, version 4.19.43-1 (optional)
> 
> The packages are to be installed in dom0 via the Qubes VM Manager or via
> the qubes-dom0-update command as follows:
> 
>   For updates from the stable repository (not immediately available):
>   $ sudo qubes-dom0-update
> 
>   For updates from the security-testing repository:
>   $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
> 
> A system restart will be required afterwards.
> 
> These packages will migrate from the security-testing repository to the
> current (stable) repository over the next two weeks after being tested
> by the community.
> 
> If you use Anti Evil Maid, you will need to reseal your secret
> passphrase to new PCR values, as PCR18+19 will change due to the new
> Xen binaries.
> 
> Credits
> 
> 
> See the original Xen Security Advisory.
> 
> References
> ===
> 
> [1] https://xenbits.xen.org/xsa/advisory-297.html
> 
> - --
> The Qubes Security Team
> https://www.qubes-os.org/securit

Re: [qubes-users] Problem with a (headless) appvm

[g80vmgmsqw]

martinga...@gmail.com:
> Hi, I have a problem with an unresponsive appvm that starts up but won't run 
> any commands.
> 
> Tried qvm-run --verbose appvm nautilus for example, which would open a Files 
> window but that command only shows: running 'nautilus' on appvm.
> 
> If one couldn't open windows on the damaged appvm, at least accessing its 
> filesystem would work around the problem.
> 
> Any suggestion? Thanks in advance!
> 

You should hopefully at least be able to get a shell with: `sudo xl
console appvm`.

-- 
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/6067bfa8-4d70-e244-bddd-d9aa73a1b47d%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] "Qubes Devices" widget not working anymore

[g80vmgmsqw]

john.e.ma...@gmail.com:
> For no apparent reason, when I plug a USB flash drive into my computer (Qubes 
> 4.0) the Qubes Devices widget in the upper right no longer displays the 
> device. When I plug in the flash drive the system presents multiple black 
> popups indicating the drive is available, but nothing shows in Qubes Devices.
> 
> I'm using a USB qube called sys-usb, and this function used to work 
> perfectly. 
> 
> Any suggestions would be greatly appreciated.
> 
> Thanks.
> John
> 

This happens often for me.  For some reason the UI seems to freeze.  Try
running, in a terminal in Dom0:

$ systemctl --user restart qubes-widget@qui-devices.service

Does that solve the issue?  If so, maybe you should make a desktop
shortcut for that command--at least until the qui-devices widget is more
stable.

-- 
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/654805a4-2bdf-8dfe-b94d-64f16517c767%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: ThinkPad X270 USB C/Thunderbolt USB C type and docking station Qubes 4.0

[g80vmgmsqw]

Matthew Roy:
> 3) Manually add and remove PCI devices provided by the dock from individual 
> Qubes (e.g. sysnet and sys-usb). The Qubes will no longer boot once the PCI 
> devices are not present after you unplug the dock, but at the same time they 
> can't be connected to the Qubes after boot since they don't have hotplug 
> enabled. So when you get to your desk you'll need to reboot the laptop, then 
> attach the PCI devices to sys-usb and sys-net, then restart those Qubes. 
> Restarting sysnet and sys-usb often results in broken tray icons, so at that 
> point you may also need to reboot the laptop (you can leave the dock connect 
> during this IME). After you leave your desk you'll need to boot without the 
> dock, remove the now-missing PCI devices from sys-net and sys-usb, and then 
> reboot again to get everything working again.

Why not just assign those devices to new VMs, "sys-net-dock" and
"sys-usb-dock"?  When you get to your desk, just reboot with the dock
attached--for very well-justified security reasons--and upon entering
the desktop, switch the network provider for "sys-firewall" from
"sys-net" to "sys-net-dock" and manually start "sys-usb-dock".

-- 
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/8090d95a-7fb3-1497-58e4-cb989a3d5476%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] signal-desktop?

[g80vmgmsqw]

haaber:
>> It's running fine for me from a flatpak --user install ... has the
>> advantage that the template only needs flatpak and all signal is in the
>> appVM only.
>>
>> Joh
>>
>> On Fri, 2019-01-04 at 18:57 -0600, Sven Semmler wrote:
>>> Hi,
>>>
>>> I just installed signal-desktop (in the template) and now try to run
>>> it in the appVM. The app starts and I can see the window border, but
>>> nothing inside the window.
>>>
>>> Haven't done much diagnosis yet. Just wondering if someone here
>>> recently installed signal-desktop on a debian-9 based qube and has
>>> some hints for me.
> 
> I tested & get same problem as Sven. Could you please explain the
> flatpak approach, Joh?  Besides the usage for signal-desktop this may be
> helpful in other cases as well!   Thank you, Bernhard
> 

See https://github.com/signalapp/Signal-Desktop/issues/2971 .

Try launching signal-desktop with the "--disable-gpu" parameter.

-- 
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/ab5ee4d5-ed62-606b-c8af-b09e3d2ab412%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Using an OnlyKey

[g80vmgmsqw]

John Maher:
> I have an OnlyKey and have been unable to figure out how to make use of it in 
> Qubes OS 4.0.
> 
> Relevant info:
> 
> * OnlyKey requires either its app being opened on the computer or one's 
> ability to go to https://apps.crp.to (simply via a browser) in order to set 
> its time.
> * I used info from this page 
> https://www.qubes-os.org/doc/usb/#how-to-use-a-usb-keyboard to get the 
> OnlyKey to operate as a USB keyboard. Doing this resulted in the OnlyKey 
> being attached to sys-usb and outputting text (password info) in dom0 and any 
> other qube. 
> * Although the OnlyKey can output like a USB keyboard in any qube, it cannot 
> get its time set without being specifically attached to an appVM that either 
> has the OnlyKey app or can access https://apps.crp.to, so TOTP will not 
> function.
> * Using the yellow drop down icon to attach the OnlyKey to a qube that has 
> the app results in (1) the time on the OnlyKey being set, and (2) the OnlyKey 
> no longer working as a USB keyboard anywhere.
> * Detaching from the qube does not restore the OnlyKey's ability to function 
> as a USB keyboard.
> 
> Short of installing the OnlyKey app in sys-usb, is there anything else I can 
> try? (And I don't even know if that would work.)
> 
> Even if I decided it was ok to install the app in sys-usb, sys-usb is based 
> on Fedora, and OnlyKey only has a deb package. Installing on Fedora has 
> proven to be very problematic.
> 
> Thanks for any help you can provide.
> 
> John
> 

Hi John,

I don't have an OnlyKey and unfortunately probably can't really help you
to debug the issues with it not being able to act again as an HID device
after attaching it directly to a VM.

However, you can absolutely use a Debian-based VM as your sys-usb qube;
just install the Debian 9 template and set your sys-usb qube to use it
as its template.  Also make sure the qubes-usb-proxy package is installed.

As for the HID issues, I do have one suggestion: have you tried not only
detaching the device from the AppVM, but also physically removing the
USB device and re-inserting it?

Best,
Andrew


-- 
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/323247f7-f155-f700-1e62-ca21cb6359ca%40riseup.net.
For more options, visit https://groups.google.com/d/optout.