遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/6086)
<a href="https://www.bestpractices.dev/projects/6086"><img src="https://www.bestpractices.dev/projects/6086/badge"></a>
An implementation of the Extensible Messaging and Presence Protocol (XMPP) in Go.
A CONTRIBUTORS file in each repo explains contributing in detail (https://mellium.im/docs/CONTRIBUTING).
DCO signatures are checked by CI https://github.com/mellium/xmpp/blob/main/.builds/validate.yml and the DCO is included in each repo https://github.com/mellium/xmpp/blob/main/DCO
As governance evolves and is decided upon, this page will receive updates: https://mellium.im/governance/
Each repo contains CODE_OF_CONDUCT.md which is also reachable from the main website at https://mellium.im/docs/CODE_OF_CONDUCT
We are actively seeking contributors who are willing to take over as maintainer in the eventuality that the active maintainer becomes incapacitated.
The roadmap is largely defined by user contributions and is available on https://opencollective.com/mellium
https://mellium.im/docs/ARCHITECTURE
https://mellium.im/docs/SECURITY
https://mellium.im/docs/overview
Documentation is periodically reviewed for correctness. Examples in the API documentation are automatically tested.
https://github.com/mellium/xmpp/
We have deliberately kept the project homepage simple and test it with a screen reader (though the tester is sighted and can only do their best to make things easy without having the life experience required to know how best to make the site accessible).
There is an open issue to add i18n features when creating features that require them, but we do not currently generate much text outside of the documentation.
Project sites do not store passwords and are statically generated.
Only the latest version of the software is maintained until we hit 1.0 at which point we will re-evaluate maintenance of older versions. Upgrade paths are provided in the release notes when breaking changes are made, and we commit to no breaking changes (except as required for security issues) after 1.0.
https://mellium.im/issue/
When vulnerabilities are reported a CVE is generated and the reporter is given credit there and in any release notes about the issue. For example, https://nvd.nist.gov/vuln/detail/CVE-2022-24968
The contributing guide explains that go fmt must be run: https://mellium.im/docs/CONTRIBUTING
gofmt is run during CI
The make file passes through linker flags correctly and allows overriding them.
The make file does not remove debugging information unless requested to do so.
Go does not allow import loops.
Go creates repeatable builds by default.
Common Go tools such as "go get" and "go install" are supported.
Go tooling is used and its standards are followed.
Go tools as well as Git are supported. Developers can test with Go Workspaces or using a module replace directive.
External dependencies can be found in each repos go.mod file: https://github.com/mellium/xmpp/blob/main/go.mod
Dependencies are periodically checked and updated. GitHub provides a security tool to automatically notify us of some issues.
Common Go tools are used to update dependencies. GitHub also automatically generates PRs for some vulnerabilities.
We do not use deprecated APIs in Go packages.
https://github.com/mellium/xmpp/tree/main/.builds
When a bug is encountered regression tests are written.
The test suite generates code coverage reports: https://github.com/mellium/xmpp/blob/main/.builds/test.yml
Tests are required for all new functionality.
The contributing document specifies that tests must be added https://mellium.im/docs/CONTRIBUTING
Go does not have warnings by default. Static analysis tools and linters are treated as errors unless a specific false positive is explicitly disabled.
The main developer eschews complexity and encourages fail-safe defaults among other security best practices.
We only use SHA-1 or similar as part of HMAC (where it is likely still safe) and not as a uniqueness mechanism.
We provide hash agility where possible. Exceptions include SCRAM authentication where we do provide new mechanisms, but cannot provide easy agility as the specifications provide no upgrade path between different SCRAM mechanisms and the server never receives the plain password (and therefore cannot re-hash it).
To the limited extent that we "process" passwords, each file that does so is marked "security critical" and contains a warning about making changes in the file and how code review should be performed. These files are kept separate from other functionality.
We require TLS 1.2 or higher in all default configurations. This version can be easily changed if issues are found.
The software uses a default TLS configuration that supports a secure version of TLS with verification enabled.
To the limited extent that this project uses HTTP, TLS is performed first by default.
The security docs mention how to verify releases: https://mellium.im/docs/SECURITY
This is true as of v0.21.4 when this policy was enacted.
To the extent that the project handles input itself (as opposed to allowing the user to handle it), it is verified to ensure that it is correct and follows the XMPP standard and security mechanisms.
To the extent possible optional security features in XMPP and HTTP are implemented.
This needs to be done in the API documentation for applicable packages. Currently some packages mention security issues and some packages do not. For example, https://pkg.go.dev/mellium.im/xmpp needs better documentation.
Gosec is run on all builds: https://github.com/mellium/xmpp/blob/main/.builds/validate.yml
The project is not written in a memory-unsafe language.
后退