7c78f80a96
1. Move existing CVE DB download generator/task login under the cve package 2. Add a new CVE scanner task generator and task type to run in the background, as well as tests for it 3. Move the CVE cache in its own package 4. Add a CVE scanner methods to check if an entry is present in the cache, and to retreive the results 5. Modify the FilterTags MetaDB method to not exit on first error This is needed in order to pass all tags to the generator, instead of the generator stopping at the first set of invalid data 6. Integrate the new scanning task generator with the existing zot code. 7. Fix an issue where the CVE scan results for multiarch images was not cached 8. Rewrite some of the older CVE tests to use the new image-utils test package 9. Use the CVE scanner as attribute of the controller instead of CveInfo. Remove functionality of CVE DB update from CveInfo, it is now responsible, as the name states, only for providing CVE information. 10. The logic to get maximum severity and cve count for image sumaries now uses only the scanner cache. 11. Removed the GetCVESummaryForImage method from CveInfo as it was only used in tests Signed-off-by: Andrei Aaron <aaaron@luxoft.com>
Adding new extensions
As new requirements come and build time extensions need to be added, there are a few things that you have to make sure are present before commiting :
- files that should be included in the binary only with a specific extension must contain the following syntax at the beginning of the file :
//go:build sync will be added automatically by the linter, so only the second line is mandatory .
NOTE: the third line in the example should be blank, otherwise the build tag would be just another comment.
//go:build sync
// +build sync
package extensions
...................
-
when adding a new tag, specify the new order in which multiple tags should be used (bottom of this page)
-
for each and every new file that contains functions (functionalities) specific to an extension, one should create a corresponding file that must contain the exact same functions, but no functionalities included. This file must begin with an "anti-tag" (e.g. // +build !sync) which will include this file in binaries that don't include this extension ( in this example, the file won't be used in binaries that include sync extension ). See extension-sync-disabled.go for an example.
-
each extension is responsible with implementing authorization for newly added HTTP endpoints. zot will provide the necessary data, including user permissions, to the extension, but actual enforcement of these permissions is the responsibility of each extension. Each extension http.Handler has access to a context previously populated by BaseAuthzHandler with relevant user info. That info has the following structure:
type AccessControlContext struct { // read method action ReadGlobPatterns map[string]bool // detectManifestCollision behaviour action DmcGlobPatterns map[string]bool IsAdmin bool Username string Groups []string }This data can then be accessed from the request context so that every extension can apply its own authorization logic, if needed .
-
when a new extension comes out, the developer should also write some blackbox tests, where a binary that contains the new extension should be tested in a real usage scenario. See test/blackbox folder for multiple extensions examples.
-
newly added blackbox tests should have targets in Makefile. You should also add them as Github Workflows, in .github/workflows/ecosystem-tools.yaml
-
with every new extension, you should modify the EXTENSIONS variable in Makefile by adding the new extension. The EXTENSIONS variable represents all extensions and is used in Make targets that require them all (e.g make test).
-
the available extensions that can be used at the moment are: sync, scrub, metrics, search . NOTE: When multiple extensions are used, they should be listed in the above presented order.