Re: [qubes-users] Re: usb keyboard not working on debian 11 template

2021-10-08 Thread unman
On Wed, Oct 06, 2021 at 10:48:14PM +0200, 'qtpie' via qubes-users wrote:
> Installing qubes-input-proxy-sender in the template it was. Problem solved.
> Thanks awokd!
> 
> Note: to avoid this problem, these should either be default installed
> packages in all templates, or be documented in
> https://www.qubes-os.org/doc/usb-qubes/. If the latter is preferred, I can
> adapt the documentation. Please let me know.
> 

qubes-input-proxy-sender is installed by default in the debian-11
template.
If you are using a minimal template, this is meant for advanced users,
but in any case, installation of qubes-input-proxy-sender is documented
at https://www.qubes-os.org/doc/templates/minimal/

-- 
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/YWArvIPQtqpjNn4I%40thirdeyesecurity.org.


[qubes-users] New article: "Reproducible builds for Debian: a big step forward" by Frédéric Pierret

2021-10-08 Thread Andrew David Wong

Dear Qubes Community,

A new article has just been published on the Qubes website:

"Reproducible builds for Debian: a big step forward" by Frédéric Pierret
https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/

For your convenience, the original Markdown text is reproduced below.



---
layout: post
title: "Reproducible builds for Debian: a big step forward"
categories: articles
author: Frédéric Pierret
---

_This is the second article in the "reproducible builds" series.
Previously: [Improvements in testing and building: GitLab CI and 
reproducible 
builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/)._


In the previous article, [Improvements in testing and building: GitLab 
CI and reproducible 
builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/#reproducible-builds), 
we discussed reproducible builds and our current short-term goals for 
them in Qubes OS. Notably, we aimed to start by building our Debian 
templates such that packages can be installed only when configured 
rebuilders confirm that they really came from the source code we 
publish. Today, we go beyond this expectation.


Reproducible builds: retrieve the past
--

The challenge in reproducible builds lies in rebuilding a package in the 
same environment in which it was officially published. This means that 
we need to retrieve every single package version that was used as 
dependency to rebuild a given package. For Debian, some packages in the 
current release were built several releases in the past but not 
necessarily with the exact same dependencies. In order to retrieve them, 
there is only one solution: a Debian service called 
`snapshot.debian.org`, which is an archive acting as a [Wayback 
Machine](https://web.archive.org/) that allows access to old packages 
based on dates and version numbers. It contains all past and present 
packages that the Debian archive provides. Unfortunately, this service 
is known to suffer significant blocking issues on usability. For 
example, watch the DebConf 2021 talk [Making use of snapshot.debian.org 
for fun and 
profit](https://debconf21.debconf.org/talks/22-making-use-of-snapshotdebianorg-for-fun-and-profit/) 
and have a look at some related Debian issues like 
[#977653](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%977653), 
[#960304](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%960304), 
[#969906](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969906), 
[#969603](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969603), 
and 
[#782857](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%782857). To 
summarize: There are throttling limits and availability issues such as 
repeatedly cutting off connections, returning partial content, etc. As 
announced in our previous article, we developed our own rebuilder tool, 
[debrebuild](https://github.com/fepitre/debrebuild), which is able to 
rebuild a single Debian package together with a rebuilder orchestrator 
[PackageRebuilder](https://github.com/fepitre/package-rebuilder). We 
started to put it in production in order to actively rebuild Qubes OS 
and Debian packages, but it quickly ceased to function, as the 
`snapshot.debian.org` service was unable to sustain the load of 
rebuilding even a single Debian package. That said, the question was: 
How should we proceed in order to make it work? Clearly, those issues 
are critical and make the `snapshot.debian.org` service awful or useless 
for reproducible builds.


Is rebuilding Debian really possible?
-

The `snapshot.debian.org` issues have still not been addressed even 
after several years. The service has existed for more than a decade, yet 
it still suffers from the aforementioned limitations. It's either a 
design problem or a lack of resources, but we still had to do something.


That's why we decided to create our own 
[snapshot](https://github.com/fepitre/debian-snapshot) service. Easy to 
say, but not to do. First, the original snapshot service from Debian is 
roughly 90 TB of repository data. Second, we cannot download files 
easily because only HTTP(S) is available, and downloading multiple files 
means we are impeded by availability issues.
In order to work around the huge volume of data, we decided to get 
repositories from 2017 to today (which corresponds approximately to when 
Debian "Buster" was released) and only related architectures `amd64`, 
`source`, and `all`. (`all` indicates no specific architecture in the 
Debian world.) For the download part itself, we needed to parse the 
metadata of each Debian repository in order to get the list of files to 
download for every timestamp for which a snapshot had been made. Then, 
we developed `resume` and `retry` download functions, which 
unfortunately are brute force download 

[qubes-users] Whonix upgrade fails after interruption

2021-10-08 Thread tetrahedra via qubes-users

I started uprading Whonix using the salt command, but the process was
interrupted.

On retrying, it fails, unable to create the whonix WS VM due to
"permission denied". From journalctl:
Oct 08 11:24:35 dom0 qubesd[2098]: permission denied for call 
b'admin.vm.Create.AppVM'+b'whonix-ws-16' (b'dom0' → b'dom0') with payload of 31 
bytes

(see below for the salt output)

When I run the qvm-create command from the salt output manually, it also
fails, because the whonix-ws-16 template doesn't exist:
$ qvm-create --verbose whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 
--label=red
2021-10-08 11:33:54,499 [MainProcess qvm_create.main:177] app: Error creating 
VM: Got empty response from qubesd. See journalctl in dom0 for details.

I assume all this is related to the failed previous attempt.

How do I reset the state so that I can successfully do the upgrade?




[user@dom0 ~]$ sudo qubesctl state.sls qvm.anon-whonix

[WARNING ] /var/cache/salt/minion/extmods/states/ext_state_qvm.py:146: 
DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
  status = Status(retcode=1, result=False, stderr=err.message + '\n')

[ERROR   ] == ['features'] ==
Virtual Machine does not exist!

== ['tags'] ==
[SKIP] Skipping due to previous failure!
[ERROR   ] == ['present'] ==
== stderr ==
/usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 
--label=red
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 
for details.

== ['prefs'] ==
Virtual Machine does not exist!

== ['features'] ==
[SKIP] Skipping due to previous failure!

== ['tags'] ==
[SKIP] Skipping due to previous failure!
local:
--
  ID: template-whonix-ws-16
Function: pkg.installed
Name: qubes-template-whonix-ws-16
  Result: True
 Comment: Package qubes-template-whonix-ws-16 is already installed
 Started: 11:24:14.138294
Duration: 5796.629 ms
 Changes:
--
  ID: whonix-ws-tag
Function: qvm.vm
Name: whonix-ws-16
  Result: False
 Comment: == ['features'] ==
  Virtual Machine does not exist!

  == ['tags'] ==
  [SKIP] Skipping due to previous failure!
 Started: 11:24:19.979281
Duration: 271.503 ms
 Changes:
--
  ID: whonix-ws-update-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy
  Result: True
 Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state
 Started: 11:24:20.261980
Duration: 14.769 ms
 Changes:
--
  ID: whonix-get-date-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.GetDate
  Result: True
 Comment: File /etc/qubes-rpc/policy/qubes.GetDate is in correct state
 Started: 11:24:20.277092
Duration: 12.533 ms
 Changes:
--
  ID: template-whonix-gw-16
Function: pkg.installed
Name: qubes-template-whonix-gw-16
  Result: True
 Comment: Package qubes-template-whonix-gw-16 is already installed
 Started: 11:24:20.289981
Duration: 1.316 ms
 Changes:
--
  ID: whonix-gw-tag
Function: qvm.vm
Name: whonix-gw-16
  Result: True
 Comment: == ['features'] ==
  [SKIP] Feature already in desired state: ENABLE 'whonix-gw' = 
Enabled

  == ['tags'] ==
  [SKIP] All requested tags already set: 
created-by-dom0,whonix-updatevm
 Started: 11:24:20.291708
Duration: 4714.395 ms
 Changes:
--
  ID: whonix-gw-update-policy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy
  Result: True
 Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state
 Started: 11:24:25.006518
Duration: 7.468 ms
 Changes:
--
  ID: sys-net
Function: qvm.exists
  Result: True
 Comment: /usr/bin/qvm-check sys-net None
 Started: 11:24:25.014322
Duration: 2048.565 ms
 Changes:
--
  ID: sys-firewall
Function: qvm.exists
  Result: True
 Comment: /usr/bin/qvm-check sys-firewall None
 Started: 11:24:27.065077
Duration: 1868.662 ms
 Changes:
--
  ID: sys-whonix
Function: qvm.exists
  Result: True
 Comment: /usr/bin/qvm-check sys-whonix None
 Started: 11:24:28.935733
Duration: 1744.59 ms
 Changes:
--
  ID: whonix-ws-16-dvm
Function: qvm.vm
  Result: False
 Comment: == ['present'] ==
  == stderr ==
  /usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM 
--template=whonix-ws-16 --label=red
  app: Error creating VM: Got empty response from qubesd. See 
journalctl in dom0 for details.

  == ['prefs'] ==
  Virtual Machine does not exist!

  

Re: [qubes-users] Re: [HCL] ThinkPad T430

2021-10-08 Thread Sven Semmler

On 9/11/21 08:23, Will Lewis wrote:

I'm using a 1TB 870 Pro


A few days ago I replaced the 870 QVO with a 860 PRO ... what a difference!!! 
Learned that lesson for sure.

--
 public key: https://www.svensemmler.org/2A632C537D744BC7.asc
fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

--
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/dc4c37a2-ea65-393c-dc61-8924c65ca70d%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-users] HCL - Asus All Series

2021-10-08 Thread Sven Semmler

Hi Stat Pow,

any chance you could tell us the actual model used? Asus motherboards are always reported 
as "All series" in the automatically generated report, but I am trying to clean 
up and make the HCL more useful. So if you can, please share the exact model so I can fix 
it.

/Sven


--
 public key: https://www.svensemmler.org/2A632C537D744BC7.asc
fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

--
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/5a7c000e-05ae-468f-d22d-e43956463409%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature