|author||dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>||Sat Dec 31 18:14:38 2022 +0000|
|committer||GitHub <firstname.lastname@example.org>||Sat Dec 31 18:14:38 2022 +0000|
Bump json5, @vue/cli-plugin-babel and stylus-loader in /ui Bumps [json5](https://github.com/json5/json5) to 2.2.3 and updates ancestor dependencies [json5](https://github.com/json5/json5), [@vue/cli-plugin-babel](https://github.com/vuejs/vue-cli/tree/HEAD/packages/@vue/cli-plugin-babel) and [stylus-loader](https://github.com/webpack-contrib/stylus-loader). These dependencies need to be updated together. Updates `json5` from 2.2.1 to 2.2.3 - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](https://github.com/json5/json5/compare/v2.2.1...v2.2.3) Updates `@vue/cli-plugin-babel` from 3.12.1 to 5.0.8 - [Release notes](https://github.com/vuejs/vue-cli/releases) - [Changelog](https://github.com/vuejs/vue-cli/blob/dev/CHANGELOG.md) - [Commits](https://github.com/vuejs/vue-cli/commits/v5.0.8/packages/@vue/cli-plugin-babel) Updates `stylus-loader` from 3.0.2 to 7.1.0 - [Release notes](https://github.com/webpack-contrib/stylus-loader/releases) - [Changelog](https://github.com/webpack-contrib/stylus-loader/blob/master/CHANGELOG.md) - [Commits](https://github.com/webpack-contrib/stylus-loader/compare/v3.0.2...v7.1.0) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect - dependency-name: "@vue/cli-plugin-babel" dependency-type: direct:development - dependency-name: stylus-loader dependency-type: direct:development ... Signed-off-by: dependabot[bot] <email@example.com>
This is a simple project to track CVEs in the upstream linux kernel. Individual distro's (RHEL, Debian, Ubuntu, etc) often do a good job of tracking CVEs for their own kernels but this information is lacking for the upstream kernel. This project aims to help out with this void. The output was generated automatically through a set of tools that has not been fully tested or made public yet.
There are two ways to view/consume the data. The easiest is the web front end at www.linuxkernelcves.com. Here can you can view CVEs by stream or by CVE id. The second way is this github page. Here, the data is laid out in both JSON and text format.
Tracking, mitigating, and patching CVEs is just a small part of maintaining a secure kernel. Let me be clear, you can patch all known CVEs and still be vulnerable. Some risk can be mitigated through properly configuring your kernel/system. I suggest you visit the Kernel Self Protection Project and other kernel security pages for more information.
Below is a list of definitions for certain strings you might see in a stream report. The only CVEs that should appear in the stream document are ones that potentially affect that stream. (ie. ones that were not fixed prior to the first release version and were not introduced after the release version) If no fixing commit is known for a CVE, then by default it is assumed to present in all streams after it was introduced.
The process for generating these documents is focused on being as automated as possible. Below is the general outline of steps.
The bulk of the data is autogenerated or pulled from other open sources. While every effort is taken to ensure its accuracy, no promise of absolute accuracy can be made. If you think a CVE is missing or is not completely accurate, please fill out an issue to have the data looked at and changed. The eventual goal would be to have a community curated list of CVEs along with when the code was introduced and when it was fixed.
Want to contribute? Great!
Any additions/removals/updates to the data should start with an Issue. Please be as accurate and complete as possible when requesting a change so the information can be validated as quickly as possible.
All code changes or enchancements must be done through a Pull Request to the staging branch. No PRs directly to master will be accepted.