Authelia

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.

All branches commits are published in our CI/CD pipeline (Buildkite), both internal PR's and public PR's (once confirmed by a maintainer) are published as docker images.

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

All releases use the semver versioning scheme: https://github.com/authelia/authelia/releases

All versions are tagged using semver tags.

We produce release notes automatically using conventional commits and conventional release notes. https://github.com/authelia/authelia/releases/tag/v4.37.5

In addition with more impactful releases we've started creating blog posts describing them: https://www.authelia.com/categories/release-notes/

Currently this is published under each GitHub release:

https://github.com/authelia/authelia/releases/tag/v4.29.3 https://github.com/authelia/authelia/releases/tag/v4.28.0

Users can submit both bug reports and security reports via the GitHub Issues system: https://github.com/authelia/authelia/issues/new/choose

The GitHub Issues system provides this functionality: https://github.com/authelia/authelia/issues

All reports of bugs are evaluated and either fixed, in the process of being fixed, or closed in the event the behavior is intended. Users routinely receive a response indicative of this promptly. We can not find any single issue that has never been responded to.

All feature requests are evaluated and either implemented, in the process of being implemented, or closed in the event the feature will not be added. Users routinely receive a response indicative of this promptly. We can not find any single issue that has never been responded to.

All bug reports and feature requests are archived along with all of their edits in the GitHub Issues system https://github.com/authelia/authelia/issues?q=is%3Aissue+is%3Aclosed

The security policies and reporting methods are documented both in https://github.com/authelia/authelia/blob/master/SECURITY.md and https://www.authelia.com/policies/security/

The vulnerability report process covers all of this information documented both in https://github.com/authelia/authelia/blob/master/SECURITY.md and https://www.authelia.com/policies/security/

We have responded to every vulnerability report within the life of Authelia within 2 or 3 days with the exception of one which was about 8 days.

All commits are automatically built and published to https://buildkite.com/authelia.

We use standard go build tools, vite, and docker buildx for building practically everything. The only exception is we use gox for streamlining multi-arch building releases which effectively is sugar for the go build tools. Our environment is roughly documented here https://www.authelia.com/contributing/development/environment/ and here https://www.authelia.com/contributing/development/build-and-test/

The build process is described here: https://www.authelia.com/contributing/development/build-and-test/

The test process is described here: https://www.authelia.com/contributing/development/build-and-test/

All of the tests use the go stdlib tests accompanied by testify.

The go test tool can be used with our tests https://www.authelia.com/contributing/development/build-and-test/

Our coverage reports for both frontend and backend are located here: https://app.codecov.io/gh/authelia/authelia

Our CI/CD pipeline is publicly visible at https://buildkite.com/authelia and performs both unit tests and integration tests with all of our external dependencies.

Where it's practical we aim to enforce a near 100% coverage on new code,

Our CI/CD pipeline automatically detects uncovered lines and while it's not a step which blocks merging it helps us ensure the test policy is followed where practical

Our policy for tests is documented at https://www.authelia.com/contributing/guidelines/introduction/#general-guidelines

We implement a fairly strict golangci-lint policy as part of our git hooks and the CI/CD pipeline, failures by this linter BLOCK merging

We have most linter and code quality warnings as a step which blocks the merge process. These checks have to be manually bypassed using obvious linter annotations.

We by default have warnings as a failure condition, and adjust the impractical ones

We use AES256-GCM for encryption. It's not restricted by the US export requirements.

We use AES256-GCM for encryption and we use stdlib implementations, not our own.

AES256-GCM is well documented and has implementations in most languages.

The administrator determines the effective key length however we forcibly use the fixed key length of AES256.

We do not support any of these broken algorithms directly and all algorithms supported by go are typically supported for any non-datastore implementations.

No security mechanisms rely on these algorithms.

We use the default algorithm preferences from go's standard tls implementation which covers this by default.

Authentication passwords use iterated and salted mechanisms. OpenID Connect 1.0 client secrets support the same, but is not currently forced (it will be in the near future).

We only use the crypto/rand package in production for these purposes.

We only support https. https://www.authelia.com/integration/prologue/get-started/#prerequisites

We only support https. https://www.authelia.com/integration/prologue/get-started/#prerequisites

This has never been the case, longest release after a vulnerability discovery was about 20 days.

Every vulnerability has been fixed promptly and as soon as possible. Longest to our recollection was about 7 days (we've only had 2 legitimate vulnerabilities).

We have protections against this as does the provider of our CI/CD pipeline.

We use golangci-lint.

We use CodeQL.

We fix all true positive vulnerabilities discovered via static analysis regardless of severity, and do so as soon as possible.

Every commit and PR is analyzed.

The project is written in Go which is considered memory safe.

We run several tests using subtests to enable easy comprehensive static and some basic dynamic testing.

We don't currently use a dynamic testing tool, we're looking into it.