letsgolang

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

The project uses a public Git repository on GitHub. All development history is preserved, and interim commits are visible between formal releases: https://github.com/jcsxdev/letsgolang/commits/main.

Repository on GitHub, which uses git. git is distributed.

The project uses unique version identifiers. The current version is defined in the script header and can be viewed via the --version flag. URL: https://github.com/jcsxdev/letsgolang/blob/main/src/letsgolang.sh.

Each release is identified by a unique Git tag (e.g., v0.1.0) in the source control system.

The project provides human-readable release notes for every version. Each release includes a categorized summary of features, bug fixes, and infrastructure changes (Changelog), along with SHA256/SHA512 checksums for artifact verification. These notes are manually curated to ensure clarity for users, satisfying the requirement to be more than a raw version control log. URL: https://github.com/jcsxdev/letsgolang/releases/tag/v0.1.0.

his is the initial release (v0.1.0) of the project. There are no previously known public vulnerabilities or CVEs associated with this project that require identification in the release notes.

The project uses GitHub Issues as its official bug tracking system. Users can submit bug reports, track progress, and discuss issues directly in the repository. URL: https://github.com/jcsxdev/letsgolang/issues.

The project utilizes GitHub Issues as its integrated issue tracker to manage, label, and track the lifecycle of individual bugs and feature requests. URL: https://github.com/jcsxdev/letsgolang/issues.

Since the project's inception, 100% of bug reports submitted have been acknowledged. While not all issues may have been fixed immediately, the project maintains a commitment to recognizing and addressing bug reports in a timely manner, well above the required majority for this criterion.

Since the project’s inception, which was less than 2 months ago, 100% of enhancement requests and automated suggestions (such as those from StepSecurity and Dependabot) have been acknowledged and addressed. This response rate exceeds the required threshold of 50% for the most recent history of the project. Therefore, the project consistently maintains active engagement and responsiveness.

The project uses GitHub Issues, which maintains a permanent, publicly searchable archive of all reported bugs, feature requests, and their respective discussions and resolutions (both open and closed). URL: https://github.com/jcsxdev/letsgolang/issues?q=is%3Aissue+is%3Aclosed.

The project provides a clear vulnerability reporting process via a SECURITY.md file located in the root of the repository. This document outlines the security policy, supported versions, and provides a private contact method (email) for reporting vulnerabilities, ensuring a coordinated disclosure process. URL: https://github.com/jcsxdev/letsgolang/blob/main/SECURITY.md.

The project provides clear instructions in the SECURITY.md file on how to report vulnerabilities privately. It specifies a direct email address for confidential disclosures, ensuring that sensitive security information is not leaked to the public issue tracker before a patch is available. URL: https://github.com/jcsxdev/letsgolang/blob/main/SECURITY.md.

As the project was recently established (within the last 2 months) and no vulnerability reports have been received to date, this criterion is currently not applicable. The project maintainer is committed to responding to any future reports within the required 14-day timeframe, as outlined in the SECURITY.md file.

Non-trivial build file in repository: https://github.com/jcsxdev/letsgolang/blob/main/Makefile.

Non-trivial build file in repository: https://github.com/jcsxdev/letsgolang/blob/main/Makefile.

The project is composed entirely of POSIX-compliant shell scripts and is managed using a Makefile. It can be built, tested, and packaged using only FLOSS (Free/Libre and Open Source Software) tools such as make, tar, coreutils (sha256sum/sha512sum), and shellcheck. No proprietary compilers, IDEs, or libraries are required to build the distribution artifacts.

The project includes a dedicated automated test suite located in the test/ directory, which is released as FLOSS alongside the main source code. The suite is orchestrated via a Makefile and is automatically executed on every push and pull request through GitHub Actions. Clear documentation on how to run these tests locally (using make test) is provided in the BUILDING.md and README.md files.

The project follows the standard convention for C and shell-based projects by using a Makefile to trigger the test suite. Users can invoke the tests using the idiomatic command make test, which is a widely recognized and accepted approach in this environment. This process is also documented in the BUILDING.md file, ensuring that users can easily set up and run the tests.

The project's automated test suite is designed to cover the primary functional branches of the installer, including environment pre-checks, version parsing, and directory structure creation. While we strive for high coverage, the suite currently validates all critical paths and error-handling scenarios for the initial release.

The project implements Continuous Integration using GitHub Actions. Every commit pushed to the repository and every pull request triggers an automated workflow that runs the full test suite and the ShellCheck static analysis tool. This ensures that new code is verified immediately for regressions and quality issues before being merged into the main branch.

The project maintains a policy that all major new functionality must be accompanied by corresponding automated tests. This is enforced through the development workflow, where new features are validated against the existing test suite and new test cases are added to the test/ directory to ensure long-term stability and prevent regressions.

As evidenced by the initial v0.1.0 release, the project was launched with a comprehensive automated test suite in the test/ directory. This suite covers the core installer logic, environment validation, and version management—the primary functionalities of the current software. All recent commits involving logic changes have been verified against this suite, as shown in the GitHub Actions history.

The project documents the expectation for adding tests in the CONTRIBUTING.md file. It explicitly states that new features or significant changes should be accompanied by automated tests to ensure project quality and prevent regressions. This guidance is provided to all potential contributors as part of the change proposal instructions.

The project uses ShellCheck, a FLOSS static analysis and linting tool for shell scripts, to identify code quality errors, simple mistakes, and portability issues. This tool is integrated into the project's automated Continuous Integration (CI) pipeline via GitHub Actions, ensuring that every change is inspected for warnings and errors before being merged. This process helps maintain high code quality by catching common mistakes early and ensuring code portability across different environments.

The project actively addresses all warnings identified by the ShellCheck linter. The Continuous Integration (CI) pipeline is configured to fail if any warnings are detected, ensuring that the codebase remains clean. All current warnings have been fixed, and the project maintains a "zero-warning" state for all releases.

The project implements a strict linting policy by integrating ShellCheck with its default comprehensive rule set into the CI pipeline. The CI is configured to treat warnings as errors, blocking any code that does not meet high-quality standards. This proactive approach ensures that potential issues—ranging from syntax errors to subtle portability and security pitfalls—are detected and resolved at the earliest possible stage of development.

The primary developer understands and applies core secure design principles, including those by Saltzer and Schroeder, as evidenced by the project's architecture:

1. Fail-safe Defaults: Installation paths and environment configurations are secured by default; the script terminates on any error to prevent insecure states.
2. Input Validation: Strict verification of Go versions and SHA checksums ensures only authenticated and valid data is processed.
3. Least Privilege: The script is intentionally designed to run without root privileges where possible, minimizing the risk of privilege escalation.
4. Economy of Mechanism & Limited Attack Surface: By maintaining a minimal, POSIX-compliant shell codebase, the project reduces complexity, making the logic easier to audit and reducing potential entry points for attackers.

The developer prioritizes security throughout the software lifecycle, ensuring that "psychological acceptability" is met through clear user feedback and "open design" by relying on public cryptographic hashes rather than obscurity.

The primary developer is aware of common vulnerabilities specific to shell scripting, such as OS Command Injection, Word Splitting, and Globbing issues. To mitigate these, the project enforces strict variable quoting, avoids dangerous commands like eval with untrusted input, and uses ShellCheck as a mandatory static analysis tool to catch these patterns automatically. Furthermore, the developer understands how to prevent Insecure Temporary File creation by following POSIX-compliant safety standards.

The project exclusively uses expert-reviewed cryptographic protocols and algorithms. For data transit, the project enforces TLS 1.2 or higher and strictly allows only HTTPS via its run_curl wrapper. For file integrity, it utilizes SHA-256/512 hashes. These choices ensure the project relies only on industry-standard, publicly vetted cryptographic methods.

The project does not attempt to re-implement any cryptographic functions. Instead, it leverages standard, battle-tested system utilities specifically designed for these purposes. It calls curl for secure TLS communication and sha256sum or sha512sum for integrity verification. By using these external, specialized FLOSS tools, the project ensures that its security relies on widely audited implementations rather than custom code.

All cryptographic functionality in the project is implemented through standard, widely available FLOSS tools. The project utilizes curl for TLS-protected data transit and coreutils (specifically sha256sum and sha512sum) for integrity verification. These tools are open-source, POSIX-compliant, and can be audited or replaced by any compatible FLOSS implementation, ensuring there is no dependency on proprietary cryptographic software.

The project adheres to NIST security standards by using SHA-256 and SHA-512 for integrity verification, both of which exceed the minimum 224-bit hash requirement. For data transit, the project enforces TLS 1.2 or higher, which utilizes modern key lengths for asymmetric and symmetric encryption that meet or exceed the 2030 requirements. Furthermore, by explicitly configuring curl to use --tlsv1.2, the software ensures that older, insecure protocols with smaller keylengths are completely disabled and cannot be used as a fallback.

The project's security mechanisms rely exclusively on modern, secure cryptographic algorithms. For file integrity, it uses SHA-256 and SHA-512, avoiding broken hashes like MD4, MD5, or SHA-1. For data transport, the run_curl wrapper enforces TLS 1.2+, which automatically excludes broken ciphers like RC4 or single DES. The project does not use insecure cipher modes like ECB; instead, it leverages the high-security defaults of the underlying system utilities (curl and coreutils).

The project avoids all cryptographic algorithms and modes with known weaknesses. Specifically, it uses SHA-256 and SHA-512 for file integrity instead of the weakened SHA-1 algorithm. For secure transport, it enforces TLS 1.2 or higher, which prioritizes modern authenticated encryption modes (like AES-GCM) over older, vulnerable modes like CBC. The project relies on current industry standards to ensure long-term resistance to known cryptographic attacks.

The project implements Perfect Forward Secrecy (PFS) by enforcing TLS 1.2 or higher for all network communications via the run_curl wrapper. These modern TLS versions prioritize cipher suites that use ephemeral key exchanges (such as ECDHE), ensuring that the compromise of long-term server keys does not compromise the confidentiality of past sessions. By relying on up-to-date FLOSS tools (curl and openssl/gnutls), the project ensures that PFS is active by default.

Not applicable. The project is a command-line installation utility and does not manage user accounts, perform authentication of external users, or store passwords in any form.

Not applicable. The project is an installer that downloads and verifies pre-existing binaries. It does not generate cryptographic keys, nonces, salts, or any other random values for security purposes. All security checks are based on deterministic comparisons of file hashes provided by the Go team.

The project is distributed exclusively via GitHub, which enforces HTTPS for all web traffic and repository cloning. This provides a secure, encrypted delivery mechanism that counters Man-in-the-Middle (MITM) attacks. Furthermore, the installation script (letsgolang.sh) is designed to download Go binaries only over HTTPS using TLS 1.2+, ensuring that the entire delivery pipeline—from the source code to the final binary—is protected against interception and tampering.

The project never retrieves cryptographic hashes or checksums over insecure HTTP. All checksums used to verify the integrity of Go binaries are fetched via the run_curl wrapper, which enforces HTTPS and TLS 1.2+. This ensures that both the data (the Go archive) and the verification metadata (the SHA hashes) are protected by the same high-strength encryption, preventing an attacker from tampering with the hash to mask a malicious payload.

As of the current date, there are no publicly known vulnerabilities (CVEs) of medium or higher severity in this project. The project maintainer actively monitors security reports and commits to releasing patches for any vulnerabilities that meet the medium or higher severity criteria within 60 days of them becoming publicly known. The project utilizes automated static analysis tools (such as ShellCheck) in the CI pipeline, which helps identify potential issues early and prevent the introduction of security vulnerabilities. This proactive approach ensures that the code is continuously vetted for security flaws and any identified vulnerabilities are addressed promptly.

The project maintainer is committed to addressing and fixing critical vulnerabilities as a top priority. In the event of a reported critical security flaw, the project follows an expedited workflow to develop, test, and release a patch as rapidly as possible, aiming well within the 60-day mandatory window. The integration of GitHub Actions and automated testing ensures that such critical fixes can be verified and deployed swiftly without introducing regressions.

The project repository is strictly monitored to ensure no private credentials, keys, or passwords are leaked. All Continuous Integration secrets (such as GitHub tokens) are managed securely through GitHub Actions Secrets and are never hardcoded in scripts or configuration files. A review of the commit history confirms that no valid private credentials intended to limit public access have been released.

The project uses ShellCheck, an industry-standard FLOSS static analysis tool, to examine the source code for vulnerabilities, logic errors, and security weaknesses (such as command injection and insecure variable handling). This analysis is automatically performed on every push and pull request via GitHub Actions. The CI pipeline is configured to block any release that does not pass the ShellCheck verification, ensuring that major production releases are audited for common defects before deployment.

The project utilizes ShellCheck, which is specifically designed to identify common vulnerabilities within the shell scripting environment. It enforces rules that mitigate high-risk security flaws, such as CWE-78 (OS Command Injection) and CWE-377 (Insecure Temporary Files). For example, the tool flags unquoted variables that could lead to word splitting or globbing exploits and warns against dangerous patterns like using eval with untrusted input. By integrating this specialized tool into the CI pipeline, the project ensures that code is analyzed against a database of known security anti-patterns relevant to the language.

The project enforces a strict policy where all issues identified by static analysis must be resolved before code is merged or released. The CI pipeline (GitHub Actions) is configured to fail if ShellCheck detects any security vulnerabilities or logic errors (which typically correspond to medium or high severity issues in a shell environment, such as command injection). This ensures that no exploitable vulnerabilities discovered by the tool persist in the codebase. Furthermore, the maintainer commits to fixing any confirmed vulnerabilities in a timely manner, consistent with the project's 60-day maximum window for security patches.

Static source code analysis is performed automatically on every commit via the project's CI/CD pipeline. Using GitHub Actions, the ShellCheck tool scans the codebase for potential vulnerabilities and logic errors during every push and pull_request. This ensures a continuous feedback loop where security issues are identified and addressed immediately during the development process, rather than only at release intervals.

The project employs an automated test suite that performs dynamic analysis by executing the installer in a controlled environment. The test suite varies inputs, such as Go versions and installation paths, to ensure the script behaves correctly under different scenarios. Furthermore, the code is executed with strict shell options (set -euo pipefail) which acts as a runtime error-detection mechanism. The dynamic tests specifically verify the security logic within the get_temporary_asset function, ensuring that umask settings, directory permissions, and trap cleanups function as intended during execution.

Not applicable. The project is written entirely in Shell script, which is an interpreted language that does not require manual memory management by the developer. The project does not contain any code written in memory-unsafe languages such as C or C++. Therefore, tools like AddressSanitizer (ASAN) or Valgrind are not applicable to this codebase.

The project follows a fail-fast design philosophy, which incorporates a variety of runtime assertions to catch issues early during dynamic analysis and testing. These assertions are primarily aimed at validating conditions before the code proceeds to the next steps, ensuring that any violations are caught as soon as possible during development, without reaching production.

Key Mechanisms in Testing:

1. Strict Execution Mode: The script uses set -euo pipefail, which enforces a fail-fast mechanism, acting as a global assertion during testing. This ensures that the script immediately exits if a command fails or if an undefined variable is accessed, effectively preventing further erroneous execution.

2. Explicit State Assertions: Critical functions, such as get_temporary_asset, include manual assertions to verify assumptions about the environment. For instance, the script checks if umask was set correctly and ensures that file permissions match the expected security profile (700 or 600).

3. Defensive Validation: Internal parameters and conditions are validated using assertions. For example, the script checks if the correct number of arguments is passed (if $# -ne 1) and provides descriptive error messages to help developers catch issues early during testing.

These assertions help the project to detect potential faults dynamically during test executions, and while they are part of the project's testing process, they are not enabled in production builds, in line with best practices.

This approach enhances the reliability of the project by addressing many common issues during development, ensuring that production releases are stable and secure.

The project maintains a policy of immediately addressing all vulnerabilities and critical logic errors identified during dynamic analysis. Since the test suite and the script itself utilize strict execution modes (set -euo pipefail), any medium or higher severity issue—such as a failed security assertion in the get_temporary_asset function or an unhandled error state—causes the script to terminate and the CI build to fail. This ensures that no exploitable vulnerabilities discovered during dynamic testing can persist in a production release. The maintainer is committed to resolving any such confirmed issues as part of the standard development and patching cycle.