Bug#1074617: Subject:Running libvirt without dnsmasq broken due to Debian’s packaging

[proc...@riseup.net]

Package: libvirt-daemon
Severity: normal

Expected behavior:
Running libvirt should be possible without dnsmasq should be possible

Actual behavior:
Libvirt crashes when dnsmasq is not installed by default.

Additional information:
Upstream libvirt confirmed, that Debian packages all into 
libvirt-daemon. [1] This is apparently not how upstream libvirt has 
designed it to be. Could you look into it please?


[1] 
https://lists.libvirt.org/archives/list/us...@lists.libvirt.org/thread/PVI6KFUVNUKG6FZK7UOHM5PMSIWNHLNC/ 

Bug#1074069: RFP: canokey-qemu

[proc...@riseup.net]

Package: wnpp
Severity: wishlist


* Package name: canokey-qemu
  Upstream Author : ZenithalHourlyRate Hongren Zheng
* URL : https://github.com/canokeys/canokey-qemu
* License : Apache-2.0 license
  Programming Lang: C
  Description : virtual canokey to the guest OS

CanoKey [1] is an open-source secure key with supports of:

- U2F / FIDO2 with Ed25519 and HMAC-secret
- OpenPGP Card V3.4 with RSA4096, Ed25519 and more 2
- PIV (NIST SP 800-73-4)
- HOTP / TOTP
- NDEF

There is an emulated QEMU device in the form of libcanokey-qemu which is 
the focus of this wishlist request. This feature will allow safe usage 
of ones keys in a virtual environment with the trust issues that 
accompany physical smartcard device implementations. Canokey also 
provides a more straightforward and generic approach to interacting with 
secure key material compared to swtpm-tools which support a subset of 
these ciphers and algos in a TPM only context.


Once packaged, this feature will bring what was exclusively a feature 
(Split GPG [3]) limited to users of security hypervisor distros like 
QubesOS to the masses.



[1] https://canokeys.org/
[2] https://www.qemu.org/docs/master/system/devices/canokey.html#id9
[3] https://www.qubes-os.org/doc/split-gpg/

Bug#941951: RFP: tpm2-pk11

[proc...@riseup.net]

Package: wnpp
X-Debbugs-CC: whonix-de...@whonix.org

* Package name: tpm2-pk11
Version : ?
Upstream Author : Iwan Timmer
* URL   : https://github.com/irtimmer/tpm2-pk11
* License : BSD 2-Clause "Simplified" License
Programming Lang:   C
Description  :  PKCS#11 Module for TPM 2.0

TPM2-PK11 provide a PKCS#11 backend for TPM 2.0 chips.
This allows you to use your TPM keys in every application which support the 
PKCS #11 standard.
For more information about howto setup keys, certificates and applications see 
the wiki .[0]

Features

Sign and decrypt using private RSA key stored in TPM
Provide on disk stored certificate in DER format to applications using PKCS 
#11

Supported applications

OpenSSH Client (SSH key in TPM)
Firefox (Private key of Client certificate in TPM)
GnuPG using gnupg-pkcs11-scd (PGP key in TPM) [1]



[0] https://github.com/irtimmer/tpm2-pk11/wiki
[1] gnupg-pkcs11-scd is already packaged for Debian

In plain English: This package has the awesome benefit of turning a TPM device 
into a universal smartcard 
for all different kinds of keys.

For our (Whonix) virtualized privacy distro this means that users can be sure 
their keys are safe 
even if the VM is infected.

Bug#941939: RFP: swtpm - Software TPM Emulator for QEMU/Libvirt

[proc...@riseup.net]

Package: wnpp
X-Debbugs-CC: whonix-de...@whonix.org

* Package name: swtpm
Version : 0.2.0
Upstream Author : Stefan Berger 
* URL   : https://github.com/stefanberger/swtpm 

* License : 3-clause BSD license
Programming Lang:   C
Description  :  Software TPM Emulator for QEMU/Libvirt

Dear maintainer when testing out the virtual TPM functionality of QEMU it gave 
an error that the swtpm doesn't exist 
at its expected path. When discussing it with upstream they told me it doesn;t 
seem to be packaged for Debian yet and
that is indeed the case. 

A virtual TPM has the benefit of storing secrets safely even when interfacing 
with untrusted guests. 
There are multiple utilities for leveraging its functionality into a universal 
smartcard of sorts, for storing GPG and SSH
 keys securely. 

Please consider packaging it in time for Debian Bullseye.

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/30/19 11:38 AM, Patrick Schleizer wrote:
> On https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html
> its developer wrote:
>
>> [...]
>> - the in-kernel crypto API has an RNG framework that provides a DRBG.
> This
> DRBG is used for in-kernel crypto API purposes. It may be accessed from
> user
> space via AF_ALG [2]. Yet, this is not accessible from /dev/random, /dev/
> urandom or getrandom. The DRBG uses the in-kernel JitterRNG to seed itself.
>> [...]
> Better entropy for in-kernel crypto API purposes sounds good as a
> general security enhancement.
>
> Fedora enables this kernel module by default, too.
>
> Does this sound like a good idea to enable loading this kernel module by
> default in Debian?
>
Stephan confirms that the Kernel DRBG is also important for crypto
operations that don't use /dev/random like the ECC cipher and much more.
I think it is important to revisit this in that case and add the jitter
module to the initramfs:


Stephan:

"Always assume that a weak RNG is bad. The DRBG is used for kernel
crypto API

for generating keys and other data. For example, the ECC key generation uses 
the DRBG and NOT the get_random_bytes (the /dev/urandom in-kernel equivalent). 
There are quite a number of other use cases.

I know, it is unfortunate that we have 2 RNGs in the kernel. But a 
consolitation approach I offered at [1] was not considered."

"So, the jitterentropy kernel module is only used by the kernel DRBG. And it 
will load the jitterentropy kernel module automatically considering that the 
module name is the same as the cipher name "jitterentropy_rng". Of course, 
this only applies if the kernel module is available in the execution 
environment (like the initramfs) and the DRBG is initialized during that time."

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/26/19 4:55 PM, Luca Boccassi wrote:
> On Fri, 2019-04-26 at 16:47 +0000, proc...@riseup.net wrote:
>> OK. I found out this is not a problem on Fedora stations likely
>> because
>> they have the module built with 'y' instead of 'm'. Can you please
>> add
>> this to your next point release?
> If you want the module to always load, you can simply list it in
> /etc/modules - have you tried that?
>
Update:

According to jitter's author Stephan Mueller, the kernel module has no
effect on the quality of entropy injected in /dev/?random (it only
handles the kernel DRBG). /dev/?random entropy is only in the domain of
the userspace jitternetropy-rngd service which already works for us:

Quote from Stephan:

"As I tried to outline in the previous email: the /dev/random or /dev/urandom 
will NOT benefit from the in-kernel Jitter RNG. Only the user space 
jitterentropy-rngd from user space would inject entropy into /dev/random / /
de/urandom.

Therefore, I do not think that inserting the jitterentropy KO will help you 
for your goal."


You can close both tickets I guess. Thanks for everyone's input.



signature.asc
Description: OpenPGP digital signature

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/26/19 4:55 PM, Luca Boccassi wrote:
> On Fri, 2019-04-26 at 16:47 +0000, proc...@riseup.net wrote:
>> OK. I found out this is not a problem on Fedora stations likely
>> because
>> they have the module built with 'y' instead of 'm'. Can you please
>> add
>> this to your next point release?
> If you want the module to always load, you can simply list it in
> /etc/modules - have you tried that?
>
Yes I've added a conf at /etc/modules-load.d/jitterentropy_rng.conf and
it loads as expected.

My suggestion was so that it would work in general on a default system
for users who don't know this is needed for the jitter service to be
effective.




signature.asc
Description: OpenPGP digital signature

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

OK. I found out this is not a problem on Fedora stations likely because
they have the module built with 'y' instead of 'm'. Can you please add
this to your next point release?

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

On 4/25/19 8:21 PM, Ben Hutchings wrote:
> Control: reassign -1 jitterentropy-rngd
> Control: severity -1 wishlist
>
> There is no dependency between the user-space daemon and the kernel
> module.  And I don't see any kernel bug here, but this might be a
> wishlist item for the user-space package.
>
> Ben.
>
I see. Thanks Ben. Is there anything you guys can do at your end to
force this particular module to load on all hosts running a kernel that
supports it? Reason is crypto entropy is exceptionally important.

Thanks.




signature.asc
Description: OpenPGP digital signature

Bug#927974: jitterentropy_rng.ko never loads: jitternentropy-rngd doesn't complain

[proc...@riseup.net]

Package: jitterentropy-rngd
Version: 1.0.8-3
Severity: important

Dear Maintainer,

As part of my work on a downstream privacy distro, I tested jitternentropy-rngd 
while integrating it and discovered the complementing kernel module 
jitterentropy_rng.ko never loads on boot as it is supposed to when the 
userspace jitterentropy daemon is installed. As a VM based OS a reliable 
entropy source that guarantees /dev/urandom is safely seeded is a priority. To 
test if it works one would see the signs described by the jitter dev Stephan 
Mueller [0]. I've confirmed that oddly no dmesg messages appear and the 
userspace service churns along fine despite the module silently never loading. 
Please try to fix this when possible. I have reported this problem against the 
kernel package too.

TIA 

[0] https://www.whonix.org/pipermail/whonix-devel/2019-April/001365.html
[1] https://www.whonix.org/pipermail/whonix-devel/2019-April/001366.html

Bug#927972: jitterentropy_rng.ko never loads

[proc...@riseup.net]

Package: linux-image-amd64
Version: 4.19+104
Severity: important

Dear Maintainer,

As part of my work on a downstream privacy distro, I tested jitternentropy-rngd 
while integrating it and discovered the complementing kernel module 
jitterentropy_rng.ko never loads on boot as it is supposed to when the 
userspace jitterentropy daemon is installed. As a VM based OS a reliable 
entropy source that guarantees /dev/urandom is safely seeded is a priority. To 
test if it works one would see the signs described by the jitter dev Stephan 
Mueller [0]. I;ve confirmed that oddly no dmesg messages appear and the 
userspace service churns along fine despite the module silently never loading. 
Please try to fix this when possible. I will report this problem against the 
jitter package too.

TIA 

[0] https://www.whonix.org/pipermail/whonix-devel/2019-April/001365.html
[1] https://www.whonix.org/pipermail/whonix-devel/2019-April/001366.html

Bug#927402: zulucrypt-gui: 100 character password limit

[proc...@riseup.net]

Package: zulucrypt-gui
Version: 5.4.0-3
Severity: important

Dear Maintainer,

As part of my work on a downstream privacy distro, I tested zulucrypt-gui 
before integrating it and discovered it silently enforces a 100 character limit 
on passphrases which is much shorter than what cryptsetup allows. Since we 
recommend users go for a 20 word diceware passphrase they will always overrun 
this limit. It turned out to be a Qt bug and is now fixed in zulucrypt git and 
will be included in the release coming out next month. Please consider and 
back-porting the patch to the frozen version in stable-next (Buster).

TIA 

https://github.com/mhogomchungu/zuluCrypt/issues/113#issuecomment-484627804
https://github.com/mhogomchungu/zuluCrypt/issues/113#issuecomment-484633815