Lector de Feeds

Vendored dependencies

Wiki Mageia - 1 Febrero, 2025 - 15:41

‎See Also: Add Trivy

← Older revision Revision as of 14:41, 1 February 2025 (7 intermediate revisions by the same user not shown)Line 45: Line 45:  # Ruby* # Ruby*  # OCaml # OCaml −# Nodejs (Javascript)*+# Javascript* (nodejs)  # PHP* # PHP*  # Erlang* # Erlang*  +# other compiled languages like C# (mono), BASIC (FreeBASIC), FORTRAN (gfortran), Pascal (lazarus)     <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules Line 57: Line 58:  === Erlang, Nodejs, Perl, PHP, Python, Ruby === === Erlang, Nodejs, Perl, PHP, Python, Ruby ===    −These are all interpreted languages that either have no concept of bundling dependencies somehow into submodules (a static linking equivalent) or developers don't generally use them. They generally do, however, have means to automatically obtain dependent modules at build time (e.g. ''pip'', ''cpan'', ''npm'') that Mageia's current policies forbid. Generally, interpreted languages rely on modules being installed in the system when they are executed and do not compile/bind/link them into an independent blob like compiled languages are forced to do.+These are all interpreted languages that either have no concept of bundling dependencies somehow into submodules (a static linking equivalent) or developers don't generally use them. They generally do, however, have means to automatically obtain dependent modules at build time (e.g. ''pip'', ''cpan'', ''npm'') that Mageia's current policies forbid. Generally, interpreted languages rely on modules being installed in the system when they are executed and do not compile/bind/link them into an independent blob like compiled languages are forced to do. Vendoring can still be useful to greatly reduce the number of packages necessary to create for a new application.     === Go, Java, OCaml, Rust === === Go, Java, OCaml, Rust === Line 69: Line 70:  Overview: Overview:    −# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a software attestation+# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a SBOM −# The build system adds packaged dependencies to the software attestation+# The build system adds packaged dependencies to the SBOM  # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application −# The build system stores the software attestation at the end of the build into a central repository+# The build system stores the SBOM at the end of the build into a central repository −# A security scanner periodically scans all software attestations to look for dependencies that have reported security vulnerabilities+# A security scanner periodically scans all SBOMs to look for dependencies that have reported security vulnerabilities  # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs −# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the software attestation)+# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the SBOM)    −Software attestations will be stored in the [https://spdx.dev/ SPDX] format.+SBOMs will be stored in the [https://spdx.dev/ SPDX] format.  +   +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.  +   +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?''  +   +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 interpreted languages, the dependencies would instead by installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''     === Go === === Go ===     The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future. These should be able to be generalized to work for applications in other compiled languages as well. It is possible to develop infrastructure to support interpreted languages as well, but the benefits may not be as clear; any such applications that ship vendored modules ''would'' benefit, but it's unclear how many of those (if any) actually exist. The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future. These should be able to be generalized to work for applications in other compiled languages as well. It is possible to develop infrastructure to support interpreted languages as well, but the benefits may not be as clear; any such applications that ship vendored modules ''would'' benefit, but it's unclear how many of those (if any) actually exist.  +  +The ''go list -json'' command can be used to generate the list of dependencies needed by an application (step 1).  +  +The [https://vuln.go.dev/ Go Vulnerability Database] can be used on an ongoing basis to find security issues in Go packages from the SBOMs of those packages.     ''details TBD'' ''details TBD'' Line 90: Line 101:  * [[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://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://vuln.go.dev/ Go Vulnerability Database]  +* [https://guac.sh/ GUAC] SBOM management tool  +* [https://github.com/anchore/grype grype], tool that can look up security issues from a SPDX SBOM  +* [https://trivy.dev/ Trivy], tool that can look up security issues from a SPDX SBOM     [[Category:Packaging]] [[Category:Packaging]] Danf
Categorías: Wiki de Mageia

MGASA-2025-0032 - Updated kernel-linus packages fix security vulnerabilities

Mageia Security - 31 Enero, 2025 - 21:54
Publication date: 31 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-36476 , CVE-2024-39282 , CVE-2024-41935 , CVE-2024-43098 , CVE-2024-45828 , CVE-2024-46896 , CVE-2024-47141 , CVE-2024-47143 , CVE-2024-47408 , CVE-2024-47809 , CVE-2024-48873 , CVE-2024-48875 , CVE-2024-48881 , CVE-2024-49568 , CVE-2024-49571 , CVE-2024-50051 , CVE-2024-52332 , CVE-2024-53164 , CVE-2024-53196 , CVE-2024-53240 , CVE-2024-53241 , CVE-2024-53680 , CVE-2024-53685 , CVE-2024-53687 , CVE-2024-53690 , CVE-2024-54031 , CVE-2024-54680 , CVE-2024-54683 , CVE-2024-55639 , CVE-2024-55881 , CVE-2024-55916 , CVE-2024-56369 , CVE-2024-56372 , CVE-2024-56565 , CVE-2024-56568 , CVE-2024-56583 , CVE-2024-56584 , CVE-2024-56585 , CVE-2024-56586 , CVE-2024-56587 , CVE-2024-56589 , CVE-2024-56590 , CVE-2024-56592 , CVE-2024-56593 , CVE-2024-56594 , CVE-2024-56595 , CVE-2024-56596 , CVE-2024-56597 , CVE-2024-56598 , CVE-2024-56600 , CVE-2024-56601 , CVE-2024-56602 , CVE-2024-56603 , CVE-2024-56604 , CVE-2024-56605 , CVE-2024-56606 , CVE-2024-56610 , CVE-2024-56611 , CVE-2024-56613 , CVE-2024-56614 , CVE-2024-56615 , CVE-2024-56616 , CVE-2024-56617 , CVE-2024-56619 , CVE-2024-56622 , CVE-2024-56623 , CVE-2024-56625 , CVE-2024-56626 , CVE-2024-56627 , CVE-2024-56628 , CVE-2024-56629 , CVE-2024-56630 , CVE-2024-56631 , CVE-2024-56633 , CVE-2024-56634 , CVE-2024-56635 , CVE-2024-56636 , CVE-2024-56637 , CVE-2024-56638 , CVE-2024-56640 , CVE-2024-56641 , CVE-2024-56642 , CVE-2024-56643 , CVE-2024-56644 , CVE-2024-56645 , CVE-2024-56648 , CVE-2024-56649 , CVE-2024-56650 , CVE-2024-56651 , CVE-2024-56653 , CVE-2024-56654 , CVE-2024-56655 , CVE-2024-56657 , CVE-2024-56658 , CVE-2024-56659 , CVE-2024-56660 , CVE-2024-56661 , CVE-2024-56662 , CVE-2024-56663 , CVE-2024-56664 , CVE-2024-56665 , CVE-2024-56667 , CVE-2024-56670 , CVE-2024-56672 , CVE-2024-56675 , CVE-2024-56709 , CVE-2024-56715 , CVE-2024-56716 , CVE-2024-56717 , CVE-2024-56718 , CVE-2024-56719 , CVE-2024-56760 , CVE-2024-56762 , CVE-2024-56763 , CVE-2024-56765 , CVE-2024-56766 , CVE-2024-56767 , CVE-2024-56769 , CVE-2024-56770 , CVE-2024-56781 , CVE-2024-56783 , CVE-2024-56785 , CVE-2024-56786 , CVE-2024-56787 , CVE-2024-57791 , CVE-2024-57792 , CVE-2024-57798 , CVE-2024-57801 , CVE-2024-57802 , CVE-2024-57807 , CVE-2024-57841 , CVE-2024-57843 , CVE-2024-57849 , CVE-2024-57850 , CVE-2024-57874 , CVE-2024-57876 , CVE-2024-57882 , CVE-2024-57884 , CVE-2024-57885 , CVE-2024-57887 , CVE-2024-57889 , CVE-2024-57890 , CVE-2024-57892 , CVE-2024-57893 , CVE-2024-57894 , CVE-2024-57895 , CVE-2024-57896 , CVE-2024-57897 , CVE-2024-57899 , CVE-2024-57900 , CVE-2024-57901 , CVE-2024-57902 , CVE-2024-57903 , CVE-2024-57904 , CVE-2024-57906 , CVE-2024-57907 , CVE-2024-57908 , CVE-2024-57910 , CVE-2024-57911 , CVE-2024-57912 , CVE-2024-57913 , CVE-2024-57915 , CVE-2024-57916 , CVE-2024-57917 , CVE-2024-57922 , CVE-2024-57925 , CVE-2024-57926 , CVE-2024-57929 , CVE-2024-57930 , CVE-2024-57931 , CVE-2024-57932 , CVE-2024-57933 , CVE-2024-57938 , CVE-2024-57939 , CVE-2024-57940 , CVE-2024-57945 , CVE-2024-57946 , CVE-2025-21629 , CVE-2025-21631 , CVE-2025-21632 , CVE-2025-21636 , CVE-2025-21637 , CVE-2025-21638 , CVE-2025-21639 , CVE-2025-21640 , CVE-2025-21642 , CVE-2025-21645 , CVE-2025-21646 , CVE-2025-21647 , CVE-2025-21648 , CVE-2025-21652 , CVE-2025-21653 , CVE-2025-21654 , CVE-2025-21655 , CVE-2025-21656 , CVE-2025-21658 , CVE-2025-21660 , CVE-2025-21662 , CVE-2025-21663 , CVE-2025-21664 , CVE-2025-23125 , CVE-2025-23128 Description Vanilla upstream kernel version 6.6.74 fixes bugs and vulnerabilities. For information about the vulnerabilities see the links. References SRPMS 9/core
  • kernel-linus-6.6.74-1.mga9

MGASA-2025-0031 - Updated clamav packages fix security vulnerability

Mageia Security - 31 Enero, 2025 - 21:54
Publication date: 31 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-20128 Description ClamAV OLE2 File Format Decryption Denial of Service Vulnerability. (CVE-2025-20128) References SRPMS 9/core
  • clamav-1.0.8-1.mga9

MGASA-2025-0030 - Updated kernel, kmod-virtualbox, kmod-xtables-addons & dwarves packages fix security vulnerabilities

Mageia Security - 31 Enero, 2025 - 21:54
Publication date: 31 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-36476 , CVE-2024-39282 , CVE-2024-41935 , CVE-2024-43098 , CVE-2024-45828 , CVE-2024-46896 , CVE-2024-47141 , CVE-2024-47143 , CVE-2024-47408 , CVE-2024-47809 , CVE-2024-48873 , CVE-2024-48875 , CVE-2024-48881 , CVE-2024-49568 , CVE-2024-49571 , CVE-2024-50051 , CVE-2024-52332 , CVE-2024-53164 , CVE-2024-53196 , CVE-2024-53240 , CVE-2024-53241 , CVE-2024-53680 , CVE-2024-53685 , CVE-2024-53687 , CVE-2024-53690 , CVE-2024-54031 , CVE-2024-54680 , CVE-2024-54683 , CVE-2024-55639 , CVE-2024-55881 , CVE-2024-55916 , CVE-2024-56369 , CVE-2024-56372 , CVE-2024-56565 , CVE-2024-56568 , CVE-2024-56583 , CVE-2024-56584 , CVE-2024-56585 , CVE-2024-56586 , CVE-2024-56587 , CVE-2024-56589 , CVE-2024-56590 , CVE-2024-56592 , CVE-2024-56593 , CVE-2024-56594 , CVE-2024-56595 , CVE-2024-56596 , CVE-2024-56597 , CVE-2024-56598 , CVE-2024-56600 , CVE-2024-56601 , CVE-2024-56602 , CVE-2024-56603 , CVE-2024-56604 , CVE-2024-56605 , CVE-2024-56606 , CVE-2024-56610 , CVE-2024-56611 , CVE-2024-56613 , CVE-2024-56614 , CVE-2024-56615 , CVE-2024-56616 , CVE-2024-56617 , CVE-2024-56619 , CVE-2024-56622 , CVE-2024-56623 , CVE-2024-56625 , CVE-2024-56626 , CVE-2024-56627 , CVE-2024-56628 , CVE-2024-56629 , CVE-2024-56630 , CVE-2024-56631 , CVE-2024-56633 , CVE-2024-56634 , CVE-2024-56635 , CVE-2024-56636 , CVE-2024-56637 , CVE-2024-56638 , CVE-2024-56640 , CVE-2024-56641 , CVE-2024-56642 , CVE-2024-56643 , CVE-2024-56644 , CVE-2024-56645 , CVE-2024-56648 , CVE-2024-56649 , CVE-2024-56650 , CVE-2024-56651 , CVE-2024-56653 , CVE-2024-56654 , CVE-2024-56655 , CVE-2024-56657 , CVE-2024-56658 , CVE-2024-56659 , CVE-2024-56660 , CVE-2024-56661 , CVE-2024-56662 , CVE-2024-56663 , CVE-2024-56664 , CVE-2024-56665 , CVE-2024-56667 , CVE-2024-56670 , CVE-2024-56672 , CVE-2024-56675 , CVE-2024-56709 , CVE-2024-56715 , CVE-2024-56716 , CVE-2024-56717 , CVE-2024-56718 , CVE-2024-56719 , CVE-2024-56760 , CVE-2024-56762 , CVE-2024-56763 , CVE-2024-56765 , CVE-2024-56766 , CVE-2024-56767 , CVE-2024-56769 , CVE-2024-56770 , CVE-2024-56781 , CVE-2024-56783 , CVE-2024-56785 , CVE-2024-56786 , CVE-2024-56787 , CVE-2024-57791 , CVE-2024-57792 , CVE-2024-57798 , CVE-2024-57801 , CVE-2024-57802 , CVE-2024-57807 , CVE-2024-57841 , CVE-2024-57843 , CVE-2024-57849 , CVE-2024-57850 , CVE-2024-57874 , CVE-2024-57876 , CVE-2024-57882 , CVE-2024-57884 , CVE-2024-57885 , CVE-2024-57887 , CVE-2024-57889 , CVE-2024-57890 , CVE-2024-57892 , CVE-2024-57893 , CVE-2024-57894 , CVE-2024-57895 , CVE-2024-57896 , CVE-2024-57897 , CVE-2024-57899 , CVE-2024-57900 , CVE-2024-57901 , CVE-2024-57902 , CVE-2024-57903 , CVE-2024-57904 , CVE-2024-57906 , CVE-2024-57907 , CVE-2024-57908 , CVE-2024-57910 , CVE-2024-57911 , CVE-2024-57912 , CVE-2024-57913 , CVE-2024-57915 , CVE-2024-57916 , CVE-2024-57917 , CVE-2024-57922 , CVE-2024-57925 , CVE-2024-57926 , CVE-2024-57929 , CVE-2024-57930 , CVE-2024-57931 , CVE-2024-57932 , CVE-2024-57933 , CVE-2024-57938 , CVE-2024-57939 , CVE-2024-57940 , CVE-2024-57945 , CVE-2024-57946 , CVE-2025-21629 , CVE-2025-21631 , CVE-2025-21632 , CVE-2025-21636 , CVE-2025-21637 , CVE-2025-21638 , CVE-2025-21639 , CVE-2025-21640 , CVE-2025-21642 , CVE-2025-21645 , CVE-2025-21646 , CVE-2025-21647 , CVE-2025-21648 , CVE-2025-21652 , CVE-2025-21653 , CVE-2025-21654 , CVE-2025-21655 , CVE-2025-21656 , CVE-2025-21658 , CVE-2025-21660 , CVE-2025-21662 , CVE-2025-21663 , CVE-2025-21664 , CVE-2025-23125 , CVE-2025-23128 Description Upstream kernel version 6.6.74 fixes bugs and vulnerabilities. The kmod-virtualbox and kmod-xtables-addons packages have been updated to work with this new kernel. For information about the vulnerabilities see the links. References SRPMS 9/core
  • kernel-6.6.74-1.mga9
  • kmod-virtualbox-7.0.24-64.mga9
  • kmod-xtables-addons-3.24-70.mga9
  • dwarves-1.29-1.mga9

MGAA-2025-0008 - Updated nvidia-current packages fix bugs

Mageia Security - 31 Enero, 2025 - 21:54
Publication date: 31 Jan 2025
Type: bugfix
Affected Mageia releases : 9
Description Minor bug fixes and improvements. References SRPMS 9/nonfree
  • nvidia-current-550.144.03-1.mga9.nonfree

Vendored dependencies

Wiki Mageia - 31 Enero, 2025 - 07:06

Add a few more languages

← Older revision Revision as of 06:06, 31 January 2025 (5 intermediate revisions by the same user not shown)Line 45: Line 45:  # Ruby* # Ruby*  # OCaml # OCaml −# Nodejs (Javascript)*+# Javascript* (nodejs)  # PHP* # PHP*  # Erlang* # Erlang*  +# other compiled languages like FreeBASIC, gfortran, C# (mono)     <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules Line 57: Line 58:  === Erlang, Nodejs, Perl, PHP, Python, Ruby === === Erlang, Nodejs, Perl, PHP, Python, Ruby ===    −These are all interpreted languages that either have no concept of bundling dependencies somehow into submodules (a static linking equivalent) or developers don't generally use them. They generally do, however, have means to automatically obtain dependent modules at build time (e.g. ''pip'', ''cpan'', ''npm'') that Mageia's current policies forbid. Generally, interpreted languages rely on modules being installed in the system when they are executed and do not compile/bind/link them into an independent blob like compiled languages are forced to do.+These are all interpreted languages that either have no concept of bundling dependencies somehow into submodules (a static linking equivalent) or developers don't generally use them. They generally do, however, have means to automatically obtain dependent modules at build time (e.g. ''pip'', ''cpan'', ''npm'') that Mageia's current policies forbid. Generally, interpreted languages rely on modules being installed in the system when they are executed and do not compile/bind/link them into an independent blob like compiled languages are forced to do. Vendoring can still be useful to greatly reduce the number of packages necessary to create for a new application.     === Go, Java, OCaml, Rust === === Go, Java, OCaml, Rust === Line 69: Line 70:  Overview: Overview:    −# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a software attestation+# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a SBOM −# The build system adds packaged dependencies to the software attestation+# The build system adds packaged dependencies to the SBOM  # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application −# The build system stores the software attestation at the end of the build into a central repository+# The build system stores the SBOM at the end of the build into a central repository −# A security scanner periodically scans all software attestations to look for dependencies that have reported security vulnerabilities+# A security scanner periodically scans all SBOMs to look for dependencies that have reported security vulnerabilities  # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs −# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the software attestation)+# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the SBOM)    −Software attestations will be stored in the [https://spdx.dev/ SPDX] format.+SBOMs will be stored in the [https://spdx.dev/ SPDX] format.  +   +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.  +   +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?''  +   +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 interpreted languages, the dependencies would instead by installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''     === Go === === Go ===     The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future. These should be able to be generalized to work for applications in other compiled languages as well. It is possible to develop infrastructure to support interpreted languages as well, but the benefits may not be as clear; any such applications that ship vendored modules ''would'' benefit, but it's unclear how many of those (if any) actually exist. The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future. These should be able to be generalized to work for applications in other compiled languages as well. It is possible to develop infrastructure to support interpreted languages as well, but the benefits may not be as clear; any such applications that ship vendored modules ''would'' benefit, but it's unclear how many of those (if any) actually exist.  +  +The ''go list -json'' command can be used to generate the list of dependencies needed by an application (step 1).  +  +The [https://vuln.go.dev/ Go Vulnerability Database] can be used on an ongoing basis to find security issues in Go packages from the SBOMs of those packages.     ''details TBD'' ''details TBD'' Line 90: Line 101:  * [[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://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://vuln.go.dev/ Go Vulnerability Database]  +* [https://guac.sh/ GUAC] SBOM management tool  +* [https://github.com/anchore/grype grype], tool that can look up security issues from a SPDX SBOM     [[Category:Packaging]] [[Category:Packaging]] Danf
Categorías: Wiki de Mageia

MGASA-2025-0029 - Updated chromium-browser-stable packages fix security vulnerabilities

Mageia Security - 30 Enero, 2025 - 19:36
Publication date: 30 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-0611 , CVE-2025-0612 Description Object corruption in V8. (CVE-2025-0611) Out of bounds memory access in V8. (CVE-2025-0612) References SRPMS 9/tainted
  • chromium-browser-stable-132.0.6834.110-1.mga9.tainted

Vendored dependencies

Wiki Mageia - 30 Enero, 2025 - 09:36

Add note on patches, links to see also

← Older revision Revision as of 08:36, 30 January 2025 (One intermediate revision by the same user not shown)Line 69: Line 69:  Overview: Overview:    −# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a software attestation+# Developer builds a package SRPM containing all application source code as well as any unpackaged dependency source code for an application (i.e. vendoring it), including a SBOM −# The build system adds packaged dependencies to the software attestation+# The build system adds packaged dependencies to the SBOM  # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application # For interpreted languages, the build system puts any vendored code into a filesystem location specific to the application −# The build system stores the software attestation at the end of the build into a central repository+# The build system stores the SBOM at the end of the build into a central repository −# A security scanner periodically scans all software attestations to look for dependencies that have reported security vulnerabilities+# A security scanner periodically scans all SBOMs to look for dependencies that have reported security vulnerabilities  # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs # If a security vulnerability is found, it outputs a list of packages that need to be updated and rebuilt and opens one or more bugs −# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the software attestation)+# Each package needing a rebuild goes back to step 1 (if a local patch to fix a vulnerability has been added, it is noted in the SBOM)    −Software attestations will be stored in the [https://spdx.dev/ SPDX] format.+SBOMs will be stored in the [https://spdx.dev/ SPDX] format.  +   +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.     === Go === === Go === Line 90: Line 92:  * [[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://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]     [[Category:Packaging]] [[Category:Packaging]] Danf
Categorías: Wiki de Mageia

Appearance of Mageia Tools

Wiki Mageia - 28 Enero, 2025 - 09:49

‎CLI: Text font & size: Just edit a line

← Older revision Revision as of 08:49, 28 January 2025 (One intermediate revision by the same user not shown)Line 10: Line 10:  The Mageia Tools use the gtk toolkit, this is why it usually has a look similar to selected theme in desktops that also use gtk toolkit (Gnome, lxde, Xfce). The Mageia Tools use the gtk toolkit, this is why it usually has a look similar to selected theme in desktops that also use gtk toolkit (Gnome, lxde, Xfce).    −If you like to change the appearance of Magiea Tools keep reading this page.+If you like to change the appearance of Magiea tools keep reading this page.  +   +A frequent question is '''how to enlarge the text size''' - best method see [[#GUI|Alternatives for all the Desktops#GUI]] at bottom of this page.       Line 36: Line 38:     ==== CLI ==== ==== CLI ====  +  +To only change text and you do not want to install a tool for it, easiest way is to as root edit /root/.config/gtk-3.0/settings.ini.  +  +In that file, edit the line "gtk-font-name=Noto Sans,  10", for example change the size number "10" to "14"  +  +  +===== Changing theme =====     First you must apply a gtk theme as user, then follow this procedure: First you must apply a gtk theme as user, then follow this procedure: Line 61: Line 70:  ==== GUI ==== ==== GUI ====    −Install {{prog|lxappearance}}, run in a terminal as root {{prog|lxappearance}} and select by example Adwaita Dark+Install {{prog|lxappearance}}, and ''as root'' in a terminal launch {{prog|lxappearance}}. There you can select another theme, i.e Adwaita Dark.  +   +If you want to '''change the text size or typeface''' you can directly do that at the bottom of the dialogue, clicking the current typeface opens another dialogue.  +   +lxappearance itself adjust immediately to theme and typeface changes.  Click Apply, and next time you start a Mageia tool it will use this setting.  +   +''Note that for example Mageia Control Center main page right pane do not follow theme nor text settings.''     == Recommendations == == Recommendations == Morgano
Categorías: Wiki de Mageia

Vendored dependencies

Wiki Mageia - 28 Enero, 2025 - 06:39

Add an apropos link re: Fedora & Go

← Older revision Revision as of 05:39, 28 January 2025 Line 89: Line 89:  * [[Packages carrying bundled copies of system libraries]] * [[Packages carrying bundled copies of system libraries]]  * [[Security Updates]] * [[Security Updates]]  +* [https://lwn.net/Articles/1005655/ Fedora proposing allowing vendored Go packages]     [[Category:Packaging]] [[Category:Packaging]] Danf
Categorías: Wiki de Mageia

MGASA-2025-0027 - Updated virtualbox, kmod-virtualbox packages fix security vulnerabilities

Mageia Security - 27 Enero, 2025 - 21:20
Publication date: 27 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-21571 , CVE-2025-21533 Description Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 7.0.24 and prior to 7.1.6. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle VM VirtualBox accessible data as well as unauthorized read access to a subset of Oracle VM VirtualBox accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:H/A:L) References SRPMS 9/core
  • virtualbox-7.0.24-1.mga9
  • kmod-virtualbox-7.0.24-63.mga9

MGAA-2025-0007 - Updated libmatemixer packages fix bug

Mageia Security - 27 Enero, 2025 - 20:44
Publication date: 27 Jan 2025
Type: bugfix
Affected Mageia releases : 9
Description Fixes a mate-volume-control crash when Bluetooth disconnects. References SRPMS 9/core
  • libmatemixer-1.26.1-1.mga9
Feed