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.

Federico Brega:

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

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,
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.
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.

Hi Ximin,
This is the perfect for upstream bug, a debian patch would be tool
large, and nor really robust.
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.

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.

Hi,

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

Cheers,
Philip