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

[Message part 1 (text/plain, inline)]
Package: pyqt5-dev-tools
Version: 5.7+dfsg-5+b1
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
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 (text/plain, attachment)]
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

On August 15, 2017 2:52:42 PM EDT, Federico Brega <charon.66@gmail.com> wrote:
>Package: pyqt5-dev-tools
>Version: 5.7+dfsg-5+b1
>Severity: wishlist
>Tags: patch
>User: reproducible-builds@lists.alioth.debian.org
>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.

This should be addressed upstream.  I don't think we should have Debian unique code generation.

Rather than the maintainers try to mediate the conversation, I think it would be better if you discussed it with them directly:

https://www.riverbankcomputing.com/mailman/listinfo/pyqt

Scott K

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

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

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/

[Message part 1 (text/plain, inline)]
Version: 5.10.1+dfsg-1

Hi,

pyqt5-dev-tools builds reproducible since version 5.10.1+dfsg-1, let's 
close this bug now.

Cheers,
Philip

[OpenPGP_signature (application/pgp-signature, attachment)]

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

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