Spec URL: http://leteckaposta.cz/505510445 SRPM URL: http://leteckaposta.cz/721026890 Description: hashcat is the world's fastest and most advanced password recovery utility, supporting five unique modes of attack for over 200 highly-optimized hashing algorithms. hashcat currently supports CPUs, GPUs, and other hardware accelerators on Linux, Windows, and macOS, and has facilities to help enable distributed password cracking. Fedora Account System Username: tkorbar Koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=24576838
please use fedorapeople to host your spec files and src.rpm, thank you.
(In reply to Itamar Reis Peixoto from comment #1) > please use fedorapeople to host your spec files and src.rpm, thank you. From [1]: > Upload Your Package > > Upload your SRPM and SPEC files onto the Internet somewhere so that others can > retrieve them. This can be anywhere accessible by a URL, but it is important > that the files be directly accessible, not hidden behind some service that > makes people wait to download things or redirects through advertising pages. The leteckaposta.cz is "somewhere", but the files are not directly downloadable, and I wasn't able to retreive them - I tried Firefox and Seamonkey browsers, but no luck, for me it worked only with the Chrome browser, so it should be fixed. Yes, it's generally better to use the fedorapeople to host the spec/srpm, but Tomas is not Fedora packager yes, so he doesn't have account there, i.e. he hasn't fulfilled the CLA+1 condition yet [2]. [1] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Upload_Your_Package [2] https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#Accessing_Your_fedorapeople.org_Space
Alright so now the files are available at SPEC: https://tkorbar.fedorapeople.org/hashcat.spec SRPM: https://tkorbar.fedorapeople.org/hashcat-4.0.1-1.fc27.src.rpm
(In reply to Tomáš Korbař from comment #3) > Alright so now the files are available at > SPEC: https://tkorbar.fedorapeople.org/hashcat.spec > SRPM: https://tkorbar.fedorapeople.org/hashcat-4.0.1-1.fc27.src.rpm Thanks. At the moment I can see two problems with the package: 1) Bundled lzma_sdk, I don't know how much effort it will take to ubundle it, but I will take a closer look. 2) Unsupported big endian architectures. Well, we can go with the exclude arch, but I would rather find out what's the blocker here. I will bring it upstream.
One more thing to note: $ hashcat --help hashcat: error while loading shared libraries: libhashcat.so.4: cannot open shared object file: No such file or directory I.e. ldconfig call is missing, the fix: add: Requires(post): /sbin/ldconfig Requires(postun): /sbin/ldconfig and: %post -p /sbin/ldconfig %postun -p /sbin/ldconfig to the spec file according to [1]: "MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun" But please keep on mind this is temporal solution, because there is s change proposal [2]. Once accepted the above mentioned change will be unnecessary for f28 (but probably still required for the older Fedoras, e.g. f27). [1] https://fedoraproject.org/wiki/Packaging:ReviewGuidelines [2] https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets
Thanks for help. Fixed.
It seems there are more problems: $ hashcat -b hashcat (v4.0.1) starting in benchmark mode... Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. Note: Using optimized kernel code limits the maximum supported password length. To disable the optimized kernel code in benchmark mode, use the -w option. /usr/bin/OpenCL/: No such file or directory Started: Tue Feb 6 08:06:34 2018 Stopped: Tue Feb 6 08:06:34 2018 The OpenCL directory holds the so called OpenCL "kernels" so it has to be packed in the base package (and the devel subpackage should be dropped until upstream will come with the public headers for their API). Also the /usr/bin/OpenCL/ directory is not good for the OpenCL kernels. You should add the PREFIX to the build phase, i.e.: %make_build SHARED=1 DEBUG=1 PREFIX="%{_usr}" ... Then the hashcat will start looking for the kernels under: /usr/share/hashcat/OpenCL/ which is not the best, but much better than the /usr/bin Another problem is that hashcat then also needs: /usr/share/hashcat/hashcat.hctune /usr/share/hashcat/hashcat.hcstat2 BTW it seems hashcat.hcstat2 is LZMA packed data file,so that's why it bundles the LZMA_SDK. On my intel machine I had to force the OpenCL devices and then it started to do "something": $ hashcat -b --force hashcat (v4.0.1) starting in benchmark mode... Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. Note: Using optimized kernel code limits the maximum supported password length. To disable the optimized kernel code in benchmark mode, use the -w option. install_dir: /usr/bin, resolved_install_folder: /usr/bin /usr/share/hashcat clGetDeviceIDs(): CL_DEVICE_NOT_FOUND clGetDeviceIDs(): CL_DEVICE_NOT_FOUND OpenCL Platform #1: Intel ========================= * Device #1: Intel(R) HD Graphics Haswell Ultrabook GT2 Mobile, 1536/2048 MB allocatable, 20MCU OpenCL Platform #2: The pocl project ==================================== * Device #2: pthread-Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, skipped. OpenCL Platform #3: Mesa, skipped or no OpenCL compatible devices found. Benchmark relevant options: =========================== * --force * --optimized-kernel-enable Hashmode: 900 - MD4 Speed.Dev.#1.....: 314.4 MH/s (66.18ms) Hashmode: 0 - MD5 Speed.Dev.#1.....: 201.4 MH/s (51.60ms) Hashmode: 5100 - Half MD5 Speed.Dev.#1.....: 126.3 MH/s (82.44ms) Hashmode: 100 - SHA1 Speed.Dev.#1.....: 35272.3 kH/s (73.79ms) Hashmode: 1400 - SHA-256 Speed.Dev.#1.....: 11895.5 kH/s (54.77ms) Hashmode: 10800 - SHA-384 ASSERTION FAILED: !(ctx->getErrCode() == OUT_OF_RANGE_IF_ENDIF && ctx->getIFENDIFFix()) at file /builddir/build/BUILD/Beignet-1.3.2-Source/backend/src/backend/gen_program.cpp, function virtual gbe::Kernel* gbe::GenProgram::compileKernel(const gbe::ir::Unit&, const string&, bool, int), line 248 Trasovací/ladící past (SIGTRAP) (core dumped [obraz paměti uložen]) Well, it's bad that it hung - we need to find out why from the coredump and probably address the problem upstream, but it's not blocker for the packaging. Also we should probably use: ExclusiveArch: %{ix86} x86_64 %{arm} in the spec file to limit the arches to x86 and arm only - I don't know much about OpenCL, but it still seems to be x86/arm specific (I haven't tried it on ARM, so I don't know whether it's usable there). But on ppc64: $ hashcat -b hashcat (v4.0.1) starting in benchmark mode... Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. Note: Using optimized kernel code limits the maximum supported password length. To disable the optimized kernel code in benchmark mode, use the -w option. Cannot find an OpenCL ICD loader library. You are probably missing the native OpenCL runtime or driver for your platform. * AMD GPUs on Linux require this runtime and/or driver: "RadeonOpenCompute (ROCm)" Software Platform (1.6.180 or later) * Intel CPUs require this runtime and/or driver: "OpenCL Runtime for Intel Core and Intel Xeon Processors" (16.1.1 or later) * Intel GPUs on Linux require this runtime and/or driver: "OpenCL 2.0 GPU Driver Package for Linux" (2.0 or later) * NVIDIA GPUs require this runtime and/or driver: "NVIDIA Driver" (367.x or later) So contrary to the hashcat-legacy which worked with the CPU, the new hashcat seems not to work without OpenCL, so it's probably useless to build it for architectures where OpenCL is not supported.
I used mesa-libOpenCL in the above mentioned test.
you should depend only on ocl-icd... And DNF should really implement pulling in appropriate implementations automatically. But until it's there, users will have to manually install appropriate driver. you can use POCL which is CPU-based implementation... Last time I tried hashcat, it worked on with POCL and proprietary driver (so no mesa, beignet).
(In reply to Igor Gnatenko from comment #9) > you should depend only on ocl-icd... And DNF should really implement pulling > in appropriate implementations automatically. But until it's there, users > will have to manually install appropriate driver. > > you can use POCL which is CPU-based implementation... Last time I tried > hashcat, it worked on with POCL and proprietary driver (so no mesa, beignet). Thanks for info, I will try.
(In reply to Jaroslav Škarvada from comment #10) > (In reply to Igor Gnatenko from comment #9) > > you should depend only on ocl-icd... And DNF should really implement pulling > > in appropriate implementations automatically. But until it's there, users > > will have to manually install appropriate driver. > > > > you can use POCL which is CPU-based implementation... Last time I tried > > hashcat, it worked on with POCL and proprietary driver (so no mesa, beignet). > > Thanks for info, I will try. Unfortunately no luck with the POCL on f26 and x86_64, it seems the POCL we have in Fedora is incompatible with the current hashcat OCL kernels: $ hashcat -b --force -d 1 --opencl-platforms=2 hashcat (v4.0.1) starting in benchmark mode... Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. Note: Using optimized kernel code limits the maximum supported password length. To disable the optimized kernel code in benchmark mode, use the -w option. clGetDeviceIDs(): CL_DEVICE_NOT_FOUND OpenCL Platform #1: Intel, skipped or no OpenCL compatible devices found. OpenCL Platform #2: The pocl project ==================================== * Device #1: pthread-Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 9903/9903 MB allocatable, 4MCU OpenCL Platform #3: Mesa, skipped or no OpenCL compatible devices found. Benchmark relevant options: =========================== * --force * --opencl-devices=1 * --opencl-platforms=2 * --optimized-kernel-enable Hashmode: 900 - MD4 Speed.Dev.#1.....: 50042.4 kH/s (84.00ms) Hashmode: 0 - MD5 38 errors generated. clBuildProgram(): CL_BUILD_PROGRAM_FAILURE error: ./inc_hash_md5.cl:204:20: passing '__generic u32 *' (aka '__generic unsigned int *') to parameter of type 'const u32 *' (aka 'const unsigned int *') changes address space of pointer error: ./inc_hash_md5.cl:204:29: passing '__generic u32 *' (aka '__generic unsigned int *') to parameter of type 'const u32 *' (aka 'const unsigned int *') changes address space of pointer error: ./inc_hash_md5.cl:204:38: passing '__generic u32 *' (aka '__generic unsigned int *') to parameter of type 'const u32 *' (aka 'const unsigned int *') changes address space of pointer error: ./inc_hash_md5.cl:204:47: passing '__generic u32 *' (aka '__generic unsigned int *') to parameter of type 'const u32 *' (aka 'const unsigned int *') changes address space of pointer ... * Device #1: Kernel /usr/share/hashcat/OpenCL/m00000_a3-optimized.cl build failed - proceeding without this device. Started: Wed Feb 7 11:24:27 2018 Stopped: Wed Feb 7 11:24:34 2018 I will try with rawhide and in case it will not work, I will bring the problem upstream.
Ah, it seems the f26 pocl is prehistoric, I will try the latest.
Tomas could you fix the spec according to the above comments (e.g. ExclusiveArch/ExcludeArch, Prefix, dropping devel package and packaging the missing files)? Also please add "Requires: ocl-icd". Then please bump a release, add changelog (e.g. with the "Implemented changes according to the package review" or similar text), create SRPM and upload new versions. Also please resubmit the links to new version in the new comment. It seems POCL is still only about x86/ARM, so it seems the point 2 from comment 4 is resolved. We will probably have to create ppc64, s390x bugs as stated in the [1] later, once the package will get into Fedora. Now the lzma bundling remains. I will take a look later. [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures
I will upload new version later today. Sorry for the delay.
It seems to work with pocl-1.0-3, but it's way too slow :) Just for the record comparison of GPU accelerated MD5 benchmark in comment 5 (201.4 MH/s) vs CPU only POCL running in one thread (24567.2 kH/s), i.e. more than 8x speedup on GPU, the POCL run: $ hashcat -b --force -d 1 --opencl-platforms=2 hashcat (v4.0.1) starting in benchmark mode... Benchmarking uses hand-optimized kernel code by default. You can use it in your cracking session by setting the -O option. Note: Using optimized kernel code limits the maximum supported password length. To disable the optimized kernel code in benchmark mode, use the -w option. install_dir: /usr/bin, resolved_install_folder: /usr/bin /usr/share/hashcat clGetDeviceIDs(): CL_DEVICE_NOT_FOUND OpenCL Platform #1: Intel, skipped or no OpenCL compatible devices found. OpenCL Platform #2: The pocl project ==================================== * Device #1: pthread-Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 2048/5807 MB allocatable, 4MCU OpenCL Platform #3: Mesa, skipped or no OpenCL compatible devices found. Benchmark relevant options: =========================== * --force * --opencl-devices=1 * --opencl-platforms=2 * --optimized-kernel-enable Hashmode: 900 - MD4 Speed.Dev.#1.....: 46218.2 kH/s (90.57ms) Hashmode: 0 - MD5 Speed.Dev.#1.....: 24567.2 kH/s (87.91ms) ...
(In reply to Jaroslav Škarvada from comment #15) > It seems to work with pocl-1.0-3, but it's way too slow :) Just for the > record comparison of GPU accelerated MD5 benchmark in comment 5 (201.4 MH/s) > vs CPU only POCL running in one thread (24567.2 kH/s), i.e. more than 8x > speedup on GPU, the POCL run: Of course comment 7 :)
Next version available SRPM: https://tkorbar.fedorapeople.org/hashcat-4.0.1-2.fc27.src.rpm SPEC: https://tkorbar.fedorapeople.org/hashcat.spec
I jsut tried for curiosity hashcat with POCL on ppc64. The POCL itself has some issues there (the internal testsuite is failing), but this will get resolved sooner or later. The bigger problem is that hashcat OCL kernels hardcode little-endian, so it will not work on ppc64 until hashcat upstream adds support for it.
The lzma-sdk version we have in Fedora lacks LZMA2 support, I created lzma-sdk rebase request (bug 1546091) to add the LZMA2 support then it should be easy to unbundle without loosing functionality.
(In reply to Jaroslav Škarvada from comment #19) > The lzma-sdk version we have in Fedora lacks LZMA2 support, I created > lzma-sdk rebase request (bug 1546091) to add the LZMA2 support then it > should be easy to unbundle without loosing functionality. Even the rebased lzma-sdk needs patching to export the Lzma2Decode function hashcat needs, patch attached to the rebase request bugzilla as bug 1546091 comment 9.
Created attachment 1398950 [details] lzma-sdk unbundle This is patch unbundling the lzma-sdk. I will propose it upstream once we figure out the proper include name (see bug 1546091 comment 8 for details). The hashcat has to be build with the lzma-sdk rebased to the version 18.01 and with the patch from the bug 1546091 comment 9 applied.
Created attachment 1398951 [details] Proposed fix to build with lzma-sdk-18.01 Hashcat also needs this patch to correctly build with the lzma-sdk-18.01. I will bring it upstream.
Created attachment 1398953 [details] Spec patch unbundling the lzma-sdk This is spec patch unbundling the lzma-sdk.
One more thing I noticed during build: *** WARNING: ./usr/share/doc/hashcat/examples/example500.sh is executable but has empty or no shebang, removing executable bit *** WARNING: ./usr/share/doc/hashcat/examples/example400.sh is executable but has empty or no shebang, removing executable bit *** WARNING: ./usr/share/doc/hashcat/examples/example0.sh is executable but has empty or no shebang, removing executable bit I think it should be enough to just remove the executable mode from the example files (by chmod).
Proposed the lzma-sdk unbundle patch upstream: https://github.com/hashcat/hashcat/issues/1528
Created attachment 1401799 [details] lzma-sdk unbundle Updated version of the lzma-sdk unbundle patch.
Created attachment 1401800 [details] Proposed fix to build with lzma-sdk-18.01 Updated version of the fix to build with lzma-sdk-18.01.
Created attachment 1401801 [details] Spec patch unbundling the lzma-sdk Updated version of the spec patch unbundling the lzma-sdk.
This is an automatic check from review-stats script. This review request ticket hasn't been updated for some time, but it seems that the review is still being working out by you. If this is right, please respond to this comment clearing the NEEDINFO flag and try to reach out the submitter to proceed with the review. If you're not interested in reviewing this ticket anymore, please clear the fedora-review flag and reset the assignee, so that a new reviewer can take this ticket. Without any reply, this request will shortly be resetted.
(In reply to Package Review from comment #29) > This is an automatic check from review-stats script. > > This review request ticket hasn't been updated for some time, but it seems > that the review is still being working out by you. If this is right, please > respond to this comment clearing the NEEDINFO flag and try to reach out the > submitter to proceed with the review. > > If you're not interested in reviewing this ticket anymore, please clear the > fedora-review flag and reset the assignee, so that a new reviewer can take > this ticket. > > Without any reply, this request will shortly be resetted. I would like to move it.
This is an automatic action taken by review-stats script. The ticket reviewer failed to clear the NEEDINFO flag in a month. As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews we reset the status and the assignee of this ticket.
hashcat is packaged in Fedora since https://bugzilla.redhat.com/show_bug.cgi?id=1673317 closing this out. *** This bug has been marked as a duplicate of bug 1673317 ***