awsum

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 compiler's main branch at github.com/awsum-lang/awsum/commits/main contains all interim commits between tagged releases — each change reaches main through a reviewed pull request gated by CI, never as a "release drop". Every commit on main is a reviewable interim state.

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

Every release of the compiler is published with a unique semantic-version git tag (v0.0.1, v0.0.2, …) at github.com/awsum-lang/awsum/releases. The same version is embedded into the binary (queryable via awsum --version), into download-artifact filenames, and is compared by the LSP server against the expectedAwsumVersion value each editor extension supplies during initialization. Each of the five editor-extension repositories follows the same scheme on its own independent release stream.

Every release is identified by an annotated git tag of the form vMAJOR.MINOR.PATCH in the compiler's repository. The full list is at github.com/awsum-lang/awsum/tags; each tag is also mounted as a GitHub Release with notes drawn from CHANGELOG.md.

Non-trivial release notes file in repository: https://github.com/awsum-lang/awsum/blob/main/CHANGELOG.md.

No publicly known run-time vulnerabilities have been assigned to the Awsum compiler or any of the awsum-lang/ public repositories to date. Release notes are nonetheless maintained in CHANGELOG.md (Keep-a-Changelog format) and surfaced as the body of each GitHub Release; the moment a CVE is filed against an Awsum release, the next release's notes will identify it under a Security section.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/awsum-lang/awsum/blob/main/SECURITY.md. [osps_do_02_01]

Every public repository under github.com/awsum-lang uses GitHub Issues for bug reports, feature requests, and per-release tracking. The compiler's tracker is at github.com/awsum-lang/awsum/issues; each editor extension and the tree-sitter grammar each have their own independent tracker on the same pattern.

Bug reports and the project's responses are archived in GitHub Issues, which is publicly readable without authentication and offers full-text search over open and closed issues alike. The compiler's archive (open + closed) is accessible at https://github.com/awsum-lang/awsum/issues?q=is%3Aissue; each of the other eight public repositories in the awsum-lang organization has its own archive on the same URL pattern.

The vulnerability reporting process is published on both surfaces. On the project website at https://awsum-lang.org/community a "Report security issues" section names the preferred channel (GitHub Private Vulnerability Reporting) and links to the full policy. The full policy itself lives at https://github.com/awsum-lang/awsum/security/policy (rendered from SECURITY.md): preferred and fallback channels, scope, supported-version policy, and committed acknowledgement / fix timelines (7 days / 90 days). The same SECURITY.md is mirrored across all nine public repositories in the awsum-lang organization.

SECURITY.md (rendered at github.com/awsum-lang/awsum/security/policy) lists two private channels: GitHub Private Vulnerability Reporting (preferred — github.com/awsum-lang/awsum/security/advisories/new, visible only to maintainers and the reporter, supports CVE coordination) and a fallback email at security@awsum-lang.org. The policy explicitly warns against using public issues, pull requests, or discussions for security reports. The same channels are surfaced from the project website at https://awsum-lang.org/community#report-security-issues.

No private vulnerability reports have been received through any of the published channels (GitHub Private Vulnerability Reporting or security@awsum-lang.org) in the last 6 months — the 14-day initial-response requirement is therefore satisfied vacuously. The published SECURITY.md commits to a 7-day acknowledgement target (stricter than the badge criterion) for any future report.

The compiler is built with Haskell Stack from publicly pinned configuration (stack.yaml + package.yaml). Local builds run stack build directly or just build for the wrapped form with pedantic warnings (see github.com/awsum-lang/awsum/blob/main/justfile). The same build is re-run by the CI workflow .github/workflows/check-and-build.yml on every pull request across the host-OS / architecture matrix documented in docs/compatibility.md. Each of the eight other public repositories in the awsum-lang organization (editor extensions, tree-sitter grammar, website, examples) ships its own analogous build system on the toolchain native to that stack.

The compiler uses Haskell Stack (the canonical build tool for Haskell projects) configured by stack.yaml and package.yaml at the repository root. A thin just recipe layer at github.com/awsum-lang/awsum/blob/main/justfile wraps the common workflows (just build, just test, just fix) — just is a widely-used command runner, not a custom build system. Continuous integration runs on GitHub Actions (.github/workflows/check-and-build.yml). All toolchain versions are pinned in configuration files committed to the repository.

The compiler is built entirely with FLOSS tools: Haskell Stack (BSD-3-Clause), GHC (BSD-3-Clause), just (CC0-1.0), and GitHub Actions runners running on FLOSS operating systems. No proprietary build dependency anywhere in the chain.
https://github.com/awsum-lang/awsum/blob/main/stack.yaml

The compiler ships a Hspec-based automated test suite under test/, released under the same Apache-2.0 license as the rest of the project. Two layers: snapshot tests across all five backends (just test) and property tests across all five backends with QuickCheck-generated inputs and an independently-computed expected value (just test-property). How to run is documented in docs/testing.md and exercised by the CI workflow .github/workflows/check-and-build.yml on every pull request.

Tests are invocable through the standard Haskell tooling — stack test runs the Hspec suite directly, the same target the CI workflow at .github/workflows/check-and-build.yml invokes. The repository's justfile exposes the same target through just test (snapshot suite) and just test-property (property suite); both wrap stack test underneath.

The test suite covers the surface language, every compiler phase, and every backend. Snapshot tests under test/sources/successful/ and test/sources/errors/ exercise the frontend, typechecker, every lowering and Core-to-Core pass, and all five codegens (LLVM / JVM / CLR / WASM / JS); each program's stdout is asserted identical across the five backends, so every cross-backend divergence in any phase becomes a test failure. Property tests under test/sources/property/ with QuickCheck-generated inputs cover the input-value space — every generated case is fed through all five backends and compared against an independently-computed expected value defined in test/Awsum/PropertySpec.hs. The development workflow in docs/testing.md requires both suites to pass before a feature is considered finished.

Continuous integration runs on every pull request via .github/workflows/check-and-build.yml. The workflow builds the compiler with pedantic warnings, runs the snapshot suite and the cross-backend property suite, and gates merge — a PR cannot land on main until CI is green. Every change therefore reaches the central code repository only after the full automated test suite has passed against it.

The compiler's docs/testing.md section "Workflow when finishing a feature" states: "Any new functionality lands together with the tests that exercise it — snapshot tests for new language features or compiler passes, property tests for behaviour that has a generator-friendly input space." The full precommit just fix (format, lint, build, snapshot tests, property tests) then enforces that those tests pass before the change is pushed.

Recent feature pull requests land with corresponding test sources under test/sources/. For example, #49 "Implement eqString" added test/sources/successful/string_eq/code/Main.aww (which auto-generates per-backend codegen and runtime-stdout snapshots), and the same pattern is visible across the merged-PR history at github.com/awsum-lang/awsum/pulls?q=is%3Apr+is%3Amerged — every PR that adds language- or compiler-visible behaviour also adds (or modifies) entries under test/sources/successful/ or test/sources/errors/. Pure-infrastructure PRs (license switch, CI tweaks) don't add tests, consistent with the policy in docs/testing.md.

The compiler's CONTRIBUTING.md, under "Pull requests", states: "Any new functionality lands together with the tests that exercise it" with a link to the detailed workflow in docs/testing.md.

The compiler enables every GHC warning. package.yaml sets ghc-options: -Weverything with a short list of explicit exclusions, and the build invocation in justfile is stack build --pedantic — --pedantic promotes warnings to errors. The separate FLOSS linter hlint is run by just lint-check and is part of the just fix precommit gate. CI .github/workflows/check-and-build.yml enforces both on every pull request.

Warnings cannot accumulate in the codebase: stack build --pedantic (the build invocation in justfile and the CI workflow .github/workflows/check-and-build.yml) promotes every GHC warning to an error, so a pull request with any unaddressed warning fails CI and cannot be merged. hlint is run on the same gate. Any new warning surfaced by a new GHC release is fixed (or explicitly suppressed in package.yaml with a comment) as part of the upgrade.

The compiler enables -Weverything (the strictest GHC setting — all warnings, including ones disabled by -Wall), with a small explicit allow-list in package.yaml and a rationale comment above each suppression. stack build --pedantic promotes every remaining warning to a build error. hlint runs alongside on the same precommit and CI gate.

Vladimir Logachev is the sole primary developer of the Awsum compiler — initiator of the project, sole maintainer of github.com/awsum-lang/awsum, sole recipient of the private vulnerability-reporting channels, and the engineer who accepts commits and performs all releases. He is familiar with secure-design principles, including the Saltzer–Schroeder principles, and applies them throughout Awsum's design: economy of mechanism (small composable language with no defaulting, no shadowing, no catch-all on case); fail-safe defaults (errors are values via Either and IO e a, platform effects denied by default per program-type — using a browser-only effect in a CLI program is a compile error); complete mediation (every effect, pattern match, and arithmetic operation is mediated by the typechecker, with no escape hatch); open design (the compiler is FOSS and every design decision is documented in docs/); limited attack surface (no network operations, no dynamic plugin loading, dependencies pinned via stack.yaml); input validation with allowlists (the parser accepts only what the formal grammar describes, the typechecker rejects everything not explicitly permitted, row labels are validated against an allowlist with FNV-1a hash-collision detection, CLI flags are checked against an explicit option set); psychological acceptability (diagnostics carry source spans and machine-readable JSON, compiler-provided quick fixes surfaced through the LSP server to all five supported editors).

Vladimir Logachev, as the sole primary developer, is familiar with common vulnerability classes relevant to compiler software — both classical (path traversal when reading source files, integer overflow in compiler internals, untrusted-input parser robustness, dependency-supply-chain risk, hash collisions in identifier tables) and code-generation-specific (memory safety in emitted LLVM/WASM via compiler-emitted reference counting, no undefined behaviour in generated IR, deterministic per-target lowering) — and applies mitigations consistently: input validation with allowlists for every external surface (grammar, type system, row-label hashes with explicit collision detection in Awsum.ElaborateLower, CLI flag parsing), Stack-pinned dependencies with no network operations, no dynamic plugin loading, OS-shell invocation only for build artefacts under paths the compiler itself controlled, and an arithmetic model (Either + typed overflow / underflow / precision-loss errors) that eliminates entire classes of silent corruption in user-written programs the compiler produces.

The Awsum compiler does not use any cryptographic protocols or algorithms. There is no network operation, no signing or encryption of compiler output, no password handling, no certificate verification. The only hash function used internally is the non-cryptographic FNV-1a 32-bit for row-label tag dispatch in Awsum.ElaborateLower, with explicit collision detection at lowering time — it is not used in a security context.

The Awsum compiler does not use cryptography for any purpose; nothing is re-implemented because nothing is needed.

The Awsum compiler does not use cryptography for any purpose.

The Awsum compiler does not use cryptography for any purpose.

The Awsum compiler does not use cryptography for any purpose.

The Awsum compiler does not use cryptography for any purpose.

The Awsum compiler does not use cryptography for any purpose.

The Awsum compiler does not use cryptography for any purpose; no key or nonce generation.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing in the Awsum compiler retrieves a cryptographic hash over a network at any point. The install workflows documented on the project website at awsum-lang.org/install use HTTPS (TLS-secured) to download release artefacts from GitHub Releases, which are themselves served by GitHub over HTTPS. There is no http:// (plain HTTP) operation anywhere in the project's source, install instructions, or CI workflows.

No publicly known unpatched vulnerabilities exist for the Awsum compiler. No CVEs have been assigned, and no reports have been submitted through the channels listed in SECURITY.md. The project commits to a 90-day fix-or-mitigation timeline once a vulnerability is reported, well within the 60-day post-disclosure window the criterion enforces.

No vulnerabilities have been reported against the Awsum compiler. The published SECURITY.md commits to acknowledgement within 7 days and a fix or mitigation within 90 days; critical findings will be prioritized for faster turnaround as standard practice.

The compiler repository at github.com/awsum-lang/awsum contains no credentials, private keys, API tokens, or any other secret material. GitHub's secret-scanning runs on every push and has flagged no exposures. No CI workflow embeds plaintext secrets — anything required by CI uses GitHub Actions encrypted secrets at runtime.

The compiler's precommit and CI gate runs hlint (BSD-3-Clause, the canonical Haskell static-analysis linter), separate from the GHC compiler warnings. Invoked as just lint-check in justfile, part of the just fix full precommit, and re-run by CI in .github/workflows/check-and-build.yml. No production release ships unless hlint reports clean.

The compiler is written in Haskell, where the type system itself enforces — by construction — many of the invariants that security-focused static analysers exist to catch in other languages: no null pointer dereferences (no implicit null), no buffer overflows (no raw pointer arithmetic, no manual length bookkeeping), no uninitialized memory reads, no implicit type conversions, no silent integer overflow in the compiler's own code (the production code uses explicit Integer or bounded arithmetic). -Weverything (in package.yaml) plus stack build --pedantic promote every such property to a build-failing diagnostic. hlint (run via just lint-check) adds code-quality and pattern-redundancy checks on top. There is no widely-adopted FLOSS Haskell-specific security linter equivalent to bandit / gosec; the type-system enforcement and pedantic compilation cover the spirit of the criterion in this language.

No medium- or higher-severity exploitable vulnerabilities have been surfaced by static analysis on the Awsum compiler. hlint runs on every pull request via just fix and CI, and a clean report is a merge gate — any new finding would block merge and be addressed before the change lands. The same gate applies to release branches; no production release ships with outstanding findings.

hlint runs on every pull request via .github/workflows/check-and-build.yml, which gates merge — a PR cannot reach main until the static-analysis step is green. Every commit reaching the main branch has therefore passed static analysis.

The compiler is subject to property-based dynamic analysis through the QuickCheck suite under test/sources/property/, invoked as just test-property. Every generated input is compiled by each of the five backends (LLVM, JVM, CLR, WASM, JS) and run, then the stdout from each is compared against an independently-computed expected value defined in Haskell — any cross-backend divergence or any incorrect answer fails the test. The property suite is part of the just fix precommit pipeline and the CI gate at .github/workflows/check-and-build.yml, so no major release ships without it passing.

The Awsum compiler is written entirely in Haskell, a memory-safe garbage-collected language. No C / C++ / unsafe-Rust code is shipped in the compiler binary.

The property-test suite (just test-property) is itself an assertion-rich dynamic-analysis configuration: every QuickCheck-generated input must produce stdout identical across all five backends and equal to an independently-computed expected value in Haskell — three layers of assertion per generated case. The compiler also includes always-on internal invariants (the Awsum.StackSafety post-pipeline verifier rejects any program where a non-tail self-call or non-trivial call-graph SCC survived the recursion-flattening passes; the Awsum.Reuse and Awsum.Lifetime passes assert well-formedness conditions on Core). These invariants ship enabled in production builds because their cost is negligible and they prevent silent miscompilation.

No medium- or higher-severity exploitable vulnerabilities have been surfaced by the project's dynamic-analysis suite (property tests, cross-backend identical-stdout invariant). The suite is a merge gate via just fix and the CI workflow .github/workflows/check-and-build.yml — any failure blocks merge and is addressed before the change lands; no release ships with outstanding findings.