Lector de Feeds

Publication date: 25 Oct 2024
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-47191 Description pam_oath.so in oath-toolkit 2.6.7 through 2.6.11 before 2.6.12 allows root privilege escalation because, in the context of PAM code running as root, it mishandles usersfile access, such as by calling fchown in the presence of a symlink. (CVE-2024-47191) References

• https://bugs.mageia.org/show_bug.cgi?id=33619
• https://lists.archlinux.org/archives/list/arch-security@lists.archlinux.org/message/IDKMOOVTHHDXCEEZ2S4VVYLM3N5QBPJA/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-47191

SRPMS 9/core

• oath-toolkit-2.6.7-1.1.mga9

Publication date: 24 Oct 2024
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-7519 , CVE-2024-7520 , CVE-2024-7521 , CVE-2024-7522 , CVE-2024-7524 , CVE-2024-7525 , CVE-2024-7526 , CVE-2024-7527 , CVE-2024-7528 , CVE-2024-7529 , CVE-2024-8385 , CVE-2024-8381 , CVE-2024-8382 , CVE-2024-8383 , CVE-2024-8384 , CVE-2024-8386 , CVE-2024-8387 , CVE-2024-9680 Description The updated package provides Firefox 128 for all mandatory arches of Mageia (x86_64, i586 and aarch64), fixing several bugs, including security vulnerabilities, for i586 and aarch64: Fullscreen notification dialog can be obscured by document content. (CVE-2024-7518) Out of bounds memory access in graphics shared memory handling. (CVE-2024-7519) Type confusion in WebAssembly. (CVE-2024-7520) Incomplete WebAssembly exception handing. (CVE-2024-7521) Out of bounds read in editor component. (CVE-2024-7522) CSP strict-dynamic bypass using web-compatibility shims. (CVE-2024-7524) Missing permission check when creating a StreamFilter. (CVE-2024-7525) Uninitialized memory used by WebGL. (CVE-2024-7526) Use-after-free in JavaScript garbage collection. (CVE-2024-7527) Use-after-free in IndexedDB. (CVE-2024-7528) Document content could partially obscure security prompts. (CVE-2024-7529) WASM type confusion involving ArrayTypes. (CVE-2024-8385) Type confusion when looking up a property name in a "with" block. (CVE-2024-8381) Internal event interfaces were exposed to web content when browser EventHandler listener callbacks ran. (CVE-2024-8382) links in an external application. (CVE-2024-8383: Firefox did not ask before openings news) Garbage collection could mis-color cross-compartment objects in OOM conditions. (CVE-2024-8384) SelectElements could be shown over another site if popups are allowed. (CVE-2024-8386) Memory safety bugs fixed in Firefox 130, Firefox ESR 128.2, and Thunderbird 128.2. (CVE-2024-8387) Compromised content process can bypass site isolation. (CVE-2024-9392) Cross-origin access to PDF contents through multipart responses. (CVE-2024-9393) Cross-origin access to JSON contents through multipart responses. (CVE-2024-9394) Clipboard write permission bypass. (CVE-2024-8900) Potential memory corruption may occur when cloning certain objects. (CVE-2024-9396) Potential directory upload bypass via clickjacking. (CVE-2024-9397) External protocol handlers could be enumerated via popups. (CVE-2024-9398) Specially crafted WebTransport requests could lead to denial of service. (CVE-2024-9399) Potential memory corruption during JIT compilation. (CVE-2024-9400) Memory safety bugs fixed in Firefox 131, Firefox ESR 115.16, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3. (CVE-2024-9401) Memory safety bugs fixed in Firefox 131, Firefox ESR 128.3, Thunderbird 131, and Thunderbird 128.3. (CVE-2024-9402) Use-after-free in Animation timeline. (CVE-2024-9680) References

• https://bugs.mageia.org/show_bug.cgi?id=33607
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7519
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7520
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7521
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7522
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7524
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7525
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7526
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7527
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7528
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7529
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8385
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8381
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8382
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8383
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8384
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8386
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-8387
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-9680

SRPMS 9/core

• firefox-128.3.1-3.mga9

Add some more config notes

← Older revision Revision as of 15:48, 24 October 2024 Line 2: Line 2:     Sympa is storing its parameters in a sort of "file database" of it's own in  /var/blah/sympa/<listname>/config The data files look like flat text configuration files with a weird organization... json or yaml would be so much clear and easy to manage. When we use the Sympa administration UI it fully rewrites the file (one per list) completely, changing the order in a way it alone knows. Sympa is storing its parameters in a sort of "file database" of it's own in  /var/blah/sympa/<listname>/config The data files look like flat text configuration files with a weird organization... json or yaml would be so much clear and easy to manage. When we use the Sympa administration UI it fully rewrites the file (one per list) completely, changing the order in a way it alone knows.  +  ==Puppet set up== ==Puppet set up==  +  Puppet has been set up (intelligent way to manage this but really unconventional use... I think Sympa's guys would be shocked) to control these data files as if they were human defined config files. So each configuration change made through admin interface is reverted in a matter of 30  minutes by puppet. Which explains the frustration  of all those who tried to play with this admin interface in Sympa. The hard part is that the tiniest change modifies nearly all the file, so diff is useless here... i had to print the file before and after and use a pencil to cross the unmodified parts to spot what changes were important. At the moment i have no brilliant idea, no idea at all would be more accurate, about how to manage this better. Puppet has been set up (intelligent way to manage this but really unconventional use... I think Sympa's guys would be shocked) to control these data files as if they were human defined config files. So each configuration change made through admin interface is reverted in a matter of 30  minutes by puppet. Which explains the frustration  of all those who tried to play with this admin interface in Sympa. The hard part is that the tiniest change modifies nearly all the file, so diff is useless here... i had to print the file before and after and use a pencil to cross the unmodified parts to spot what changes were important. At the moment i have no brilliant idea, no idea at all would be more accurate, about how to manage this better.  +  +== Configuration Notes ==     In the puppet "Sympa" module there is now a variable named "critical", false by default. If we set it to true the list archive and subscription get restricted. So we will be able to reuse this easily for other lists if the need appears later. In the puppet "Sympa" module there is now a variable named "critical", false by default. If we set it to true the list archive and subscription get restricted. So we will be able to reuse this easily for other lists if the need appears later.  +  +When sender_subscriber=true (a.k.a. allow_subscriber=true) then all subscribers to the list are allowed to send to the list as well. However, what isn't obvious is that ''anyone'' with a @mageia.org may also send to the list, whether subscribed or not.  +  +If automated e-mails are expected to be sent to a group, make sure the From: address is included in sender_email. This isn't necessary if sender_subscriber=true and the mail comes from @mageia.org.     [[Category:Sysadmin]] [[Category:Sysadmin]] Danf

‎Sympa Configuration: slight changes to improve readability

← Older revision Revision as of 15:43, 24 October 2024 Line 1: Line 1:  = Sympa Configuration = = Sympa Configuration =    −Sympa is storing its parameters in a sort of "file database" of it's own in  /var/blah/sympa/<listname>/config The data files look like flat text configuration files with a weird organization... json or yaml would be so much clear and easy to manage. When we use the Sympa administration UI it fully rewrites the file (one per list) completely, changing the order in a way it alone knows. Puppet has been set up (intelligent way to manage this but really unconventional use... I think Sympa's guys would be shocked) to control these data files as if they were human defined config files. So each configuration change made through admin interface is reverted in a matter of 30  minutes by puppet. Which explains the frustration  of all those who tried to play with this admin interface in Sympa. The hard part is that the tiniest change modifies nearly all the file, so diff is useless here... i had to print the file before and after and use a pencil to cross the unmodified parts to spot what changes were important. At the moment i have no brilliant idea, no idea at all would be more accurate, about how to manage this better.+Sympa is storing its parameters in a sort of "file database" of it's own in  /var/blah/sympa/<listname>/config The data files look like flat text configuration files with a weird organization... json or yaml would be so much clear and easy to manage. When we use the Sympa administration UI it fully rewrites the file (one per list) completely, changing the order in a way it alone knows.  +==Puppet set up==  +Puppet has been set up (intelligent way to manage this but really unconventional use... I think Sympa's guys would be shocked) to control these data files as if they were human defined config files. So each configuration change made through admin interface is reverted in a matter of 30  minutes by puppet. Which explains the frustration  of all those who tried to play with this admin interface in Sympa. The hard part is that the tiniest change modifies nearly all the file, so diff is useless here... i had to print the file before and after and use a pencil to cross the unmodified parts to spot what changes were important. At the moment i have no brilliant idea, no idea at all would be more accurate, about how to manage this better.    −In the puppet "Sympa" module a variable named "critical", false by default, if we set it to true the list archive and subscription get restricted. So we will be able to reuse this easily for other lists if the need appears later.+In the puppet "Sympa" module there is now a variable named "critical", false by default. If we set it to true the list archive and subscription get restricted. So we will be able to reuse this easily for other lists if the need appears later.     [[Category:Sysadmin]] [[Category:Sysadmin]] Marja

Create page with information by Maât

New page

= Sympa Configuration =

Sympa is storing its parameters in a sort of "file database" of it's own in  /var/blah/sympa/<listname>/config The data files look like flat text configuration files with a weird organization... json or yaml would be so much clear and easy to manage. When we use the Sympa administration UI it fully rewrites the file (one per list) completely, changing the order in a way it alone knows. Puppet has been set up (intelligent way to manage this but really unconventional use... I think Sympa's guys would be shocked) to control these data files as if they were human defined config files. So each configuration change made through admin interface is reverted in a matter of 30  minutes by puppet. Which explains the frustration  of all those who tried to play with this admin interface in Sympa. The hard part is that the tiniest change modifies nearly all the file, so diff is useless here... i had to print the file before and after and use a pencil to cross the unmodified parts to spot what changes were important. At the moment i have no brilliant idea, no idea at all would be more accurate, about how to manage this better.

In the puppet "Sympa" module a variable named "critical", false by default, if we set it to true the list archive and subscription get restricted. So we will be able to reuse this easily for other lists if the need appears later.

[[Category:Sysadmin]] Danf

‎Members

← Older revision Revision as of 14:12, 24 October 2024 Line 14: Line 14:     * David Walser <luigiwalser@yahoo.com> * David Walser <luigiwalser@yahoo.com>  +* Nicolas Salguero (ns80) <ns80 AT mageia DOT org     === Policies === === Policies === Marja

‎Update the Maintdb: Add a safer version

← Older revision Revision as of 20:32, 23 October 2024 Line 14: Line 14:     To unassign a package on behalf of another user, run this command on the pkgsubmit host (currently duvel): To unassign a package on behalf of another user, run this command on the pkgsubmit host (currently duvel):  +<pre>  +sudo -u maintdb /usr/local/sbin/maintdb OLDUSER set PACKAGE nobody  +</pre>  +where PACKAGE is the package name, OLDUSER is the user who will be removed and nobody is the user to which the package will be assigned.  +  +The raw (read: dangerous) alternative with fewer checks is to run this instead:  <pre> <pre>  sudo -u maintdb sh -c 'cat "/var/lib/maintdb/db/$1" && echo "$2" >"/var/lib/maintdb/db/$1"' x PACKAGE nobody sudo -u maintdb sh -c 'cat "/var/lib/maintdb/db/$1" && echo "$2" >"/var/lib/maintdb/db/$1"' x PACKAGE nobody  </pre> </pre> −where PACKAGE is the package name and nobody is the user to which the package will be assigned. The previous maintainer's ID will be displayed when done. If the package name is invalid, an error message will be displayed and no reassignment will take place.+The previous maintainer's ID will be displayed when done. If the package name is invalid, an error message will be displayed and no reassignment will take place. Danf

Add distrib

← Older revision Revision as of 18:33, 23 October 2024 Line 8: Line 8:     Source RPMs also contain the binrepo files, so if a file is removed from binrepo it can be recovered from the associated .src.rpm (assuming we have it around in a long-term archive). So, if a file was in a src.rpm for an obsolete mga release, if we can recover it if needed, and if it is no longer used in cauldron or any current mga release, then it should be fine to remove it. Source RPMs also contain the binrepo files, so if a file is removed from binrepo it can be recovered from the associated .src.rpm (assuming we have it around in a long-term archive). So, if a file was in a src.rpm for an obsolete mga release, if we can recover it if needed, and if it is no longer used in cauldron or any current mga release, then it should be fine to remove it.  +  +== distrib ==  +This holds all RPMs and metadata for all supported releases. When this fills, nobody can build any more packages. One strategy to free space is to hard link identical RPMs between bootstrap and mirror for cauldron. Another is to remove obsolete and unsupported releases, although you must first ensure the files are available elsewhere in case we need to fulfill any obligations under the GPL (and other licenses) to provide source code (this responsibility may not actually apply, but you need to be sure about that before deleting).     == Expanding partitions == == Expanding partitions == Danf

Publication date: 23 Oct 2024
Type: bugfix
Affected Mageia releases : 9
Description After installing FreeFileSync, no icon appears in the Plasma menu for FreeFileSync or RealTimeSync. References

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

SRPMS 9/core

• freefilesync-12.5-1.4.mga9