Contributing License Agreement
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA. For more details, visit https://cla.microsoft.com.Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.Getting Started
When starting to develop for Azure Linux, use the Azure Linux Tutorials repo. This repository guides developers on using Azure Linux’s tools to customize or add new packages or images. Once you have confirmed your change builds and functions as expected, consider whether it should be added to the core repo, Azure Linux.Quick Start Resources
- Quickstart Guide - Tutorial for getting started
- Building Instructions - In-depth overview of building within Azure Linux
Contributing to Packages
Azure Linux packages live in eitherSPECS or SPECS-EXTENDED:
| Package Support Level | Published | Supported | Requirements |
|---|---|---|---|
| SPECS-EXTENDED | Yes | No | - Package needs a viable upstream source which actively addresses CVEs - Package must not include project specific code |
| SPECS | Yes | Yes | - Package needs a viable upstream source which actively addresses CVEs - Package must not include project specific code - Package needs to offer value for multiple use cases |
Package Support Levels
SPECS Directory: Packages in theSPECS directory have full support and coverage with timely CVE maintenance.
SPECS-EXTENDED Directory: Packages in SPECS-EXTENDED are for experimentation or proof-of-concept purposes only. This directory can be used as a staging area for iterating on packages with the possibility of the package being graduated to SPECS.
Graduating a Package from SPECS-EXTENDED to SPECS
When looking to graduate a package fromSPECS-EXTENDED to SPECS, file a GitHub issue highlighting the package’s value and ensure that the following steps are completed for associated PRs:
- Increment the spec’s
Releasevalue - Add changelog entries “Package promoted from SPECS-EXTENDED to SPECS” and “License verified”
- Add a
%checksection to the spec if not already present and confirm it passes - Ensure spec is free of references, macros, comments, etc. only applicable to other distros
- Complete the PR checklist
- Pass the GitHub checks
Contributing to Toolkit
We welcome tooling improvements. When contributing to the toolkit, please adhere to Go formatting as described by the fmt package. To format using this package, run:Contributing to Documentation
We welcome documentation improvements. See toolkit/docs for the latest documentation.Reporting Bugs
If the bug is security related, please see the security guidelines below. Otherwise, please use the issues page on Azure Linux to file bugs.Security Vulnerabilities
Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations.Reporting Security Issues
Please do not report security vulnerabilities through public GitHub issues. Instead, please report them to the Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/create-report. If you prefer to submit without logging in, send email to [email protected]. If possible, encrypt your message with our PGP key; please download it from the Microsoft Security Response Center PGP Key page. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.What to Include in Security Reports
Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:- Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
- Full paths of source file(s) related to the manifestation of the issue
- The location of the affected source code (tag/branch/commit or direct URL)
- Any special configuration required to reproduce the issue
- Step-by-step instructions to reproduce the issue
- Proof-of-concept or exploit code (if possible)
- Impact of the issue, including how an attacker might exploit the issue