Giter Site home page Giter Site logo

openwall / john-packages Goto Github PK

View Code? Open in Web Editor NEW
80.0 6.0 14.0 4.72 MB

Community packages of John the Ripper, the auditing tool and advanced offline password cracker (Docker images, Windows PortableApp, Mac OS, Flatpak, and Ubuntu SNAP packages)

Home Page: https://www.openwall.com/john/

License: GNU General Public License v2.0

Shell 66.76% Dockerfile 10.59% HCL 19.97% C 2.68%
john cracker opencl gpgpu jtr password john-the-ripper linux-packages windows-package

john-packages's Introduction

John the Ripper Packages

john-the-ripper License

OpenSSF Scorecard Best Practices CodeFactor Grade

Openwall's John the Ripper (JtR) is a fast password cracker, currently available for many flavors of Unix and for Windows. Its primary purpose is to detect weak Unix passwords. Besides several crypt(3) password hash types most commonly found on various Unix systems, supported out of the box are Windows LM hashes, various macOS password hashes, as well as many non-hashes such as SSH private keys, encrypted filesystems such as macOS .dmg files and "sparse bundles", encrypted archives such as ZIP, RAR, and 7z, encrypted document files such as PDF and Microsoft Office's, plus lots of other hashes and ciphers.

Table of Contents

Openwall logo

  1. Introduction
    1. Continuous Delivery Status
    2. Package Build Environments
    3. Testing, Continuous Integration, and Continuous Delivery
    4. Packaging and Application Distribution
    5. The commits feed of this repository New Commits Feed
    6. The feed of John the Ripper releases New Releases Feed
  2. Windows Package
  3. Snap Package
  4. macOS Package
  5. Flatpak Package
  6. Docker Image
  7. Checksums
  8. Package Security
  9. About This Project
  10. Contribute
  11. Acknowledgments and Contact
  12. License

(back to top)

Introduction

Continuous Delivery Status

We produce software in short cycles, ensuring that the software can be reliably released at any time, following a pipeline through a "production-like environment".

Docker Flatpak macOS Windows

Launchpad Download on Flathub

Virus Scan

Releases Latest
Release Version
Prerelease
Prerelease Version
GitHub Total Downloads Release Date Prerelease Date

Package Building Environments

Click on the link to learn more about our packages Building Environments.

Testing and Continuous Integration

All continuous integration (CI) and continuous delivery (CD) procedures are fully automated, builds and tests are performed whenever requested by the packager. Manual procedures are required just to start the process.

Click on the link to learn more about our Continuous Integration and Continuous Delivery procedures.

Graph

Packaging and Application Distribution

Snap and Flatpak are cool new ways of distributing Linux applications among a wide range of different distros. They are technologies to deploy applications in a secure, sandboxed and containerized way.

A Docker image is a read-only template used to execute code in a Docker container. An image is an immutable file that contains the binaries, configuration files, libraries, dependencies, tools, and other files needed for John the Ripper application to run.

When the Docker user runs an image, it becomes one instance (it becomes a container, in other words, a running instance of the application).

(back to top)

📂 Windows

Delivered using Microsoft-hosted Windows 2019 Server in Azure [ supports up to AVX512BW ]

To install John the Ripper by downloading the .7z file and installing it manually, follow these steps:

  • Download the compressed file to your machine.
  • Navigate to where you downloaded the file and double click the compressed file.
  • Extract it to a directory such as C:\john-the-ripper.
  • Start a command prompt.
  • Navigate to the directory you extracted the compressed file, e.g., cd C:\john-the-ripper\run.
  • Run JtR:
 C:\john-the-ripper\run>john --list=build-info
 [...]
 Build: cygwin 64-bit x86_64 AVX2 AC OMP OPENCL
 SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
 [...]
 C:\john-the-ripper\run>john --test --format=SHA512crypt

| 📑 More examples of running John The Ripper on Windows.

The highlights (👀):

  • fallback for CPU[*] and OMP;
  • OpenCL available (GPU driver installation is needed);
  • generic crypt(3) format available;
  • security feature Address Space Layout Randomisation (ASLR) enabled;
  • security feature Data Execution Prevention (DEP) enabled;
  • the released version of John 1.9.0 Jumbo 1+ (is a rolling release);
  • a development version is also available.

[*] John the Ripper runs using the best SIMD instructions available on the host it's running on.

Windows Deployments

Windows Downloads

Using the above instructions you can install the rolling version of John the Ripper Jumbo 1+, the hot and bleeding version, or a previous stable version in your system.

The package contains all the executables and libraries needed to run a fresh John the Ripper installation.

OpenSSF SLSA

SLSA is a framework intended to codify and promote secure software supply-chain practices, it helps trace software artifacts back to the build and source control systems that produced them.

⚠️ NOTE: the release assets from our GitHub Releases are level 1 compliant.

Logo

SLSA Provenance Traceability

Running a non-OpenMP build on Windows

In some situations a non-OpenMP build may be faster. You can ask to fallback to a non-OpenMP build specifying the value of OMP_NUM_THREADS in the command-line. You avail the best SIMD instructions at one's disposal without any OpenMP stuff. E.g.:

 PS C:\john-the-ripper\run> set OMP_NUM_THREADS=1
 PS C:\john-the-ripper\run> .\john --list=build-info

Accessing OpenCL on Windows

If John the Ripper is not recognizing your GPU card:

  • make sure all required GPU drivers are installed;
  • restart your PC, if you have just installed the drivers.

(back to top)

📂 Snap

Delivered using Launchpad [ supports up to AVX512BW ]

A Snap is a gpg signed squashfs file containing an application together with its dependencies, and a description of how it should safely be run on your system.

You can install john by following the instructions at https://snapcraft.io/john-the-ripper. For distributions without snap pre-installed, users should enable snap support, then install:

 sudo snap install john-the-ripper

Just dance now:

 $ john-the-ripper -list=build-info
 [...]
 Build: linux-gnu 64-bit x86_64 AVX2 AC OMP OPENCL
 SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
 Deploy: sandboxed as a Snap app
 [...]

You can also run the software using the official john alias:

 john -list=build-info

John runs confined under a restrictive security sandbox by default. Nevertheless, you can access and audit any file located in your home. Below, an usage example:

 john -list=format-tests | cut -f3 > ~/allTests.in
 john --format=SHA512crypt ~/allTests.in

For your convenience, the snap installed on your system contains the file /snap/john-the-ripper/current/snap/manifest.yaml which field build_url points to its build log.

The highlights (👀):

  • fallback for CPU[*] and OMP;
  • OpenCL available (GPU driver installation is needed);
  • John the Ripper is a "featured software" in the security category on Canonical Snap Store;
  • John the Ripper is a software with 4-star (⭐⭐⭐⭐) user reviews on Canonical Snap Store;
  • John the Ripper is tagged as safe, confined and auditable software on Canonical Snap Store;
  • John the Ripper supports and has a package for all architectures supported by Ubuntu itself.
  • also available via the alias john, e.g. john -list=build-info;
  • the released version of John 1.9.0 Jumbo 1+ (is a rolling release);
  • a development version is also available.

[*] John the Ripper runs using the best SIMD instructions available on the host it's running on.

John the Ripper snap package has approximately eight thousand active users [*].

[*] 7 Day Active Users: the number of unique users who had at least one session within a 7 day period.

Enabling Aliases

You are free to pick and set up aliases. To enable the usage of aliases with John the Ripper snap, run sudo snap alias john-the-ripper <alias>. For example:

 sudo snap alias john-the-ripper john-snap
 sudo snap alias john-the-ripper.dmg2john dmg2john

Once enabled, John itself plus the *2john tools can be invoked using the aliases. In the example, to run John type john-snap.

| 📑 More examples of enabling alias for John The Ripper snap.

Running a non-OpenMP build

In some situations a non-OpenMP build may be faster. You can ask to fallback to a non-OpenMP build specifying OMP_NUM_THREADS=1 john <options> in the command-line. You avail the best SIMD instructions at one's disposal without any OpenMP stuff. E.g.:

 OMP_NUM_THREADS=1 john --list=build-info

Accessing OpenCL on Snap

As noted at https://forum.snapcraft.io/t/snaps-and-opencl/8509/17, the use of OpenCL by snaps is a problem. Support for NVIDIA cards is under development.

As a "general" solution (or in the case of AMD hardware), the user can run john out of the sandbox, unconfined (e.g., run /snap/john-the-ripper/current/run/john).

Snap Deployments

Get it from the Snap Store

If you followed the above instructions, you installed the stable (or rolling) version of John the Ripper Jumbo 1+ in your system. If you want to access the hot and bleeding developing version of JtR, you must follow a development channel. For a clean installation:

 sudo snap install --channel=edge john-the-ripper

If you already has JtR installed:

 sudo snap refresh --channel=edge john-the-ripper

If you do so, you will be running the development version available on GitHub.

(back to top)

📂 macOS

Delivered using Cirrus CI [ supports ASIMD (on ARM) ]

To install John the Ripper by downloading the .7z file and installing it manually, follow these steps:

  • Download the compressed file to your machine.
  • Extract it to a directory such as /Users/Me/bleeding.
  • Start a command prompt.
  • Navigate to the directory you extracted the compressed file, e.g., cd /Users/Me/bleeding.
  • Run the software:

Install required Homebrew packages (if not already installed):

 brew update
 brew install libomp openssl gmp

Execute John the Ripper:

 $ run/john -list=build-info
 [...]
 Build: darwin22.6.0 64-bit arm ASIMD AC OMP OPENCL
 SIMD: ASIMD, interleaving: MD4:2 MD5:2 SHA1:1 SHA256:1 SHA512:1
 OMP fallback binary: john-arm64
 [...]

The highlights (👀):

  • fallback for CPU[*] (if that makes sense) and OMP;
  • OpenCL available;
  • built using clang from the official XCode toolchain plus non-system libraries from Homebrew;
  • the released version of John 1.9.0 Jumbo 1+ (is a rolling release);
  • a development version is also available.

[*] John the Ripper runs using the best SIMD instructions available on the host it's running on.

macOS Deployments

macOS Downloads

Using the above instructions you can install the rolling version of John the Ripper Jumbo 1+, the hot and bleeding version, or a previous stable version in your system.

The package contains the necessary executables to run a fresh install of John the Ripper. You must install required Homebrew libraries.

OpenSSF SLSA

SLSA is a framework intended to codify and promote secure software supply-chain practices, it helps trace software artifacts back to the build and source control systems that produced them.

⚠️ NOTE: the release assets from our GitHub Releases are level 1 compliant.

Logo

SLSA Provenance Traceability

Running a non-OpenMP build on macOS

In some situations a non-OpenMP build may be faster. You can ask to fallback to a non-OpenMP build specifying the value of OMP_NUM_THREADS in the command-line. You avail the best SIMD instructions at one's disposal without any OpenMP stuff. E.g.:

OMP_NUM_THREADS=1 run/john --list=build-info

(back to top)

📂 Flatpak

Delivered using GitLab CI [ supports up to AVX512BW ]

Flatpak is a new framework for desktop applications on Linux, built to be distribution agnostic and allow deployment on any Linux operating system out there.

Flatpak is available for the most common Linux distributions.

To install JtR download the john.flatpak file and run:

 # Note that root privileges are required for some operations.
 sudo dnf install -y flatpak # or 'yum install', 'apt-get install', etc.
 sudo flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo # flatpak repository
 sudo flatpak install -y flathub org.freedesktop.Platform//23.08 # install the runtime (base "container")
 flatpak --user install --bundle john.flatpak # per-user installation (not system wide)

John runs confined under a restrictive security sandbox by default. Nevertheless, you can access and audit any file located in your home. Below, an usage example:

 flatpak run com.openwall.John -list=build-info
 flatpak run com.openwall.John -list=format-tests | cut -f3 > ~/allTests.in
 flatpak run com.openwall.John --format=SHA512crypt ~/allTests.in

The highlights (👀):

  • fallback for CPU[*] and OMP;
  • the released version of John 1.9.0 Jumbo 1+ (is a rolling release):
  • a development version is also available.

[*] John the Ripper runs using the best SIMD instructions available on the host it's running on.

Flatpak Deployments

Flatpak Download

Using the above instructions you can install the rolling version of John the Ripper Jumbo 1+, the hot and bleeding version, or a previous stable version in your system.

OpenSSF SLSA

SLSA is a framework intended to codify and promote secure software supply-chain practices, it helps trace software artifacts back to the build and source control systems that produced them.

⚠️ NOTE: the release assets from our GitHub Releases are level 1 compliant.

Logo

SLSA Provenance Traceability

(back to top)

📂 Docker Image

Delivered using GitHub Actions [ supports up to AVX512BW ]

Docker provides the ability to package and run an application in a loosely isolated environment called a container.

To use it:

 # CPU and GPU formats
 docker run -it ghcr.io/openwall/john:latest <binary id> <john options>

 # To run ztex formats
 docker run --device=/dev/ttyUSB0 ghcr.io/openwall/john:v1.9.0J1 ztex <john options>

Run John the Ripper and check if it is working:

 docker run ghcr.io/openwall/john # => uses the best SIMD available, tag 'latest' can be omitted
 docker run ghcr.io/openwall/john:rolling # => uses the latest rolling release
 docker run ghcr.io/openwall/john:latest best # => uses the best SIMD available

| 📑 More examples of running John The Ripper on Docker.

The highlights (👀):

  • OpenSSF SLSA 3 compliant;
  • has NVIDIA OpenCL available (GPU driver is required on the host);
  • has auto-selection of the best SIMD if user specifies best as the <binary id>;
    • example: docker run ghcr.io/openwall/john:latest best -list=build-info.
  • the released version of John 1.9.0 Jumbo 1+ (is a rolling release):
    • install from the command-line: docker pull ghcr.io/openwall/john:rolling.
  • the development version:
    • install from the command-line: docker pull ghcr.io/openwall/john:latest.

Docker Image Deployments

Docker Image Downloads

Using the above instructions you can install the rolling version of John the Ripper Jumbo 1+, the hot and bleeding version, or a previous stable version in your system.

OpenSSF SLSA

SLSA is a framework intended to codify and promote secure software supply-chain practices, it helps trace software artifacts back to the build and source control systems that produced them.

⚠️ NOTE: the Docker images from our GitHub Packages are level 3 compliant.

Logo

SLSA Provenance Traceability

(back to top)

Packages Checksums

Released packages checksums computed by Build Servers

File verification is the process of using an algorithm for verifying the integrity of a computer file. A popular approach is to store checksums (hashes) of files, also known as message digests, for later comparison. All john packages checksums (hashes) are computed by the CI servers.

By accessing the build logs for each release on GitHub releases you can view the hashes of all relevant files.

You can also go to https://github.com/openwall/john-packages/attestations for a list of our named artifacts along with their digest.

(back to top)

⚠ Security

Please inspect all packages prior to running any of them to ensure safety. We already know they're safe, but you should verify the security and contents of any binary from the internet you are not familiar with.

We take security very seriously.

(back to top)

About This Project

This project aims to create tools and procedures to automate the creation and enable traceability of packages for John the Ripper software, developing a CI and CD pipeline.

(back to top)

Contribute

We love contributions in the form of issues and pull requests. Read the Contributor Guide before contributing.

(back to top)

Acknowledgments and Contact

John the Ripper is proudly Powered by Open Source Community

(back to top)

License

GNU General Public License v2.0

(back to top)

john-packages's People

Contributors

claudioandre-br avatar dependabot[bot] avatar step-security-bot avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

john-packages's Issues

Refactor, use pinned dependencies and more auditability

1. Is your feature request related to a problem? Please describe

The goal is to force the use of all bash scripts as pinned dependencies. Then, increase traceability.

Pinned dependencies reduce several security risks:

  • ensure that verification and deployment are done with the same software, simplifying debugging and allowing reproducibility;
  • can help mitigate compromised dependencies that undermine project security;
  • they are one way to combat dependency confusion attacks

2. Describe the solution you'd like

Refactor the scripts and use pinned ones.

3. Describe alternatives you've considered

We will create a first attempt followed by improvements. The ultimate goal is to print the checksums of the scripts used within the logs.

john --show doesn't print anything

As seen in openwall/john#4852

I have intalled John on my ubuntu 20 machine using snap, I have the following version:
John the Ripper 1.9.0-jumbo-1 OMP [linux-gnu 64-bit x86_64 AVX2 AC]

I crack some passwords.
But now I want to use --show to see these passwords:

ask@Garsy:~/Notes/TA/AppliedInfoSec/PassCracking$ john --show passwords_md5.txt
0 password hashes cracked, 6826 left
And john claims that no passwords have been cracked. This seems strange.

I tried looking in the john.pot file, only to find out that there is none!

EOL 32-bit X86 packages

The i386 architecture has been removed in core22 (snap) and from flathub (flatpak).

Windows packages were discontinued in #16

Add "verification" to Flathub

1. Is your feature request related to a problem? Please describe.

Verify your app ID to indicate that your Flathub upload is approved by the app developer. You'll need to prove that you have control of the app via a website on the app's domain or by checking access to the app's account on a source code hosting site. The verified badge will be shown alongside the app name, publisher name, and the way that the app ID was verified.

2. Describe the solution you'd like

Create a page at https://openwall.com/.well-known/org.flathub.VerifiedApps.txt containing the following token:

67ab019e-c4e8-456f-80ca-ad89b7d4121d


If it is necessary to become a publisher of the application on Flathub (or on snap/Launchpad), the person must go to johh's repository on Flathub (or to Lauchpad, where the build takes place, and to the snapcraft store) and request this.

We never know when shit happens

Add arm64 Docker image (with NVIDIA GPU support)

1. Is your feature request related to a problem? Please describe.

Sooner or later ARM will be (perhaps already is) a very important player even in the cloud.

2. Describe the solution you'd like

Real build based on NVIDIA ARM64 Docker image.

Target CPU ......................................... aarch64 ASIMD, 64-bit LE
AES-NI support ..................................... no
Target OS .......................................... linux-gnu
Cross compiling .................................... no
Legacy arch header ................................. arm64le.h

Optional libraries/features found:
Memory map (share/page large files) ................ yes
Fork support ....................................... yes
OpenMP support ..................................... yes (not for fast formats)
OpenCL support ..................................... yes
Generic crypt(3) format ............................ yes
OpenSSL (many additional formats) .................. yes
libgmp (PRINCE mode and faster SRP formats) ........ yes
128-bit integer (faster PRINCE mode) ............... yes
libz (7z, pkzip and some other formats) ............ yes
libbz2 (7z and gpg2john bz2 support) ............... yes
libpcap (vncpcap2john and SIPdump) ................. yes
Non-free unrar code (complete RAR support) ......... yes
librexgen (regex mode, see doc/README.librexgen) ... no
OpenMPI support (default disabled) ................. no
Experimental code (default disabled) ............... no
ZTEX USB-FPGA module 1.15y support ................. no

EOL 32-bit Windows packages

Documenting for future reference, from upstream Cygwin:

Therefore we recommend using 32 bit Cygwin only in limited scenarios, with only a minimum of necessary packages installed, and only if there's no way to run 64 bit Cygwin instead.

You have been warned. If you're still sure you really need a 32 bit Cygwin, and there's absolutely no way around it, you may run the setup-x86.exe installer.

JtR developers will no longer support 32-bit builds on Windows sooner or later.

john AI integration

1. Is your feature request related to a problem? Please describe.

It is going to be nice if we can integrate John the Ripper with AI tools:

  • Q&A bot;
  • code review (the best now seems to be ChatGPT CodeReviewer).

2. Describe the solution you'd like

It would be interesting to see the reviews these tools can produce, since we don't have a lot of eyeballs.

3. Describe alternatives you've considered

I will try "Senior Dev AI Bot" to see how it behaves and performs. It can be a step that an OSS can afford.

Create an Android build

No apk:

  • To create an apk package I need several files created by Android Studio. A lot.
  • And I need to add support for CMake.

I tested the build and created a zip for Android X86 and another for Android ARM.

Mute linter and split on spaces

1. Is your feature request related to a problem? Please describe.

Mute linter warnings

2. Describe the solution you'd like

Make this work like a pro

SYSTEM_WIDE='--with-systemwide'
X86_REGULAR="--disable-native-tests $SYSTEM_WIDE"
X86_NO_OPENMP="--disable-native-tests $SYSTEM_WIDE --disable-openmp"

./configure $X86_NO_OPENMP --enable-simd=sse2   && do_build ../run/john-sse2

Is there a reasonable solution?

Make the deploy process faster

To make the build process faster, remove builds that target SIMD extensions that are older than 10 years.

Remove builds for:

  • ssse3
  • sse4.1
  • sse4.2
  • xop (I found no XOP in recent AMD CPUs) [1]
  • deprecate sse2 or avx in the next 3-5 years
    SSE2 if we give up old hardware, AVX if we stop caring about outdated hardware.

Well, I've seen some timeouts in my build spot (instances) farm infrastructure.

The new fallback chain would be:

  • AVX512BW -> AVX512F -> AVX2 -> AVX -> SSE2 (x 2 = 10 binaries).

Do this after the next (rolling) release.

[1] BTW: no one seems to have ever compared XOP and AVX in the john-users list. Is XOP really faster than AVX?

Antivirus complaining about JtR Windows package

At least, BitDefender.

  • the build uses a Windows 2016 Azure (Official) image;
    • created by Azure team. Anyone can audit the image.
  • Cygwin needs to be installed. Cygwin is installed via Chocolatey.

To ensure that the package is safe:

VirusTotal
a1

MetaDefender
a2

Jotti
a3

Drop donation badges/links

I just noticed that we have some donation badges/links in here. Looks like two lead nowhere, and one to the 0-Day Clothing store for Openwall/JtR apparel. The latter used to include a $10 donation in t-shirt prices that we intended to use for sending free t-shirts to project contributors, which we once did, but we haven't actually done so again for years (maybe wrongly!), leaving these funds with 0-Day Clothing. It looks like they no longer collect those donations now (quite reasonably). I should probably follow up with them on that, but anyhow we're not currently collecting any donations, so shouldn't currently have such badges/links.

I may enable GitHub Sponsors later, but even if so I was thinking of requesting support only from organizations (so with pre-tax money), not from individuals.

Performance regression in latest Docker image?

I noticed a big performance impact when testing on CircleCI. Upon reviewing I realized that I can't reproduce the issue locally, but I can using the cloud. Below, using Microsoft's cloud.

Latest version:

$ docker run -it ghcr.io/openwall/john:latest best    --test=10 --format=SHA512crypt
 best --test=10 --format=SHA512crypt
Sorry, AVX512BW is required for this build
Sorry, AVX512F is required for this build
Will use /john/run/john-avx2
Will run 8 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 256/256 AVX2 4x]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:    3280 c/s real, 682 c/s virtual

Previous version:

$ docker run -it ghcr.io/openwall/john:v1.9.0J2_J36.7 best    --test=10 --format=SHA512crypt
 best --test=10 --format=SHA512crypt
Sorry, AVX512BW is required for this build
Sorry, AVX512F is required for this build
Will use /john/run/john-avx2
Will run 8 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 256/256 AVX2 4x]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:    3319 c/s real, 687 c/s virtual

Locally:

$ docker run --rm ghcr.io/openwall/john:latest best --test=10 --format=SHA512crypt
best --test=10 --format=SHA512crypt
Sorry, AVX512BW is required for this build
Sorry, AVX512F is required for this build
Will use /john/run/john-avx2
Will run 8 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 256/256 AVX2 4x]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:	2129 c/s real, 286 c/s virtual
$ docker run --rm ghcr.io/openwall/john:v1.9.0J2 best --test=10 --format=SHA512crypt
best --test=10 --format=SHA512crypt
Sorry, AVX512BW is required for this build
Sorry, AVX512F is required for this build
Will use /john/run/john-avx2
Will run 8 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 256/256 AVX2 4x]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:	2100 c/s real, 284 c/s virtual

CircleCI now (this is AWS):

Will run 2 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 512/512 AVX512BW 8x]... (2xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:	5263 c/s real, 2693 c/s virtual

Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 512/512 AVX512BW 8x]... DONE
Speed for cost 1 (iteration count) of 5000
Raw:	2793 c/s real, 2793 c/s virtual

A week ago:

Will run 2 OpenMP threads
Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 512/512 AVX512BW 8x]... (2xOMP) DONE
Speed for cost 1 (iteration count) of 5000
Raw:	6718 c/s real, 3362 c/s virtual

Benchmarking: sha512crypt, crypt(3) $6$ (rounds=5000) [SHA512 512/512 AVX512BW 8x]... DONE
Speed for cost 1 (iteration count) of 5000
Raw:	3486 c/s real, 3486 c/s virtual

  • Is it AVX512 related? No, it seems.
  • The new image uses make strip. Is it important?
  • Is the cloud particularly busy today?

Checklist

🥇 👍

Maybe stop using 7z

I ran a couple of polls on Feb 7, 2024, and 7z appears to be a really unpopular choice of a download file format.

https://twitter.com/solardiz/status/1755221747626885298

When given a choice, I usually prefer to download a
zip - 33.1%
7z - 10%
tar.gz - 38.5%
tar.xz - 18.5%
130 votes

https://twitter.com/solardiz/status/1755223774004158819

When not giving a choice, downloads should be available only as
zip - 43.7%
7z - 7.6%
tar.gz - 39.5%
tar.xz - 9.2%
119 votes

We can still use the program 7z to produce zip or tar.gz archives with slightly better compression than the usual zip or gzip programs would. IIRC, I did just that for our 1.9.0-jumbo-1 release archives.

Add OpenSSF Best Practices

1. Is your feature request related to a problem? Please describe.

Audit this repository as seen at https://bestpractices.coreinfrastructure.org/projects/7525
image

2. Describe the solution you'd like

Add the checklist for the repository practices.

3. Additional context

OpenSSF Best Practices


@solardiz , when you have some free time could you please accept the access request you (probably) received some days ago?

  • from Github and me to autorize codefactor to access the repos.

This will authorize codefactor (https://www.codefactor.io/repository/github/openwall/john-packages) to run and scan all commits.

Add an experimental build for Solaris

At least, I'll feel like I'm living in the 80s.

SunOS Release 5.11 Version 11.4.0.15.0 64-bit

Copyright (c) 1983, 2018, Oracle and/or its affiliates. All rights reserved.
Hostname: solaris

[...]
The physical processor has 3 virtual processors (0-2)
  x86 (GenuineIntel 306A9 family 6 model 58 step 9 clock 3478 MHz)
	Intel(r) Xeon(r) CPU E5-1650 v2 @ 3.50GHz
                             Oracle Solaris 11.4 X86
  Copyright (c) 1983, 2018, Oracle and/or its affiliates.  All rights reserved.
                            Assembled 16 August 2018
[...]
  $ uname -m; id; uname -a
  i86pc
  uid=0(root) gid=0(root)
  SunOS solaris 5.11 11.4.0.15.0 i86pc i386 i86pc
--------------------------------
            Building
--------------------------------
checking build system type... i386-pc-solaris2.11
checking host system type... i386-pc-solaris2.11
checking whether to compile using MPI... no

Also [1]:

checking build system type... x86_64-pc-solaris2.11
checking host system type... x86_64-pc-solaris2.11
[...]
  Configured for building John the Ripper jumbo:
  Target CPU ......................................... x86_64 AVX, 64-bit LE
  AES-NI support ..................................... depends on OpenSSL
  Target OS .......................................... solaris2.11
  Cross compiling .................................... no
  Legacy arch header ................................. x86-64.h
  Optional libraries/features found:
  Memory map (share/page large files) ................ yes
  Fork support ....................................... yes
  OpenMP support ..................................... yes (not for fast formats)
  OpenCL support ..................................... no
  Generic crypt(3) format ............................ yes
  OpenSSL (many additional formats) .................. yes
  libgmp (PRINCE mode and faster SRP formats) ........ yes
  128-bit integer (faster PRINCE mode) ............... yes
  libz (7z, pkzip and some other formats) ............ yes
  libbz2 (7z and gpg2john bz2 support) ............... yes
  libpcap (vncpcap2john and SIPdump) ................. yes
  Non-free unrar code (complete RAR support) ......... yes
  librexgen (regex mode, see doc/README.librexgen) ... no
  OpenMPI support (default disabled) ................. no
  Experimental code (default disabled) ............... no
  ZTEX USB-FPGA module 1.15y support ................. no
  Install missing libraries to get any needed features that were omitted.
  Configure finished.  Now "gmake -s clean && gmake -sj4" to compile.

[1] I'm struggling with the package system. Let's trust the second run.

Stop building SSE2 binaries for Docker, snap, and flatpak packages

1. Is your feature request related to a problem? Please describe.

The build time is already a problem for me on some occasions.

2. Describe the solution you'd like

Even "average" AWS instances struggle to build all 10 binaries. So removing the SSE2 binaries will improve things.

Announce john-packages to john-users

1. Is your feature request related to a problem? Please describe.

We should let people know about us.

2. Describe the solution you'd like

Post the message below to john-users


Subject: John the Ripper binary packages

This is in fact nothing new for the list, but we would like to announce the existence of John the Ripper compiled packages:

  • there are a stable release (Jumbo 1), a rolling release [1], and a development release;
  • you can find packages:
    • in PortableApp style: for Windows and Mac;
    • in sandoboxed [2] style: for Linux;
      • a Canonical snap (the recommended), a flatpak and a Docker image (the recommended method for use in the cloud ☁);

What these packages offer:

  • the deployment process and scripts used are public and are evaluated by Static Code Analyzers;
  • the VM images used for the build are produced by leaders players, for example, the disk image used in the Windows
    package build is created by the Microsoft team, the Mac X86 by the Circle Internet Services, Inc; well known and very active in Asia;
  • automatic virus scanned by VirusTotal;

Deployment Process
image

Hardening:

  • it's known [3] that john isn't to be used on untrusted inputs, but how about use hardening with john?
    • or Linux packages execute in a sandbox which limits the system privileges so that if a malicious
      content manages exploits a vulnerability to execute arbitrary code it will be unable to compromise the underlying OS.
    • in addition, some packages use binary hardening techniques [4];

The packages and usage guidelines are available for use by the community at https://github.com/openwall/john-packages.

We appreciate your input and feedback. Greetings everyone.

Proposal: improve release listing

1. Is your feature request related to a problem? Please describe.

Better advertise the most recent (latest) available releases.

2. Describe the solution you'd like

Ignore the borders. They depend on the viewer (the proposal has not yet been committed, I'm viewing it locally)

From:
image

To:
image
Mouse cursor is over the "release date"

image
Mouse cursor is over the "pre-release version"

Move Docker images to GitHub Packages

Due to pull rate limit imposed by Docker Hub, I'm looking for better places to host Docker images. I'm planing to move JtR Docker images from Docker Hub to GitHub Repository. It seems one configuration is missing.

denied: failed_precondition: Improved container support has not been enabled for 'openwall'. Learn more: https://docs.github.com/packages/getting-started-with-github-container-registry/enabling-improved-container-support

@solardiz, could you please enable it? There is no cost involved; the images will be public and docs says there are no fees for public images.

Docker image with Python

Currently the Docker images do not contain Python, precluding the use of the xxx2john.py scripts. It would be nice to have a version of the images which have Python included. (Perhaps a separate tag should be used, so people don't have to use the extra space if they don't want Python?)

Rebuild 1.9.0-jumbo-1 packages

At least snap and Windows.

Libraries put into these packages are out of date and detection tools are complaining about known security issues.

I should do something to fix this. Rebuild and redeploy these packages seems reasonable.

Add an experimental build for MacOS

At least, I will be notified when something bad happens on Darwin OS.

Target CPU ......................................... x86_64 SSE4.1, 64-bit LE
AES-NI support ..................................... depends on OpenSSL
Target OS .......................................... darwin21.6.0
Cross compiling .................................... no
Legacy arch header ................................. x86-64.h

Optional libraries/features found:
Memory map (share/page large files) ................ yes
Fork support ....................................... yes
OpenMP support ..................................... no
OpenCL support ..................................... yes
Generic crypt(3) format ............................ yes
OpenSSL (many additional formats) .................. yes
libgmp (PRINCE mode and faster SRP formats) ........ yes
128-bit integer (faster PRINCE mode) ............... yes
libz (7z, pkzip and some other formats) ............ yes
libbz2 (7z and gpg2john bz2 support) ............... yes
libpcap (vncpcap2john and SIPdump) ................. yes
Non-free unrar code (complete RAR support) ......... yes
librexgen (regex mode, see doc/README.librexgen) ... no
OpenMPI support (default disabled) ................. no
Experimental code (default disabled) ............... no
ZTEX USB-FPGA module 1.15y support ................. no

Install missing libraries to get any needed features that were omitted.

Configure finished.  Now "make -s clean && make -sj4" to compile.
ar: creating archive poly1305-donna.a
ar: creating archive aes.a
ar: creating archive secp256k1.a
ar: creating archive ed25519-donna.a

Make process completed.
Version: 1.9.0-jumbo-1+bleeding-99ebf64df 2023-04-14 13:53:49 -0300
Build: darwin21.6.0 64-bit x86_64 SSE4.1 AC OPENCL
SIMD: AVX, interleaving: MD4:4 MD5:5 SHA1:2 SHA256:1 SHA512:1
CPU tests: AVX
$JOHN is ../run/
Format interface version: 14
Max. number of reported tunable costs: 4
Rec file version: REC4
Charset file version: CHR3
CHARSET_MIN: 1 (0x01)
CHARSET_MAX: 255 (0xff)
CHARSET_LENGTH: 24
SALT_HASH_SIZE: 1048576
SINGLE_IDX_MAX: 2147483648
SINGLE_BUF_MAX: 4294967295
Effective limit: Number of salts vs. SingleMaxBufferSize
Max. Markov mode level: 400
Max. Markov mode password length: 30
clang version: 14.0.0 (clang-1400.0.29.202) (gcc 4.2.1 compatibility)
OpenCL headers version: 1.2
Crypto library: OpenSSL
OpenSSL library version: 030100000
OpenSSL 3.1.0 14 Mar 2023
GMP library version: 6.2.1
File locking: fcntl()
fseek(): fseek
ftell(): ftell
fopen(): fopen
memmem(): System's
times(2) sysconf(_SC_CLK_TCK) is 100
Using times(2) for timers, resolution 10 ms
HR timer: mach_absolute_time(), latency 119 ns
Total physical host memory: 8 GiB
Available physical host memory: 6126 MiB
Terminal locale string: en_US.UTF-8
Parsed terminal locale: UTF-8
Testing: descrypt, traditional crypt(3) [DES 128/128 AVX]... /�-�\�|�/�-�PASS
[...]
Testing: crypt, generic crypt(3) [?/64]... |�/�-�\�|�/�PASS
All 403 formats passed self-tests!
 Ok: -test-full=0 --format=cpu
  • Nothing makes it detect OMP;
    • ./configure --enable-werror $BUILD_OPTS LDFLAGS="-L/usr/local/opt/libomp/lib -lomp" CPPFLAGS="-I/usr/local/opt/libomp/include"
ls -lRh /usr/local/opt/libomp/lib  || true
total 3136
-r--r--r--  1 admin  admin   882K Apr  5 03:36 libomp.a
-r--r--r--  1 admin  admin   681K Apr 14 17:10 libomp.dylib
ls -lRh /usr/local/opt/libomp/include  || true
total 256
-rw-r--r--  1 admin  admin    50K Apr  5 03:36 omp-tools.h
-rw-r--r--  1 admin  admin    23K Apr  5 03:36 omp.h
-rw-r--r--  1 admin  admin    50K Apr  5 03:36 ompt.h
  • Detection saying SSE4.1 is wrong;

configuring snap version via john.conf

There is apparently no documentation about how John can be configured in the Snap version. The John snap filesystem is intentionally write protected and therefore the /snap/johne-the-ripper/current/run/john.conf cannot be altered. Where in the userspace is John looking for an alternate john.conf? This question should be discussed in the Snap version docs.

Unwritable JOHN_HOME causing permission problems in Docker/OCI container

Checklist

  • 🥇 I've read and understood these instructions;
  • 👍 I've tested using latest bleeding package version from this repository.
  • 😕 I'm confused and I need guidance.

Problem description

JtR fails to execute cracking in Docker/container image due permission problems:

$ docker run --rm --volume "${PWD}:/data" ghcr.io/openwall/john:rolling_J31 best --wordlist=/data/wordlist.txt /data/shadow.bak

best --wordlist=/data/wordlist.txt /data/shadow.bak
Will use /john/run/john-avx512bw
Warning: detected hash type "md5crypt", but the string is also recognized as "md5crypt-long"
Use the "--format=md5crypt-long" option to force loading these as that type instead
Warning: only loading hashes of type "md5crypt", but also saw type "sha256crypt"
Use the "--format=sha256crypt" option to force loading hashes of that type instead
Warning: only loading hashes of type "md5crypt", but also saw type "sha512crypt"
Use the "--format=sha512crypt" option to force loading hashes of that type instead
Using default input encoding: UTF-8
open: /john/run/john.log: Permission denied

JOHN_HOME seems to be "/john/run". The default container user "JtR" (UID 1000) does not have write permission to this directory, causing execution to fail.

Build info

$ docker run --rm ghcr.io/openwall/john:rolling_J31 best --list=build-info

best --list=build-info
Will use /john/run/john-avx512bw
Version: 1.9.0-jumbo-1+bleeding-15b3b7c 2023-04-03 12:44:54 -0300
Build: linux-gnu 64-bit x86_64 AVX512BW AC OMP
SIMD: AVX512BW, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
CPU tests: AVX512BW
$JOHN is /john/run/
Format interface version: 14
Max. number of reported tunable costs: 4
Rec file version: REC4
Charset file version: CHR3
CHARSET_MIN: 1 (0x01)
CHARSET_MAX: 255 (0xff)
CHARSET_LENGTH: 24
SALT_HASH_SIZE: 1048576
SINGLE_IDX_MAX: 32768
SINGLE_BUF_MAX: 4294967295
Effective limit: Max. KPC 32768
Max. Markov mode level: 400
Max. Markov mode password length: 30
gcc version: 11.3.0
GNU libc version: 2.35 (loaded: 2.35)
Crypto library: OpenSSL
OpenSSL library version: 030000020
OpenSSL 3.0.2 15 Mar 2022
GMP library version: 6.2.1
File locking: fcntl()
fseek(): fseek
ftell(): ftell
fopen(): fopen
memmem(): System's
times(2) sysconf(_SC_CLK_TCK) is 100
Using times(2) for timers, resolution 10 ms
HR timer: clock_gettime(), latency 33 ns
Total physical host memory: 3827 MiB
Available physical host memory: 2583 MiB
Terminal locale string: C
Parsed terminal locale: UNDEF

$ docker image inspect ghcr.io/openwall/john:rolling_J31 | grep -F Id | tr -d ' '
"Id":"sha256:23d9759026815b746fcd2295314ec609920c99223ee73bc78ab92aede6249b1a",

Migrate our Intel OpenCL CPU CI tests to the new driver

  1. We cannot trust Ubuntu 16 for ever;
  2. New version runs on Ubuntu 22.04;
  3. It is updated (see the driver version);
  4. FPGA emulation looks nice;
  5. Still slow, but faster than the current (Ubuntu 16) version.
Platform #0 name: Intel(R) OpenCL, version: OpenCL 3.0 LINUX
    Device #0 (1) name:     Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
    Device vendor:          Intel(R) Corporation
    Device type:            CPU (LE)
    Device version:         OpenCL 3.0 (Build 0)
    OpenCL version support: OpenCL C 3.0 
    Driver version:         2023.16.10.0.17_160000 
    Native vector widths:   char 64, short 32, int 16, long 8
    Preferred vector width: char 1, short 1, int 1, long 1
    Global Memory:          6921 MiB
    Global Memory Cache:    256 KiB
    Local Memory:           32 KiB (Global)
    Constant Buffer size:   128 KiB
    Max memory alloc. size: 3460 MiB
    Max clock (MHz):        2600
    Profiling timer res.:   1 ns
    Max Work Group Size:    8192
    Parallel compute cores: 2
    Speed index:            41600

Platform #1 name: Intel(R) FPGA Emulation Platform for OpenCL(TM), version: OpenCL 1.2 Intel(R) FPGA SDK for OpenCL(TM), Version 20.3
    Device #0 (2) name:     Intel(R) FPGA Emulation Device
    Device vendor:          Intel(R) Corporation
    Device type:            Accelerator (LE)
    Device version:         OpenCL 1.2 
    OpenCL version support: OpenCL C 1.2 
    Driver version:         2023.16.10.0.17_160000 
    Native vector widths:   char 64, short 32, int 16, long 8
    Preferred vector width: char 1, short 1, int 1, long 1
    Global Memory:          6921 MiB
    Global Memory Cache:    256 KiB
    Local Memory:           256 KiB (Global)
    Constant Buffer size:   128 KiB
    Max memory alloc. size: 3460 MiB
    Max clock (MHz):        2600
    Profiling timer res.:   1 ns
    Max Work Group Size:    67108864
    Parallel compute cores: 2
    Stream processors:      16  (2 x 8)
    Speed index:            41600

Legacy platform is:

Platform #0 name: Intel(R) CPU Runtime for OpenCL(TM) Applications, version: OpenCL 2.1 LINUX
    Device #0 (1) name:     Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
    Device vendor:          Intel(R) Corporation
    Device type:            CPU (LE)
    Device version:         OpenCL 2.1 (Build 0)
    OpenCL version support: OpenCL C 2.0 
    Driver version:         18.1.0.0920 
    Native vector widths:   char 32, short 16, int 8, long 4
    Preferred vector width: char 1, short 1, int 1, long 1
    Global Memory:          6921 MiB
    Global Memory Cache:    256 KiB
    Local Memory:           32 KiB (Global)
    Constant Buffer size:   128 KiB
    Max memory alloc. size: 1730 MiB
    Max clock (MHz):        2300
    Profiling timer res.:   1 ns
    Max Work Group Size:    8192
    Parallel compute cores: 2
    Speed index:            18400

john-avx2.exe

Hi Andre

I could find only the non-omp verson of john-avx2.exe. Do you happen to have the compiled version for windows using omp and avx2 ?

best regards

Create a new 23.04 rolling release

There are some nice fixes upstream and magnum now is improving NT.

There's not much I need to do, it would still be useful to get access to 'super' server again so I can use my GPU-dependent testing tools.

  • 🥇
  • 👍

Rename requirements.txt to requirements.hash

1. Is your feature request related to a problem? Please describe

Some tools are detecting the project as pip related, which doesn't make sense (actually, who cares).

2. Describe the solution you'd like

Anyway, just rename the file.

Create a tool to run JtR in the cloud

Using Terraform and Ansible, automate the creation of a password cracking cluster using the cloud (I’ll start with AWS). Using this tool, the user will be able to:

  • Automate:
    • create count instances in the cloud using Terraform;
    • install JtR on the instance using Ansible (or use Openwall's ami);
    • from the user's local machine he or she will be able to run, control and stop cracking tasks using Ansible

The user will be able to select the type of instance (any instance types including free tier ones).


The user will run locally (well, the master/controller node can run anywhere, including in the cloud):

  • terraform init/apply (inventory file is created);
  • ansible-playbook -i inventory create-jtr.yml (build JtR if AMI does not have it);
  • SSH or ansible command (to run cracking sessions)

See #9


To do:

  • allow SPOT instances and think how we should handle it.

No password hashes loaded

unshadow passwd shadow > full
john full --wordlist=/usr/share/wordlists/rockyou.txt

It just throw the error "No password hashes loaded"

Add automatic Virus Total Scan

Is your feature request related to a problem? Please describe.

In order to increase the security of our packages, add an automatic virus scan process to the repository. When a release happens, scan it.

Describe the solution you'd like

A Github action will do this for us when we create a new release.

Additional context

Maybe some noise will be seen while I work on this.

Add support for NVIDIA GPUs in Docker Image

1. Is your feature request related to a problem? Please describe.

Basically to be ready to use on any GPU in the cloud.

  • The build process is simple and will take advantage of all the infrastructure used to build the CPU version.
  • I don't have continuous access to any NVIDIA GPUs. Therefore, the image cannot be tested properly by CI.
  • Have I told you that I cannot test it properly? No CPU test restrictions.

2. Describe the solution you'd like

The image will be based on nvidia/cuda:12.2.0-base-ubuntu22.04 instead of ubuntu:22.04.

3. Additional context

No AMD or Intel.

Remove the 'tag a Docker image' action

1. Describe the bug

It seems like a bad idea to keep the 'tag Docker image' action active in main. It requires a permissive policy enabled by default and is not important for the repository's daily activities.

In the future, if we need to tag an image, we can do so using the code below (in a temporary branch).

2. How the final version turned out

For the record:

name: Tag Docker Image

on:
  workflow_dispatch:
    inputs:
      target:
        description: "ID of the image to be tagged"
        required: true
        default: "rolling-2310"
      tag:
        description: "The tag that will be applied"
        required: true
        default: "latest"

jobs:
  add-tag:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
      - name: Harden Runner
        uses: step-security/harden-runner@8ca2b8b2ece13480cda6dacd3511b49857a23c09 # v2.5.1
        with:
          egress-policy: audit

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d # v3.0.0
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Run script file
        run: |
          docker pull "ghcr.io/openwall/john:${{ github.event.inputs.target }}"
          docker tag "ghcr.io/openwall/john:${{ github.event.inputs.target }}" "ghcr.io/openwall/john:${{ github.event.inputs.tag }}"
          docker images
          docker push "ghcr.io/openwall/john:${{ github.event.inputs.tag }}"
        shell: bash

Attract contributors (at least one more)

[Edited]

1. Describe the bug

We have a few tasks (the first one, at least) that need to be performed by someone else.

Tasks:

  • open this list of PRs and approve open pull requests [1][2];
  • create a PR to add one example of using the Docker image on some "different" cloud GPU provider;
  • add Sonar code review (this requires @solardiz to approve the extension)
    • BTW: it only have access to the john-packages repository - they use the appropriate GitHub "get access to repository" interface.

[1] add a comment saying lgtm to closed PRs (as a late formal review).
[2] an easy review task (documentation only) is to approve open PR #278.

Document how the Bitrise file differs from what was committed

1. Is your feature request related to a problem? Please describe

Bitrise validation conflicts with our linters. We must document how.

2. Describe the solution you'd like

I will add a patch file that shows where the differences are. It's just formatting.

diff --git a/deploy/Android-Delivery.yml b/deploy/Android-Delivery.yml
index 0427ab8..8021ea9 100644
--- a/deploy/Android-Delivery.yml
+++ b/deploy/Android-Delivery.yml
@@ -50,10 +50,10 @@ workflows:
 
   _deploy:
     steps:
-      - activate-ssh-key@4:
+    - activate-ssh-key@4:
         run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
-      - git-clone@8: {}
-      - [email protected]:
+    - git-clone@8: {}
+    - [email protected]:
         title: Checkout code
         inputs:
           - content: |-
@@ -63,7 +63,7 @@ workflows:
               rm -rf tmp
               git clone --depth 10 https://github.com/openwall/john.git tmp
               cp -r tmp/. .
-      - [email protected]:
+    - [email protected]:
         title: Building JtR
         inputs:
           - content: |-
@@ -85,7 +85,7 @@ workflows:
               mv README.md "${BITRISE_DEPLOY_DIR}/${default_apk_name}/"
               mv run "${BITRISE_DEPLOY_DIR}/${default_apk_name}/run"
               mv doc "${BITRISE_DEPLOY_DIR}/${default_apk_name}/doc"
-      - deploy-to-bitrise-io:
+    - deploy-to-bitrise-io:
         run_if: ".IsCI"
         inputs:
           - is_compress: "true"

IMO, this closed issue is enough to document. Closing.

compress-raw-lzma-perl No longer exists

A large majority of john run commands no longer work due to lzma merging with xz such commands are 7z2john

I dont think I need to list steps to reproduce, just that a large amount of commands are not functional as you can no longer install the old packages

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.