leetNightshade
/
help-center-docs
Archived
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

packaging: Add info about CVE .nopatch 

Signed-off-by: Peter O'Connor <peter@solus-project.com>
This commit is contained in:
Peter O'Connor 2017-05-31 17:43:38 +10:00
parent cbecc34d3e
commit 28eb90337a
No known key found for this signature in database
GPG Key ID: 7337C8741744DE8A
1 changed files with 2 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
packaging/packaging-practices/en.md
View File

@ -93,6 +93,8 @@ Both patches and extra files (such as systemd units) are stored in this director
Where `xxxx-xxxx` is replaced with the full CVE ID. Complying with this simple rule ensures that we can know at any time the security status of packages when using tools such as `cve-check-tool` Where `xxxx-xxxx` is replaced with the full CVE ID. Complying with this simple rule ensures that we can know at any time the security status of packages when using tools such as `cve-check-tool`
Solus tooling allows the use of `./files/security/cve-xxxx-xxxx.nopatch` (which isn't applied in the build) to indicate that a CVE has been validated as not applicable to the Solus package. This can be because another patch resolves this CVE, or there is a false positive via `cve-check-tool`. The contents of the file can describe why it doesn't apply without requiring a patch (i.e. Resolved by cve-xxxx-xxxx.patch).
### Applying a patch ### Applying a patch
It is common practice to apply the patch within the `setup` section of your build staging. We can achieve this using the `%patch` macro, and the `$pkgfiles` variable. In this example, the required file is located It is common practice to apply the patch within the `setup` section of your build staging. We can achieve this using the `%patch` macro, and the `$pkgfiles` variable. In this example, the required file is located