The use of last_updated was ambiguous (is it when an Envoy contributor
creates a PR, merges a commit, or when the dependency is released?).
We really are after the release date as a measure of how stale the
dependency is.
This patch introduces a tool, tools/dependency/release_dates.py, that
uses the GitHub API to compute release date. If a mismatch is detected, an
error is raised.
This patch also introduces a dependency validation CI job that gathers existing
scripts and the release_dates.py script into a single job.
Signed-off-by: Harvey Tuch <htuch@google.com>
Co-authored-by: Michael Payne <michael@sooper.org>
Mirrored from https://github.com/envoyproxy/envoy @ 91f2bb75a34e1068dcc91de1cafca9dad92feecb
.
* Python/Go dependencies that aren't part of the Envoy binary build
don't make sense to track in repository_locations.bzl, since they
have their own language specific metadata (e.g. requirements.txt)
or are in many cases transitively implied.
* Ensure that the full set of dependencies visible to bazel query
is now validated. This requires that we explicitly call out
transitive dependencies that are implied by direct dependencies
in repository_locations.bzl. A new annotation `implied_untracked_deps`
is used.
Fixes#12673
* dependencies: CVE scanner for repository_locations.bzl metadata.
This is a custom CVE scanner that consumes the NIST CVE database and
heuristically matches against the CPEs, versions and last update stamps
in repository_locations.bzl.
Future PRs will create a CI job that runs this on a periodic basis
(every few hours) to provide a CVE early warning system.
Example output:
Based on heuristic matching with the NIST CVE database, Envoy may be vulnerable to:
CVE ID: CVE-2019-19391
CVSS v3 score: 9.1
Severity: CRITICAL
Published date: 2019-11-29
Last modified date: 2019-12-19
Dependencies: com_github_luajit_luajit
Description: ** DISPUTED ** In LuaJIT through 2.0.5, as used in Moonjit before
2.1.2 and other products, debug.getinfo has a type confusion issue
that leads to arbitrary memory write or read operations, because
certain cases involving valid stack levels and > options are
mishandled. NOTE: The LuaJIT project owner states that the debug
libary is unsafe by definition and that this is not a vulnerability.
When LuaJIT was originally developed, the expectation was that the
entire debug library had no security guarantees and thus it made no
sense to assign CVEs. However, not all users of later LuaJIT
derivatives share this perspective.
Affected CPEs:
- cpe:2.3🅰️moonjit_project:moonjit:*
- cpe:2.3🅰️luajit:luajit:*
Risk level: Low
Testing: cve_scan_test.py unit tests, manual.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7d50518ce44aacc702d252eb05eb603c69461834
- Refactor code responsible for processing repository location specs, i.e. checking for the presence of fields like last_updated and interpolation of version. The same code is now usable by both API repository_locations.bzl and bazel/repository_locations.bzl.
- Cleanup reference to repo locations in repository_locations.bzl, now using a consistent set of macros.
- Add API dependencies to dependency dashboard.
Risk level: Low
Testing: Docs build.
Part of #12673
data-plane-api(Azure Pipelines)