lagebuch

Public git repository: https://github.com/CodeForFire/lagebuch

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

Every change reaches main through a pull request, so interim work is public on branches and in the PR before it is released: https://github.com/CodeForFire/lagebuch/commits/main

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

Each release has a unique vX.Y.Z tag and a matching GitHub release: https://github.com/CodeForFire/lagebuch/releases

Semantic Versioning. The project is pre-1.0 and the changelog says plainly that breaking changes may occur in any release until then; ROADMAP.md defines what 1.0 commits to: https://github.com/CodeForFire/lagebuch/blob/main/ROADMAP.md

Tags of the form vX.Y.Z, currently through v0.5.0: https://github.com/CodeForFire/lagebuch/tags

CHANGELOG.md follows Keep a Changelog 1.1.0 and each GitHub release carries human-readable notes derived from it, not a raw commit log: https://github.com/CodeForFire/lagebuch/blob/main/CHANGELOG.md

No vulnerability has been reported or fixed in the project to date, so no release note has had to identify one. The changelog keeps a Security section for when that changes.

CONTRIBUTING.md explains how to report a bug, and the issue templates ask for version, platform, steps and expected versus actual behaviour: https://github.com/CodeForFire/lagebuch/tree/main/.github/ISSUE_TEMPLATE

GitHub Issues: https://github.com/CodeForFire/lagebuch/issues

Every issue opened so far has been responded to and the large majority closed: https://github.com/CodeForFire/lagebuch/issues?q=is%3Aissue

Feature requests are answered in the issue and, when accepted, placed in a roadmap milestone: https://github.com/CodeForFire/lagebuch/milestones

GitHub Issues and Discussions are publicly readable and permanently archived: https://github.com/CodeForFire/lagebuch/issues

SECURITY.md documents the process and is linked from the README, CONTRIBUTING.md and the issue-template chooser: https://github.com/CodeForFire/lagebuch/blob/main/SECURITY.md

GitHub private vulnerability reporting via the Security tab. SECURITY.md gives step-by-step instructions and states explicitly that vulnerabilities must not go in public issues, discussions or pull requests: https://github.com/CodeForFire/lagebuch/blob/main/SECURITY.md

No vulnerability has been reported in the last six months, which is the case the criterion says to answer N/A for.

dotnet build, wrapped by a Makefile, with the SDK version pinned in global.json: https://github.com/CodeForFire/lagebuch/blob/main/Makefile

The .NET SDK and MSBuild, both widely used and freely available.

The .NET SDK is MIT-licensed FLOSS and the build runs on Linux in CI. The optional Android head additionally needs the Android SDK; a Docker-based build is provided so that head can be built with FLOSS tooling too.

126 test files and roughly 1,100 test methods across eight xUnit projects, including a headless Avalonia render suite that exercises real views: https://github.com/CodeForFire/lagebuch/tree/main/tests

dotnet test, or make test, optionally narrowed with PROJECT= and FILTER=.

Coverage is collected on every CI run and summarised into the job summary: https://github.com/CodeForFire/lagebuch/blob/main/.github/workflows/ci.yml

GitHub Actions builds and tests on Ubuntu and Windows for every push and pull request: https://github.com/CodeForFire/lagebuch/blob/main/.github/workflows/ci.yml

CONTRIBUTING.md and AGENTS.md require tests with new functionality and the pull-request template carries the checklist: https://github.com/CodeForFire/lagebuch/blob/main/CONTRIBUTING.md

Recent feature pull requests add tests alongside the code. The README screenshots and the sample incident file are themselves produced by tests, so they cannot drift from the application: https://github.com/CodeForFire/lagebuch/pulls?q=is%3Apr+is%3Amerged

The policy is written down in CONTRIBUTING.md: https://github.com/CodeForFire/lagebuch/blob/main/CONTRIBUTING.md

Directory.Build.props sets AnalysisMode=All and AnalysisLevel=10.0, enables nullable reference types and adds StyleCop.Analyzers to every project. CI additionally runs dotnet format in whitespace and style modes with --verify-no-changes: https://github.com/CodeForFire/lagebuch/blob/main/Directory.Build.props

TreatWarningsAsErrors=true, so any warning fails the build and therefore the pull request. There is no backlog of tolerated warnings. The only suppression is CS1591 (missing XML doc comment); the two disabled analyzer rules, CA2007 and CA1716, each carry a written rationale in .editorconfig, and no CA3xxx or CA5xxx security rule is suppressed anywhere.

Warnings are errors, analysis mode is the strictest setting rather than the default subset, and the format checks are enforced in CI rather than advisory.

The maintainer has a long background in open-source infrastructure software and handles security advisories for it. In this project that shows as least privilege by default in CI, a deliberate removal of the accept-any-certificate fallback in the sync client so there is no way to skip verification, and a threat model in SECURITY.md that names its own limitations rather than hiding them: https://github.com/CodeForFire/lagebuch/blob/main/SECURITY.md

Input from outside the trust boundary is treated as hostile: attachment file names are sanitised before use, the Android FileProvider is deliberately scoped, and the PIN gate sits in middleware ahead of routing so no endpoint can be reached around it. Parameterised SQL throughout, nullable reference types enabled, and CodeQL's security-and-quality suite on every pull request: https://github.com/CodeForFire/lagebuch/blob/main/.github/workflows/codeql.yml

Only published, standardised algorithms: TLS as negotiated by the platform, ECDSA on NIST P-256, SHA-256. Nothing proprietary and nothing secret.

The project implements no cryptography of its own. Everything is delegated to .NET's System.Security.Cryptography and the platform TLS stack through Kestrel and HttpClientHandler.

The .NET runtime and its cryptographic libraries are MIT-licensed FLOSS, and the platform TLS implementation is the operating system's.

ECDSA on NIST P-256, a 128-bit security level, well above the 112-bit minimum. Certificates are signed with SHA-256.

No broken algorithm is used. There is no MD5, no SHA-1 and no DES anywhere. Verified by inventorying every System.Security.Cryptography call site in src/, of which there are three.

The same inventory shows nothing from the deprecated list. Certificate fingerprints and signatures are SHA-256.

TLS 1.2 and 1.3 as negotiated by the platform, with an ECDSA certificate, so the key exchange is ECDHE and provides forward secrecy.

The software has no user accounts and no login, so it stores no passwords for authenticating external users and this criterion has nothing to apply to. To pre-empt the obvious question: there is one shared secret, a four-digit PIN that gates joining a sync session. It is generated per session with the platform cryptographically secure generator, exists only in memory, is never written to disk and is discarded when the session ends, so it is never stored and could not be stored as a salted iterated hash. It is transmitted only inside TLS, and brute force is answered by per-source-IP exponential backoff in middleware ahead of routing rather than by a longer secret. SECURITY.md states plainly that the PIN plus network reachability is the whole access-control boundary: https://github.com/CodeForFire/lagebuch/blob/main/SECURITY.md

The share PIN, the one security-relevant random value, is generated with RandomNumberGenerator.GetInt32, the platform cryptographically secure generator. System.Random does not appear anywhere in src/ or tests/. The remaining randomness is Guid.NewGuid for entity identifiers and temporary directory names, which is not key or nonce material.

Releases are downloaded from GitHub over HTTPS: https://github.com/CodeForFire/lagebuch/releases

The criterion forbids retrieving a cryptographic hash over plain HTTP and trusting it without a signature. The project publishes no checksums at all today and every download is over HTTPS, so no such retrieval happens. Checksums and build attestations are planned, and will be served over HTTPS alongside the packages.

No vulnerability has been reported, so nothing of medium or higher severity is unpatched. Dependabot runs weekly over five update configurations covering three ecosystems, GitHub Actions, Docker and NuGet, the last across three separate package directories: https://github.com/CodeForFire/lagebuch/blob/main/.github/dependabot.yml. CodeQL additionally runs on every pull request.

There are no known unpatched vulnerabilities of any severity.

No key, certificate or credential file is committed anywhere, and there are no hardcoded secrets in src/. Certificates used in tests are generated at runtime. Real master data is treated as personal data: seed-source/ and *.masterdata.json are gitignored, and the only tracked master data is an anonymised example.

Two independent tools. CodeQL with the security-and-quality suite runs on every pull request, every push to main and weekly, with results in the repository's Code Scanning tab: https://github.com/CodeForFire/lagebuch/blob/main/.github/workflows/codeql.yml. Separately the build itself enforces the .NET analyzers at AnalysisMode=All plus StyleCop, with warnings as errors: https://github.com/CodeForFire/lagebuch/blob/main/Directory.Build.props

CodeQL's security-and-quality suite is explicitly vulnerability-focused, and no CA3xxx injection or CA5xxx security analyzer rule is suppressed in the build.

There are no outstanding CodeQL alerts; the first full run on the default branch reported none. Analyzer findings cannot accumulate at all, because TreatWarningsAsErrors turns them into build failures.

On every pull request and every push to main, plus a weekly scheduled run so that newly released queries reach existing code even when the repository is quiet.

C# is memory-safe and the project contains no unsafe blocks and no native code of its own.

Debug builds enable assertions, and the roughly 1,100-method test suite runs with them enabled.

No dynamic analysis is run, so it has produced no findings to fix.