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 fully complies with the repo_interim criterion. It uses GitHub as its version control system, where all commits and development history are publicly visible. The repository shows a continuous stream of commits between tagged releases, preserving the complete development timeline. This allows for collaborative review of all interim versions and changes. The project follows a standard Git workflow, with feature branches, pull requests, and regular commits to the main branch, making the entire development process transparent. The commit history demonstrates incremental development rather than just publishing final releases. There's no evidence of history rewriting or squashing that would obscure interim development stages. Pull requests with discussions and code reviews are also available, further supporting collaborative development. This approach ensures that reviewers can examine how the code evolved between releases, satisfying the repo_interim criterion's requirement for accessible interim versions.

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

SemVer is beeing used for releases

git tags are beeing used

There have been no publicly known vulnerabilities

If you encounter bugs or have feature requests, please file an issue at: https://github.com/szydell/gcs_antal/issues When reporting issues, please include:

Steps to reproduce the problem
Expected behavior
Actual behavior
GCS Antal version
Go version
NATS server version
GitLab version (if relevant)

https://github.com/szydell/gcs_antal/issues

https://github.com/szydell/gcs_antal/issues?q=is%3Aissue%20state%3Aclosed

https://github.com/szydell/gcs_antal/security/advisories/new

https://github.com/szydell/gcs_antal/blob/main/SECURITY.md

Github Actions

Only a golang compiler is needed.

esting Unit Tests

To run the automated test suite for GCS Antal:

Run all tests

go test ./...

Run tests with verbose output

go test -v ./...

Run tests with coverage report

go test -cover ./...

Generate detailed HTML coverage report

go test -coverprofile=coverage.out ./... go tool cover -html=coverage.out -o coverage.html

When adding new features or fixing bugs, make sure to run the test suite to verify that everything continues to work as expected.

go test

0 warnings for now. Clean code policy.

The project meets the crypto_floss criterion as it is built entirely in Go, which is FLOSS software. All cryptographic functionality in the project relies on Go's standard crypto libraries, distributed under the BSD license approved by the OSI. The project uses no proprietary cryptographic implementations or services requiring closed-source code. All cryptographic standards used (such as TLS, SHA, AES) have FLOSS implementations that the project utilizes. The build and testing processes, including security verification, are performed using FLOSS tools like GitHub Actions, CodeQL, and OSV-Scanner. This ensures full compliance with the Open Standards Requirement for Software, as all cryptographic functionality can be implemented using only FLOSS components.

The project meets the security requirements for key lengths. The application uses Go's standard crypto libraries, which by default implement TLS with cipher suites that meet NIST's minimum requirements through 2030. According to NIST specifications from 2012, RSA keys should be at least 3072 bits and ECC keys at least 256 bits for security beyond 2030 16.

Go's TLS implementation defaults to secure cipher suites, with ECDHE-ECDSA-AES256-GCM-SHA384 being preferred, which uses 256-bit ECC keys that meet the NIST requirements 14. The project allows configuration of TLS parameters through Go's crypto/tls package, where developers can set the MinVersion to TLS 1.2 or higher and specify only cipher suites with adequate key lengths.

Additionally, Go's crypto libraries automatically block weak encryption methods, ensuring smaller key lengths can be completely disabled by correctly configuring the supported cipher suites and minimum TLS version. The project follows these security best practices and does not override these secure defaults with custom configurations that would reduce security.

The project complies with the crypto_working criterion. Analysis shows that it relies solely on Go's standard cryptographic libraries, which by default avoid broken cryptographic algorithms such as MD4, MD5, single DES, RC4, and Dual_EC_DRBG. Go's TLS implementation defaults to secure modern cipher suites, preferring algorithms like AES-GCM and ECDHE key exchange. The project doesn't override these secure defaults or implement any custom cryptographic protocols that could introduce weak algorithms. Additionally, Go's standard library automatically disables weak ciphers in its TLS implementation. The project doesn't require any broken algorithms for interoperability purposes, so no documentation of security risks or mitigations is necessary. By using Go's crypto packages with their default settings, the project inherits modern security practices that avoid deprecated and broken cryptographic algorithms.

The project complies with the crypto_weaknesses criterion as it relies on Go's standard cryptographic libraries which default to secure algorithms and modes. Go's crypto packages avoid known weaknesses by default, preferring AES-GCM over CBC mode and using SHA-256 or stronger hashing algorithms rather than SHA-1. The project doesn't override these secure defaults with custom implementations. For SSH functionality, Go's crypto/ssh package disables CBC mode by default since Go 1.11, using more secure options like AES-GCM or ChaCha20-Poly1305. The codebase doesn't explicitly enable any cryptographic algorithms with known weaknesses, and Go's modern TLS implementation automatically selects cipher suites that avoid problematic modes. By adhering to Go's secure defaults, the project inherently avoids dependence on cryptographic algorithms or modes with known serious weaknesses.

The project satisfies the crypto_pfs criterion as it relies on Go's standard TLS implementation, which provides perfect forward secrecy by default. Go's crypto/tls package prioritizes cipher suites that use Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) for key exchange, ensuring that session keys are generated independently for each session. With ECDHE, even if a server's long-term private key is compromised in the future, previously recorded encrypted sessions cannot be decrypted as the ephemeral keys used for those sessions are discarded after use. Go's default cipher suite preference list places ECDHE suites at the top, such as TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, and the project doesn't override these secure defaults. Additionally, with TLS 1.3 support in modern Go versions, perfect forward secrecy is mandatory for all connections. By leveraging Go's secure defaults, the project inherently implements perfect forward secrecy in its TLS communications.

Based on the analysis of the project, it appears that the application does not implement any user authentication system that would require password storage. The project is a Go application focused on specific functionalities rather than user management. There is no code present for storing, hashing, or validating user passwords. Since the project doesn't store passwords for authentication of external users, the crypto_password_storage criterion is not applicable to this project. If user authentication functionality were to be added in the future, it would need to implement password storage using appropriate key stretching algorithms like Argon2id, Bcrypt, Scrypt, or PBKDF2 with per-user salts as recommended by OWASP's Password Storage Cheat Sheet to comply with this criterion.

The project meets the crypto_random criterion by exclusively using Go's cryptographically secure random number generation facilities. The codebase relies on Go's standard crypto packages, which internally use the crypto/rand package for generating keys and nonces. This package implements a cryptographically secure random number generator that draws entropy from the operating system. The project doesn't use Go's math/rand package, which would be cryptographically insecure, for any security-related operations. Additionally, when creating TLS configurations or working with other cryptographic primitives, the project inherits the secure defaults from Go's standard libraries, which automatically use secure random sources. By leveraging Go's crypto packages and their built-in secure random number generation, the project ensures that all cryptographic keys and nonces are generated using cryptographically secure methods.

The project complies with the delivery_mitm criterion as it utilizes secure delivery mechanisms that counter Man-in-the-Middle attacks. The project is hosted on GitHub, which uses HTTPS by default for all repository operations including cloning, pulling, and accessing releases. This ensures encrypted communication that prevents eavesdropping and tampering during code delivery. For users who prefer additional security, GitHub also supports SSH access to repositories, providing cryptographic authentication and encrypted transfers. The project's continuous integration and deployment processes, implemented through GitHub Actions, similarly operate over HTTPS connections. While the project does not currently implement digitally signed packages (which would provide an additional layer of security against compromised distribution systems), the use of HTTPS and SSH satisfies the baseline requirement for countering MITM attacks in the delivery process.

Go's module system, which the project uses for dependency management, verifies package checksums against the go.sum file, and this verification happens over HTTPS, not HTTP. Additionally, the project doesn't implement any custom code that would download hashes over insecure HTTP connections and use them without cryptographic signature verification.

The project follows secure practices by leveraging Go's standard security mechanisms and GitHub's secure delivery infrastructure. There are no instances where the project would download a cryptographic hash over plain HTTP and use it without verification, thus satisfying the delivery_unsigned criterion which prohibits such insecure practices.

Every push to repo is tested for private credentials.

CodeQL

CodeQL, OSV-Scanner

every pushed to repo commit, and daily.

Software written in Golang.