MsgEater

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.

Work lands on main as individual commits between releases, so the repository history contains interim states and not only final releases. Releases are git tags (v0.4.1 ... v0.4.4) placed on that history. main is protected and requires pull requests, so every intermediate change is publicly reviewable. https://github.com/oscarhenriquezg/msgeater/commits/main

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

Every release carries a unique version identifier: the version field in package.json (currently 0.4.4), a matching git tag, a GitHub Release, version-stamped installer filenames (for example MsgEater-0.4.4-x86_64.AppImage), and the version shown in the application About dialog. https://github.com/oscarhenriquezg/msgeater/releases

The project uses Semantic Versioning (MAJOR.MINOR.PATCH), for example 0.4.3 followed by 0.4.4, both in package.json and in the git tags.

Each release is identified in git with a v<version> tag (v0.4.1, v0.4.2, v0.4.3, v0.4.4). The release workflow is in fact triggered by pushing such a tag. https://github.com/oscarhenriquezg/msgeater/tags

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

There have been no publicly known vulnerabilities in the software produced by this project, so no release note has had to describe one. CHANGELOG.md does record dependency-level advisories that were remediated, but this criterion explicitly excludes dependencies.

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

The project uses GitHub Issues as its issue tracker for individual bug reports and enhancement requests. https://github.com/oscarhenriquezg/msgeater/issues

All issues opened so far have been acknowledged and resolved by the maintainer; there is no backlog of unanswered bug reports. CONTRIBUTING.md sets the expectation for how reports are handled, and SECURITY.md commits to a 72-hour acknowledgement for security reports. https://github.com/oscarhenriquezg/msgeater/issues

Enhancement requests are tracked in the same GitHub issue tracker and are answered by the maintainer, either by accepting them onto the roadmap or by explaining why they fall outside the scope described in the README section on known limitations. There are no unanswered enhancement requests. https://github.com/oscarhenriquezg/msgeater/issues

The GitHub issue tracker is a publicly readable, permanently archived and searchable record of reports and responses, with a stable URL per issue and per comment. https://github.com/oscarhenriquezg/msgeater/issues

SECURITY.md publishes the vulnerability reporting process: do not open a public issue; report privately through GitHub Security Advisories ("Report a vulnerability") or by email to the maintainer with the subject [SECURITY] msgeater. It states what to include in a report, the expected timeline (acknowledgement within 72 hours, initial assessment and remediation plan within 2 weeks), the coordinated-disclosure expectation, the supported version, and what is in and out of scope. GitHub also surfaces it through the repository Security tab. https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

SECURITY.md documents two private reporting channels: GitHub Security Advisories ("Report a vulnerability") at https://github.com/oscarhenriquezg/msgeater/security/advisories/new, and email to the maintainer with the subject [SECURITY] msgeater. It also asks reporters not to open a public issue for security defects. https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

No vulnerability report has been received in the last 6 months. SECURITY.md commits publicly to acknowledging any report within 72 hours and providing an initial assessment, with a remediation plan where applicable, within 2 weeks. https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

npm ci followed by npm run build (electron-vite) rebuilds the application from source automatically; npm run build:linux and npm run build:mac produce the distributable installers through electron-builder. The CI workflow performs this build from a clean checkout on every push and pull request, which proves the build system works from source alone. Documented in the README "Desarrollo" section and in .github/workflows/ci.yml. https://github.com/oscarhenriquezg/msgeater/blob/main/.github/workflows/ci.yml

The build uses the standard tooling of the Node/Electron ecosystem: npm, TypeScript, Vite through electron-vite, and electron-builder for packaging. No custom or unusual build tool is involved. https://github.com/oscarhenriquezg/msgeater/blob/main/package.json

The entire toolchain is FLOSS: Node.js, npm, TypeScript, Vite/electron-vite, electron-builder, ESLint, Vitest and Playwright. The Linux build runs on standard ubuntu-latest runners with no proprietary component. The macOS build runs on macOS because Apple's platform requires it, not because a proprietary build tool is needed.

The repository contains an automated test suite under tests/, released as FLOSS under the same GPL-3.0 license as the project: twelve Vitest unit and property-based test files (MSG and EML adapters, export sanitisation, homograph and deceptive-link detection, attachment name handling, Received-header analysis, executable-attachment detection, Markdown and ZIP bundle generation, and fast-check property tests over generated adversarial input) plus a Playwright end-to-end suite that drives the built Electron application. How to run it is documented in the README "Desarrollo" section and executed in .github/workflows/ci.yml. https://github.com/oscarhenriquezg/msgeater/tree/main/tests

The suites are invoked in the standard way for the Node/TypeScript ecosystem: npm test runs Vitest, and npx playwright test runs the end-to-end suite against the built application.

Coverage is measured with the Vitest V8 coverage provider (npm run test:coverage) and reported in CI. The unit and property-based suites cover the parsing, sanitisation and export code paths and the security-relevant logic (deceptive links, attachment names, executable attachments), and the Playwright suite covers the main user flows of the built application, including the requirement that no outbound network traffic occurs (NFR-03).

GitHub Actions runs lint, typecheck, npm audit, the unit suite, a full build and the Playwright end-to-end suite on every push to main and on every pull request, on both Linux and macOS. main is a protected branch and these checks are required before a merge is allowed. https://github.com/oscarhenriquezg/msgeater/actions/workflows/ci.yml

CONTRIBUTING.md states the policy explicitly: any change that adds or modifies functionality must add or update the corresponding automated tests, and a pull request that introduces new behaviour without tests is not merged. https://github.com/oscarhenriquezg/msgeater/blob/main/CONTRIBUTING.md

The most recent significant changes followed that policy. Release v0.4.4 added property-based tests with fast-check (tests/unit/property.test.ts) together with the release-provenance work; earlier changes added tests/unit/homograph.test.ts for deceptive-link detection and tests/unit/export-sanitize.test.ts for sanitisation of exported bodies. https://github.com/oscarhenriquezg/msgeater/tree/main/tests/unit

The requirement to add tests for new functionality is documented in CONTRIBUTING.md, which is the project's instructions for change proposals. https://github.com/oscarhenriquezg/msgeater/blob/main/CONTRIBUTING.md

Two mechanisms are used. ESLint 10 with the recommended rule sets from @eslint/js and typescript-eslint (eslint.config.js), and TypeScript compiled in strict mode. Both run in CI as npm run lint and npm run typecheck on every push and pull request. https://github.com/oscarhenriquezg/msgeater/blob/main/eslint.config.js

CI fails on any ESLint error or TypeScript diagnostic, and that job is a required check on the protected main branch, so a change carrying warnings cannot be merged and warnings cannot accumulate. https://github.com/oscarhenriquezg/msgeater/blob/main/.github/workflows/ci.yml

The project is deliberately strict: TypeScript runs with strict, noUncheckedIndexedAccess, noImplicitOverride and forceConsistentCasingInFileNames; unused variables are an error rather than a warning; and CodeQL is run with the security-and-quality query suite instead of the narrower default security suite. https://github.com/oscarhenriquezg/msgeater/blob/main/tsconfig.node.json

The software exists to open potentially hostile input, and its design reflects that. docs/SECURITY-ARCHITECTURE.md documents the trust boundaries, the data-flow diagram and the residual risk at each point; SECURITY.md documents the applied design decisions: least privilege (parsing in an isolated worker thread, no Node APIs reachable from the renderer), a sandboxed iframe without allow-scripts under a restrictive CSP, input validation and sanitisation through a single shared DOMPurify policy applied in both processes, session-level blocking of all outbound network traffic, and explicit user consent before any external resource is fetched. https://github.com/oscarhenriquezg/msgeater/blob/main/docs/SECURITY-ARCHITECTURE.md

The design and the test suite address the classes of error that matter for this software: HTML/script injection from message bodies (DOMPurify plus sandboxed iframe plus CSP, with a diff of what was stripped shown to the user), path traversal through crafted attachment filenames (tests/unit/attachment-name.test.ts), homograph and deceptive links (tests/unit/homograph.test.ts), unsafe handling of executable attachments (tests/unit/executable.test.ts), and crashes or corruption on malformed input (fast-check property tests over a generated adversarial corpus). https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

The software produced by the project does not implement cryptography. It parses and displays mail files; encrypted S/MIME is explicitly reported as unsupported and signatures are indicated but not verified.

No cryptographic primitive is re-implemented. Where a digest is required (release SHA256SUMS, attachment integrity checks) the project relies on the Node.js built-in crypto module, and release provenance is signed through Sigstore via GitHub Artifact Attestations.

All cryptography the project depends on is FLOSS: Node.js and its OpenSSL-backed crypto module for digests, and Sigstore for signing release provenance.

The software does not generate, negotiate or configure cryptographic keys.

The software implements no cryptographic algorithms or modes, broken or otherwise.

The software has no default security mechanism that depends on a cryptographic algorithm or mode; its protections are sandboxing, sanitisation and network blocking.

The software establishes no network key-agreement protocol. It performs no automatic outbound network traffic at all.

The software does not authenticate users and stores no passwords.

The software does not generate random values for any security purpose.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Releases and their SHA256SUMS file are served exclusively over HTTPS from GitHub, and the checksum is never the only control: every artifact also carries a Sigstore-signed GitHub Artifact Attestation, published additionally as a msgeater-x.y.z.sigstore.json bundle among the release assets, so provenance can be verified cryptographically rather than by hash alone. docs/VERIFY-RELEASE.md documents the verification steps for Linux and macOS. The install script fetches only over HTTPS. https://github.com/oscarhenriquezg/msgeater/blob/main/docs/VERIFY-RELEASE.md

No vulnerability in the software produced by the project has been publicly reported. Dependency advisories are surfaced continuously by Dependabot, by npm audit --omit=dev --audit-level=high which fails CI on HIGH or CRITICAL issues in dependencies that ship in the binary, and by Dependency Review on pull requests, and are remediated within days: the esbuild advisory GHSA-g7r4-m6w7-qqqr was pinned through package.json overrides in v0.4.4. https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

SECURITY.md commits to treating a CVE in a production dependency with the same priority as a defect in the project's own code: apply the upstream patch and publish a corrected release if one exists, otherwise mitigate by pinning, avoiding the vulnerable code path or replacing the dependency. No critical vulnerability has been reported to date. https://github.com/oscarhenriquezg/msgeater/blob/main/SECURITY.md

The repository contains no credentials. CI authenticates only with the ephemeral github.token, and release signing uses OIDC (id-token: write) rather than a long-lived secret. Real .msg files used for manual testing, which could contain sensitive data, live in tests/fixtures/real/ which is git-ignored; the committed corpus is synthetic and generated by scripts/make-fixtures.mjs.

CodeQL (github/codeql-action, javascript-typescript) runs on every push to main and on every pull request, and additionally on a weekly schedule. It is a required check on the protected main branch, so it necessarily runs against the exact commit any release is built from. ESLint and TypeScript strict mode run in the same CI pipeline. Results are published to the repository's Code scanning tab. https://github.com/oscarhenriquezg/msgeater/actions/workflows/codeql.yml

CodeQL is configured with the security-and-quality query suite rather than the default security-only set, which includes GitHub's rules for common vulnerability classes such as injection, cross-site scripting, path traversal and unsafe deserialisation. https://github.com/oscarhenriquezg/msgeater/blob/main/.github/workflows/codeql.yml

CodeQL findings are published to the repository's Code scanning tab and the CodeQL job is a required check for merging into main, so a finding blocks the change that introduced it rather than being deferred. Findings are fixed rather than dismissed, and there are currently no open alerts. https://github.com/oscarhenriquezg/msgeater/security/code-scanning

Static analysis is not limited to release time: CodeQL runs on every push to main, on every pull request, and weekly via a scheduled workflow so that newly published queries are applied to unchanged code. ESLint and TypeScript run on every commit in the same way. https://github.com/oscarhenriquezg/msgeater/blob/main/.github/workflows/codeql.yml

Dynamic analysis runs on every commit. fast-check property-based tests generate randomised and malformed .msg and .eml input to check that the parser neither crashes nor emits unsanitised output; scripts/make-fixtures.mjs generates a synthetic adversarial corpus that the unit suite consumes; and a Playwright end-to-end suite drives the built Electron application, including verifying that the application produces no outbound network traffic (NFR-03). https://github.com/oscarhenriquezg/msgeater/blob/main/tests/unit/property.test.ts

The software produced by the project is written in TypeScript and runs on Node.js and Chromium, so the project's own code is memory-safe and a memory-safety fuzzer with sanitisers such as ASan does not apply to it.

The test suites run against unminified development builds with all assertions active (Vitest expectations and Playwright assertions), and no assertion-disabling or production-stripping flag is used in the CI test job.

Defects found by the property-based and end-to-end suites are fixed before the change can land: both suites are required checks on the protected main branch, so a failure blocks the pull request rather than being carried forward.