Bugzilla – Bug 1208478
tigervnc embeds random RSA key
Last modified: 2023-03-19 20:16:23 UTC
While working on reproducible builds for openSUSE, I found that our tigervnc package does not build reproducibly because it embeds a private key with timestamps in its .jar --- old /usr/share/vnc/classes/VncViewer.jar/META-INF/TIGERVNC.RSA (hex) +++ new /usr/share/vnc/classes/VncViewer.jar/META-INF/TIGERVNC.RSA (hex) @@ -1,8 +1,8 @@ 000000c0 74 77 61 72 65 20 44 65 76 65 6c 6f 70 6d 65 6e |tware Developmen| 000000d0 74 31 11 30 0f 06 03 55 04 03 13 08 54 69 67 65 |t1.0...U....Tige| 000000e0 72 56 4e 43 30 1e 17 0d 32 33 30 32 31 39 30 39 |rVNC0...23021909| -000000f0 35 31 32 30 5a 17 0d 34 33 30 32 31 34 30 39 35 |5120Z..430214095| -00000100 31 32 30 5a 30 7f 31 0b 30 09 06 03 55 04 06 13 |120Z0.1.0...U...| +000000f0 35 32 34 33 5a 17 0d 34 33 30 32 31 34 30 39 35 |5243Z..430214095| +00000100 32 34 33 5a 30 7f 31 0b 30 09 06 03 55 04 06 13 |243Z0.1.0...U...| 00000110 02 55 53 31 0e 30 0c 06 03 55 04 08 13 05 54 65 |.US1.0...U....Te| 00000120 78 61 73 31 0f 30 0d 06 03 55 04 07 13 06 41 75 |xas1.0...U....Au| 00000130 73 74 69 6e 31 1d 30 1b 06 03 55 04 0a 13 14 54 |stin1.0...U....T| Is that key used? And for what?
That is a self-signed certificate generated to sign the .jar file and is necessary to enable some functionality on the java vncviewer. These certificates have a validity period, and it looks like that is the timestamp you see. Because of how the certificate is generated, each time it is built, the validity of the cert is changed from the current build date until 20 years. I think I can change the current date to a specific date i.e. make the validity period from e.g. 01-01-2023 to 01-01-2043. I think that would make the same timestamp from the cert always. Would that make tigervnc reproducibly? Apart from this certificate, the java client also has other timestamps to tell when it was built, I could change that too, that's more trivial.
The timestamp is only one part. The more tricky part is that a random key is generated (in my test I had only replaced /dev/(u)random with /dev/zero to avoid that randomness = https://github.com/bmwiedemann/reproducible-faketools/blob/master/reproducible-faketools.spec#L145 ). But if it is meant to secure something, we probably do not want everyone to be able to reproduce the same private key. Or would it not matter? This makes it tricky. For secure-boot, we keep the private key in OBS and use https://github.com/openSUSE/pesign-obs-integration/ to unpack+sign+repack. But even that is not so nice.
(In reply to Bernhard Wiedemann from comment #3) > The timestamp is only one part. > The more tricky part is that a random key is generated (in my test I had > only replaced /dev/(u)random with /dev/zero to avoid that randomness = > https://github.com/bmwiedemann/reproducible-faketools/blob/master/ > reproducible-faketools.spec#L145 ). > But if it is meant to secure something, we probably do not want everyone to > be able to reproduce the same private key. Or would it not matter? The use of that signing key is a requisite of the java vncviewer to use the system clipboard of the server it connects. To make the connection secure you can configure the connection to use x509 cert or other security methods VNC provides (this is something out of the build scope and not related with the key we are talking about). From my perspective, I would say there is no harm in using the same private key.
This key should not be in the package, but generated on the host during installation if it does not already exist. Additionally document how for infrastructure deployments this can be done by the admins.
For reference: The TigerVNC build process seems to support the use of a predefined Java keystore, in which case no self-signed certificate will be generated: https://github.com/TigerVNC/tigervnc/blob/1.13-branch/java/cmake/SignJar.cmake#L12