Bug#872285: pyqt5-dev-tools: please make the built resources reproducible (randomness)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#872285: pyqt5-dev-tools: please make the built resources reproducible (randomness)

Federico Brega
Package: pyqt5-dev-tools
Version: 5.7+dfsg-5+b1
Severity: wishlist
Tags: patch
User: [hidden email]
Usertags: randomness

Hello.

I noticed that the python files generated by pyrcc5 are not reproducible.

I attached a patch to set the seed of QHash, which is used by the cpp part of pyrcc. This removes the randomness out of QHash, so generating the same resource file twice gives identical files.

set_qhash_seed.diff (350 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5

Ximin Luo-5
Federico Brega:

> Hello,
>
> I'm packaging an application making use of pyrcc5 and I noticed the
> nondeterminism it adds.
> I see[1] that this is currently description is not correct.
> You can see that pyrcc5 uses QHash, which is made to avoid algorithmic
> complexity attacks[2]
> introducing a randomization.
>
> There are two possible solutions[2]: set the environment variable
> QT_HASH_SEED to a constant value before
> pyrcc5 is called (this is my current workaround) or call qSetGlobalQHashSeed().
>
> I can help with the implementation if needed.
>
> Regards
> --
> Federico
>
> [1] https://tests.reproducible-builds.org/debian/issues/unstable/nondeterminism_added_by_pyqt5_pyrcc5_issue.html
> [2] http://doc.qt.io/qt-5/qhash.html
>

Hi Federico,

It might be safer to subclass QHash into a deterministic QDetHash or something. This would allow one to use QHash both non-deterministically (to protect against DoS attacks) and deterministically in the same program, depending on the use-case.

For example, the rust compiler internally uses a deterministic hash table but offers a non-deterimistic version in its standard library, see https://github.com/rust-lang/rust/issues/34902 for details.

You are setting seed = 0 in a header file. If this is a public header file, then anyone that #includes it would lose protection against those attacks, not just pyrcc.

X

--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Reply | Threaded
Open this post in threaded view
|

Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5

Federico Brega
In reply to this post by Federico Brega
Hi Ximin,

> It might be safer to subclass QHash into a deterministic QDetHash or something. This would allow one to use QHash both non-deterministically (to protect against DoS attacks) and deterministically in the same program, depending on the use-case.
>
> For example, the rust compiler internally uses a deterministic hash table but offers a non-deterimistic version in its standard library, see https://github.com/rust-lang/rust/issues/34902 for details.
This is the perfect for upstream bug, a debian patch would be tool
large, and nor really robust.
For sure any upstream solution is better then a debian patch.

> You are setting seed = 0 in a header file. If this is a public header file, then anyone that #includes it would lose protection against those attacks, not just pyrcc.
My understanding was that rcc.h is a private header, which is only
included by the python module pyrcc which is also private, and can be
used only within PyQt.
The only alternative I can implement is changing the shell wrapper
(pyrcc5) that calls python3, the QT_HASH_SEED variable can be set in
this wrapper, so it is clear than only pyrcc can be affected.

--
Federico

Reply | Threaded
Open this post in threaded view
|

Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5

Federico Brega
In reply to this post by Ximin Luo-5
Hi Ximin,

> It might be safer to subclass QHash into a deterministic QDetHash or something. This would allow one to use QHash both non-deterministically (to protect against DoS attacks) and deterministically in the same program, depending on the use-case.
>
> For example, the rust compiler internally uses a deterministic hash table but offers a non-deterimistic version in its standard library, see https://github.com/rust-lang/rust/issues/34902 for details.
This is the perfect for upstream bug, a debian patch would be tool
large, and nor really robust.

> You are setting seed = 0 in a header file. If this is a public header file, then anyone that #includes it would lose protection against those attacks, not just pyrcc.
My understanding was that rcc.h is a private header, which is only
included by the python module pyrcc which is also private, and can be
used only within PyQt.
The only alternative I can implement is changing the shell wrapper
(pyrcc5) that calls python3, the QT_HASH_SEED variable can be set in
this wrapper, so it is clear than only pyrcc can be affected.

For sure any upstream solution is better then a debian patch.


--
Federico

Reply | Threaded
Open this post in threaded view
|

Bug#872285: header file is no issue

Salvo Tomaselli-3
In reply to this post by Federico Brega
The header file is not part of a library; it's just internal. So there
is no issue at all in changing it like that.


--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

http://ltworf.github.io/ltworf/