2020-08-08 20:08:23 +02:00
|
|
|
#!/usr/bin/env python3
|
2009-10-28 00:28:40 +01:00
|
|
|
|
|
|
|
# Copyright (C) 2009 by Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
2022-07-27 17:48:20 +02:00
|
|
|
# Copyright (C) 2022 by Sen Hastings <sen@phobosdpl.com>
|
2009-10-28 00:28:40 +01:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
# General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program; if not, write to the Free Software
|
|
|
|
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
import aiohttp
|
2018-04-04 22:05:33 +02:00
|
|
|
import argparse
|
2020-08-08 20:08:23 +02:00
|
|
|
import asyncio
|
2018-04-04 22:05:33 +02:00
|
|
|
import datetime
|
|
|
|
import fnmatch
|
|
|
|
import os
|
2022-11-02 11:34:27 +01:00
|
|
|
from collections import defaultdict, namedtuple
|
2018-04-04 22:05:33 +02:00
|
|
|
import re
|
|
|
|
import subprocess
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
import json
|
2020-03-07 08:56:24 +01:00
|
|
|
import sys
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2020-11-05 17:30:19 +01:00
|
|
|
brpath = os.path.normpath(os.path.join(os.path.dirname(__file__), "..", ".."))
|
|
|
|
|
|
|
|
sys.path.append(os.path.join(brpath, "utils"))
|
2020-03-24 14:24:44 +01:00
|
|
|
from getdeveloperlib import parse_developers # noqa: E402
|
2020-02-15 13:44:16 +01:00
|
|
|
|
2019-02-07 22:04:26 +01:00
|
|
|
INFRA_RE = re.compile(r"\$\(eval \$\(([a-z-]*)-package\)\)")
|
|
|
|
URL_RE = re.compile(r"\s*https?://\S*\s*$")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
RM_API_STATUS_ERROR = 1
|
|
|
|
RM_API_STATUS_FOUND_BY_DISTRO = 2
|
|
|
|
RM_API_STATUS_FOUND_BY_PATTERN = 3
|
|
|
|
RM_API_STATUS_NOT_FOUND = 4
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2020-03-24 14:25:57 +01:00
|
|
|
|
2020-03-07 08:56:29 +01:00
|
|
|
class Defconfig:
|
|
|
|
def __init__(self, name, path):
|
|
|
|
self.name = name
|
|
|
|
self.path = path
|
|
|
|
self.developers = None
|
|
|
|
|
|
|
|
def set_developers(self, developers):
|
|
|
|
"""
|
|
|
|
Fills in the .developers field
|
|
|
|
"""
|
|
|
|
self.developers = [
|
|
|
|
developer.name
|
|
|
|
for developer in developers
|
|
|
|
if developer.hasfile(self.path)
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
|
|
def get_defconfig_list():
|
|
|
|
"""
|
|
|
|
Builds the list of Buildroot defconfigs, returning a list of Defconfig
|
|
|
|
objects.
|
|
|
|
"""
|
|
|
|
return [
|
|
|
|
Defconfig(name[:-len('_defconfig')], os.path.join('configs', name))
|
2020-11-05 17:30:19 +01:00
|
|
|
for name in os.listdir(os.path.join(brpath, 'configs'))
|
2020-03-07 08:56:29 +01:00
|
|
|
if name.endswith('_defconfig')
|
|
|
|
]
|
|
|
|
|
2019-02-07 22:04:26 +01:00
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
Br2Tree = namedtuple("Br2Tree", ["name", "path"])
|
|
|
|
|
|
|
|
|
|
|
|
def get_trees():
|
|
|
|
raw_variables = subprocess.check_output(["make", "--no-print-directory", "-s",
|
|
|
|
"BR2_HAVE_DOT_CONFIG=y", "printvars",
|
|
|
|
"VARS=BR2_EXTERNAL_NAMES BR2_EXTERNAL_%_PATH"])
|
|
|
|
variables = dict(line.split("=") for line in raw_variables.decode().split("\n") if line)
|
|
|
|
variables["BR2_EXTERNAL_BUILDROOT_PATH"] = brpath
|
|
|
|
externals = ["BUILDROOT", *variables["BR2_EXTERNAL_NAMES"].split()]
|
|
|
|
return [Br2Tree(name, os.path.normpath(variables[f"BR2_EXTERNAL_{name}_PATH"])) for name in externals]
|
|
|
|
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
class Package:
|
2020-03-07 08:56:25 +01:00
|
|
|
all_licenses = dict()
|
2018-04-04 22:05:33 +02:00
|
|
|
all_license_files = list()
|
|
|
|
all_versions = dict()
|
2020-02-15 13:44:16 +01:00
|
|
|
all_ignored_cves = dict()
|
2021-01-05 23:23:31 +01:00
|
|
|
all_cpeids = dict()
|
2020-03-07 08:56:32 +01:00
|
|
|
# This is the list of all possible checks. Add new checks to this list so
|
2023-08-12 21:28:29 +02:00
|
|
|
# a tool that post-processes the json output knows the checks before
|
2020-03-07 08:56:32 +01:00
|
|
|
# iterating over the packages.
|
|
|
|
status_checks = ['cve', 'developers', 'hash', 'license',
|
|
|
|
'license-files', 'patches', 'pkg-check', 'url', 'version']
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
def __init__(self, tree, name, path):
|
|
|
|
self.tree = tree.name
|
|
|
|
self.tree_path = tree.path
|
2018-04-04 22:05:33 +02:00
|
|
|
self.name = name
|
|
|
|
self.path = path
|
2020-03-07 08:56:28 +01:00
|
|
|
self.pkg_path = os.path.dirname(path)
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
# Contains a list of tuple (type, infra), such as ("target",
|
|
|
|
# "autotools"). When pkg-stats is run without -c, it contains
|
|
|
|
# the list of all infra/type supported by the package. When
|
|
|
|
# pkg-stats is run with -c, it contains the list of infra/type
|
|
|
|
# used by the current configuration.
|
2018-04-04 22:05:33 +02:00
|
|
|
self.infras = None
|
2020-03-07 08:56:25 +01:00
|
|
|
self.license = None
|
2018-04-04 22:05:33 +02:00
|
|
|
self.has_license = False
|
|
|
|
self.has_license_files = False
|
|
|
|
self.has_hash = False
|
2020-03-07 08:56:23 +01:00
|
|
|
self.patch_files = []
|
2018-04-04 22:05:33 +02:00
|
|
|
self.warnings = 0
|
|
|
|
self.current_version = None
|
2018-10-02 04:37:28 +02:00
|
|
|
self.url = None
|
2018-10-02 04:37:29 +02:00
|
|
|
self.url_worker = None
|
2020-12-04 16:45:57 +01:00
|
|
|
self.cpeid = None
|
2020-02-15 13:44:16 +01:00
|
|
|
self.cves = list()
|
2021-02-11 10:29:10 +01:00
|
|
|
self.ignored_cves = list()
|
2022-01-09 16:00:51 +01:00
|
|
|
self.unsure_cves = list()
|
2020-03-07 08:56:22 +01:00
|
|
|
self.latest_version = {'status': RM_API_STATUS_ERROR, 'version': None, 'id': None}
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status = {}
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
def pkgvar(self):
|
|
|
|
return self.name.upper().replace("-", "_")
|
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
@property
|
|
|
|
def pkgdir(self):
|
|
|
|
return os.path.join(self.tree_path, self.pkg_path)
|
|
|
|
|
|
|
|
@property
|
|
|
|
def pkgfile(self):
|
|
|
|
return os.path.join(self.tree_path, self.path)
|
|
|
|
|
|
|
|
@property
|
|
|
|
def hashpath(self):
|
|
|
|
return self.pkgfile.replace(".mk", ".hash")
|
|
|
|
|
2018-10-02 04:37:28 +02:00
|
|
|
def set_url(self):
|
|
|
|
"""
|
|
|
|
Fills in the .url field
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['url'] = ("warning", "no Config.in")
|
2022-11-02 11:34:27 +01:00
|
|
|
for filename in os.listdir(self.pkgdir):
|
2018-10-02 04:37:28 +02:00
|
|
|
if fnmatch.fnmatch(filename, 'Config.*'):
|
2022-11-02 11:34:27 +01:00
|
|
|
fp = open(os.path.join(self.pkgdir, filename), "r")
|
2018-10-02 04:37:28 +02:00
|
|
|
for config_line in fp:
|
|
|
|
if URL_RE.match(config_line):
|
|
|
|
self.url = config_line.strip()
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['url'] = ("ok", "found")
|
2018-10-02 04:37:28 +02:00
|
|
|
fp.close()
|
|
|
|
return
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['url'] = ("error", "missing")
|
2018-10-02 04:37:28 +02:00
|
|
|
fp.close()
|
|
|
|
|
2020-03-07 08:56:23 +01:00
|
|
|
@property
|
|
|
|
def patch_count(self):
|
|
|
|
return len(self.patch_files)
|
|
|
|
|
2020-03-07 08:56:31 +01:00
|
|
|
@property
|
|
|
|
def has_valid_infra(self):
|
2021-05-19 04:46:37 +02:00
|
|
|
if self.infras is None:
|
|
|
|
return False
|
|
|
|
return len(self.infras) > 0
|
|
|
|
|
|
|
|
@property
|
|
|
|
def is_actual_package(self):
|
2020-03-07 08:56:31 +01:00
|
|
|
try:
|
2021-05-19 04:46:37 +02:00
|
|
|
if not self.has_valid_infra:
|
|
|
|
return False
|
2020-03-07 08:56:31 +01:00
|
|
|
if self.infras[0][1] == 'virtual':
|
|
|
|
return False
|
|
|
|
except IndexError:
|
2020-03-24 14:26:31 +01:00
|
|
|
return False
|
2020-03-07 08:56:31 +01:00
|
|
|
return True
|
|
|
|
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
def set_infra(self, show_info_js):
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
|
|
|
Fills in the .infras field
|
|
|
|
"""
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
# If we're running pkg-stats for a given Buildroot
|
|
|
|
# configuration, keep only the type/infra that applies
|
|
|
|
if show_info_js:
|
|
|
|
keep_host = "host-%s" % self.name in show_info_js
|
|
|
|
keep_target = self.name in show_info_js
|
|
|
|
# Otherwise, keep all
|
|
|
|
else:
|
|
|
|
keep_host = True
|
|
|
|
keep_target = True
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
self.infras = list()
|
2022-11-02 11:34:27 +01:00
|
|
|
with open(self.pkgfile, 'r') as f:
|
2018-04-04 22:05:33 +02:00
|
|
|
lines = f.readlines()
|
2021-01-07 14:39:42 +01:00
|
|
|
for line in lines:
|
|
|
|
match = INFRA_RE.match(line)
|
2018-04-04 22:05:33 +02:00
|
|
|
if not match:
|
|
|
|
continue
|
|
|
|
infra = match.group(1)
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
if infra.startswith("host-") and keep_host:
|
2018-04-04 22:05:33 +02:00
|
|
|
self.infras.append(("host", infra[5:]))
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
elif keep_target:
|
2018-04-04 22:05:33 +02:00
|
|
|
self.infras.append(("target", infra))
|
|
|
|
|
|
|
|
def set_license(self):
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
Fills in the .status['license'] and .status['license-files'] fields
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
2021-05-19 04:46:37 +02:00
|
|
|
if not self.is_actual_package:
|
2020-03-07 08:56:31 +01:00
|
|
|
self.status['license'] = ("na", "no valid package infra")
|
|
|
|
self.status['license-files'] = ("na", "no valid package infra")
|
|
|
|
return
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
var = self.pkgvar()
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['license'] = ("error", "missing")
|
|
|
|
self.status['license-files'] = ("error", "missing")
|
2018-04-04 22:05:33 +02:00
|
|
|
if var in self.all_licenses:
|
2020-03-07 08:56:25 +01:00
|
|
|
self.license = self.all_licenses[var]
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['license'] = ("ok", "found")
|
2018-04-04 22:05:33 +02:00
|
|
|
if var in self.all_license_files:
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['license-files'] = ("ok", "found")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
def set_hash_info(self):
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
Fills in the .status['hash'] field
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
2021-05-19 04:46:37 +02:00
|
|
|
if not self.is_actual_package:
|
2020-03-07 08:56:31 +01:00
|
|
|
self.status['hash'] = ("na", "no valid package infra")
|
|
|
|
self.status['hash-license'] = ("na", "no valid package infra")
|
|
|
|
return
|
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
if os.path.exists(self.hashpath):
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['hash'] = ("ok", "found")
|
|
|
|
else:
|
|
|
|
self.status['hash'] = ("error", "missing")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
def set_patch_count(self):
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
Fills in the .patch_count, .patch_files and .status['patches'] fields
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
2021-05-19 04:46:37 +02:00
|
|
|
if not self.is_actual_package:
|
2020-03-07 08:56:31 +01:00
|
|
|
self.status['patches'] = ("na", "no valid package infra")
|
|
|
|
return
|
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
for subdir, _, _ in os.walk(self.pkgdir):
|
2020-03-07 08:56:23 +01:00
|
|
|
self.patch_files = fnmatch.filter(os.listdir(subdir), '*.patch')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2020-03-07 08:56:26 +01:00
|
|
|
if self.patch_count == 0:
|
|
|
|
self.status['patches'] = ("ok", "no patches")
|
|
|
|
elif self.patch_count < 5:
|
|
|
|
self.status['patches'] = ("warning", "some patches")
|
|
|
|
else:
|
|
|
|
self.status['patches'] = ("error", "lots of patches")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
def set_current_version(self):
|
|
|
|
"""
|
|
|
|
Fills in the .current_version field
|
|
|
|
"""
|
|
|
|
var = self.pkgvar()
|
|
|
|
if var in self.all_versions:
|
|
|
|
self.current_version = self.all_versions[var]
|
|
|
|
|
2020-12-04 16:45:57 +01:00
|
|
|
def set_cpeid(self):
|
|
|
|
"""
|
|
|
|
Fills in the .cpeid field
|
|
|
|
"""
|
|
|
|
var = self.pkgvar()
|
2021-05-19 04:46:37 +02:00
|
|
|
if not self.is_actual_package:
|
2021-05-19 04:46:38 +02:00
|
|
|
self.status['cpe'] = ("na", "N/A - virtual pkg")
|
|
|
|
return
|
|
|
|
if not self.current_version:
|
|
|
|
self.status['cpe'] = ("na", "no version information available")
|
2020-12-04 16:45:57 +01:00
|
|
|
return
|
|
|
|
|
|
|
|
if var in self.all_cpeids:
|
|
|
|
self.cpeid = self.all_cpeids[var]
|
2024-02-07 16:35:17 +01:00
|
|
|
self.status['cpe'] = ("ok", "(not checked against CPE dictionary)")
|
2020-12-04 16:45:57 +01:00
|
|
|
else:
|
|
|
|
self.status['cpe'] = ("error", "no verified CPE identifier")
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def set_check_package_warnings(self):
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
Fills in the .warnings and .status['pkg-check'] fields
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
2020-11-05 17:30:19 +01:00
|
|
|
cmd = [os.path.join(brpath, "utils/check-package")]
|
2020-03-07 08:56:26 +01:00
|
|
|
self.status['pkg-check'] = ("error", "Missing")
|
2022-11-02 11:34:27 +01:00
|
|
|
for root, dirs, files in os.walk(self.pkgdir):
|
2018-04-04 22:05:33 +02:00
|
|
|
for f in files:
|
2023-09-01 21:27:10 +02:00
|
|
|
cmd.append(os.path.join(root, f))
|
2018-04-04 22:05:33 +02:00
|
|
|
o = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE).communicate()[1]
|
|
|
|
lines = o.splitlines()
|
|
|
|
for line in lines:
|
2020-03-01 22:18:48 +01:00
|
|
|
m = re.match("^([0-9]*) warnings generated", line.decode())
|
2018-04-04 22:05:33 +02:00
|
|
|
if m:
|
|
|
|
self.warnings = int(m.group(1))
|
2020-03-07 08:56:26 +01:00
|
|
|
if self.warnings == 0:
|
|
|
|
self.status['pkg-check'] = ("ok", "no warnings")
|
|
|
|
else:
|
|
|
|
self.status['pkg-check'] = ("error", "{} warnings".format(self.warnings))
|
2018-04-04 22:05:33 +02:00
|
|
|
return
|
|
|
|
|
2021-02-11 10:29:10 +01:00
|
|
|
def set_ignored_cves(self):
|
2020-02-15 13:44:16 +01:00
|
|
|
"""
|
2020-07-24 17:43:52 +02:00
|
|
|
Give the list of CVEs ignored by the package
|
2020-02-15 13:44:16 +01:00
|
|
|
"""
|
2021-02-11 10:29:10 +01:00
|
|
|
self.ignored_cves = list(self.all_ignored_cves.get(self.pkgvar(), []))
|
2020-02-15 13:44:16 +01:00
|
|
|
|
2020-03-07 08:56:24 +01:00
|
|
|
def set_developers(self, developers):
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
Fills in the .developers and .status['developers'] field
|
2020-03-07 08:56:24 +01:00
|
|
|
"""
|
|
|
|
self.developers = [
|
|
|
|
dev.name
|
|
|
|
for dev in developers
|
|
|
|
if dev.hasfile(self.path)
|
|
|
|
]
|
|
|
|
|
2020-03-07 08:56:26 +01:00
|
|
|
if self.developers:
|
|
|
|
self.status['developers'] = ("ok", "{} developers".format(len(self.developers)))
|
|
|
|
else:
|
|
|
|
self.status['developers'] = ("warning", "no developers")
|
|
|
|
|
|
|
|
def is_status_ok(self, name):
|
2021-01-07 14:39:38 +01:00
|
|
|
return name in self.status and self.status[name][0] == 'ok'
|
|
|
|
|
|
|
|
def is_status_error(self, name):
|
|
|
|
return name in self.status and self.status[name][0] == 'error'
|
|
|
|
|
|
|
|
def is_status_na(self, name):
|
|
|
|
return name in self.status and self.status[name][0] == 'na'
|
2020-03-07 08:56:26 +01:00
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def __eq__(self, other):
|
|
|
|
return self.path == other.path
|
|
|
|
|
|
|
|
def __lt__(self, other):
|
|
|
|
return self.path < other.path
|
|
|
|
|
|
|
|
def __str__(self):
|
|
|
|
return "%s (path='%s', license='%s', license_files='%s', hash='%s', patches=%d)" % \
|
2020-03-24 14:28:05 +01:00
|
|
|
(self.name, self.path, self.is_status_ok('license'),
|
|
|
|
self.is_status_ok('license-files'), self.status['hash'], self.patch_count)
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
2022-11-02 11:34:27 +01:00
|
|
|
def get_pkglist(trees, npackages, package_list):
|
2018-04-04 22:05:33 +02:00
|
|
|
"""
|
|
|
|
Builds the list of Buildroot packages, returning a list of Package
|
|
|
|
objects. Only the .name and .path fields of the Package object are
|
|
|
|
initialized.
|
|
|
|
|
|
|
|
npackages: limit to N packages
|
|
|
|
package_list: limit to those packages in this list
|
|
|
|
"""
|
|
|
|
WALK_USEFUL_SUBDIRS = ["boot", "linux", "package", "toolchain"]
|
2023-09-01 21:27:09 +02:00
|
|
|
WALK_EXCLUDES = ["boot/barebox/barebox.mk",
|
|
|
|
"boot/common.mk",
|
2018-04-04 22:05:33 +02:00
|
|
|
"linux/linux-ext-.*.mk",
|
2023-09-01 21:27:09 +02:00
|
|
|
"package/fftw/fftw.mk",
|
2018-04-04 22:05:33 +02:00
|
|
|
"package/freescale-imx/freescale-imx.mk",
|
|
|
|
"package/gcc/gcc.mk",
|
|
|
|
"package/gstreamer/gstreamer.mk",
|
|
|
|
"package/gstreamer1/gstreamer1.mk",
|
|
|
|
"package/gtk2-themes/gtk2-themes.mk",
|
2023-09-01 21:27:09 +02:00
|
|
|
"package/kf5/kf5.mk",
|
|
|
|
"package/llvm-project/llvm-project.mk",
|
2018-04-04 22:05:33 +02:00
|
|
|
"package/matchbox/matchbox.mk",
|
|
|
|
"package/opengl/opengl.mk",
|
|
|
|
"package/qt5/qt5.mk",
|
2023-09-01 21:27:09 +02:00
|
|
|
"package/qt6/qt6.mk",
|
2018-04-04 22:05:33 +02:00
|
|
|
"package/x11r7/x11r7.mk",
|
|
|
|
"package/doc-asciidoc.mk",
|
|
|
|
"package/pkg-.*.mk",
|
|
|
|
"toolchain/toolchain-external/pkg-toolchain-external.mk",
|
|
|
|
"toolchain/toolchain-external/toolchain-external.mk",
|
|
|
|
"toolchain/toolchain.mk",
|
|
|
|
"toolchain/helpers.mk",
|
|
|
|
"toolchain/toolchain-wrapper.mk"]
|
|
|
|
packages = list()
|
|
|
|
count = 0
|
2022-11-02 11:34:27 +01:00
|
|
|
for br_tree, root, dirs, files in ((tree, *rdf) for tree in trees for rdf in os.walk(tree.path)):
|
|
|
|
root = os.path.relpath(root, br_tree.path)
|
2018-04-04 22:05:33 +02:00
|
|
|
rootdir = root.split("/")
|
2020-11-05 17:30:19 +01:00
|
|
|
if len(rootdir) < 1:
|
2018-04-04 22:05:33 +02:00
|
|
|
continue
|
2020-11-05 17:30:19 +01:00
|
|
|
if rootdir[0] not in WALK_USEFUL_SUBDIRS:
|
2018-04-04 22:05:33 +02:00
|
|
|
continue
|
|
|
|
for f in files:
|
|
|
|
if not f.endswith(".mk"):
|
|
|
|
continue
|
|
|
|
# Strip ending ".mk"
|
|
|
|
pkgname = f[:-3]
|
|
|
|
if package_list and pkgname not in package_list:
|
|
|
|
continue
|
|
|
|
pkgpath = os.path.join(root, f)
|
|
|
|
skip = False
|
|
|
|
for exclude in WALK_EXCLUDES:
|
2020-11-05 17:30:19 +01:00
|
|
|
if re.match(exclude, pkgpath):
|
2018-04-04 22:05:33 +02:00
|
|
|
skip = True
|
|
|
|
continue
|
|
|
|
if skip:
|
|
|
|
continue
|
2022-11-02 11:34:27 +01:00
|
|
|
p = Package(br_tree, pkgname, pkgpath)
|
2018-04-04 22:05:33 +02:00
|
|
|
packages.append(p)
|
|
|
|
count += 1
|
|
|
|
if npackages and count == npackages:
|
|
|
|
return packages
|
|
|
|
return packages
|
|
|
|
|
|
|
|
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
def get_show_info_js():
|
support/scripts/pkg-stats: support generating stats based on configured packages
pkg-stats was initially a Buildroot maintenance oriented tool: it was
designed to examine all Buildroot packages and provide
statistics/details about them.
However, it turns out that a number of details provided by pkg-stats,
especially CVEs, are relevant also for Buildroot users, who would like
to check regularly if their specific Buildroot configuration is
affected by CVEs or not, and possibly check if all packages have
license information, license files, etc.
The cve-checker script was recently introduced to provide an output
relatively similar to pkg-stats, but focused on CVEs only.
But in fact, its main difference is on the set of packages that we
consider: pkg-stats considers all packages, while cve-checker uses
"make show-info" to only consider packages enabled in the current
configuration.
So, this commit introduces a -c option to pkg-stats, to tell pkg-stats
to generate its output based on the list of configured packages. -c is
mutually exclusive with the -p option (explicit list of packages) and
-n option (a number of packages, picked randomly).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-11-05 17:30:20 +01:00
|
|
|
cmd = ["make", "--no-print-directory", "show-info"]
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
return json.loads(subprocess.check_output(cmd))
|
support/scripts/pkg-stats: support generating stats based on configured packages
pkg-stats was initially a Buildroot maintenance oriented tool: it was
designed to examine all Buildroot packages and provide
statistics/details about them.
However, it turns out that a number of details provided by pkg-stats,
especially CVEs, are relevant also for Buildroot users, who would like
to check regularly if their specific Buildroot configuration is
affected by CVEs or not, and possibly check if all packages have
license information, license files, etc.
The cve-checker script was recently introduced to provide an output
relatively similar to pkg-stats, but focused on CVEs only.
But in fact, its main difference is on the set of packages that we
consider: pkg-stats considers all packages, while cve-checker uses
"make show-info" to only consider packages enabled in the current
configuration.
So, this commit introduces a -c option to pkg-stats, to tell pkg-stats
to generate its output based on the list of configured packages. -c is
mutually exclusive with the -p option (explicit list of packages) and
-n option (a number of packages, picked randomly).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-11-05 17:30:20 +01:00
|
|
|
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def package_init_make_info():
|
2019-07-19 16:35:55 +02:00
|
|
|
# Fetch all variables at once
|
2021-11-24 16:06:54 +01:00
|
|
|
variables = subprocess.check_output(["make", "--no-print-directory", "-s",
|
|
|
|
"BR2_HAVE_DOT_CONFIG=y", "printvars",
|
2020-12-04 16:45:57 +01:00
|
|
|
"VARS=%_LICENSE %_LICENSE_FILES %_VERSION %_IGNORE_CVES %_CPE_ID"])
|
2020-03-01 22:18:48 +01:00
|
|
|
variable_list = variables.decode().splitlines()
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# We process first the host package VERSION, and then the target
|
|
|
|
# package VERSION. This means that if a package exists in both
|
2019-07-19 16:35:55 +02:00
|
|
|
# target and host variants, with different values (eg. version
|
|
|
|
# numbers (unlikely)), we'll report the target one.
|
|
|
|
variable_list = [x[5:] for x in variable_list if x.startswith("HOST_")] + \
|
|
|
|
[x for x in variable_list if not x.startswith("HOST_")]
|
|
|
|
|
2021-05-18 20:21:53 +02:00
|
|
|
for item in variable_list:
|
2018-04-04 22:05:33 +02:00
|
|
|
# Get variable name and value
|
2021-11-13 13:42:34 +01:00
|
|
|
pkgvar, value = item.split("=", maxsplit=1)
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2019-07-19 16:35:55 +02:00
|
|
|
# Strip the suffix according to the variable
|
|
|
|
if pkgvar.endswith("_LICENSE"):
|
|
|
|
# If value is "unknown", no license details available
|
|
|
|
if value == "unknown":
|
|
|
|
continue
|
|
|
|
pkgvar = pkgvar[:-8]
|
2020-03-07 08:56:25 +01:00
|
|
|
Package.all_licenses[pkgvar] = value
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2019-08-01 17:12:43 +02:00
|
|
|
elif pkgvar.endswith("_LICENSE_FILES"):
|
2019-07-19 16:35:55 +02:00
|
|
|
if pkgvar.endswith("_MANIFEST_LICENSE_FILES"):
|
|
|
|
continue
|
|
|
|
pkgvar = pkgvar[:-14]
|
|
|
|
Package.all_license_files.append(pkgvar)
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2019-07-19 16:35:55 +02:00
|
|
|
elif pkgvar.endswith("_VERSION"):
|
|
|
|
if pkgvar.endswith("_DL_VERSION"):
|
|
|
|
continue
|
|
|
|
pkgvar = pkgvar[:-8]
|
|
|
|
Package.all_versions[pkgvar] = value
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2020-02-15 13:44:16 +01:00
|
|
|
elif pkgvar.endswith("_IGNORE_CVES"):
|
|
|
|
pkgvar = pkgvar[:-12]
|
|
|
|
Package.all_ignored_cves[pkgvar] = value.split()
|
|
|
|
|
2020-12-04 16:45:57 +01:00
|
|
|
elif pkgvar.endswith("_CPE_ID"):
|
|
|
|
pkgvar = pkgvar[:-7]
|
|
|
|
Package.all_cpeids[pkgvar] = value
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2021-01-05 23:23:31 +01:00
|
|
|
|
2020-08-08 20:08:25 +02:00
|
|
|
check_url_count = 0
|
|
|
|
|
|
|
|
|
|
|
|
async def check_url_status(session, pkg, npkgs, retry=True):
|
|
|
|
global check_url_count
|
|
|
|
|
2020-08-08 20:08:24 +02:00
|
|
|
try:
|
|
|
|
async with session.get(pkg.url) as resp:
|
|
|
|
if resp.status >= 400:
|
|
|
|
pkg.status['url'] = ("error", "invalid {}".format(resp.status))
|
2020-08-08 20:08:25 +02:00
|
|
|
check_url_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_url_count, npkgs, pkg.name))
|
2020-08-08 20:08:24 +02:00
|
|
|
return
|
|
|
|
except (aiohttp.ClientError, asyncio.TimeoutError):
|
|
|
|
if retry:
|
2020-08-08 20:08:25 +02:00
|
|
|
return await check_url_status(session, pkg, npkgs, retry=False)
|
2020-08-08 20:08:24 +02:00
|
|
|
else:
|
|
|
|
pkg.status['url'] = ("error", "invalid (err)")
|
2020-08-08 20:08:25 +02:00
|
|
|
check_url_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_url_count, npkgs, pkg.name))
|
2020-08-08 20:08:24 +02:00
|
|
|
return
|
2018-10-02 04:37:29 +02:00
|
|
|
|
2020-08-08 20:08:24 +02:00
|
|
|
pkg.status['url'] = ("ok", "valid")
|
2020-08-08 20:08:25 +02:00
|
|
|
check_url_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_url_count, npkgs, pkg.name))
|
2018-10-02 04:37:29 +02:00
|
|
|
|
2020-08-08 20:08:24 +02:00
|
|
|
|
|
|
|
async def check_package_urls(packages):
|
|
|
|
tasks = []
|
|
|
|
connector = aiohttp.TCPConnector(limit_per_host=5)
|
2022-04-02 16:15:29 +02:00
|
|
|
async with aiohttp.ClientSession(connector=connector, trust_env=True,
|
|
|
|
timeout=aiohttp.ClientTimeout(total=15)) as sess:
|
2020-08-08 20:08:24 +02:00
|
|
|
packages = [p for p in packages if p.status['url'][0] == 'ok']
|
|
|
|
for pkg in packages:
|
2020-11-19 15:53:52 +01:00
|
|
|
tasks.append(asyncio.ensure_future(check_url_status(sess, pkg, len(packages))))
|
2020-08-08 20:08:24 +02:00
|
|
|
await asyncio.wait(tasks)
|
2018-10-02 04:37:28 +02:00
|
|
|
|
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
def check_package_latest_version_set_status(pkg, status, version, identifier):
|
|
|
|
pkg.latest_version = {
|
|
|
|
"status": status,
|
|
|
|
"version": version,
|
|
|
|
"id": identifier,
|
|
|
|
}
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
if pkg.latest_version['status'] == RM_API_STATUS_ERROR:
|
|
|
|
pkg.status['version'] = ('warning', "Release Monitoring API error")
|
|
|
|
elif pkg.latest_version['status'] == RM_API_STATUS_NOT_FOUND:
|
|
|
|
pkg.status['version'] = ('warning', "Package not found on Release Monitoring")
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
if pkg.latest_version['version'] is None:
|
|
|
|
pkg.status['version'] = ('warning', "No upstream version available on Release Monitoring")
|
|
|
|
elif pkg.latest_version['version'] != pkg.current_version:
|
|
|
|
pkg.status['version'] = ('error', "The newer version {} is available upstream".format(pkg.latest_version['version']))
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
else:
|
2020-08-08 20:08:23 +02:00
|
|
|
pkg.status['version'] = ('ok', 'up-to-date')
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
async def check_package_get_latest_version_by_distro(session, pkg, retry=True):
|
2023-08-12 21:28:29 +02:00
|
|
|
url = "https://release-monitoring.org/api/project/Buildroot/%s" % pkg.name
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
try:
|
2020-08-08 20:08:23 +02:00
|
|
|
async with session.get(url) as resp:
|
|
|
|
if resp.status != 200:
|
|
|
|
return False
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
data = await resp.json()
|
support/scripts/pkg-stats: strengthen version check in check_package_get_latest_version_by_distro()
The check_package_get_latest_version_by_distro() function analyzes the
data returned by release-monitoring.org. For two of our
packages (bento4 and qextserialport), release-monitoring.org returns
something that is a bit odd: it returns an entry with a
"stable_versions" field that contains an empty array. Our code was
ready to have or not have a "stable_versions" entry, but when it is
present, we assumed it was not an empty array. These two packages, for
some reason, break this assumption.
In order to solve this problem, this commit is more careful, and uses
the stable_versions field only if it exists and it has at least one
entry. The code is also reworked as a sequence of "if...elif...else"
to be more readable.
This fixes the following exception when running pkg-stats on the full
package set:
Task exception was never retrieved
future: <Task finished name='Task-10772' coro=<check_package_latest_version_get() done, defined at ./support/scripts/pkg-stats:532> exception=IndexError('list index out of range')>
Traceback (most recent call last):
File "./support/scripts/pkg-stats", line 535, in check_package_latest_version_get
if await check_package_get_latest_version_by_distro(session, pkg):
File "./support/scripts/pkg-stats", line 489, in check_package_get_latest_version_by_distro
version = data['stable_versions'][0] if 'stable_versions' in data else data['version'] if 'version' in data else None
IndexError: list index out of range
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: non-sequence tests as True]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-03-16 22:48:46 +01:00
|
|
|
if 'stable_versions' in data and data['stable_versions']:
|
|
|
|
version = data['stable_versions'][0]
|
|
|
|
elif 'version' in data:
|
|
|
|
version = data['version']
|
|
|
|
else:
|
|
|
|
version = None
|
2020-08-08 20:08:23 +02:00
|
|
|
check_package_latest_version_set_status(pkg,
|
|
|
|
RM_API_STATUS_FOUND_BY_DISTRO,
|
|
|
|
version,
|
|
|
|
data['id'])
|
|
|
|
return True
|
|
|
|
|
|
|
|
except (aiohttp.ClientError, asyncio.TimeoutError):
|
|
|
|
if retry:
|
|
|
|
return await check_package_get_latest_version_by_distro(session, pkg, retry=False)
|
|
|
|
else:
|
|
|
|
return False
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
async def check_package_get_latest_version_by_guess(session, pkg, retry=True):
|
|
|
|
url = "https://release-monitoring.org/api/projects/?pattern=%s" % pkg.name
|
|
|
|
try:
|
|
|
|
async with session.get(url) as resp:
|
|
|
|
if resp.status != 200:
|
|
|
|
return False
|
|
|
|
|
|
|
|
data = await resp.json()
|
|
|
|
# filter projects that have the right name and a version defined
|
support/scripts/pkg-stats: use the new 'stable_versions' field of release-monitoring.org
The pkg-stats script queries release-monitoring.org to find the latest
upstream versions of our packages. However, up until recently,
release-monitoring.org had no notion of stable
vs. development/release-candidate versions, so for some packages the
"latest" version was in fact a development/release-candidate version
that we didn't want to package in Buildroot.
However, in recent time, release-monitoring.org has gained support for
differentiating stable vs. development releases of upstream
projects. See for example
https://release-monitoring.org/project/10024/ for the glib library,
which has a number of versions marked "Pre-release".
The JSON blurb returned by release-monitoring.org has 3 relevant
fields:
- "version", which we are using currently, which is a string
containing the reference of the latest version, including
pre-release.
- "versions", which is an array of strings listing all versions,
pre-release or not.
- "stable_versions", which is an array of string listing only
non-pre-release versions. It is ordered newest first to oldest
last.
So, this commit changes from using 'version' to using
'stable_versions[0]'.
As an example, before this change, pkg-stats reports that nfs-utils
needs to be bumped to 2.5.5rc3, while after this patch, it reports
that nfs-utils is already at 2.5.4, and that this is the latest stable
version (modulo an issue where Buildroot has 2.5.4 and
release-monitoring.org has 2-5-4, this will be addressed separately).
Note that part of this change was already done in commit f7b0e0860, but
it was incomplete.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2021-10-08 23:21:35 +02:00
|
|
|
projects = [p for p in data['projects'] if p['name'] == pkg.name and 'stable_versions' in p]
|
2020-08-08 20:08:23 +02:00
|
|
|
projects.sort(key=lambda x: x['id'])
|
|
|
|
|
support/scripts/pkg-stats: add better checking in check_package_get_latest_version_by_guess()
The 'rtl8723ds' name, when queried from release-monitoring.org at
https://release-monitoring.org/api/projects/?pattern=rtl8723ds returns
one project, with one "stable_versions" array, which is empty. This
was not expected by the pkg-stats code, causing an exception:
Task exception was never retrieved
future: <Task finished name='Task-764' coro=<check_package_latest_version_get() done, defined at /home/thomas/projets/buildroot/./support/scripts/pkg-stats:558> exception=IndexError('list index out of range')>
Traceback (most recent call last):
File "/home/thomas/projets/buildroot/./support/scripts/pkg-stats", line 566, in check_package_latest_version_get
if await check_package_get_latest_version_by_guess(session, pkg):
File "/home/thomas/projets/buildroot/./support/scripts/pkg-stats", line 544, in check_package_get_latest_version_by_guess
projects[0]['stable_versions'][0],
IndexError: list index out of range
This commit therefore improves the checks done on the results received
from release-monitoring.org to avoid this issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2022-07-27 23:09:18 +02:00
|
|
|
if len(projects) == 0:
|
|
|
|
return False
|
|
|
|
|
|
|
|
if len(projects[0]['stable_versions']) == 0:
|
|
|
|
return False
|
|
|
|
|
|
|
|
check_package_latest_version_set_status(pkg,
|
|
|
|
RM_API_STATUS_FOUND_BY_PATTERN,
|
|
|
|
projects[0]['stable_versions'][0],
|
|
|
|
projects[0]['id'])
|
|
|
|
return True
|
2020-08-08 20:08:23 +02:00
|
|
|
|
|
|
|
except (aiohttp.ClientError, asyncio.TimeoutError):
|
|
|
|
if retry:
|
|
|
|
return await check_package_get_latest_version_by_guess(session, pkg, retry=False)
|
|
|
|
else:
|
|
|
|
return False
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
|
|
|
|
2020-08-08 20:08:25 +02:00
|
|
|
check_latest_count = 0
|
|
|
|
|
|
|
|
|
|
|
|
async def check_package_latest_version_get(session, pkg, npkgs):
|
|
|
|
global check_latest_count
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
if await check_package_get_latest_version_by_distro(session, pkg):
|
2020-08-08 20:08:25 +02:00
|
|
|
check_latest_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_latest_count, npkgs, pkg.name))
|
2020-08-08 20:08:23 +02:00
|
|
|
return
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
if await check_package_get_latest_version_by_guess(session, pkg):
|
2020-08-08 20:08:25 +02:00
|
|
|
check_latest_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_latest_count, npkgs, pkg.name))
|
2020-08-08 20:08:23 +02:00
|
|
|
return
|
2019-08-01 17:12:44 +02:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
check_package_latest_version_set_status(pkg,
|
|
|
|
RM_API_STATUS_NOT_FOUND,
|
|
|
|
None, None)
|
2020-08-08 20:08:25 +02:00
|
|
|
check_latest_count += 1
|
|
|
|
print("[%04d/%04d] %s" % (check_latest_count, npkgs, pkg.name))
|
2019-08-01 17:12:44 +02:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
|
|
|
|
async def check_package_latest_version(packages):
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
"""
|
|
|
|
Fills in the .latest_version field of all Package objects
|
|
|
|
|
2020-03-07 08:56:22 +01:00
|
|
|
This field is a dict and has the following keys:
|
|
|
|
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
- status: one of RM_API_STATUS_ERROR,
|
|
|
|
RM_API_STATUS_FOUND_BY_DISTRO, RM_API_STATUS_FOUND_BY_PATTERN,
|
|
|
|
RM_API_STATUS_NOT_FOUND
|
|
|
|
- version: string containing the latest version known by
|
|
|
|
release-monitoring.org for this package
|
|
|
|
- id: string containing the id of the project corresponding to this
|
|
|
|
package, as known by release-monitoring.org
|
|
|
|
"""
|
2020-03-07 08:56:26 +01:00
|
|
|
|
2021-05-19 04:46:37 +02:00
|
|
|
for pkg in [p for p in packages if not p.is_actual_package]:
|
2020-08-08 20:08:23 +02:00
|
|
|
pkg.status['version'] = ("na", "no valid package infra")
|
2020-03-09 15:17:09 +01:00
|
|
|
|
2020-08-08 20:08:23 +02:00
|
|
|
tasks = []
|
|
|
|
connector = aiohttp.TCPConnector(limit_per_host=5)
|
|
|
|
async with aiohttp.ClientSession(connector=connector, trust_env=True) as sess:
|
2021-05-19 04:46:37 +02:00
|
|
|
packages = [p for p in packages if p.is_actual_package]
|
2020-08-08 20:08:23 +02:00
|
|
|
for pkg in packages:
|
2020-11-19 15:53:52 +01:00
|
|
|
tasks.append(asyncio.ensure_future(check_package_latest_version_get(sess, pkg, len(packages))))
|
2020-08-08 20:08:23 +02:00
|
|
|
await asyncio.wait(tasks)
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
|
|
|
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
def check_package_cve_affects(cve, cpe_product_pkgs):
|
|
|
|
for product in cve.affected_products:
|
2021-01-05 23:23:31 +01:00
|
|
|
if product not in cpe_product_pkgs:
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
continue
|
|
|
|
for pkg in cpe_product_pkgs[product]:
|
2022-01-09 16:00:51 +01:00
|
|
|
cve_status = cve.affects(pkg.name, pkg.current_version, pkg.ignored_cves, pkg.cpeid)
|
|
|
|
if cve_status == cve.CVE_AFFECTS:
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
pkg.cves.append(cve.identifier)
|
2022-01-09 16:00:51 +01:00
|
|
|
elif cve_status == cve.CVE_UNKNOWN:
|
|
|
|
pkg.unsure_cves.append(cve.identifier)
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
|
2021-01-05 23:23:31 +01:00
|
|
|
|
2020-02-15 13:44:16 +01:00
|
|
|
def check_package_cves(nvd_path, packages):
|
|
|
|
if not os.path.isdir(nvd_path):
|
|
|
|
os.makedirs(nvd_path)
|
|
|
|
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
cpe_product_pkgs = defaultdict(list)
|
|
|
|
for pkg in packages:
|
2021-05-19 04:46:37 +02:00
|
|
|
if not pkg.is_actual_package:
|
2021-05-19 04:46:38 +02:00
|
|
|
pkg.status['cve'] = ("na", "N/A")
|
2020-12-04 16:45:59 +01:00
|
|
|
continue
|
|
|
|
if not pkg.current_version:
|
2020-12-04 16:46:00 +01:00
|
|
|
pkg.status['cve'] = ("na", "no version information available")
|
2020-12-04 16:45:59 +01:00
|
|
|
continue
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
if pkg.cpeid:
|
|
|
|
cpe_product = cvecheck.cpe_product(pkg.cpeid)
|
|
|
|
cpe_product_pkgs[cpe_product].append(pkg)
|
|
|
|
else:
|
|
|
|
cpe_product_pkgs[pkg.name].append(pkg)
|
2020-02-15 13:44:16 +01:00
|
|
|
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
for cve in cvecheck.CVE.read_nvd_dir(nvd_path):
|
|
|
|
check_package_cve_affects(cve, cpe_product_pkgs)
|
2020-09-02 23:21:57 +02:00
|
|
|
|
2020-12-04 16:46:00 +01:00
|
|
|
for pkg in packages:
|
|
|
|
if 'cve' not in pkg.status:
|
2022-01-09 16:00:51 +01:00
|
|
|
if pkg.cves or pkg.unsure_cves:
|
2020-12-04 16:46:00 +01:00
|
|
|
pkg.status['cve'] = ("error", "affected by CVEs")
|
|
|
|
else:
|
|
|
|
pkg.status['cve'] = ("ok", "not affected by CVEs")
|
|
|
|
|
2021-01-05 23:23:31 +01:00
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def calculate_stats(packages):
|
|
|
|
stats = defaultdict(int)
|
2020-03-07 08:56:27 +01:00
|
|
|
stats['packages'] = len(packages)
|
2018-04-04 22:05:33 +02:00
|
|
|
for pkg in packages:
|
|
|
|
# If packages have multiple infra, take the first one. For the
|
|
|
|
# vast majority of packages, the target and host infra are the
|
|
|
|
# same. There are very few packages that use a different infra
|
|
|
|
# for the host and target variants.
|
|
|
|
if len(pkg.infras) > 0:
|
|
|
|
infra = pkg.infras[0][1]
|
|
|
|
stats["infra-%s" % infra] += 1
|
|
|
|
else:
|
|
|
|
stats["infra-unknown"] += 1
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('license'):
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["license"] += 1
|
|
|
|
else:
|
|
|
|
stats["no-license"] += 1
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('license-files'):
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["license-files"] += 1
|
|
|
|
else:
|
|
|
|
stats["no-license-files"] += 1
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('hash'):
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["hash"] += 1
|
|
|
|
else:
|
|
|
|
stats["no-hash"] += 1
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['status'] == RM_API_STATUS_FOUND_BY_DISTRO:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["rmo-mapping"] += 1
|
|
|
|
else:
|
|
|
|
stats["rmo-no-mapping"] += 1
|
2020-03-07 08:56:22 +01:00
|
|
|
if not pkg.latest_version['version']:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["version-unknown"] += 1
|
2020-03-07 08:56:22 +01:00
|
|
|
elif pkg.latest_version['version'] == pkg.current_version:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["version-uptodate"] += 1
|
|
|
|
else:
|
|
|
|
stats["version-not-uptodate"] += 1
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["patches"] += pkg.patch_count
|
2020-02-15 13:44:16 +01:00
|
|
|
stats["total-cves"] += len(pkg.cves)
|
2022-01-09 16:00:51 +01:00
|
|
|
stats["total-unsure-cves"] += len(pkg.unsure_cves)
|
2020-02-15 13:44:16 +01:00
|
|
|
if len(pkg.cves) != 0:
|
|
|
|
stats["pkg-cves"] += 1
|
2022-01-09 16:00:51 +01:00
|
|
|
if len(pkg.unsure_cves) != 0:
|
|
|
|
stats["pkg-unsure-cves"] += 1
|
2020-12-04 16:45:57 +01:00
|
|
|
if pkg.cpeid:
|
|
|
|
stats["cpe-id"] += 1
|
|
|
|
else:
|
|
|
|
stats["no-cpe-id"] += 1
|
2018-04-04 22:05:33 +02:00
|
|
|
return stats
|
|
|
|
|
|
|
|
|
|
|
|
html_header = """
|
2022-07-22 21:15:58 +02:00
|
|
|
<!DOCTYPE html>
|
|
|
|
<html lang="en">
|
2018-04-04 22:05:33 +02:00
|
|
|
<head>
|
2022-07-22 21:15:58 +02:00
|
|
|
<meta charset="UTF-8">
|
|
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
|
|
<script>
|
2022-07-28 04:14:44 +02:00
|
|
|
const triangleUp = String.fromCodePoint(32, 9652);
|
|
|
|
const triangleDown = String.fromCodePoint(32, 9662);
|
|
|
|
var lastColumnName = false;
|
2022-07-29 01:23:55 +02:00
|
|
|
const styleElement = document.createElement('style');
|
|
|
|
document.head.insertAdjacentElement("afterend", styleElement);
|
|
|
|
const styleSheet = styleElement.sheet;
|
2022-07-29 01:23:57 +02:00
|
|
|
addedCSSRules = [
|
|
|
|
".collapse{ height: 200px; overflow: hidden scroll;}",
|
|
|
|
".see-more{ display: block;}",
|
|
|
|
".label:hover,.see-more:hover { cursor: pointer; background: #d2ffc4;}"
|
|
|
|
];
|
2022-07-29 01:23:55 +02:00
|
|
|
|
2022-07-29 01:23:57 +02:00
|
|
|
addedCSSRules.forEach(rule => styleSheet.insertRule(rule));
|
2022-07-28 04:14:44 +02:00
|
|
|
|
2022-07-22 21:15:58 +02:00
|
|
|
function sortGrid(sortLabel){
|
2022-07-28 04:14:44 +02:00
|
|
|
let i = 0;
|
2022-07-22 21:15:58 +02:00
|
|
|
let pkgSortArray = [], sortedPkgArray = [], pkgStringSortArray = [], pkgNumSortArray = [];
|
support/scripts/pkg-stats: fix/improve git hash sorting
sortGrid()'s handling of git hashes and other large hex numbers
has been inconsistent, they can be detected as strings or numbers
depending on what type of character they start with.
This patch fixes the behaviour by using a regex to capture everything
that looks like a big hex number and treat it as a string.
This means when you sort by current version ascending all the version
strings with big hex numbers should show up first, sorted 0-9,a-f.
First we check for a string length >= 39, and then apply a regex
to return an array with every char from that string that matched
the regex. If the length of this array is still >= 39 we can assume
we are looking at something containing a git hash.
The reason why the length is defined as ">= 39" and not "40" or
"39 or 40" is twofold:
Firstly, 39 was chosen as a minimum to match stuff with 39 char git
hashes, like the rockchip-mali package.
Secondly, there is no max because we actually want to catch not
just explicitly git hashes, but any verson string with big gnarly
hex numbers in it.
Stuff like: "1.4.2-168-ged3039cdbeeb28fc0011c3585d8f7dfb91038292"
Why? Well, the idea is less about git hashes and sorting
and more about grouping similarly formatted version strings.
It would be impossble (or at least annoyingly complicated) and of
dubious utility to get a real sequential sort out of the
current version column, so the attempt here is to at the very
least collect all the similarly formatted things together.
This isn't perfect, but it's a (arguably) more useful sorted
output than before.
A demo is available here:
https://sen-h.codeberg.page/pkg-stats-demos/@pages/fix-improve-git-hash-sorting.html
Signed-off-by: Sen Hastings <sen@hastings.org>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ce7363524c172e65571e4b5d76ef65a36f7c3020)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2024-03-05 10:33:34 +01:00
|
|
|
const git_hash_regex = /[a-f,0-9]/gi;
|
2022-07-28 04:14:44 +02:00
|
|
|
const columnValues = Array.from(document.getElementsByClassName(sortLabel));
|
|
|
|
const columnName = document.getElementById(sortLabel);
|
|
|
|
let lastStyle = document.getElementById("sort-css");
|
|
|
|
|
|
|
|
if (lastStyle){
|
|
|
|
lastStyle.disable = true;
|
|
|
|
lastStyle.remove();
|
|
|
|
};
|
|
|
|
styleElement.id = "sort-css";
|
|
|
|
document.head.appendChild(styleElement);
|
|
|
|
const styleSheet = styleElement.sheet;
|
|
|
|
|
|
|
|
columnValues.shift();
|
|
|
|
columnValues.forEach((listing) => {
|
|
|
|
let sortArr = [];
|
|
|
|
sortArr[0] = listing.id.replace(sortLabel+"_", "");
|
|
|
|
if (!listing.innerText){
|
|
|
|
sortArr[1] = -1;
|
|
|
|
} else {
|
|
|
|
sortArr[1] = listing.innerText;
|
|
|
|
};
|
|
|
|
pkgSortArray.push(sortArr);
|
|
|
|
});
|
|
|
|
pkgSortArray.forEach((listing) => {
|
support/scripts/pkg-stats: fix/improve git hash sorting
sortGrid()'s handling of git hashes and other large hex numbers
has been inconsistent, they can be detected as strings or numbers
depending on what type of character they start with.
This patch fixes the behaviour by using a regex to capture everything
that looks like a big hex number and treat it as a string.
This means when you sort by current version ascending all the version
strings with big hex numbers should show up first, sorted 0-9,a-f.
First we check for a string length >= 39, and then apply a regex
to return an array with every char from that string that matched
the regex. If the length of this array is still >= 39 we can assume
we are looking at something containing a git hash.
The reason why the length is defined as ">= 39" and not "40" or
"39 or 40" is twofold:
Firstly, 39 was chosen as a minimum to match stuff with 39 char git
hashes, like the rockchip-mali package.
Secondly, there is no max because we actually want to catch not
just explicitly git hashes, but any verson string with big gnarly
hex numbers in it.
Stuff like: "1.4.2-168-ged3039cdbeeb28fc0011c3585d8f7dfb91038292"
Why? Well, the idea is less about git hashes and sorting
and more about grouping similarly formatted version strings.
It would be impossble (or at least annoyingly complicated) and of
dubious utility to get a real sequential sort out of the
current version column, so the attempt here is to at the very
least collect all the similarly formatted things together.
This isn't perfect, but it's a (arguably) more useful sorted
output than before.
A demo is available here:
https://sen-h.codeberg.page/pkg-stats-demos/@pages/fix-improve-git-hash-sorting.html
Signed-off-by: Sen Hastings <sen@hastings.org>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
(cherry picked from commit ce7363524c172e65571e4b5d76ef65a36f7c3020)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2024-03-05 10:33:34 +01:00
|
|
|
if ( listing[1].length >= 39 && listing[1].match(git_hash_regex).length >= 39){
|
|
|
|
pkgStringSortArray.push(listing);
|
|
|
|
} else if ( isNaN(parseInt(listing[1], 10)) ){
|
2022-07-28 04:14:44 +02:00
|
|
|
pkgStringSortArray.push(listing);
|
|
|
|
} else {
|
|
|
|
listing[1] = parseFloat(listing[1]);
|
|
|
|
pkgNumSortArray.push(listing);
|
|
|
|
};
|
|
|
|
});
|
|
|
|
|
|
|
|
let sortedStringPkgArray = pkgStringSortArray.sort((a, b) => {
|
|
|
|
if (a[1].toUpperCase() < b[1].toUpperCase()) { return -1; };
|
|
|
|
if (a[1].toUpperCase() > b[1].toUpperCase()) { return 1; };
|
|
|
|
return 0;
|
|
|
|
});
|
|
|
|
let sortedNumPkgArray = pkgNumSortArray.sort((a, b) => a[1] - b[1]);
|
|
|
|
|
|
|
|
if (columnName.lastElementChild.innerText == triangleDown) {
|
|
|
|
columnName.lastElementChild.innerText = triangleUp;
|
|
|
|
sortedStringPkgArray.reverse();
|
|
|
|
sortedNumPkgArray.reverse();
|
|
|
|
sortedPkgArray = sortedNumPkgArray.concat(sortedStringPkgArray);
|
|
|
|
} else {
|
|
|
|
columnName.lastElementChild.innerText = triangleDown;
|
|
|
|
sortedPkgArray = sortedStringPkgArray.concat(sortedNumPkgArray);
|
|
|
|
};
|
|
|
|
|
|
|
|
if (lastColumnName && lastColumnName != columnName){lastColumnName.lastElementChild.innerText = ""};
|
|
|
|
lastColumnName = columnName;
|
|
|
|
sortedPkgArray.unshift(["label"]);
|
|
|
|
sortedPkgArray.forEach((listing) => {
|
|
|
|
i++;
|
|
|
|
let rule = "." + listing[0] + " { grid-row: " + i + "; }";
|
|
|
|
styleSheet.insertRule(rule);
|
|
|
|
});
|
2022-07-29 01:23:57 +02:00
|
|
|
addedCSSRules.forEach(rule => styleSheet.insertRule(rule));
|
2022-07-29 01:23:55 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
function expandField(fieldId){
|
|
|
|
const field = document.getElementById(fieldId);
|
|
|
|
const fieldText = field.firstElementChild.innerText;
|
|
|
|
const fieldTotal = fieldText.split(' ')[2];
|
|
|
|
|
|
|
|
if (fieldText == "see all " + fieldTotal + triangleDown){
|
|
|
|
field.firstElementChild.innerText = "see less " + fieldTotal + triangleUp;
|
|
|
|
field.style.height = "auto";
|
|
|
|
} else {
|
|
|
|
field.firstElementChild.innerText = "see all " + fieldTotal + triangleDown;
|
|
|
|
field.style.height = "200px";
|
|
|
|
}
|
2022-07-28 04:14:44 +02:00
|
|
|
};
|
2022-07-22 21:15:58 +02:00
|
|
|
</script>
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2022-07-22 21:15:58 +02:00
|
|
|
<style>
|
2020-12-04 16:45:57 +01:00
|
|
|
|
2022-07-29 01:23:55 +02:00
|
|
|
.see-more{
|
|
|
|
display: none;
|
|
|
|
}
|
|
|
|
|
|
|
|
.label, .see-more {
|
2022-07-22 21:15:58 +02:00
|
|
|
position: sticky;
|
|
|
|
top: 1px;
|
2020-12-04 16:45:57 +01:00
|
|
|
}
|
2022-07-22 21:15:58 +02:00
|
|
|
.label{
|
2022-07-29 01:23:55 +02:00
|
|
|
z-index: 1;
|
2022-07-22 21:15:58 +02:00
|
|
|
background: white;
|
|
|
|
padding: 10px 2px 10px 2px;
|
2020-12-04 16:45:57 +01:00
|
|
|
}
|
2022-07-22 21:15:58 +02:00
|
|
|
#package-grid, #results-grid {
|
|
|
|
display: grid;
|
|
|
|
grid-gap: 2px;
|
2022-11-02 11:34:27 +01:00
|
|
|
grid-template-columns: min-content 1fr repeat(12, min-content);
|
2020-12-04 16:46:00 +01:00
|
|
|
}
|
2022-07-22 21:15:58 +02:00
|
|
|
#results-grid {
|
|
|
|
grid-template-columns: 3fr 1fr;
|
2020-12-04 16:46:00 +01:00
|
|
|
}
|
2022-07-22 21:15:58 +02:00
|
|
|
.data {
|
|
|
|
border: solid 1px gray;
|
2020-12-04 16:46:00 +01:00
|
|
|
}
|
2022-07-22 21:15:58 +02:00
|
|
|
.centered {
|
|
|
|
text-align: center;
|
2021-04-22 21:45:57 +02:00
|
|
|
}
|
2024-02-13 13:07:14 +01:00
|
|
|
|
|
|
|
.current_version {
|
|
|
|
overflow: scroll;
|
|
|
|
width: 21ch;
|
|
|
|
padding: 10px 2px 10px 2px;
|
|
|
|
}
|
|
|
|
|
2022-07-22 21:15:58 +02:00
|
|
|
.correct, .nopatches, .good_url, .version-good, .cpe-ok, .cve-ok {
|
|
|
|
background: #d2ffc4;
|
|
|
|
}
|
2022-07-27 17:41:11 +02:00
|
|
|
.wrong, .lotsofpatches, .invalid_url, .version-needs-update, .cpe-nok, .cve-nok {
|
|
|
|
background: #ff9a69;
|
|
|
|
}
|
2023-09-01 21:27:10 +02:00
|
|
|
.somepatches, .somewarnings, .missing_url, .version-unknown, .cpe-unknown, .cve-unknown {
|
2022-07-22 21:15:58 +02:00
|
|
|
background: #ffd870;
|
|
|
|
}
|
|
|
|
.cve_ignored, .version-error {
|
|
|
|
background: #ccc;
|
|
|
|
}
|
2021-04-22 21:45:57 +02:00
|
|
|
|
2009-10-28 00:28:40 +01:00
|
|
|
</style>
|
2022-07-22 21:15:58 +02:00
|
|
|
|
2012-07-31 21:32:25 +02:00
|
|
|
<title>Statistics of Buildroot packages</title>
|
2022-07-22 21:15:58 +02:00
|
|
|
|
2009-10-28 00:28:40 +01:00
|
|
|
</head>
|
|
|
|
|
2022-07-22 21:15:58 +02:00
|
|
|
<body>
|
|
|
|
|
2022-08-06 23:56:40 +02:00
|
|
|
<a href="#results">Results</a><br/>
|
2009-10-28 00:28:40 +01:00
|
|
|
|
2022-07-23 19:45:59 +02:00
|
|
|
""" # noqa - tabs and spaces
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2017-07-06 03:36:31 +02:00
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
html_footer = """
|
2022-07-22 21:15:58 +02:00
|
|
|
</body>
|
2018-04-04 22:05:33 +02:00
|
|
|
</html>
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
|
|
|
def infra_str(infra_list):
|
|
|
|
if not infra_list:
|
|
|
|
return "Unknown"
|
|
|
|
elif len(infra_list) == 1:
|
|
|
|
return "<b>%s</b><br/>%s" % (infra_list[0][1], infra_list[0][0])
|
|
|
|
elif infra_list[0][1] == infra_list[1][1]:
|
|
|
|
return "<b>%s</b><br/>%s + %s" % \
|
|
|
|
(infra_list[0][1], infra_list[0][0], infra_list[1][0])
|
|
|
|
else:
|
|
|
|
return "<b>%s</b> (%s)<br/><b>%s</b> (%s)" % \
|
|
|
|
(infra_list[0][1], infra_list[0][0],
|
|
|
|
infra_list[1][1], infra_list[1][0])
|
|
|
|
|
|
|
|
|
|
|
|
def boolean_str(b):
|
|
|
|
if b:
|
|
|
|
return "Yes"
|
|
|
|
else:
|
|
|
|
return "No"
|
|
|
|
|
|
|
|
|
|
|
|
def dump_html_pkg(f, pkg):
|
2022-07-28 04:14:43 +02:00
|
|
|
pkg_css_class = pkg.path.replace("/", "_")[:-3]
|
2022-11-02 11:34:27 +01:00
|
|
|
f.write(f'<div id="tree__{pkg_css_class}" \
|
|
|
|
class="tree data _{pkg_css_class}">{pkg.tree}</div>\n')
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f'<div id="package__{pkg_css_class}" \
|
|
|
|
class="package data _{pkg_css_class}">{pkg.path}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
# Patch count
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'patch_count__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered patch_count data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2018-04-04 22:05:33 +02:00
|
|
|
if pkg.patch_count == 0:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("nopatches")
|
2018-04-04 22:05:33 +02:00
|
|
|
elif pkg.patch_count < 5:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("somepatches")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("lotsofpatches")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)} \
|
|
|
|
">{str(pkg.patch_count)}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# Infrastructure
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'infrastructure__{pkg_css_class}'
|
2018-04-04 22:05:33 +02:00
|
|
|
infra = infra_str(pkg.infras)
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered infrastructure data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2018-04-04 22:05:33 +02:00
|
|
|
if infra == "Unknown":
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("wrong")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("correct")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)} \
|
|
|
|
">{infra_str(pkg.infras)}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# License
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'license__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered license data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('license'):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("correct")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("wrong")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)} \
|
|
|
|
">{boolean_str(pkg.is_status_ok("license"))}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# License files
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'license_files__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered license_files data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('license-files'):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("correct")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("wrong")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)} \
|
|
|
|
">{boolean_str(pkg.is_status_ok("license-files"))}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# Hash
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'hash_file__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered hash_file data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.is_status_ok('hash'):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("correct")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("wrong")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)} \
|
|
|
|
">{boolean_str(pkg.is_status_ok("hash"))}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
# Current version
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'current_version__{pkg_css_class}'
|
2024-02-13 13:07:14 +01:00
|
|
|
current_version = pkg.current_version
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" \
|
|
|
|
class="centered current_version data _{pkg_css_class}">{current_version}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
# Latest version
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'latest_version__{pkg_css_class}'
|
2024-02-25 23:05:44 +01:00
|
|
|
div_class = ["centered"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("latest_version data")
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['status'] == RM_API_STATUS_ERROR:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("version-error")
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['version'] is None:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("version-unknown")
|
2020-03-07 08:56:22 +01:00
|
|
|
elif pkg.latest_version['version'] != pkg.current_version:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("version-needs-update")
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("version-good")
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['status'] == RM_API_STATUS_ERROR:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
latest_version_text = "<b>Error</b>"
|
2020-03-07 08:56:22 +01:00
|
|
|
elif pkg.latest_version['status'] == RM_API_STATUS_NOT_FOUND:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
latest_version_text = "<b>Not found</b>"
|
|
|
|
else:
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['version'] is None:
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
latest_version_text = "<b>Found, but no version</b>"
|
|
|
|
else:
|
2022-08-27 22:58:18 +02:00
|
|
|
latest_version_text = f"""<a href="https://release-monitoring.org/project/{pkg.latest_version['id']}">""" \
|
|
|
|
f"""<b>{str(pkg.latest_version['version'])}</b></a>"""
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
|
|
|
latest_version_text += "<br/>"
|
|
|
|
|
2020-03-07 08:56:22 +01:00
|
|
|
if pkg.latest_version['status'] == RM_API_STATUS_FOUND_BY_DISTRO:
|
2022-08-27 22:58:18 +02:00
|
|
|
latest_version_text += 'found by <a href="https://release-monitoring.org/distro/Buildroot/">distro</a>'
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
else:
|
|
|
|
latest_version_text += "found by guess"
|
|
|
|
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">{latest_version_text}</div>\n')
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
# Warnings
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'warnings__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered warnings data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2018-04-04 22:05:33 +02:00
|
|
|
if pkg.warnings == 0:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("correct")
|
2023-09-01 21:27:10 +02:00
|
|
|
elif pkg.warnings < 5:
|
|
|
|
div_class.append("somewarnings")
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("wrong")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">{pkg.warnings}</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2018-10-02 04:37:28 +02:00
|
|
|
# URL status
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'upstream_url__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered upstream_url data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2020-03-07 08:56:26 +01:00
|
|
|
url_str = pkg.status['url'][1]
|
|
|
|
if pkg.status['url'][0] in ("error", "warning"):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("missing_url")
|
2020-03-07 08:56:26 +01:00
|
|
|
if pkg.status['url'][0] == "error":
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("invalid_url")
|
2022-08-06 23:56:41 +02:00
|
|
|
url_str = f"""<a href="{pkg.url}">{pkg.status['url'][1]}</a>"""
|
2018-10-02 04:37:28 +02:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("good_url")
|
2022-08-06 23:56:41 +02:00
|
|
|
url_str = f'<a href="{pkg.url}">Link</a>'
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">{url_str}</div>\n')
|
2018-10-02 04:37:28 +02:00
|
|
|
|
2020-02-15 13:44:16 +01:00
|
|
|
# CVEs
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'cves__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered cves data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2022-07-29 01:23:55 +02:00
|
|
|
if len(pkg.cves) > 10:
|
|
|
|
div_class.append("collapse")
|
2021-01-07 14:39:39 +01:00
|
|
|
if pkg.is_status_ok("cve"):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cve-ok")
|
2021-01-07 14:39:39 +01:00
|
|
|
elif pkg.is_status_error("cve"):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cve-nok")
|
2021-05-19 04:46:38 +02:00
|
|
|
elif pkg.is_status_na("cve") and not pkg.is_actual_package:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cve-ok")
|
2020-02-15 13:44:16 +01:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cve-unknown")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">\n')
|
2022-07-29 01:23:55 +02:00
|
|
|
if len(pkg.cves) > 10:
|
|
|
|
cve_total = len(pkg.cves) + 1
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div onclick="expandField(\'{data_field_id}\')" \
|
|
|
|
class="see-more centered cve_ignored">see all ({cve_total}) ▾</div>\n')
|
2021-01-07 14:39:39 +01:00
|
|
|
if pkg.is_status_error("cve"):
|
2024-02-25 23:05:37 +01:00
|
|
|
for cve in cvecheck.CVE.sort_id(pkg.cves):
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(f' <a href="https://security-tracker.debian.org/tracker/{cve}">{cve}</a><br/>\n')
|
2024-02-25 23:05:37 +01:00
|
|
|
for cve in cvecheck.CVE.sort_id(pkg.unsure_cves):
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(f' <a href="https://security-tracker.debian.org/tracker/{cve}">{cve} <i>(unsure)</i></a><br/>\n')
|
2021-01-07 14:39:39 +01:00
|
|
|
elif pkg.is_status_na("cve"):
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(f""" {pkg.status['cve'][1]}""")
|
2021-01-07 14:39:39 +01:00
|
|
|
else:
|
|
|
|
f.write(" N/A\n")
|
2022-07-22 21:15:58 +02:00
|
|
|
f.write(" </div>\n")
|
2020-02-15 13:44:16 +01:00
|
|
|
|
2021-04-22 21:45:57 +02:00
|
|
|
# CVEs Ignored
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'ignored_cves__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["centered data ignored_cves"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2021-04-22 21:45:57 +02:00
|
|
|
if pkg.ignored_cves:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cve_ignored")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">\n')
|
2021-04-22 21:45:57 +02:00
|
|
|
for ignored_cve in pkg.ignored_cves:
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(f' <a href="https://security-tracker.debian.org/tracker/{ignored_cve}">{ignored_cve}</a><br/>\n')
|
2022-07-22 21:15:58 +02:00
|
|
|
f.write(" </div>\n")
|
2021-04-22 21:45:57 +02:00
|
|
|
|
2020-12-04 16:45:57 +01:00
|
|
|
# CPE ID
|
2022-07-28 04:14:43 +02:00
|
|
|
data_field_id = f'cpe_id__{pkg_css_class}'
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class = ["left cpe_id data"]
|
2022-07-28 04:14:43 +02:00
|
|
|
div_class.append(f'_{pkg_css_class}')
|
2021-01-31 14:38:16 +01:00
|
|
|
if pkg.is_status_ok("cpe"):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cpe-ok")
|
2021-01-31 14:38:16 +01:00
|
|
|
elif pkg.is_status_error("cpe"):
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cpe-nok")
|
2021-05-19 04:46:38 +02:00
|
|
|
elif pkg.is_status_na("cpe") and not pkg.is_actual_package:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cpe-ok")
|
2020-12-04 16:45:57 +01:00
|
|
|
else:
|
2022-07-22 21:15:58 +02:00
|
|
|
div_class.append("cpe-unknown")
|
2022-08-06 23:56:40 +02:00
|
|
|
f.write(f' <div id="{data_field_id}" class="{" ".join(div_class)}">\n')
|
2021-01-31 14:38:16 +01:00
|
|
|
if pkg.cpeid:
|
2022-08-03 17:33:24 +02:00
|
|
|
cpeid_begin = ":".join(pkg.cpeid.split(":")[0:4]) + ":"
|
|
|
|
cpeid_formatted = pkg.cpeid.replace(cpeid_begin, cpeid_begin + "<wbr>")
|
|
|
|
f.write(" <code>%s</code>\n" % cpeid_formatted)
|
2021-01-31 14:38:16 +01:00
|
|
|
if not pkg.is_status_ok("cpe"):
|
2021-05-19 04:46:38 +02:00
|
|
|
if pkg.is_actual_package and pkg.current_version:
|
|
|
|
if pkg.cpeid:
|
2022-08-27 22:58:18 +02:00
|
|
|
f.write(f""" <br/>{pkg.status['cpe'][1]} <a href="https://nvd.nist.gov/products/cpe/search/results?"""
|
|
|
|
f"""namingFormat=2.3&keyword={":".join(pkg.cpeid.split(":")[0:5])}">(Search)</a>\n""")
|
2021-05-19 04:46:38 +02:00
|
|
|
else:
|
2022-08-27 22:58:18 +02:00
|
|
|
f.write(f""" {pkg.status['cpe'][1]} <a href="https://nvd.nist.gov/products/cpe/search/results?"""
|
|
|
|
f"""namingFormat=2.3&keyword={pkg.name}">(Search)</a>\n""")
|
2021-04-22 21:45:56 +02:00
|
|
|
else:
|
2021-05-19 04:46:38 +02:00
|
|
|
f.write(" %s\n" % pkg.status['cpe'][1])
|
2021-04-22 21:45:56 +02:00
|
|
|
|
2022-07-22 21:15:58 +02:00
|
|
|
f.write(" </div>\n")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
def dump_html_all_pkgs(f, packages):
|
|
|
|
f.write("""
|
2022-08-06 23:56:40 +02:00
|
|
|
<div id="package-grid">
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 1;" onclick="sortGrid(this.id)" id="tree"
|
|
|
|
class="tree data label"><span>Tree</span><span></span></div>
|
|
|
|
<div style="grid-column: 2;" onclick="sortGrid(this.id)" id="package"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="package data label"><span>Package</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 3;" onclick="sortGrid(this.id)" id="patch_count"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered patch_count data label"><span>Patch count</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 4;" onclick="sortGrid(this.id)" id="infrastructure"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered infrastructure data label">Infrastructure<span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 5;" onclick="sortGrid(this.id)" id="license"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered license data label"><span>License</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 6;" onclick="sortGrid(this.id)" id="license_files"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered license_files data label"><span>License files</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 7;" onclick="sortGrid(this.id)" id="hash_file"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered hash_file data label"><span>Hash file</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 8;" onclick="sortGrid(this.id)" id="current_version"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered current_version data label"><span>Current version</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 9;" onclick="sortGrid(this.id)" id="latest_version"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered latest_version data label"><span>Latest version</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 10;" onclick="sortGrid(this.id)" id="warnings"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered warnings data label"><span>Warnings</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 11;" onclick="sortGrid(this.id)" id="upstream_url"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered upstream_url data label"><span>Upstream URL</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 12;" onclick="sortGrid(this.id)" id="cves"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered cves data label"><span>CVEs</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 13;" onclick="sortGrid(this.id)" id="ignored_cves"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered ignored_cves data label"><span>CVEs Ignored</span><span></span></div>
|
2022-11-02 11:34:27 +01:00
|
|
|
<div style="grid-column: 14;" onclick="sortGrid(this.id)" id="cpe_id"
|
2022-08-06 23:56:40 +02:00
|
|
|
class="centered cpe_id data label"><span>CPE ID</span><span></span></div>
|
2018-04-04 22:05:33 +02:00
|
|
|
""")
|
|
|
|
for pkg in sorted(packages):
|
|
|
|
dump_html_pkg(f, pkg)
|
2022-07-22 21:15:58 +02:00
|
|
|
f.write("</div>")
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
def dump_html_stats(f, stats):
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<a id="results"></a>\n')
|
|
|
|
f.write('<div class="data" id="results-grid">\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
infras = [infra[6:] for infra in stats.keys() if infra.startswith("infra-")]
|
|
|
|
for infra in infras:
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages using the <i>%s</i> infrastructure</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
(infra, stats["infra-%s" % infra]))
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages having license information</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["license"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages not having license information</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["no-license"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages having license files information</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["license-files"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages not having license files information</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["no-license-files"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages having a hash file</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["hash"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Packages not having a hash file</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["no-hash"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write(' <div class="data">Total number of patches</div><div class="data">%s</div>\n' %
|
2018-04-04 22:05:33 +02:00
|
|
|
stats["patches"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages having a mapping on <i>release-monitoring.org</i></div><div class="data">%s</div>\n' %
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["rmo-mapping"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages lacking a mapping on <i>release-monitoring.org</i></div><div class="data">%s</div>\n' %
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["rmo-no-mapping"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages that are up-to-date</div><div class="data">%s</div>\n' %
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["version-uptodate"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages that are not up-to-date</div><div class="data">%s</div>\n' %
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["version-not-uptodate"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages with no known upstream version</div><div class="data">%s</div>\n' %
|
support/scripts/pkg-stats: add latest upstream version information
This commit adds fetching the latest upstream version of each package
from release-monitoring.org.
The fetching process first tries to use the package mappings of the
"Buildroot" distribution [1]. This mapping mechanism allows to tell
release-monitoring.org what is the name of a package in a given
distribution/build-system. For example, the package xutil_util-macros
in Buildroot is named xorg-util-macros on release-monitoring.org. This
mapping can be seen in the section "Mappings" of
https://release-monitoring.org/project/15037/.
If there is no mapping, then it does a regular search, and within the
search results, looks for a package whose name matches the Buildroot
name.
Even though fetching from release-monitoring.org is a bit slow, using
multiprocessing.Pool has proven to not be reliable, with some requests
ending up with an exception. So we keep a serialized approach, but
with a single HTTPSConnectionPool() for all queries. Long term, we
hope to be able to use a database dump of release-monitoring.org
instead.
From an output point of view, the latest version column:
- Is green when the version in Buildroot matches the latest upstream
version
- Is orange when the latest upstream version is unknown because the
package was not found on release-monitoring.org
- Is red when the version in Buildroot doesn't match the latest
upstream version. Note that we are not doing anything smart here:
we are just testing if the strings are equal or not.
- The cell contains the link to the project on release-monitoring.org
if found.
- The cell indicates if the match was done using a distro mapping, or
through a regular search.
[1] https://release-monitoring.org/distro/Buildroot/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 16:19:59 +01:00
|
|
|
stats["version-unknown"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages affected by CVEs</div><div class="data">%s</div>\n' %
|
2020-02-15 13:44:16 +01:00
|
|
|
stats["pkg-cves"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Total number of CVEs affecting all packages</div><div class="data">%s</div>\n' %
|
2020-02-15 13:44:16 +01:00
|
|
|
stats["total-cves"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages affected by unsure CVEs</div><div class="data">%s</div>\n' %
|
2022-01-09 16:00:51 +01:00
|
|
|
stats["pkg-unsure-cves"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Total number of unsure CVEs affecting all packages</div><div class="data">%s</div>\n' %
|
2022-01-09 16:00:51 +01:00
|
|
|
stats["total-unsure-cves"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages with CPE ID</div><div class="data">%s</div>\n' %
|
2020-12-04 16:45:57 +01:00
|
|
|
stats["cpe-id"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('<div class="data">Packages without CPE ID</div><div class="data">%s</div>\n' %
|
2020-12-04 16:45:57 +01:00
|
|
|
stats["no-cpe-id"])
|
2022-08-06 23:56:41 +02:00
|
|
|
f.write('</div>\n')
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
2019-08-01 11:07:27 +02:00
|
|
|
def dump_html_gen_info(f, date, commit):
|
2018-04-04 22:05:33 +02:00
|
|
|
# Updated on Mon Feb 19 08:12:08 CET 2018, Git commit aa77030b8f5e41f1c53eb1c1ad664b8c814ba032
|
2019-07-19 15:06:30 +02:00
|
|
|
f.write("<p><i>Updated on %s, git commit %s</i></p>\n" % (str(date), commit))
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
2019-07-19 15:06:30 +02:00
|
|
|
def dump_html(packages, stats, date, commit, output):
|
2018-04-04 22:05:33 +02:00
|
|
|
with open(output, 'w') as f:
|
|
|
|
f.write(html_header)
|
|
|
|
dump_html_all_pkgs(f, packages)
|
|
|
|
dump_html_stats(f, stats)
|
2019-08-01 11:07:27 +02:00
|
|
|
dump_html_gen_info(f, date, commit)
|
2018-04-04 22:05:33 +02:00
|
|
|
f.write(html_footer)
|
|
|
|
|
|
|
|
|
2020-03-07 08:56:29 +01:00
|
|
|
def dump_json(packages, defconfigs, stats, date, commit, output):
|
2019-07-19 15:06:29 +02:00
|
|
|
# Format packages as a dictionnary instead of a list
|
|
|
|
# Exclude local field that does not contains real date
|
2022-11-02 11:34:27 +01:00
|
|
|
excluded_fields = ['url_worker', 'name', 'tree_path']
|
2019-07-19 15:06:29 +02:00
|
|
|
pkgs = {
|
|
|
|
pkg.name: {
|
|
|
|
k: v
|
|
|
|
for k, v in pkg.__dict__.items()
|
|
|
|
if k not in excluded_fields
|
|
|
|
} for pkg in packages
|
|
|
|
}
|
2020-03-07 08:56:29 +01:00
|
|
|
defconfigs = {
|
|
|
|
d.name: {
|
|
|
|
k: v
|
|
|
|
for k, v in d.__dict__.items()
|
|
|
|
} for d in defconfigs
|
|
|
|
}
|
2019-07-19 15:06:29 +02:00
|
|
|
# Aggregate infrastructures into a single dict entry
|
|
|
|
statistics = {
|
|
|
|
k: v
|
|
|
|
for k, v in stats.items()
|
|
|
|
if not k.startswith('infra-')
|
|
|
|
}
|
|
|
|
statistics['infra'] = {k[6:]: v for k, v in stats.items() if k.startswith('infra-')}
|
|
|
|
# The actual structure to dump, add commit and date to it
|
|
|
|
final = {'packages': pkgs,
|
|
|
|
'stats': statistics,
|
2020-03-07 08:56:29 +01:00
|
|
|
'defconfigs': defconfigs,
|
2020-03-07 08:56:32 +01:00
|
|
|
'package_status_checks': Package.status_checks,
|
2019-07-19 15:06:30 +02:00
|
|
|
'commit': commit,
|
|
|
|
'date': str(date)}
|
2019-07-19 15:06:29 +02:00
|
|
|
|
|
|
|
with open(output, 'w') as f:
|
|
|
|
json.dump(final, f, indent=2, separators=(',', ': '))
|
|
|
|
f.write('\n')
|
|
|
|
|
|
|
|
|
2020-03-07 11:37:05 +01:00
|
|
|
def resolvepath(path):
|
2020-07-12 21:23:13 +02:00
|
|
|
return os.path.abspath(os.path.expanduser(path))
|
2020-03-07 11:37:05 +01:00
|
|
|
|
|
|
|
|
2022-01-09 16:58:45 +01:00
|
|
|
def list_str(values):
|
|
|
|
return values.split(',')
|
|
|
|
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def parse_args():
|
|
|
|
parser = argparse.ArgumentParser()
|
2019-07-19 15:06:29 +02:00
|
|
|
output = parser.add_argument_group('output', 'Output file(s)')
|
2020-03-07 11:37:05 +01:00
|
|
|
output.add_argument('--html', dest='html', type=resolvepath,
|
2018-04-04 22:05:33 +02:00
|
|
|
help='HTML output file')
|
2020-03-07 11:37:05 +01:00
|
|
|
output.add_argument('--json', dest='json', type=resolvepath,
|
2019-07-19 15:06:29 +02:00
|
|
|
help='JSON output file')
|
2019-07-19 15:06:28 +02:00
|
|
|
packages = parser.add_mutually_exclusive_group()
|
support/scripts/pkg-stats: support generating stats based on configured packages
pkg-stats was initially a Buildroot maintenance oriented tool: it was
designed to examine all Buildroot packages and provide
statistics/details about them.
However, it turns out that a number of details provided by pkg-stats,
especially CVEs, are relevant also for Buildroot users, who would like
to check regularly if their specific Buildroot configuration is
affected by CVEs or not, and possibly check if all packages have
license information, license files, etc.
The cve-checker script was recently introduced to provide an output
relatively similar to pkg-stats, but focused on CVEs only.
But in fact, its main difference is on the set of packages that we
consider: pkg-stats considers all packages, while cve-checker uses
"make show-info" to only consider packages enabled in the current
configuration.
So, this commit introduces a -c option to pkg-stats, to tell pkg-stats
to generate its output based on the list of configured packages. -c is
mutually exclusive with the -p option (explicit list of packages) and
-n option (a number of packages, picked randomly).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-11-05 17:30:20 +01:00
|
|
|
packages.add_argument('-c', dest='configpackages', action='store_true',
|
|
|
|
help='Apply to packages enabled in current configuration')
|
2019-07-19 15:06:28 +02:00
|
|
|
packages.add_argument('-n', dest='npackages', type=int, action='store',
|
2019-08-01 17:12:43 +02:00
|
|
|
help='Number of packages')
|
2019-07-19 15:06:28 +02:00
|
|
|
packages.add_argument('-p', dest='packages', action='store',
|
2019-08-01 17:12:43 +02:00
|
|
|
help='List of packages (comma separated)')
|
2020-02-15 13:44:16 +01:00
|
|
|
parser.add_argument('--nvd-path', dest='nvd_path',
|
2020-03-07 11:37:05 +01:00
|
|
|
help='Path to the local NVD database', type=resolvepath)
|
2022-01-09 16:58:45 +01:00
|
|
|
parser.add_argument('--disable', type=list_str,
|
2024-02-07 16:35:17 +01:00
|
|
|
help='Features to disable, comma-separated (cve, upstream, url, warning)',
|
2022-01-09 16:58:45 +01:00
|
|
|
default=[])
|
2019-07-19 15:06:29 +02:00
|
|
|
args = parser.parse_args()
|
|
|
|
if not args.html and not args.json:
|
|
|
|
parser.error('at least one of --html or --json (or both) is required')
|
|
|
|
return args
|
2018-04-04 22:05:33 +02:00
|
|
|
|
2021-01-05 23:23:31 +01:00
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
def __main__():
|
2020-11-19 15:53:51 +01:00
|
|
|
global cvecheck
|
|
|
|
|
2018-04-04 22:05:33 +02:00
|
|
|
args = parse_args()
|
2020-11-19 15:53:51 +01:00
|
|
|
|
|
|
|
if args.nvd_path:
|
|
|
|
import cve as cvecheck
|
|
|
|
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
show_info_js = None
|
2018-04-04 22:05:33 +02:00
|
|
|
if args.packages:
|
|
|
|
package_list = args.packages.split(",")
|
support/scripts/pkg-stats: support generating stats based on configured packages
pkg-stats was initially a Buildroot maintenance oriented tool: it was
designed to examine all Buildroot packages and provide
statistics/details about them.
However, it turns out that a number of details provided by pkg-stats,
especially CVEs, are relevant also for Buildroot users, who would like
to check regularly if their specific Buildroot configuration is
affected by CVEs or not, and possibly check if all packages have
license information, license files, etc.
The cve-checker script was recently introduced to provide an output
relatively similar to pkg-stats, but focused on CVEs only.
But in fact, its main difference is on the set of packages that we
consider: pkg-stats considers all packages, while cve-checker uses
"make show-info" to only consider packages enabled in the current
configuration.
So, this commit introduces a -c option to pkg-stats, to tell pkg-stats
to generate its output based on the list of configured packages. -c is
mutually exclusive with the -p option (explicit list of packages) and
-n option (a number of packages, picked randomly).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-11-05 17:30:20 +01:00
|
|
|
elif args.configpackages:
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
show_info_js = get_show_info_js()
|
|
|
|
package_list = set([v["name"] for v in show_info_js.values() if 'name' in v])
|
2018-04-04 22:05:33 +02:00
|
|
|
else:
|
|
|
|
package_list = None
|
2024-02-28 23:44:59 +01:00
|
|
|
date = datetime.datetime.now(datetime.timezone.utc)
|
2020-11-05 17:30:19 +01:00
|
|
|
commit = subprocess.check_output(['git', '-C', brpath,
|
|
|
|
'rev-parse',
|
2020-03-01 22:18:48 +01:00
|
|
|
'HEAD']).splitlines()[0].decode()
|
2018-05-18 15:05:00 +02:00
|
|
|
print("Build package list ...")
|
2022-11-02 11:34:27 +01:00
|
|
|
all_trees = get_trees()
|
|
|
|
packages = get_pkglist(all_trees, args.npackages, package_list)
|
2020-03-07 08:56:24 +01:00
|
|
|
print("Getting developers ...")
|
2020-11-19 15:53:54 +01:00
|
|
|
developers = parse_developers()
|
2020-03-07 08:56:29 +01:00
|
|
|
print("Build defconfig list ...")
|
|
|
|
defconfigs = get_defconfig_list()
|
|
|
|
for d in defconfigs:
|
|
|
|
d.set_developers(developers)
|
2018-05-18 15:05:00 +02:00
|
|
|
print("Getting package make info ...")
|
2018-04-04 22:05:33 +02:00
|
|
|
package_init_make_info()
|
2018-05-18 15:05:00 +02:00
|
|
|
print("Getting package details ...")
|
2018-04-04 22:05:33 +02:00
|
|
|
for pkg in packages:
|
support/scripts/pkg-stats: tweak infras field when running with -c
When we use the statistics output to generate a CVE/CPE customer
report showing whether a product is affected by CVEs, we are primarily
interested in whether they are relevant to the target
system. Currently we cannot see if the package is configured for the
build (infra==host) and/or the target system (infra==target).
Therefore this commit extends the pkg-stats script to leverage the
information available in "make show-info" output to tweak the list of
package infrastructures for each package. Thanks to this commit, the
script now has a more consistent behavior:
* When pkg-stats is run without -c, i.e without a defined Buildroot
configuration, it continues to operate as it did, i.e it lists all
package infrastructures supported by the package (such as autotools
host+target, or kconfig target, etc.)
* When pkg-stats is run with -c, i.e with a defined Buildroot
configuration which defines the list of packages that should be
considered, then for each package it now lists only the package
infrastructures used by the package in that current
configuration. For example if you have a package with a host and
target variant, but only the host variant is used in your
configuration, now the pkg-stats output will only say that the host
variant of this package is used;
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
[Thomas: pretty much rework the entire implementation and how the
result is presented.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-06-24 14:57:03 +02:00
|
|
|
pkg.set_infra(show_info_js)
|
2018-04-04 22:05:33 +02:00
|
|
|
pkg.set_license()
|
|
|
|
pkg.set_hash_info()
|
|
|
|
pkg.set_patch_count()
|
2022-04-02 16:15:28 +02:00
|
|
|
if "warnings" not in args.disable:
|
|
|
|
pkg.set_check_package_warnings()
|
2018-04-04 22:05:33 +02:00
|
|
|
pkg.set_current_version()
|
2020-12-04 16:45:57 +01:00
|
|
|
pkg.set_cpeid()
|
2018-10-02 04:37:28 +02:00
|
|
|
pkg.set_url()
|
2021-02-11 10:29:10 +01:00
|
|
|
pkg.set_ignored_cves()
|
2020-03-07 08:56:24 +01:00
|
|
|
pkg.set_developers(developers)
|
2022-01-09 21:00:56 +01:00
|
|
|
if "url" not in args.disable:
|
2022-01-09 16:58:45 +01:00
|
|
|
print("Checking URL status")
|
|
|
|
loop = asyncio.get_event_loop()
|
|
|
|
loop.run_until_complete(check_package_urls(packages))
|
2022-01-09 21:00:56 +01:00
|
|
|
if "upstream" not in args.disable:
|
2022-01-09 16:58:45 +01:00
|
|
|
print("Getting latest versions ...")
|
|
|
|
loop = asyncio.get_event_loop()
|
|
|
|
loop.run_until_complete(check_package_latest_version(packages))
|
2022-01-09 21:00:56 +01:00
|
|
|
if "cve" not in args.disable and args.nvd_path:
|
2020-02-15 13:44:16 +01:00
|
|
|
print("Checking packages CVEs")
|
support/scripts/{pkg-stats, cve.py}: support CPE ID based matching
This commit modifies cve.py, as well as its users cve-checker and
pkg-stats to support CPE ID based matching, for packages that have CPE
ID information.
One of the non-trivial thing is that we can't simply iterate over all
CVEs, and then iterate over all our packages to see which packages
have CPE ID information that match the CPEs affected by the
CVE. Indeed, this is an O(n^2) operation.
So instead, we do a pre-filtering of packages potentially affected. In
check_package_cves(), we build a cpe_product_pkgs dict that associates
a CPE product name to the packages that have this CPE product
name. The CPE product name is either derived from the CPE information
provided by the package if available, and otherwise we use the package
name, which is what was used prior to this patch.
And then, when we look at CVEs, we only consider the packages that
have a CPE product name matching the CPE products affected by the
CVEs. This is done in check_package_cve_affects().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2020-12-04 16:45:58 +01:00
|
|
|
check_package_cves(args.nvd_path, packages)
|
2018-05-18 15:05:00 +02:00
|
|
|
print("Calculate stats")
|
2018-04-04 22:05:33 +02:00
|
|
|
stats = calculate_stats(packages)
|
2019-07-19 15:06:29 +02:00
|
|
|
if args.html:
|
|
|
|
print("Write HTML")
|
2019-07-19 15:06:30 +02:00
|
|
|
dump_html(packages, stats, date, commit, args.html)
|
2019-07-19 15:06:29 +02:00
|
|
|
if args.json:
|
|
|
|
print("Write JSON")
|
2020-03-07 08:56:29 +01:00
|
|
|
dump_json(packages, defconfigs, stats, date, commit, args.json)
|
2018-04-04 22:05:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
__main__()
|