[Python-modules-team] Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5
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 ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#872285: More info about nondeterminism_added_by_pyqt5_pyrcc5
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 ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
[Python-modules-team] Bug#872285: pyqt5-dev-tools: please make the built resources reproducible (randomness)
Package: pyqt5-dev-tools Version: 5.7+dfsg-5+b1 Severity: wishlist Tags: patch User: reproducible-bui...@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. Description: Make the build reproducible Author: Federico Brega Last-Update: 2017-08-15 --- a/qpy/pyrcc/rcc.h +++ b/qpy/pyrcc/rcc.h @@ -124,6 +124,7 @@ mCompressLevel = -1; mCompressThreshold = 70; mTreeOffset = mNamesOffset = mDataOffset = 0; +qSetGlobalQHashSeed(0); } struct RCCFileInfo ___ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
