Debian package requires python2

[rudis]

Hello,

python2 is end-of-life and will be removed in Debian Bullseye (next Release). This will break the onerng package.

The following patch against onerng_3.6.orig.tar.gz (not a pull request as I didn't find the repository) fixes this issue for me.

diff -u -r onerng_3.6.orig/debian/control onerng_3.6/debian/control
--- onerng_3.6.orig/debian/control	2017-01-15 03:49:59.000000000 +0100
+++ onerng_3.6/debian/control	2020-11-17 08:29:08.347563330 +0100
@@ -1,5 +1,5 @@
 Source: onerng
-Section: contrib
+Section: utils
 Priority: extra
 Maintainer: Paul Campbell <paul@taniwha.com>
 Build-Depends: debhelper (>= 8.0.0), autotools-dev
@@ -8,9 +8,9 @@
 
 Package: onerng
 Architecture: all
-Depends: rng-tools, udev, python, python-gnupg, gnupg, at, openssl
+Depends: rng-tools, udev, python3, python3-gnupg, gnupg, at, openssl
 Description: Driver for the OneRNG open source hardware entropy generator
 	OneRNG is an open source hardware entropy generator in a USB dongle - it does not
 	require any special kernel drivers but does need a set of udev and sstem scripts to start the
-	rmgd daemon (from the rng-tools package) when the device is plugged in
+	rngd daemon (from the rng-tools package) when the device is plugged in
 
diff -u -r onerng_3.6.orig/debian/onerng/sbin/onerng.sh onerng_3.6/debian/onerng/sbin/onerng.sh
--- onerng_3.6.orig/debian/onerng/sbin/onerng.sh	2017-10-01 10:11:50.000000000 +0200
+++ onerng_3.6/debian/onerng/sbin/onerng.sh	2020-11-17 08:07:59.135615092 +0100
@@ -83,7 +83,7 @@
 		echo "cmdw" >/dev/$2		# flush entropy pool
 
 		# process the data, verify its signature, log any errors
-		python /sbin/onerng_verify.py $t 
+		/sbin/onerng_verify.py $t 
 
 		# res 1 err, 0 OK
 		res=$?
diff -u -r onerng_3.6.orig/debian/onerng/sbin/onerng_verify.py onerng_3.6/debian/onerng/sbin/onerng_verify.py
--- onerng_3.6.orig/debian/onerng/sbin/onerng_verify.py	2017-10-01 10:11:50.000000000 +0200
+++ onerng_3.6/debian/onerng/sbin/onerng_verify.py	2020-11-17 08:07:35.039609221 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 #
 #	OneRNG firmware verification
 #	(C) Copyright Paul Campbell Moonbase Otago 2014
diff -u -r onerng_3.6.orig/files/onerng.sh onerng_3.6/files/onerng.sh
--- onerng_3.6.orig/files/onerng.sh	2017-10-01 10:00:49.000000000 +0200
+++ onerng_3.6/files/onerng.sh	2020-11-17 08:07:59.147615096 +0100
@@ -83,7 +83,7 @@
 		echo "cmdw" >/dev/$2		# flush entropy pool
 
 		# process the data, verify its signature, log any errors
-		python /sbin/onerng_verify.py $t 
+		/sbin/onerng_verify.py $t 
 
 		# res 1 err, 0 OK
 		res=$?
diff -u -r onerng_3.6.orig/files/onerng_verify.py onerng_3.6/files/onerng_verify.py
--- onerng_3.6.orig/files/onerng_verify.py	2017-01-15 03:49:59.000000000 +0100
+++ onerng_3.6/files/onerng_verify.py	2020-11-17 08:07:35.031609220 +0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 #
 #	OneRNG firmware verification
 #	(C) Copyright Paul Campbell Moonbase Otago 2014

Regards
Simon

[rudis]

The patch also fixes a typo in the description and changes the section to "utils" because "contrib" is not a valid section in Debian.

[MoonbaseOtago]

On Tuesday, 17 November 2020 8:51:25 PM NZDT rudis wrote: python2 is end-of-life and will be removed in Debian Bullseye (next Release). This will break the onerng package. The following patch against onerng_3.6.orig.tar.gz (not a pull request as I didn't find the repository) fixes this issue for me.

thanks - this is also part of my upcoming fix (possibly slightly differently, I'll go over yours as well and incorporate anything useful) Paul

[TheWanderer1983]

Any update to this?

[pymander]

Also wondering if there is an update to this.

[TimidRobot]

Debian 11 (bullseye)

Python alternative

(Instead of performing this mitigation, see "Custom OneRNG 3.7 package", below)

On Debian, at least, the alternatives system can be used to mitigate the use of python (Python 2):

sudo update-alternatives --install /usr/local/bin/python python /usr/bin/python3 50

Forced dpkg install

(Instead of performing this mitigation, see "Custom OneRNG 3.7 package", below)

The Python 2 dependencies can be ignored on installation:

sudo dpkg -i --force-depends onerng_3.6-1_all.deb

LED doesn't dim

The LED doesn't dim (as detailed per "Test OneRNG Operation" on https://onerng.info/onerng/), but this is expected per mailing list [onerng talk] OneRNG does not work on Ubunti 21.10:

At the moment you are quite right; the OneRNG helper software does not work with recent distributions of Linux correctly. There have been a lot of changes in both the kernel's random code, and in the userspace tools - the latter due to distributions preferring systemd options to existing daemons.

I'm not the expert in the userspace tools, so I'll have to do another dive into the current state of affairs; but my understanding is that /dev/random no longer works the way it used to - it will not make extra calls to hardware entropy sources when under heavy use, and instead will continue to deliver data from a software PRNG; and therefore even if all the other software is set up correctly, you won't see any change in the OneRNG LEDs.

Verification

1. Python alternative, above
2. Forced dpkg install, above
3. insert OneRNG USB device
4. Verify the appropriate processes are started:

   ps -C openssl,rngd jf

     PPID     PID    PGID     SID TTY        TPGID STAT   UID   TIME COMMAND
         1   31290    6477    6477 ?             -1 SNLl     0   0:00 rngd -f --rng-entropy=.93750 -r /dev/stdin
         1   31289    6477    6477 ?             -1 SN       0   0:00 openssl enc -aes128 -nosalt -in /dev/ttyACM0 -pass file:/dev/tt
   

5. Manually run rngd in foreground for ~10 seconds before stopping it with CTRL-C

   sudo rngd -f --rng-entropy=.93750 -r /dev/ttyACM0

   rngd 2.2 starting up...
   entropy feed to the kernel ready
   ^Cstats: bits received from HRNG source: 60064
   stats: bits sent to kernel pool: 512
   stats: entropy added to kernel pool: 480
   stats: FIPS 140-2 successes: 3
   stats: FIPS 140-2 failures: 0
   stats: FIPS 140-2(2001-10-10) Monobit: 0
   stats: FIPS 140-2(2001-10-10) Poker: 0
   stats: FIPS 140-2(2001-10-10) Runs: 0
   stats: FIPS 140-2(2001-10-10) Long run: 0
   stats: FIPS 140-2(2001-10-10) Continuous run: 0
   stats: HRNG source speed: (min=6.593; avg=19.377; max=908.261)Mibits/s
   stats: FIPS tests speed: (min=77.851; avg=89.407; max=97.314)Mibits/s
   stats: Lowest ready-buffers level: 2
   stats: Entropy starvations: 0
   stats: Time spent starving for entropy: (min=0; avg=0.000; max=0)us
   Exiting...
   

OneRNG appears to be functioning OK???

Testing 3.7

(Instead of performing this mitigation, see "Custom OneRNG 3.7 package", below)

The OneRNG new scripts for testing mailing list post includes the following testing 3.7 files:

• onerng_verify.py (attachment.py) (same as 3.6; still requires Python alternative)
• onerng.conf (attachment.bin)
• onerng.sh (attachment-0001.bin)

With the updated /etc/onerng.conf and /sbin/onerng.sh, I do see the OneRNG LED dim every 5 seconds.

Custom OneRNG 3.7 package

This creates an unofficial (danger!) package that does not need the mitigations described above.

On a Debian host:

1. Download onerng_3.6-1_all.deb
2. Extract package contents:

   dpkg-deb -x onerng_3.6-1_all.deb oldpack/
   

3. Extract package metadata:

   dpkg-deb -e onerng_3.6-1_all.deb oldpack/DEBIAN
   

4. Replace oldpack/etc/onerng.conf with Testing 3.7 version
   • OneRNG new scripts for testing
     • onerng.conf (attachment.bin)
5. Replace oldpack/sbin/onerng.sh with Testing 3.7 version
   • OneRNG new scripts for testing
     • onerng.sh (attachment-0001.bin)
6. Modify oldpack/sbin/onerng_verify.py
   • #!/usr/bin/python => #!/usr/bin/python3
7. Modify oldpack/DEBIAN/control
   • Version: 3.6-1 => Version: 3.7-1
   • Depends: rng-tools, udev, python, python-gnupg, gnupg, at, openssl => Depends: rng-tools, udev, python3, python3-gnupg, gnupg, at, openssl
8. Create onerng_3.7-1_all.deb:

   dpkg-deb -Z xz -b oldpack ./