Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package cargo-audit-advisory-db for
openSUSE:Factory checked in at 2025-03-11 20:45:05
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/cargo-audit-advisory-db (Old)
and /work/SRC/openSUSE:Factory/.cargo-audit-advisory-db.new.19136 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "cargo-audit-advisory-db"
Tue Mar 11 20:45:05 2025 rev:45 rq:1251915 version:20250304
Changes:
--------
---
/work/SRC/openSUSE:Factory/cargo-audit-advisory-db/cargo-audit-advisory-db.changes
2025-02-04 18:14:39.204786752 +0100
+++
/work/SRC/openSUSE:Factory/.cargo-audit-advisory-db.new.19136/cargo-audit-advisory-db.changes
2025-03-11 20:46:10.036322310 +0100
@@ -1,0 +2,15 @@
+Tue Mar 04 01:06:21 UTC 2025 - william.br...@suse.com
+
+- Update to version 20250304:
+ * openh264-sys is not a notice, it's a vuln (#2234)
+ * Assigned RUSTSEC-2025-0008 to openh264-sys2 (#2232)
+ * `openh264-sys2` upstream heap overflow. (#2231)
+ * *ring* is maintained again, withdraw 2025-0007. (#2230)
+ * Assigned RUSTSEC-2025-0007 to ring (#2229)
+ * Add unmaintained advisory for *ring* (#2228)
+ * Assigned RUSTSEC-2024-0435 to fyrox-core (#2224)
+ * Report unsoundness and patch in fyrox-core (#2172)
+ * vec-const is gone from crates.io, update linter to fix CI (#2223)
+ * Assigned RUSTSEC-2025-0006 to hickory-proto (#2222)
+
+-------------------------------------------------------------------
Old:
----
advisory-db-20250204.tar.xz
New:
----
advisory-db-20250304.tar.xz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ cargo-audit-advisory-db.spec ++++++
--- /var/tmp/diff_new_pack.wfnHLx/_old 2025-03-11 20:46:10.696349870 +0100
+++ /var/tmp/diff_new_pack.wfnHLx/_new 2025-03-11 20:46:10.696349870 +0100
@@ -17,7 +17,7 @@
Name: cargo-audit-advisory-db
-Version: 20250204
+Version: 20250304
Release: 0
Summary: A database of known security issues for Rust depedencies
License: CC0-1.0
++++++ _service ++++++
--- /var/tmp/diff_new_pack.wfnHLx/_old 2025-03-11 20:46:10.740351709 +0100
+++ /var/tmp/diff_new_pack.wfnHLx/_new 2025-03-11 20:46:10.740351709 +0100
@@ -2,7 +2,7 @@
<service mode="disabled" name="obs_scm">
<param name="url">https://github.com/RustSec/advisory-db.git</param>
<param name="scm">git</param>
- <param name="version">20250204</param>
+ <param name="version">20250304</param>
<param name="revision">main</param>
<param name="changesgenerate">enable</param>
<param name="changesauthor">william.br...@suse.com</param>
++++++ advisory-db-20250204.tar.xz -> advisory-db-20250304.tar.xz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/advisory-db-20250204/.duplicate-id-guard
new/advisory-db-20250304/.duplicate-id-guard
--- old/advisory-db-20250204/.duplicate-id-guard 2025-02-03
00:37:03.000000000 +0100
+++ new/advisory-db-20250304/.duplicate-id-guard 2025-03-02
23:52:43.000000000 +0100
@@ -1,3 +1,3 @@
This file causes merge conflicts if two ID assignment jobs run concurrently.
This prevents duplicate ID assignment due to a race between those jobs.
-08c7bf6d499fd30aba2666ee1f10fbf0dbf2bd5a50b58a517a46d4798e36a680 -
+8f8b578dd4c799cedee943ff9932fe2ba6fb64638055d9cb02d5838146000a4e -
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/advisory-db-20250204/.github/workflows/validate.yml
new/advisory-db-20250304/.github/workflows/validate.yml
--- old/advisory-db-20250204/.github/workflows/validate.yml 2025-02-03
00:37:03.000000000 +0100
+++ new/advisory-db-20250304/.github/workflows/validate.yml 2025-03-02
23:52:43.000000000 +0100
@@ -26,4 +26,4 @@
fi
- name: Lint advisories
- run: rustsec-admin lint --skip-namecheck rustdecimal
+ run: rustsec-admin lint --skip-namecheck rustdecimal,vec-const
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/advisory-db-20250204/crates/fyrox-core/RUSTSEC-2024-0435.md
new/advisory-db-20250304/crates/fyrox-core/RUSTSEC-2024-0435.md
--- old/advisory-db-20250204/crates/fyrox-core/RUSTSEC-2024-0435.md
1970-01-01 01:00:00.000000000 +0100
+++ new/advisory-db-20250304/crates/fyrox-core/RUSTSEC-2024-0435.md
2025-03-02 23:52:43.000000000 +0100
@@ -0,0 +1,25 @@
+```toml
+[advisory]
+id = "RUSTSEC-2024-0435"
+package = "fyrox-core"
+date = "2024-12-19"
+url = "https://github.com/FyroxEngine/Fyrox/issues/630";
+references = ["https://github.com/FyroxEngine/Fyrox/pull/662";]
+categories = []
+keywords = ["uninitialized"]
+informational = "unsound"
+
+[versions]
+patched = [">= 0.36"]
+
+[affected]
+functions = {"fyrox_core::transmute_vec_as_bytes" = [">= 0.28.1, <= 0.36"]}
+```
+
+# Unsound usages of `Vec::from_raw_parts`
+
+The library provides a public safe API `transmute_vec_as_bytes`, which
incorrectly assumes that any generic type `T` could have stable layout, causing
to uninitialized memory exposure if the users pass any types with padding bytes
as `T` and cast it to `u8` pointer.
+
+In the [issue](https://github.com/FyroxEngine/Fyrox/issues/630), we develop a
PoC to show passing struct type to `transmute_vec_as_bytes` could lead to
undefined behavior with `Vec::from_raw_parts`.
+
+The developers provide a patch by changing trait of `Copy` to `Pod`, which can
make sure `T` should be plain data. This was patched in the latest version of
[master](https://github.com/FyroxEngine/Fyrox/blob/3f9ad6f9667047dac051b0e97d544e5b38e5ae72/fyrox-core/src/lib.rs#L351-L360)
branch, but still not on the latest release (0.28.1).
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/advisory-db-20250204/crates/grcov/RUSTSEC-2025-0005.md
new/advisory-db-20250304/crates/grcov/RUSTSEC-2025-0005.md
--- old/advisory-db-20250204/crates/grcov/RUSTSEC-2025-0005.md 1970-01-01
01:00:00.000000000 +0100
+++ new/advisory-db-20250304/crates/grcov/RUSTSEC-2025-0005.md 2025-03-02
23:52:43.000000000 +0100
@@ -0,0 +1,20 @@
+```toml
+[advisory]
+id = "RUSTSEC-2025-0005"
+package = "grcov"
+date = "2025-01-13"
+url = "https://bugzilla.mozilla.org/show_bug.cgi?id=1917475";
+categories = ["memory-corruption"]
+
+[affected]
+functions = { "grcov::covdir::get_coverage" = ["<=0.8.20"] }
+
+[versions]
+patched = [">0.8.20"]
+```
+# Out of bounds write triggered by crafted coverage data
+Function `grcov::covdir::get_coverage` uses the `unsafe` function
`get_unchecked_mut`
+without validating that the index is in bounds.
+
+This results in memory corruption, and could potentially allow arbitrary code
execution
+provided that an attacker can feed the tool crafted coverage data.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/advisory-db-20250204/crates/hickory-proto/RUSTSEC-2025-0006.md
new/advisory-db-20250304/crates/hickory-proto/RUSTSEC-2025-0006.md
--- old/advisory-db-20250204/crates/hickory-proto/RUSTSEC-2025-0006.md
1970-01-01 01:00:00.000000000 +0100
+++ new/advisory-db-20250304/crates/hickory-proto/RUSTSEC-2025-0006.md
2025-03-02 23:52:43.000000000 +0100
@@ -0,0 +1,29 @@
+```toml
+[advisory]
+id = "RUSTSEC-2025-0006"
+package = "hickory-proto"
+date = "2025-02-07"
+url =
"https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-37wc-h8xc-5hc4";
+categories = ["crypto-failure"]
+keywords = ["dnssec"]
+
+[versions]
+patched = ["^ 0.24.3", ">= 0.25.0-alpha.5"]
+unaffected = ["< 0.8.0"]
+
+[affected.functions]
+"hickory_proto::dnssec::DnssecDnsHandle::send" = [">= 0.25.0-alpha.5"]
+"hickory_proto::xfer::DnssecDnsHandle::send" = [">= 0.24.3", "< 0.25.0"]
+```
+
+# Hickory DNS failure to verify self-signed RRSIG for DNSKEYs
+
+Summary
+
+The DNSSEC validation routines treat entire RRsets of DNSKEY records as
trusted once they have established trust in only one of the DNSKEYs. As a
result, if a zone includes a DNSKEY with a public key that matches a configured
trust anchor, all keys in that zone will be trusted to authenticate other
records in the zone. There is a second variant of this vulnerability involving
DS records, where an authenticated DS record covering one DNSKEY leads to trust
in signatures made by an unrelated DNSKEY in the same zone.
+
+Details
+
+verify_dnskey_rrset() will return Ok(true) if any record's public key matches
a trust anchor. This results in verify_rrset() returning a Secure proof. This
ultimately results in successfully verifying a response containing DNSKEY
records. verify_default_rrset() looks up DNSKEY records by calling
handle.lookup(), which takes the above code path. There's a comment following
this that says "DNSKEYs were already validated by the inner query in the above
lookup", but this is not the case. To fully verify the whole RRset of DNSKEYs,
it would be necessary to check self-signatures by the trusted key over the
other keys. Later in verify_default_rrset(), verify_rrset_with_dnskey() is
called multiple times with different keys and signatures, and if any call
succeeds, then its Proof is returned.
+
+Similarly, verify_dnskey_rrset() returns Ok(false) if any DNSKEY record is
covered by a DS record. A comment says "If all the keys are valid, then we are
secure", but this is only checking that one key is authenticated by a DS in the
parent zone's delegation point. This time, after control flow returns to
verify_rrset(), it will call verify_default_rrset(). The special handling for
DNSKEYs in verify_default_rrset() will then call verify_rrset_with_dnskey()
using each KSK DNSKEY record, and if one call succeeds, return its Proof. If
there are multiple KSK DNSKEYs in the RRset, then this leads to another
authentication break. We need to either pass the authenticated DNSKEYs from the
DS covering check to the RRSIG validation, or we need to perform this RRSIG
validation of the DNSKEY RRset inside verify_dnskey_rrset() and cut
verify_default_rrset() out of DNSKEY RRset validation entirely.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/advisory-db-20250204/crates/openh264-sys2/RUSTSEC-2025-0008.md
new/advisory-db-20250304/crates/openh264-sys2/RUSTSEC-2025-0008.md
--- old/advisory-db-20250204/crates/openh264-sys2/RUSTSEC-2025-0008.md
1970-01-01 01:00:00.000000000 +0100
+++ new/advisory-db-20250304/crates/openh264-sys2/RUSTSEC-2025-0008.md
2025-03-02 23:52:43.000000000 +0100
@@ -0,0 +1,26 @@
+```toml
+[advisory]
+id = "RUSTSEC-2025-0008"
+package = "openh264-sys2"
+date = "2025-02-24"
+references = [ "https://github.com/cisco/openh264/pull/3818/"; ]
+categories = [ "memory-corruption" ]
+keywords = [ "openh264" ]
+related = [ "CVE-2025-27091" ]
+
+
+[versions]
+patched = [ ">=0.8.0" ]
+
+```
+
+# Openh264 Decoding Functions Heap Overflow Vulnerability
+
+OpenH264 recently reported a [heap
overflow](https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x)
that was fixed in upstream
[63db555](https://github.com/cisco/openh264/commit/63db555e30986e3a5f07871368dc90ae78c27449)
and [integrated
into](https://github.com/ralfbiedert/openh264-rs/commit/3a822fff0b4c9a984622ca2b179fe8898ac54b14)
our 0.6.6 release. For users relying on Cisco's pre-compiled DLL, we also
published 0.8.0, which is compatible with their latest fixed DLL version
2.6.0.
+
+In other words:
+- if you rely on our `source` feature only, >=0.6.6 should be safe,
+- if you rely on `libloading`, you must upgrade to 0.8.0 _and_ use their
latest DLL >=2.6.0.
+
+Users handling untrusted video files should update immediately.
+
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/advisory-db-20250204/crates/ring/RUSTSEC-2025-0007.md
new/advisory-db-20250304/crates/ring/RUSTSEC-2025-0007.md
--- old/advisory-db-20250204/crates/ring/RUSTSEC-2025-0007.md 1970-01-01
01:00:00.000000000 +0100
+++ new/advisory-db-20250304/crates/ring/RUSTSEC-2025-0007.md 2025-03-02
23:52:43.000000000 +0100
@@ -0,0 +1,25 @@
+```toml
+[advisory]
+id = "RUSTSEC-2025-0007"
+package = "ring"
+date = "2025-02-20"
+informational = "unmaintained"
+url = "https://github.com/briansmith/ring/discussions/2414";
+withdrawn = "2025-02-22"
+
+[versions]
+patched = []
+unaffected = []
+```
+
+# *ring* is unmaintained
+
+The author has announced an indefinite hiatus in its development, noting that
+any reported security vulnerabilities may go unaddressed for prolonged periods
+of time.
+
+# Update: security maintenance only
+
+After this advisory was published, the author graciously agreed to give
+access to the rustls team. The rustls team is committed to providing
+security (only) maintenance for *ring* for the foreseeable future.
