Lector de Feeds

Sysadmin Tasks

Wiki Mageia - 2 Febrero, 2025 - 04:06

‎Access/Identity: Reset password

← Older revision Revision as of 03:06, 2 February 2025 Line 20: Line 20:  * [[SOP Change SSH key]] * [[SOP Change SSH key]]  * [[SOP Delete user]] on request * [[SOP Delete user]] on request  +* [[SOP Reset password]]  * [[SOP Sysadmin access revocation]] * [[SOP Sysadmin access revocation]]  * [[SOP Adding groups]] * [[SOP Adding groups]] Danf
Categorías: Wiki de Mageia

SOP Change user e-mail

Wiki Mageia - 1 Febrero, 2025 - 19:23

‎Request Verification: Fix typo & simplify

← Older revision Revision as of 18:23, 1 February 2025 Line 11: Line 11:  ldapsearch -H ldaps://ldap.mageia.org -b ou=People,dc=mageia,dc=org -D uid=$USER,ou=People,dc=mageia,dc=org -W '(mail=REQUESTER@E-MAIL)' ldapsearch -H ldaps://ldap.mageia.org -b ou=People,dc=mageia,dc=org -D uid=$USER,ou=People,dc=mageia,dc=org -W '(mail=REQUESTER@E-MAIL)'  </pre> </pre> −Replace $USER with your Mageia user ID (if necessarY0 and REQUESTER@E-MAIL with the e-mail address from Bugzilla. Use your Mageia password when it asks for a password. The user's Mageia account info will be shown including the uid of the account owner. If it matches the request, you're go to go.+Replace REQUESTER@E-MAIL with the e-mail address from Bugzilla. Use your Mageia password when it asks for a password. The user's Mageia account info will be shown including the uid of the account owner. If it matches the request, you're go to go.     * If the user isn't able to log in to Bugzilla but has an SSH key on file, you can use that to authenticate him/her. If the account holder is a packager, he/she can prove identity by making a specific requested change to an svn or git file. * If the user isn't able to log in to Bugzilla but has an SSH key on file, you can use that to authenticate him/her. If the account holder is a packager, he/she can prove identity by making a specific requested change to an svn or git file. Danf
Categorías: Wiki de Mageia

Vendored dependencies

Wiki Mageia - 1 Febrero, 2025 - 15:41

‎See Also: Add Trivy

← Older revision Revision as of 14:41, 1 February 2025 (2 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 105: Line 106:  * [https://guac.sh/ GUAC] SBOM management tool * [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://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

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
Feed