You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"_justification": "This is a false positive, probably because it says the word password and has a hash. It is just a measurement of the pam.d system-password configuration file."
Please use the [auto-generated table of contents](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes#auto-generated-table-of-contents-for-readme-files) GitHub creates. To reveal it, select the three bar menu icon at the top of the page.
6
+
7
+
## Contributing License Agreement
2
8
3
9
This project welcomes contributions and suggestions. Most contributions require you to
4
10
agree to a Contributor License Agreement (CLA) declaring that you have the right to,
5
11
and actually do, grant us the rights to use your contribution. For details, visit
6
-
https://cla.microsoft.com.
12
+
<https://cla.microsoft.com>.
7
13
8
14
When you submit a pull request, a CLA-bot will automatically determine whether you need
9
15
to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the
@@ -13,17 +19,17 @@ This project has adopted the [Microsoft Open Source Code of Conduct](https://ope
13
19
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/).
23
29
24
30
If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's [Microsoft's definition of a security vulnerability](https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc751383(v=technet.10)) of a security vulnerability, please report it to us as described below.
25
31
26
-
## Reporting Security Issues
32
+
###Reporting Security Issues
27
33
28
34
**Please do not report security vulnerabilities through public GitHub issues.**
29
35
@@ -35,24 +41,169 @@ You should receive a response within 24 hours. If for some reason you do not, pl
35
41
36
42
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:
37
43
38
-
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
39
-
* Full paths of source file(s) related to the manifestation of the issue
40
-
* The location of the affected source code (tag/branch/commit or direct URL)
41
-
* Any special configuration required to reproduce the issue
42
-
* Step-by-step instructions to reproduce the issue
43
-
* Proof-of-concept or exploit code (if possible)
44
-
* Impact of the issue, including how an attacker might exploit the issue
44
+
* Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
45
+
* Full paths of source file(s) related to the manifestation of the issue
46
+
* The location of the affected source code (tag/branch/commit or direct URL)
47
+
* Any special configuration required to reproduce the issue
48
+
* Step-by-step instructions to reproduce the issue
49
+
* Proof-of-concept or exploit code (if possible)
50
+
* Impact of the issue, including how an attacker might exploit the issue
45
51
46
52
This information will help us triage your report more quickly.
47
53
48
54
If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://microsoft.com/msrc/bounty) page for more details about our active programs.
49
55
50
-
## Preferred Languages
56
+
###Preferred Languages
51
57
52
58
We prefer all communications to be in English.
53
59
54
-
## Policy
60
+
###Policy
55
61
56
62
Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://www.microsoft.com/en-us/msrc/cvd).
57
63
58
-
<!-- END MICROSOFT SECURITY.MD BLOCK -->
64
+
<!-- END MICROSOFT SECURITY.MD BLOCK -->
65
+
66
+
## Develop for CBL-Mariner
67
+
68
+
When starting to develop for CBL-Mariner, use the [CBL-MarinerTutorials](https://github.com/microsoft/CBL-MarinerTutorials) repo. This repository guides developers on using CBL-Mariner'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, [CBL-Mariner](https://github.com/microsoft/CBL-Mariner). Please see our [quickstart](toolkit/docs/quick_start/quickstart.md) for a tutorial and [building instructions](toolkit/docs/building/building.md) for an in-depth overview of building within CBL-Mariner. Please adhere to the [Pull Request guidelines](pull-request-guidelines) when contributing.
69
+
70
+
### Packages
71
+
72
+
CBL-Mariner packages live in either [SPECS](SPECS) or [SPECS-EXTENDED](SPECS-EXTENDED). CBL-Mariner packages that are in the `SPECS` directory have full support and coverage with timely CVE maintenance. Packages in `SPECS-EXTENDED` are for experimentation or proof-of-concept purposes only. `SPECS-EXTENDED` can be used as a staging area for iterating on packages with the possiblity of the package being graduated to `SPECS`.
73
+
74
+
| Package Support Level | Published | Supported | Comments
|SPECS-EXTENDED |**Yes** |No | - Package needs a viable upstream source which actively addresses CVEs </br> - Package must not include project specific code
77
+
|SPECS |**Yes** |**Yes** | - Package needs a viable upstream source which actively addresses CVEs </br> - Package must not include project specific code </br> - Package needs to offer value for multiple use cases
78
+
79
+
When looking to graduate a package from `SPECS-EXTENDED` to `SPECS`, file a [GitHub issue](https://github.com/microsoft/CBL-Mariner/issues) highlighting the package's value and ensure that the following steps are completed for associated PRs.
80
+
81
+
1. Increment the spec's `Release` value
82
+
1. Add changelog entries "Package promoted from SPECS-EXTENDED to SPECS" and "License verified"
83
+
1. Add a `%check` section to the spec if not already present and confirm it passes
84
+
1. Ensure spec is free of references, macros, comments, etc. only applicable to other distros
85
+
1. Complete the [PR checklist](#pr-checklist)
86
+
1. Pass the GitHub checks
87
+
88
+
### Toolkit
89
+
90
+
We welcome tooling improvements. When contributing to the toolkit, please adhere to `golang` formatting as described by the [fmt](https://pkg.go.dev/fmt) package. To format using this package, you can run `make go-tidy-all` in your CBL-Mariner toolkit. For guidance on building with the toolkit, see our [building instructions](toolkit/docs/building/building.md).
91
+
92
+
### Documentation
93
+
94
+
We welcome documentation improvements. See [toolkit/docs](toolkit/docs) for the latest documentation.
95
+
96
+
## Pull Request Guidelines
97
+
98
+
Please direct pull requests to the desired development branch. Development changes to `2.0` should target `main`. Development changes to `1.0` should target `1.0-dev`.
99
+
100
+
### Branch structure
101
+
102
+
An overview of how the branches are structured can be seen below
|1.0 |No |Yes - eventually | Staging branch for publishing
115
+
|1.0-stable |No |Yes | Last published release
116
+
|1.0-preview |No |No | Publishing in progress
117
+
118
+
### PR Titles
119
+
120
+
PR titles should start with an action
121
+
122
+
```bash
123
+
- Add <package>
124
+
- Bump Release version for October Update
125
+
- Change whatever you changed.
126
+
- Fix <thing you fixed><reason you fixed it>
127
+
- Patch <package> to fix CVE-XXXX-YYYY, CVE-XXXX-YYYY…
128
+
- Upgrade <package> to version vvvv to fix CVE-XXXX-YYYY…
129
+
- Remove <package><reason you removed it>
130
+
```
131
+
132
+
Please avoid titles such as
133
+
134
+
```bash
135
+
- package: <whatever you did to the package>
136
+
- CVE-XXXX-YYYY (leaving off what package was patched or upgraded)
137
+
- [1.0] (prefixing with branch or other information)
138
+
```
139
+
140
+
### PR Checklist
141
+
142
+
When creating your PR, please ensure the following:
143
+
144
+
* The toolchain has been rebuilt successfully (or no changes were made to it). This only applies if you changed any packages in the [toolchain package manifests](toolkit/resources/manifests/package). Specifically, `toolchain_x86_64.txt` and `toolchain_aarch64.txt`. For guidance on building the toolchain, see our [building instructions](toolkit/docs/building/building.md).
145
+
146
+
* The [toolchain / worker package manifests](toolkit/resources/manifests/package) are up-to-date (versions match latest package versions in SPEC files). The manifests are the following files:
147
+
* toolchain_x86_64.txt
148
+
* toolchain_aarch64.txt
149
+
* pkggen_core_x86_64.txt
150
+
* pkggen_core_aarch64.txt
151
+
152
+
* Any updated packages successfully build (or no packages were changed). For guidance on building packages, see our [building instructions](toolkit/docs/building/building.md). Please ensure the package is located in the [appropriate folder](#packages).
153
+
154
+
* Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their `Release` tag incremented. Dependent packages are packages which contain a `BuildRequires` on the package you are updating and create static links from your package. This can be difficult to discern based on spec files alone and may require investigating `make` commands in dependent packages or consulting a CBL-Mariner dev.
155
+
156
+
* Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files. When running the check section, results will not fail a build. Check the logs for the results of this section.
157
+
158
+
* All package sources are available. The sources are either in the source server or local `SPECS` folder (`SPECS/<package>/SOURCES` or `SPECS/<package>`). While it is possible to build packages with all sources inside the repo, our policy is generally to have the source compressed and placed on the source server. Uploading to the source server can only be accomplished by a CBL-Mariner developer. Please request help in your PR for uploading your sources to the source server. To check the source server see [https://cblmarinerstorage.blob.core.windows.net/sources/core/< source tar >].
159
+
160
+
* cgmanifest files are up-to-date and alphabetically sorted. The cgmanifest files are used to record all package sources. They include the following files:
161
+
162
+
* ./cgmanifest.json
163
+
* ./toolkit/tools/cgmanifest.json
164
+
* ./toolkit/scripts/toolchain/cgmanifest.json,
165
+
* .github/workflows/cgmanifest.json
166
+
167
+
To validate, run the following in a CBL-Mariner container or Ubuntu >= 22.04
* LICENSE-MAP files are up-to-date. These files indicate which licenses are being used by CBL-Mariner's packages and where the package may be derived from. The license files include the following files:
174
+
* ./SPECS/LICENSES-AND-NOTICES/data/licenses.json
175
+
* ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md
176
+
177
+
This can be checked by running
178
+
179
+
```bash
180
+
python3 ./toolkit/scripts/license_map.py \
181
+
./SPECS/LICENSES-AND-NOTICES/data/licenses.json \
182
+
./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md \
183
+
./SPECS \
184
+
./SPECS-EXTENDED \
185
+
./SPECS-SIGNED
186
+
```
187
+
188
+
* All source files have up-to-date hashes in the *.signatures.json files. This hash is generated by `sha256sum`. You can also use the make tools to automatically update these hashes.
189
+
190
+
```bash
191
+
cd toolkit
192
+
sudo make input-srpms REBUILD_TOOLS=y SRPM_FILE_SIGNATURE_HANDLING=update
193
+
```
194
+
195
+
* If you modified the go tools, ensure that the formatting meets golang's standards and that the tests still pass.
196
+
197
+
```bash
198
+
cd toolkit
199
+
# fix formatting
200
+
sudo make go-tidy-all
201
+
# check tests
202
+
sudo make go-test-coverage
203
+
```
204
+
205
+
* Documentation has been updated to match any changes to the build system. See [toolkit/docs](toolkit/docs).
206
+
207
+
## Bugs
208
+
209
+
If the bug is security related, please use the [security guidelines](#security-vulnerabilities) above. Otherwise, please use the [issues page](https://github.com/microsoft/CBL-Mariner/issues) on CBL-Mariner to file bugs.
0 commit comments