Lector de Feeds

Publication date: 03 Apr 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-56161 Description Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP. (CVE-2024-56161) References

• https://bugs.mageia.org/show_bug.cgi?id=34149
• https://lists.debian.org/debian-lts-announce/2025/03/msg00024.html
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56161

SRPMS 9/nonfree

• microcode-0.20250211-2.mga9.nonfree

Add more Rust info

← Older revision Revision as of 20:09, 3 April 2025 (One intermediate revision by the same user not shown)Line 83: Line 83:  Security updates are assumed to consist of upgrading to a new upstream release. Those that require patching a dependency complicates this flow, since the same patch must then be applied to each vendored instance of that dependency. If an unpackaged dependency needs a local patch instead of an upgrade, then we could implement a policy that the dependency must be first be packaged before rebuilds are performed, with that new package added as a dependency to any application that needs it before rebuilding. That avoids carrying the identical patch around in many packages. Security updates are assumed to consist of upgrading to a new upstream release. Those that require patching a dependency complicates this flow, since the same patch must then be applied to each vendored instance of that dependency. If an unpackaged dependency needs a local patch instead of an upgrade, then we could implement a policy that the dependency must be first be packaged before rebuilds are performed, with that new package added as a dependency to any application that needs it before rebuilding. That avoids carrying the identical patch around in many packages.    −A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'').  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?''+A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'', but see other historic precedence below).  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?''     For step 2., the various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location. For step 2., the various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location. Line 109: Line 109:  #: <pre>grype --output json sbom:"%{NAME}-%{VERSION}.%{RELEASE}.%{ARCH}.spdx"</pre> #: <pre>grype --output json sbom:"%{NAME}-%{VERSION}.%{RELEASE}.%{ARCH}.spdx"</pre>  # If any new vulnerabilities are found, open a bug so the package can be rebuilt. # If any new vulnerabilities are found, open a bug so the package can be rebuilt.  +  +=== Rust ===  +  +Some Rust packages in Mageia already include vendored dependencies. These are stored in the tree in a binrepo file called SOURCES/''<packagename>''-vendor.tar.xz. The macro ''%cargo_prep -v vendor'' in the ''%prep'' section takes care of extracting them into the right place before a build. This archive is created with the ''cargo vendor'' command. Some means of extracting a list of those vendored packages into a SPDX file needs to be determined.     == See Also == == See Also == Line 115: Line 119:  * [[Security Updates]] * [[Security Updates]]  * [https://lwn.net/Articles/1005655/ Fedora proposing allowing vendored Go packages] * [https://lwn.net/Articles/1005655/ Fedora proposing allowing vendored Go packages]  +* [https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_vendored_dependencies Fedora policy on vendored Rust dependencies]  * [https://fosdem.org/2025/schedule/event/fosdem-2025-5570-rust-rpms-and-the-fine-art-of-dependency-bundling/ Rust, RPMs, and the Fine Art of Dependency Bundling] * [https://fosdem.org/2025/schedule/event/fosdem-2025-5570-rust-rpms-and-the-fine-art-of-dependency-bundling/ Rust, RPMs, and the Fine Art of Dependency Bundling]  * [https://ml.mageia.org/l/arc/dev/2023-04/msg00579.html Thread on packages with many components/modules/subpackages] * [https://ml.mageia.org/l/arc/dev/2023-04/msg00579.html Thread on packages with many components/modules/subpackages] Danf

‎Cauldron Package Removal: Show how to use mga-move-pkg

← Older revision Revision as of 15:20, 3 April 2025 Line 79: Line 79:  # Evaluate the request. Will deleting the package break the repository (is it a dependency of something else)? Is there a prior version still available in the repository that would be used in its place? Was this asked by the packager that built the package or the registered maintainer of the package?   # Evaluate the request. Will deleting the package break the repository (is it a dependency of something else)? Is there a prior version still available in the repository that would be used in its place? Was this asked by the packager that built the package or the registered maintainer of the package?    # In most cases, the requester will want to delete the latest version of a package and restore an older version. Make sure the old packages are still available under '''/var/lib/schedbot/old/''' # In most cases, the requester will want to delete the latest version of a package and restore an older version. Make sure the old packages are still available under '''/var/lib/schedbot/old/''' −# Find the RPMs under '''/distrib/bootstrap/distrib/cauldron/*/media/core/updates_testing/''' (or the relevant location)+# Find the RPMs under '''/distrib/bootstrap/distrib/cauldron/*/media/core/updates_testing/''' (or the relevant location). If the RPMs to remove are indeed from ''updates_testing'' (or ''backports_testing''), then you can use the "Raw Commands" output of '''mga-move-pkg --dry-run 9/core/foobar-0.1-1.mga9.src.rpm''' to find the RPM paths given the SRPM names (add '''--backport''' as appropriate).  # Delete package(s) manually, making sure all architectures, the SRPM and all subpackages are removed. # Delete package(s) manually, making sure all architectures, the SRPM and all subpackages are removed.  # If this is the '''release''' subsection, copy ALL the equivalent older version files back as replacements. # If this is the '''release''' subsection, copy ALL the equivalent older version files back as replacements. Danf

Publication date: 03 Apr 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-0167 , CVE-2025-0665 , CVE-2025-0725 Description When asked to use a .netrc file for credentials and to follow HTTP redirects, curl could leak the password used for the first host to the followed-to host under certain circumstances. The fix was included previously as part of MGAA-2025-0004. References

• https://bugs.mageia.org/show_bug.cgi?id=33992
• https://bugs.mageia.org/show_bug.cgi?id=33893
• https://curl.se/docs/CVE-2025-0167.html
• https://advisories.mageia.org/MGAA-2025-0004.html
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-0167
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-0665
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-0725

SRPMS 9/core

• curl-7.88.1-4.6.mga9

Publication date: 03 Apr 2025
Type: bugfix
Affected Mageia releases : 9
Description opencpn-celestial-navigation-plugin, opencpn-weather-routing-plugin and opencpn-weatherfax-plugin have improvements, useful for sailors using OpenCPN (a navigation chart plotter). References

• https://bugs.mageia.org/show_bug.cgi?id=34150

SRPMS 9/core

• opencpn-celestial-navigation-plugin-2.4.47.0-1.mga9
• opencpn-weather-routing-plugin-1.15.21.22-1.mga9
• opencpn-weatherfax-plugin-1.10.17.0-1.mga9

Publication date: 03 Apr 2025
Type: bugfix
Affected Mageia releases : 9
Description This new version of opencpn-o-charts-plugin contains a new nonfree binary for aarch64 but no major change for the other arches. References

• https://bugs.mageia.org/show_bug.cgi?id=34148

SRPMS 9/nonfree

• opencpn-o-charts-plugin-2.0.30.0-1.mga9.nonfree

Publication date: 02 Apr 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-2849 Description UPX p_lx_elf.cpp un_DT_INIT heap-based overflow. (CVE-2025-2849) References

• https://bugs.mageia.org/show_bug.cgi?id=34157
• https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/message/4FBRFLGSEHNFULMPARVADU2TACHDQM4L/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-2849

SRPMS 9/core

• upx-4.2.3-1.1.mga9