Skip to content

Commit 2d5c9ac

Browse files
lakhansamanilakhansamani
authored
chore: CNCF Sandbox prep — community files + Apache-2.0 relicense (#612)
* chore: add community files for CNCF Sandbox prep Adds the community health and supply-chain files expected of CNCF Sandbox candidates: - SECURITY.md Vulnerability disclosure policy via GitHub Security Advisories, with response SLAs and safe-harbour. - GOVERNANCE.md Project governance: roles, decision-making (lazy consensus), maintainer add/remove process, conflict resolution, IP policy. - MAINTAINERS.md Current maintainer list with areas of responsibility. - ADOPTERS.md Public adopters template; opens the channel for the community to self-list. - .github/workflows/scorecard.yml OpenSSF Scorecard workflow with pinned action SHAs; runs weekly + on push to main + on branch-protection changes; uploads SARIF to the Security tab. Out of scope of this PR: - Relicensing (MIT -> Apache-2.0) is a separate effort that requires contributor consent; tracked separately. - README badges for Scorecard will be added after the first successful run publishes results. - ROADMAP.md (promotion of ROADMAP_V2.md) is a separate decision. Refs: CNCF Charter Section 11 (IP Policy); CNCF Sandbox process at https://github.com/cncf/sandbox. * chore: address review feedback on CNCF community files - SECURITY.md: use lakhan.m.samani@gmail.com as the fallback channel until the security@authorizer.dev mailbox is set up. TODO comments mark the lines to update. - Move CODE_OF_CONDUCT.md and CONTRIBUTING.md from .github/ to repo root for discoverability (GitHub recognises either location; root is more visible to CNCF reviewers and new contributors). - Update README.md and CONTRIBUTING.md cross-references to the new paths. * chore: relicense from MIT to Apache License 2.0 Aligns the project's outbound license with the CNCF IP Policy (Charter §11(b)(iii)), which requires CNCF-accepted projects to distribute under Apache 2.0. Apache 2.0 adds an explicit patent grant and clearer contribution terms relative to MIT, while remaining a permissive license. Existing copies distributed under the MIT License retain their original grant; this change applies to the project's outbound license going forward. Changes: - LICENSE: replaced MIT text with the canonical Apache 2.0 text. - NOTICE: new file crediting "The Authorizer Authors" and noting that prior MIT-licensed contributions remain available under MIT as well. - GOVERNANCE.md: updated the Intellectual Property section to reflect the new license and the dual status of historical contributions. - CHANGELOG.md: added an entry under [Unreleased] explaining the change. - web/app/package.json, web/dashboard/package.json: corrected the "license" field from the stale "ISC" value to "Apache-2.0", matching the project's actual outbound license. Refs: CNCF Charter §11 (IP Policy); https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy
1 parent a422973 commit 2d5c9ac

13 files changed

Lines changed: 586 additions & 26 deletions

File tree

‎.github/workflows/scorecard.yml‎

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
# OpenSSF Scorecard workflow
2+
#
3+
# Drop this at .github/workflows/scorecard.yml in the main repo
4+
# (and any sibling repos you want scored separately).
5+
#
6+
# After first successful run:
7+
# 1. Add the badge to README.md:
8+
# [![OpenSSF Scorecard](https://api.securityscorecards.dev/projects/github.com/authorizerdev/authorizer/badge)](https://securityscorecards.dev/viewer/?uri=github.com/authorizerdev/authorizer)
9+
# 2. Results appear under the repo's Security tab → Code scanning.
10+
# 3. Publishing to the public Scorecard API requires `publish_results: true`
11+
# and a one-time opt-in by registering the repo at https://securityscorecards.dev/
12+
13+
name: Scorecard supply-chain security
14+
15+
on:
16+
branch_protection_rule:
17+
schedule:
18+
# Weekly on Monday at 06:00 UTC.
19+
- cron: '0 6 * * 1'
20+
push:
21+
branches:
22+
- main
23+
24+
# Top-level read-all permissions; jobs override what they need.
25+
permissions: read-all
26+
27+
jobs:
28+
analysis:
29+
name: Scorecard analysis
30+
runs-on: ubuntu-latest
31+
permissions:
32+
# Required to upload SARIF results to the Security tab.
33+
security-events: write
34+
# Required for OIDC token used by Scorecard for public publishing.
35+
id-token: write
36+
# Read-only, needed by Scorecard checks.
37+
contents: read
38+
actions: read
39+
40+
steps:
41+
- name: Checkout
42+
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
43+
with:
44+
persist-credentials: false
45+
46+
- name: Run Scorecard analysis
47+
uses: ossf/scorecard-action@0864cf19026789058feabb7e87baa5f140aac736 # v2.3.1
48+
with:
49+
results_file: results.sarif
50+
results_format: sarif
51+
# Set to true to publish results to https://securityscorecards.dev
52+
# (the badge in README points at this endpoint).
53+
publish_results: true
54+
55+
- name: Upload artifact
56+
uses: actions/upload-artifact@26f96dfa697d77e81fd5907df203aa23a56210a8 # v4.3.0
57+
with:
58+
name: SARIF file
59+
path: results.sarif
60+
retention-days: 5
61+
62+
- name: Upload to code-scanning
63+
uses: github/codeql-action/upload-sarif@012739e5082ff0c22ca6d6ab32e07c36df03c4a4 # v3.22.12
64+
with:
65+
sarif_file: results.sarif

‎ADOPTERS.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Authorizer Adopters
2+
3+
This file lists organizations and projects that use Authorizer in production. If you use Authorizer and would like to be listed, please open a pull request adding yourself.
4+
5+
We are gathering this list to demonstrate community adoption for the [CNCF Sandbox application](https://github.com/cncf/sandbox). Public listing is optional. If you cannot list publicly but are willing to share your use case privately for the application, please email **adopters@authorizer.dev**.
6+
7+
## How to add yourself
8+
9+
Open a PR that appends a row to the table below. Required: organization name, use case (1–2 sentences), contact (GitHub handle or email — public). Optional: logo URL, link to a blog post or case study, deployment scale.
10+
11+
```markdown
12+
| Organization | Use case | Contact | Since | Notes |
13+
|--------------|----------|---------|-------|-------|
14+
| Your Org | Brief description of how you use Authorizer (auth provider for SaaS, internal tools, embedded in product, etc.). | @githubhandle | 2025-01 | (optional link to a blog post, deployment scale, anything else) |
15+
```
16+
17+
## Production adopters
18+
19+
| Organization | Use case | Contact | Since | Notes |
20+
|--------------|----------|---------|-------|-------|
21+
| _Your organization could be here._ | | | | |
22+
23+
## Pilot / non-production adopters
24+
25+
Organizations evaluating Authorizer or running it for internal tools but not yet in production.
26+
27+
| Organization | Use case | Contact | Since |
28+
|--------------|----------|---------|-------|
29+
| _Your organization could be here._ | | | |
30+
31+
## Why we ask
32+
33+
Listed adopters help the project:
34+
35+
- Demonstrate adoption to CNCF reviewers and the broader cloud-native community.
36+
- Prioritize roadmap items based on real-world use cases.
37+
- Connect adopters with each other for shared learning.
38+
39+
If you would prefer a private listing for the CNCF application only (not on this public file), please contact us at **adopters@authorizer.dev**.
40+
41+
---
42+
43+
*Last updated: 2026-05-20*

‎CHANGELOG.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
99

1010
### Changed
1111

12+
- **License: relicensed from MIT to Apache License 2.0.** Per the CNCF IP Policy ([Charter §11(b)(iii)](https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy)), Authorizer's outbound code is now distributed under the Apache License 2.0. Existing copies distributed under the MIT License remain valid under their original grant; this change applies to the project's outbound license going forward. See [NOTICE](NOTICE) for attribution.
1213
- **Fine-grained authorization is always enforcing.** The previously-proposed `--authorization-enforcement` flag and its dual `permissive`/`enforcing` modes were removed before shipping. `required_permissions` checks against an unmatched or denied `(resource, scope)` pair return `unauthorized`. There is no permissive "log but allow" mode.
1314
- **Authz Prometheus shape**: `authorizer_authz_checks_total` has only a `result` label (`allowed|denied|unmatched|error`); `authorizer_authz_unmatched_total` has no labels.
1415

.github/CODE_OF_CONDUCT.md renamed to CODE_OF_CONDUCT.md

File renamed without changes.

.github/CONTRIBUTING.md renamed to CONTRIBUTING.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ We're so excited you're interested in helping with Authorizer! We are happy to h
55
## New to Open Source?
66

77
1. Take a look at [How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github)
8-
2. Go through the [Authorizer Code of Conduct](https://github.com/authorizerdev/authorizer/blob/main/.github/CODE_OF_CONDUCT.md)
8+
2. Go through the [Authorizer Code of Conduct](./CODE_OF_CONDUCT.md)
99

1010
## Where to ask questions?
1111

‎GOVERNANCE.md‎

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
# Authorizer Governance
2+
3+
This document describes how the Authorizer project is governed. It is intended to be a living document that evolves as the community grows.
4+
5+
## Project Mission
6+
7+
Provide an open-source, self-hosted authentication and authorization platform that:
8+
9+
- Respects user data sovereignty.
10+
- Works with any reasonable database backend.
11+
- Implements modern, standards-compliant OAuth2/OIDC protocols.
12+
- Is operable as a single Go binary.
13+
- Stays approachable for individual developers and operable for enterprise teams.
14+
15+
## Roles
16+
17+
### Users
18+
19+
Anyone who uses Authorizer. Users contribute by filing bug reports, sharing experiences, requesting features, and helping each other in community channels.
20+
21+
### Contributors
22+
23+
Anyone who has contributed code, documentation, design, examples, translations, or any other improvement merged into an Authorizer repository. Contributors are listed automatically via Git history. There is no formal application process.
24+
25+
### Maintainers
26+
27+
Maintainers have write access to one or more Authorizer repositories and are responsible for the long-term health of the project. They:
28+
29+
- Review and merge pull requests.
30+
- Triage issues.
31+
- Cut releases.
32+
- Set technical direction.
33+
- Enforce the Code of Conduct.
34+
35+
The current maintainer list is in [MAINTAINERS.md](MAINTAINERS.md).
36+
37+
### Project Lead
38+
39+
While the project has a single lead maintainer, that person acts as the final arbiter on technical disputes that cannot be resolved by consensus. This role exists explicitly until the maintainer group expands; at that point this section will be replaced by collective decision-making.
40+
41+
## Becoming a Maintainer
42+
43+
A contributor may be invited to become a maintainer when they have demonstrated:
44+
45+
- **Sustained contribution** over a period of at least **3 months**.
46+
- **Technical judgement** through high-quality reviews and code.
47+
- **Community alignment** through respectful, constructive engagement.
48+
- **Reliability** in following through on commitments.
49+
50+
The process:
51+
52+
1. An existing maintainer nominates the contributor by opening a PR adding them to `MAINTAINERS.md`.
53+
2. The nomination is open for **2 weeks** of public comment.
54+
3. The nomination is accepted if there is **consensus among existing maintainers** and no unaddressed objections from the community.
55+
4. The new maintainer is granted write access and announced in the next release notes.
56+
57+
There is no fixed cap on maintainer count.
58+
59+
## Stepping Down
60+
61+
A maintainer may step down at any time by opening a PR moving themselves to the **Emeritus Maintainers** section of `MAINTAINERS.md`. Emeritus maintainers retain credit for their contributions but no longer have merge authority.
62+
63+
A maintainer may be moved to emeritus status by consensus of the other maintainers if they have been inactive for **6 months** and have not responded to outreach.
64+
65+
## Decision Making
66+
67+
Authorizer aims to make decisions by **lazy consensus**:
68+
69+
- A maintainer proposes a change.
70+
- If no maintainer raises an objection within a reasonable time (**7 days** for routine work, **14 days** for architectural changes), the change moves forward.
71+
- If objections are raised, the proposers and objectors work toward resolution in the issue or PR thread.
72+
- If consensus cannot be reached, the project lead has the final say. This is a deliberate choice for the current single-maintainer phase and will be replaced with maintainer voting once there are three or more maintainers.
73+
74+
### Scope of Decision
75+
76+
| Decision Type | Who decides |
77+
|---|---|
78+
| Bug fixes, minor features, docs | Any maintainer |
79+
| Breaking changes, new public APIs | Maintainer consensus |
80+
| Major architectural shifts, license, governance changes | Maintainer consensus + 2-week community notice |
81+
| Security fixes under embargo | Security maintainers (subset of all maintainers) |
82+
83+
## Conflict Resolution
84+
85+
1. Discuss in the relevant issue or PR.
86+
2. Escalate to a private maintainer channel if discussion becomes unproductive.
87+
3. The project lead has final authority. This authority transitions to maintainer voting once the maintainer group expands.
88+
89+
All participants are expected to follow the [Code of Conduct](CODE_OF_CONDUCT.md). Violations are handled per the CoC enforcement process.
90+
91+
## Release Management
92+
93+
- **Versioning**: [Semantic Versioning 2.0.0](https://semver.org/).
94+
- **Cadence**: Patch releases as needed, minor releases approximately monthly, major releases approximately yearly.
95+
- **Release notes**: Generated from PR titles + manual curation in `CHANGELOG.md`.
96+
- **Release authority**: Any maintainer can cut a release after CI passes and maintainer consensus on inclusion.
97+
98+
## Code of Conduct
99+
100+
Authorizer adopts the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). All participants in any Authorizer space — repositories, Discord, Slack, conferences, social media — are expected to follow it.
101+
102+
Report violations to **conduct@authorizer.dev**. Reports are reviewed by maintainers who are not involved in the incident. If a maintainer is the subject of a report, that maintainer recuses themselves.
103+
104+
## Intellectual Property
105+
106+
- The project is distributed under the [Apache License 2.0](LICENSE). All new contributions are accepted under Apache 2.0 unless explicitly stated otherwise. Prior contributions originally submitted under the MIT License remain available under their original MIT grant in addition to the current Apache 2.0 distribution; see [NOTICE](NOTICE) for attribution.
107+
- The **Authorizer** name and logo are owned by the project. The project is committed to neutral, community-oriented stewardship of these assets.
108+
- Future ownership of trademark and assets may be transferred to a neutral foundation. Any such transfer will be announced publicly and discussed openly before completion.
109+
110+
## Modifying This Document
111+
112+
Changes to this governance document follow the **architectural change** decision path: maintainer consensus plus a **2-week community notice period** on a public PR.
113+
114+
---
115+
116+
*Last updated: 2026-05-20*

0 commit comments

Comments
 (0)