Hello, I would like to ask for and exception that would allow the Volatility framework (python-volatility) to use the pytho2 for build and runtime. The tool unfortunately doesn't support python3 - unfortunately not even close to getting one.
Unfortunately its capabilities in dissecting the memory dumps for memory forensics is unmatched with any other opensource tool so I would like to keep it as long as python2 runtime is present in Fedora or untill the framework is migrated to python3. I believe that for things like forensics it is better to have tools with defined and repeatable build process in Fedora distribution rather than forcing users to download ad-hoc stuff using pip.
Thank you Michal Ambroz
Context: https://bugzilla.redhat.com/show_bug.cgi?id=1738194
python2-setuptools and python2-crypto are also needed.
+1 assuming the python2-crypto maintainers are on board. Cc @pghmcfc @firewing
Metadata Update from @churchyard: - Issue tagged with: python 2 exception
Can python2-cryptodomex not be used instead of python2-crypto (would need some amount of porting but at least that is maintained upstream, whilst python2-crypto is not)?
I've blocked https://bugzilla.redhat.com/show_bug.cgi?id=1761070 until the decision here is made.
Also, cc @melmorabity
I also would prefer if pycryptodome would be used instead of outdated and unsupported pycrypto.
fwiw count me out if waiting for a response from me, I haven't maintained pycrypto in a little while now.
Hello, To make clear the expectations - I probably would not have capacity till the f31 release / f32 branching to migrate from python2-crypto to python2-cryptodomex as suggested by @pghmcfc . I do not have sufficient insight to neither the codebase of volatility or difference of those 2 crypto frameworks. If you have some experience with that I would welcome some help / patch for that.
@pghmcfc Assuming it would still use python-crypto, is that OK with you?
As a short-term fix I'm OK with keeping python-crypto around but I'd like to see upstreams encouraged to make the relatively simple (unless doing something esoteric or insecure) switch to pycryptodomex.
See https://www.pycryptodome.org/en/latest/src/vs_pycrypto.html
In any case, all I'm doing with security issues on pycrypto is backporting the fixes from pycryptoddome.
After 1 week, this ticket is at +1,0,-0. Waiting for another week.
The use of python-crypto in the package seems to be:
$ grep -rwn Crypto . ./volatility-2.6.1/setup.py:86: 'packages': opts['packages'] + ['socket', 'ctypes', 'Crypto.Cipher', 'urllib', 'distorm3', 'yara', 'xml.etree.ElementTree'], ./volatility-2.6.1/volatility/win32/domcachedump.py:34:from Crypto.Hash import HMAC ./volatility-2.6.1/volatility/win32/domcachedump.py:35:from Crypto.Cipher import ARC4, AES ./volatility-2.6.1/volatility/win32/hashdump.py:32:from Crypto.Hash import MD5, MD4 ./volatility-2.6.1/volatility/win32/hashdump.py:33:from Crypto.Cipher import ARC4, DES ./volatility-2.6.1/volatility/win32/lsasecrets.py:34:from Crypto.Hash import MD5, SHA256 ./volatility-2.6.1/volatility/win32/lsasecrets.py:35:from Crypto.Cipher import ARC4, DES, AES
And at least ./volatility-2.6.1/volatility/win32/hashdump.py calls the constructors with explicit mode argument, which is one of the requirements mentioned in the cryptodomex's vs_pycropto.html page. It looks like this can be ported very easily. I would make this myself, but the package has no test suite and I have no idea how to verify if the result would be correct.
I'll vote +1, reluctantly.
I would make this myself, but the package has no test suite and I have no idea how to verify if the result would be correct.
Hello Zbysek, all of the mentioned files are non-essential part of Volatility, and can be tested separately. The code actually came from creddump tool.
If you provide patch I would be able to test whether it works or not.
It can be tested by taking memory image samples from https://github.com/volatilityfoundation/volatility/wiki/Memory-Samples For example images from "Jackcr's forensic challenge" from https://t.co/Rfx8Iw7j would work.
It can be tested by: export VOLATILITY_LOCATION=/path/to/jackcr-challenge/ENG-USTXHOU-148/memdump.bin export VOLATILITY_PROFILE=WinXPSP2x86 vol cachedump vol hashdump vol lsadump
Best regards Michal Ambroz
Patched and tested - it works on F30. Just replacing the "Crypto" with "Cryptodome" was enough. Pushed this to rawhide - https://koji.fedoraproject.org/koji/taskinfo?taskID=38482175.
so the exception request is for python2-volatility, python2-pycryptodomex, python2-setuptools?
Is @melmorabity on board?
I withdraw my vote until the maintainers of all involved packages are on board. We cannot force package maintainers to maintain Python 2 packages. Alternatively, you can commit to package separate python2-pycryptodomex source RPM if the maintainer of python-pycryptodomex won't respond.
I didn't know about the beta release of volatility for python3. https://github.com/volatilityfoundation/volatility/issues/598 https://github.com/volatilityfoundation/volatility3/
If we are speaking about fc32 and not removal from fc31, then I have got much more confidence now that it would be possible to switch over to python3.
I plan to switch over in rawhide to this new codebase. I need some time to repackage and test.
May I close this exception request or would you like to still get the exception to get more time to test the new version before adding it to rawhide?
For sure I will need some time. Please what are the deadlines if this request is closed?
We plan to start removing packages no sooner than 2019-11-15.
OK that should be enough to have the package in some state switched to python3. In worst case buggy and not tested completely, but that is what is rawhide for right. Let's close this request.
Metadata Update from @rebus: - Issue close_status updated to: Rejected - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.