Bug: install.sh fails checksum verification when falling back to OpenSSL (invalid cut flag)

[gokalp-ercilasun]

The Problem
The install.sh script for golangci-lint fails during the checksum verification step when the system falls back to using openssl for hashing. This occurs when sha256sum or shasum are unavailable in the $PATH.

Environments Impacted:

• Local Development: macOS (Darwin/arm64) environments where openssl is the primary hashing utility.
• CI/CD Pipelines: Minimal GitLab runners (amd64) and Docker images (like alpine or debian-slim) that include openssl for security but omit coreutils or perl.

Root Cause Analysis
The failure is located in the hash_sha256 function's OpenSSL block:

elif is_command openssl; then
  hash=$(openssl -dst openssl dgst -sha256 "$TARGET") || return 1
  echo "$hash" | cut -d ' ' -f a  # <--- The invalid flag

1. Invalid Syntax: -f a is not a valid field list for cut. On most modern shells, this causes an immediate exit when set -e is active.
2. Parsing Failure: Because cut fails to extract the hash, the script compares the full OpenSSL output (e.g., SHA256(file)= [hash]) against the raw hex string in the checksum file. This leads to a verification error:
   err hash_sha256_verify checksum for '...' did not verify [HASH] vs [PREFIXED_HASH]

This bug has likely remained dormant for years because openssl is the last priority in the function. However, as more teams move toward minimal CI images and Apple Silicon, this fallback is being triggered more frequently.

The Solution
I propose replacing the brittle cut command with awk '{print $NF}'.

Why this is more robust:

• Position Independence: OpenSSL output formats vary across versions and OS flavors (e.g., SHA256(file)= hash vs (stdin)= hash vs just the hash).
• Reliability: awk '{print $NF}' (Print Next Field) always extracts the final string on the line, which is guaranteed to be the hash, regardless of what prefix OpenSSL provides.
• Compatibility: awk is a POSIX standard found in almost all minimal environments, including BusyBox.

Proposed Change:

elif is_command openssl; then
  openssl dgst -sha256 "$TARGET" | awk '{print $NF}'

See implementation example on this fork

Testing
I have verified this fix locally on macOS and within a minimal GitLab runner environment. It successfully parses the hash and passes the hash_sha256_verify check.

I am happy to submit a Pull Request if the maintainers agree this is the right approach.

[ldez]

Duplicate of #6539, #6537, #6555, #6556, #6540, #6568, #6570, #6585

---

Important

If you are using the install script from the master branch:
https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh
This branch is not used anymore, we are using main.

We recommend using https://golangci-lint.run/install.sh as URL to install golangci-lint.

https://golangci-lint.run/docs/welcome/install/local/#binaries

---

[ldez]

Fresh new account (19 minutes), AI-generated content without looking for duplicate, forked golangci-lint to "fix" the thing.

Details

This is an AI agent.

You are banned.

Attached accounts:

• https://github.com/arcug
• https://github.com/gokalper

---

EDIT:

A freshly created account (less than 20 minutes) has open a discussion to report a bug (why not an issue?) on, IMO, a duplicated and fixed problem (already 8 duplicates).
The content was 100% AI-generated, and referring to a fork created by this account but with a commit from another account.

Right after the discussion was closed, and the first account banned, a 3nd account created a new issue (AI-generated too) to complain about the ban of the first account, where a discussion may be more appropriate this time.
This issue has been created without using our required issue templates, with an inappropriate title, and some inappropriate content.

The issue has been automatically closed, and then I deleted it, the 3rd account has been banned for violation of our community guidelines.

Also, using multiple accounts to interact with a repository is against our community guidelines and the GitHub terms of service.

The user behind these accounts may have had interesting things to say, but he went about it the wrong way.

After that, the user jumps on the general Slack channel of the Gopher community to complain about the sanction he received.
And publicly accuse me of being "very mean", "lacking common decency", "crazy", doing "antics", and "spoiling the gopher community".

The admins of the Gopher Slack Community have deleted the message of this user.

The ban was already justified, but this reaction reinforced my decision.