Lector de Feeds

Publication date: 26 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-0395 Description When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size. (CVE-2025-0395) References

• https://bugs.mageia.org/show_bug.cgi?id=33953
• https://www.openwall.com/lists/oss-security/2025/01/22/4
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-0395

SRPMS 9/core

• glibc-2.36-55.mga9

Publication date: 26 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-13176 Description Timing side-channel in ECDSA signature computation. (CVE-2024-13176) References

• https://bugs.mageia.org/show_bug.cgi?id=33942
• https://openssl-library.org/news/secadv/20250120.txt
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-13176

SRPMS 9/core

• openssl-3.0.15-1.2.mga9

Add more specifics for certain languages & a skeletal proposal

← Older revision Revision as of 22:28, 25 January 2025 Line 1: Line 1: −A '''vendored dependency''' is an aggregation of code (such as a package, module or library) that is included as part a larger aggregation (usually an application) but which is also available separately standalone (such as a dynamic library). A typical example is an application (e.g. Mariadb) that distributes the source for a separate library within its source tree (e.g. readline). This can be done for a number of reasons, such as licensing issues that prevent using of the module separately, custom code changes made for the application's use that are not/can not be upstreamed, and ease of compilation for the developer.+A '''vendored dependency''' is an aggregation of code (such as a package, module or library) that is included as part a larger aggregation (usually an application) but which is also available separately standalone (such as a dynamic library). A typical example is an application (e.g. Mariadb) that distributes the source for a separate library within its source tree (e.g. readline). This can be done for a number of reasons, such as licensing issues that prevent using of the module separately, custom code changes made for the application's use that are not/can not be upstreamed, and ease of compilation for the developer. ''git modules'' one mechanism developers use do this (in Mageia we always start from a source tar ball and never directly from a source code control system).     There are many downsides to this approach. Probably the biggest one is that when a standalone dynamic library is updated to fix a security bug, the vendored versions included in other applications are not automatically updated. These applications must be updated separately, and the upstream developer may not immediately (or even ever) include the security fixes in the vendored copy, leaving the application vulnerable to security issues. There are many downsides to this approach. Probably the biggest one is that when a standalone dynamic library is updated to fix a security bug, the vendored versions included in other applications are not automatically updated. These applications must be updated separately, and the upstream developer may not immediately (or even ever) include the security fixes in the vendored copy, leaving the application vulnerable to security issues. Line 5: Line 5:  For these reasons, vendored libraries are discouraged in Mageia ''(TBD: point to the policy)'' For these reasons, vendored libraries are discouraged in Mageia ''(TBD: point to the policy)''    −A closely related issue is using '''dependencies that are downloaded''' at compile time. This are common in languages such as Go, Rust and Javascript (npm) and it ends up with similar problems to vendoring. The result is even worse problems because it can not only be difficult to determine which dependencies have been used, but downright impossible to determine the version numbers actually used at compile time. Without dependency names and version numbers, it becomes impossible to tell when a package is affected by a security issue in a dependency. When a security issue is reported, it can result in the need to recompile many application packages instead of a single one. It is also difficult to ensure that the licenses of all downloaded packages match those allowed by the distribution. And when packages have licenses like the GPL that require source code be supplied with the binary, it becomes mandatory to make a copy of the downloaded source available to users.+A closely related issue is using '''dependencies that are downloaded''' at compile time. This are common in languages such as Go (''go install''), Rust (''cargo'') and Javascript (''npm'') and using them ends up with similar problems to vendoring. The result is even worse because it can not only be difficult to determine which dependencies have been used, but downright impossible to determine the version numbers actually used at compile time. Without dependency names and version numbers, it becomes impossible to tell when a package is affected by a security issue in a dependency. When a security issue is reported, it can result in the need to recompile many application packages instead of a single one. It is also difficult to ensure that the licenses of all downloaded packages match those allowed by the distribution. And when packages have licenses like the GPL that require source code be supplied with the binary, it becomes mandatory to make a copy of the downloaded source available to users.     For these reasons, files downloaded at compile time are disallowed in Mageia ''(TBD: point to the policy)'' For these reasons, files downloaded at compile time are disallowed in Mageia ''(TBD: point to the policy)'' Line 33: Line 33:  If we can find a way to satisfy those requirements to a reasonable degree while still allowing vendoring and downloading of modules at compile time, we can ease the burden on our packagers and infrastructure. If we can find a way to satisfy those requirements to a reasonable degree while still allowing vendoring and downloading of modules at compile time, we can ease the burden on our packagers and infrastructure.    −== A way forward ==+== Language landscape ==    −=== Go ===+To give a rough idea of what languages might benefit from easing restrictions on vendoring, here are the languages with the most number of modules in Mageia as of this writing (in approximate decreasing order):    −The following proposal satisfies the reasons for the anti-vendoring policies above, while allowing applications to be packaged without individually packaging each dependency. The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future.+# C/C++  +# Rust  +# Perl*  +# Python*  +# Java  +# Go  +# Ruby*  +# OCaml  +# Nodejs (Javascript)*  +# PHP*  +# Erlang*    −TBD +<nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules     === C/C++ === === C/C++ ===    −Since these languages support dynamic linking and the developer culture does not generally encourage a huge number of small dependencies, no proposal is currently being made to ease the vendoring restrictions in C or C++ applications.+These languages support dynamic linking and the developer culture does not generally encourage either a huge number of small dependencies or vendored dependencies. There are also no popular cross-platform build mechanisms that many upstream developers uses to download and building dependencies alongside their applications (although Conda, Conary and vcpkg are changing this) that could be utilized to save packager time. No proposal is therefore currently being made to ease the vendoring restrictions in C or C++ applications.  +   +=== 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.  +   +=== Go, Java, OCaml, Rust ===  +   +These languages result in statically-linked (or equivalent) binaries. If a dependency has a security issue, every application using that dependency must be recompiled.  +   +== A way forward ==  +   +The following proposal satisfies the reasons for the anti-vendoring policies in the introduction, while allowing applications to be packaged without separately needing to package each dependency. It handles vendored dependencies, dependencies downloaded at build time, as well as statically-linked applications.  +   +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  +# The build system adds packaged dependencies to the software attestation  +# 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  +# A security scanner periodically scans all software attestations 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  +# 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)    −=== Others ===+Software attestations will be stored in the [https://spdx.dev/ SPDX] format.    −The proposals for Go 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.+=== Go ===    −The languages with the most number of modules in Mageia as of this writing (in approximate decreasing order) are:+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.    −# Rust+''details TBD'' −# Perl  −# Python  −# Java  −# Go  −# Ruby  −# OCaml  −# Nodejs (Javascript)  −# PHP  −# Erlang      == See Also == == See Also == Danf

Publication date: 25 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-53580 Description It was discovered that iperf 3.17.1 contains a segmentation violation via the iperf_exchange_parameters() function. References

• https://bugs.mageia.org/show_bug.cgi?id=33914
• https://lists.almalinux.org/archives/list/announce@lists.almalinux.org/message/77I3GUDI3ZWMFAYZRZIRL3FI5TCBTNBQ/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53580

SRPMS 9/core

• iperf-3.18-1.mga9

Connecting examples web browser link and hexchat usage.

← Older revision Revision as of 17:08, 25 January 2025 Line 9: Line 9:     On 15 June 2021, we were forced to move [[Mageia IRC Channels|our IRC channels on Freenode]] to [https://libera.chat/ Liberachat]. You can visit them on the Libera Chat Network (ircs://irc.libera.chat:6697) On 15 June 2021, we were forced to move [[Mageia IRC Channels|our IRC channels on Freenode]] to [https://libera.chat/ Liberachat]. You can visit them on the Libera Chat Network (ircs://irc.libera.chat:6697) −  −Connect to server ircs://irc.libera.chat:6697 and type /join channelname, replacing channelname with the name of the channel (including the leading "#"). All channels use English unless otherwise specified. Using a secure connection with SSL by connecting to port 6697 is obligatory.      The intention was to have a backup on Liberachat for each of our channels on Freenode. You can find them below, but some might not yet be populated or registered. If you have a question about an empty channel, then please ask in [ircs://irc.libera.chat:6697/#mageia #mageia] The intention was to have a backup on Liberachat for each of our channels on Freenode. You can find them below, but some might not yet be populated or registered. If you have a question about an empty channel, then please ask in [ircs://irc.libera.chat:6697/#mageia #mageia]     The channels will host regular meetings (see [[meetings|summaries and logs]]). The channels will host regular meetings (see [[meetings|summaries and logs]]).  +  +All channels use English unless otherwise specified.     Some channels (will) have useful bots; [[IRC bots|learn about them]]. Some channels (will) have useful bots; [[IRC bots|learn about them]].  +  +Connect to server ircs://irc.libera.chat:6697 and type /join channelname, replacing channelname with the name of the channel (including the leading "#"). Using a secure connection with SSL by connecting to port 6697 is obligatory.  +  +Using a browser: https://web.libera.chat/  +  +Using an IRC client such as for example {{prog|hexchat}} : choose network Libera.Chat, and menu Server > Join a channel > #mageia-something from list below.     == Project-wide channels: == == Project-wide channels: == Morgano

‎Contact the team: link to other channels

← Older revision Revision as of 16:59, 25 January 2025 Line 16: Line 16:     * Subscribing to the [https://ml.mageia.org/l/info/qa-discuss QA-Discuss] mailing list and then send a mail message to it, to introduce yourself * Subscribing to the [https://ml.mageia.org/l/info/qa-discuss QA-Discuss] mailing list and then send a mail message to it, to introduce yourself −* By joining the [irc://irc.libera.chat/#mageia-qa #mageia-qa] IRC channel on libera.chat. How: web browser using https://web.libera.chat/, or an IRC client such as for example {{prog|hexchat}} : choose network Libera.Chat, and menu Server > Join a channel > #mageia-qa+* By joining the [irc://irc.libera.chat/#mageia-qa #mageia-qa] IRC channel on libera.chat. How: web browser using https://web.libera.chat/, or an IRC client such as for example {{prog|hexchat}} : choose network Libera.Chat, and menu Server > Join a channel > #mageia-qa. Other channels see: [[Mageia_IRC_Channels_Liberachat|Mageia IRC Channels Liberachat]].     * Team  leader : Thomas J Andrews (MageiaTJ) - andrewsfarm AT gmail dot com * Team  leader : Thomas J Andrews (MageiaTJ) - andrewsfarm AT gmail dot com Morgano

Publication date: 24 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2023-30536 , CVE-2024-2961 Description fix possible security issue with library code slim/psr7 (CVE-2023-30536) fix possible security issue relating to iconv (CVE-2024-2961, PMASA-2025-3) fix an XSS vulnerability in the check tables feature (PMASA-2025-1) fix an XSS vulnerability in the Insert tab (PMASA-2025-2) References

• https://bugs.mageia.org/show_bug.cgi?id=33948
• https://www.phpmyadmin.net/news/2025/1/21/phpMyAdmin-522-is-released/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-30536
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-2961

SRPMS 9/core

• phpmyadmin-5.2.2-1.mga9

Publication date: 24 Jan 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-56378 Description libpoppler.so has an out-of-bounds read vulnerability within the JBIG2Bitmap::combine function in JBIG2Stream.cc. (CVE-2024-56378) References

• https://bugs.mageia.org/show_bug.cgi?id=33932
• https://ubuntu.com/security/notices/USN-7213-1
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56378

SRPMS 9/core

• poppler-23.02.0-1.4.mga9

Initial notes on supporting vendored dependencies

New page

A '''vendored dependency''' is an aggregation of code (such as a package, module or library) that is included as part a larger aggregation (usually an application) but which is also available separately standalone (such as a dynamic library). A typical example is an application (e.g. Mariadb) that distributes the source for a separate library within its source tree (e.g. readline). This can be done for a number of reasons, such as licensing issues that prevent using of the module separately, custom code changes made for the application's use that are not/can not be upstreamed, and ease of compilation for the developer.

There are many downsides to this approach. Probably the biggest one is that when a standalone dynamic library is updated to fix a security bug, the vendored versions included in other applications are not automatically updated. These applications must be updated separately, and the upstream developer may not immediately (or even ever) include the security fixes in the vendored copy, leaving the application vulnerable to security issues.

For these reasons, vendored libraries are discouraged in Mageia ''(TBD: point to the policy)''

A closely related issue is using '''dependencies that are downloaded''' at compile time. This are common in languages such as Go, Rust and Javascript (npm) and it ends up with similar problems to vendoring. The result is even worse problems because it can not only be difficult to determine which dependencies have been used, but downright impossible to determine the version numbers actually used at compile time. Without dependency names and version numbers, it becomes impossible to tell when a package is affected by a security issue in a dependency. When a security issue is reported, it can result in the need to recompile many application packages instead of a single one. It is also difficult to ensure that the licenses of all downloaded packages match those allowed by the distribution. And when packages have licenses like the GPL that require source code be supplied with the binary, it becomes mandatory to make a copy of the downloaded source available to users.

For these reasons, files downloaded at compile time are disallowed in Mageia ''(TBD: point to the policy)''

'''Static linking''' is another practice that effectively results in the same problems as the above. Some languages (e.g. Go, Rust) statically link their dependencies so security issues in those dependencies means rebuilding them all against the fixed packages.

For these reasons, static linking is discouraged in Mageia ''(TBD: point to the policy)''

These are really three separate topics but since the effects of all three are very similar, they are discussed here as a block.

== Problems with disallowing vendoring ==

When vendored (bundled) and downloaded packages are disallowed, they must instead be packaged separately. This means extra work for packagers since adding a single new complicated application can require individually packaging dozens or even hundreds of new separate dependency packages. This takes extra time, disk space and the especially rare commodity, packager time. It is simply not scalable and effectively means that new applications written in some of the languages particularly prone to this way of working just aren't available to Mageia users.

== The landscape ==

Two languages becoming more popular these days, Go and Rust, particularly suffer from the issues described and supporting applications using them in Mageia is difficult due to policies designed for the C and C++ applications that were the most popular ones in the past. If we want to support programs in these languages, we need to ease the burden on packagers.

The main reasons for anti-vendoring (and related) policies are:

# to easily identify which packages need to be updated to fix security issues
# to ensure that a known security issue does not unknowingly go unfixed in the distribution
# to reduce the work in updating those packages when necessary
# to reduce time, bandwidth and disk space for users
# to ensure source code is always available to users to fulfill licensing obligations

If we can find a way to satisfy those requirements to a reasonable degree while still allowing vendoring and downloading of modules at compile time, we can ease the burden on our packagers and infrastructure.

== A way forward ==

=== Go ===

The following proposal satisfies the reasons for the anti-vendoring policies above, while allowing applications to be packaged without individually packaging each dependency. The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future.

TBD

=== C/C++ ===

Since these languages support dynamic linking and the developer culture does not generally encourage a huge number of small dependencies, no proposal is currently being made to ease the vendoring restrictions in C or C++ applications.

=== Others ===

The proposals for Go 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.

The languages with the most number of modules in Mageia as of this writing (in approximate decreasing order) are:

# Rust
# Perl
# Python
# Java
# Go
# Ruby
# OCaml
# Nodejs (Javascript)
# PHP
# Erlang

== See Also ==

* [[Packages carrying bundled copies of system libraries]]
* [[Security Updates]]

[[Category:Packaging]] Danf

‎Cancel the build: Run as schedbot

← Older revision Revision as of 06:58, 24 January 2025 Line 11: Line 11:  Find the build at https://pkgsubmit.mageia.org/ and look under ''Status'' for the build's ID (it will look like YYYYMMDDHHMMSS.USER.HOST.ID). Log in to duvel and run: Find the build at https://pkgsubmit.mageia.org/ and look under ''Status'' for the build's ID (it will look like YYYYMMDDHHMMSS.USER.HOST.ID). Log in to duvel and run:    −   cancel_build 20231231211004.pterjan.duvel.1487312+   sudo -u schedbot cancel_build 20231231211004.pterjan.duvel.1487312     providing the build ID you just found. providing the build ID you just found. Danf