Lector de Feeds

← Older revision Revision as of 08:58, 29 May 2025 Line 2: Line 2:  [[Category:Mageia 9]] [[Category:Mageia 9]]    −{{multi language banner-de|[[Mageia 9 Errata-de|Deutsch]] ; [[Mageia 9 Errata|English]] ; [[Erratas de Mageia 9-es|Español]] ; [[Mageia 9 Errata-fr|Français]] ; [[Mageia 9 Errata-pt-PT|Português (Portugal)]] ; [[Errata_do_Mageia_9-pt-BR|português brasileiro]]}}+{{multi language banner-de|[[Mageia 9 Errata-de|Deutsch]] ; [[Mageia 9 Errata|English]] ; [[Erratas de Mageia 9-es|Español]] ; [[Mageia 9 Errata-fr|Français]] ; [[Mageia 9 Errata-pt-PT|Português (Portugal)]] ; [[Errata_do_Mageia_9-pt-BR|português brasileiro]]}}     == Hinweis == == Hinweis == Line 44: Line 44:     === Live Installer === === Live Installer === −{{bug|33135}} '''Wenn ein aktualisiertes Live'''-System verwendet wird (durch Persistenz oder es wurde während der Verwendung aktualisiert) und es besteht keine Internetverbindung bei der Installation, allerdings Aktualisierungen für grub2 oder dessen Abhängingkeiten angeboten werden, wird der Installer beim letzen Schritt der Installation fehlschlagen, da die benötigten Pakete nicht geladen werden können.  '''WORKAROUND''' ist, die '''Online Repositorien zu deaktivieren bevor der Installer gestartet wird'''. Beachten Sie, dass die internen, voreingestellten Live Repositorien aktiviert sein müssen. Für weiterführende Informationen, siehe [[Install_to_removable_device#Using_the_Live_installer|die Hinweise zum Live Installer]].+{{bug|33135}} '''Wenn ein aktualisiertes Live'''-System verwendet wird (durch Persistenz oder es wurde während der Verwendung aktualisiert) und es besteht keine Internetverbindung bei der Installation, allerdings Aktualisierungen für grub2 oder dessen Abhängigkeiten angeboten werden, wird der Installer beim letzen Schritt der Installation fehlschlagen, da die benötigten Pakete nicht geladen werden können.  '''WORKAROUND''' ist, die '''Online Repositorien zu deaktivieren bevor der Installer gestartet wird'''. Beachten Sie, dass die internen, voreingestellten Live Repositorien aktiviert sein müssen. Für weiterführende Informationen, siehe [[Install_to_removable_device#Using_the_Live_installer|die Hinweise zum Live Installer]].     ==== Beibehaltung eines Bootloaders eines Drittanbieters ==== ==== Beibehaltung eines Bootloaders eines Drittanbieters ==== Line 88: Line 88:  Mit Venroy müssen Sie nicht das Laufwerk jedes Mal neu formatieren - Sie müssen nur die ISO/WIM/IMG/VHD(x)/EFI Dateien auf das USB-Laufwerk kopieren und direkt von dieser starten. Mit Venroy müssen Sie nicht das Laufwerk jedes Mal neu formatieren - Sie müssen nur die ISO/WIM/IMG/VHD(x)/EFI Dateien auf das USB-Laufwerk kopieren und direkt von dieser starten.    −Nach dem starten eines Netzwerk-Abbilds, wenn die Quelle der Mageia Installation (kann eine klassische Installer-DVD oder eine lokale Kopie von Mageias Baumstruktur der Dateien sein) sich in der als '''Ventoy''' bezeichneten Partiton befindet (z. B. in dem die ISO-Abbilder gespeichert sein müssen), müssen Sie möglicherweise das USB-Gerät abstecken und erneut anstecken um Zugriff auf die Partiton zu erhalten. [https://bugs.mageia.org/show_bug.cgi?id=28371#c23 Comment#23 in mga#28371]+Nach dem starten eines Netzwerk-Abbilds, wenn die Quelle der Mageia Installation (kann eine klassische Installer-DVD oder eine lokale Kopie von Mageias Baumstruktur der Dateien sein) sich in der als '''Ventoy''' bezeichneten Partiton befindet (z. B. in dem die ISO-Abbilder gespeichert sein müssen), müssen Sie möglicherweise das USB-Gerät abstecken und erneut anstecken um Zugriff auf die Partition zu erhalten. [https://bugs.mageia.org/show_bug.cgi?id=28371#c23 Comment#23 in mga#28371]     Eine andere Umgehungsmöglichkeit ist es, beim Formatieren des USB-Geräts mit Ventoy, etwas Speicherplatz zu reserverieren, die Partition mit einem der unterstützten Dateisystemen des Installers zu formatieren und die Quelle der Mageiainstallation in diese Partition zu speichern ([https://bugs.mageia.org/show_bug.cgi?id=28371#c33 Kommentar 33 in mga#28371]). Eine andere Umgehungsmöglichkeit ist es, beim Formatieren des USB-Geräts mit Ventoy, etwas Speicherplatz zu reserverieren, die Partition mit einem der unterstützten Dateisystemen des Installers zu formatieren und die Quelle der Mageiainstallation in diese Partition zu speichern ([https://bugs.mageia.org/show_bug.cgi?id=28371#c33 Kommentar 33 in mga#28371]).    −Beachte: Natürlich können Sie, wenn Sie eine der klassichen DVD-Installationsabbilder haben, diese statdessen direkt in Ventoys Startmenü auswählen.+Beachte: Natürlich können Sie, wenn Sie eine der klassichen DVD-Installationsabbilder haben, diese stattdessen direkt in Ventoys Startmenü auswählen.     === Den klassischen 32-Bit Installer als Repository auf einem USB-Stick verwenden === === Den klassischen 32-Bit Installer als Repository auf einem USB-Stick verwenden === Line 114: Line 114:  {{Bug|31095}} Beim Ausführen von '''Mageia 9 Plasma als VirtualBox Gast''' muss die 3D Beschleunigung in den Gast-Einstellungen aktiviert werden. {{Bug|31095}} Beim Ausführen von '''Mageia 9 Plasma als VirtualBox Gast''' muss die 3D Beschleunigung in den Gast-Einstellungen aktiviert werden.    −{{Bug|32182}} - '''Inkompatible OpenGL Unterstützung mit alten GPUs.''' Beispiel: '''Blender''' zeigt keinen Text in den Menüs und Dialogen - Möglicherweise ist weitere Software mit anderen Symptomen betroffen. Selten. Wenn Sie eine alte GPU verwenden für den kein moderner Treiber zur Verfügung steht, wird möglicherweise OpenGL für einige Anwendungen nicht weit genug unterstützt. Ein Symptom ist es, dass Sie die Meldung "[INVALID_OPCODE]" im Journal sehen. Um den Treiber zu wechseln, Protokolle anzusehen, usw., siehe  [[Grafischen_Server_aufsetzen-de|hier]]. Hierbei handelt es sich ein komplexes Problem bezüglich der Anforderungen der Anwendung und der verwendeten GPU. Bezüglich des Beispiels funktioniert häufig nouveau+modesettings zu verwenden, jedoch schlägt dies bei anderen Nvidia GPUs fehl. '''Teilweise BEHOBEN''' durch Aktualisierungen. Jedoch können nicht alle Fälle bei älterer Hardware abgedeckt werden. '''Workarounds:''' 1.)versuchen Sie einen anderen Treiber. 2.) Versuchen Sie es ohne die modesetting (falls Sie diese verwenden) oder wechseln Sie zu modesetting. 3.) Deaktivieren Sie die Hardwarebeschleunigung: {{prog|Mageia Kontrollzentrum}}, Abschnitt {{menu|Hardware > Grafischen Server einrichten}}, {{menu|Optionen}}) und aktivieren Sie die Box "Hardwarebeschleunigung deaktvieren" (verfügbar nur bei intel, amdgpu, nvidia proprietärer Treiber, nouveau und modesetting).+{{Bug|32182}} - '''Inkompatible OpenGL Unterstützung mit alten GPUs.''' Beispiel: '''Blender''' zeigt keinen Text in den Menüs und Dialogen - Möglicherweise ist weitere Software mit anderen Symptomen betroffen. Selten. Wenn Sie eine alte GPU verwenden für den kein moderner Treiber zur Verfügung steht, wird möglicherweise OpenGL für einige Anwendungen nicht weit genug unterstützt. Ein Symptom ist es, dass Sie die Meldung "[INVALID_OPCODE]" im Journal sehen. Um den Treiber zu wechseln, Protokolle anzusehen, usw., siehe  [[Grafischen_Server_aufsetzen-de|hier]]. Hierbei handelt es sich ein komplexes Problem bezüglich der Anforderungen der Anwendung und der verwendeten GPU. Bezüglich des Beispiels funktioniert häufig nouveau+modesettings zu verwenden, jedoch schlägt dies bei anderen Nvidia GPUs fehl. '''Teilweise BEHOBEN''' durch Aktualisierungen. Jedoch können nicht alle Fälle bei älterer Hardware abgedeckt werden. '''Workarounds:''' 1.)versuchen Sie einen anderen Treiber. 2.) Versuchen Sie es ohne die modesetting (falls Sie diese verwenden) oder wechseln Sie zu modesetting. 3.) Deaktivieren Sie die Hardwarebeschleunigung: {{prog|Mageia Kontrollzentrum}}, Abschnitt {{menu|Hardware > Grafischen Server einrichten}}, {{menu|Optionen}}) und aktivieren Sie die Box "Hardwarebeschleunigung deaktivieren" (verfügbar nur bei intel, amdgpu, nvidia proprietärer Treiber, nouveau und modesetting).     === AMD/ATI === === AMD/ATI === Line 129: Line 129:  Verwenden Sie zu erst {{cmd-de|drakx11}} ({{prog-de|Mageia Kontrollzentrum}}, Abschnitt {{menu-de|Hardware > Grafischen Server einrichten}}, {{menu-de|Grafikkarte}}) um den Treiber ''"ATI radeon HD 4870 und früher"'' auszuwählen (zumindest für Bonaire Karten). Verwenden Sie zu erst {{cmd-de|drakx11}} ({{prog-de|Mageia Kontrollzentrum}}, Abschnitt {{menu-de|Hardware > Grafischen Server einrichten}}, {{menu-de|Grafikkarte}}) um den Treiber ''"ATI radeon HD 4870 und früher"'' auszuwählen (zumindest für Bonaire Karten).    −Falls das Starten im grafischen Modus fehlschlägt, nutzen Sie die Tasten {{keypress|Strg}}+{{keypress|Alt}}+{{keypress|F3}} (oder starten Sie im Rettungmodus neu) um eine Konsole zu öffnen und {{cmd-de|drakx11}} auszuführen, um einen anderen Treiber auszuwählen und anschließend mit dem Befehl {{cmd-de|reboot}} das System neu zu starten.+Falls das Starten im grafischen Modus fehlschlägt, nutzen Sie die Tasten {{keypress|Strg}}+{{keypress|Alt}}+{{keypress|F3}} (oder starten Sie im Rettungsmodus neu) um eine Konsole zu öffnen und {{cmd-de|drakx11}} auszuführen, um einen anderen Treiber auszuwählen und anschließend mit dem Befehl {{cmd-de|reboot}} das System neu zu starten.     ==== AMD OpenCL ==== ==== AMD OpenCL ==== Line 205: Line 205:     ==== Plasma mit Wayland ==== ==== Plasma mit Wayland ==== −{{Bug|31841}} (verschiedene Probleme), {{Bug|31984}} (Aufwachen aus dem Schalfmodus)+{{Bug|31841}} (verschiedene Probleme), {{Bug|31984}} (Aufwachen aus dem Schlafmodus)     == Software == == Software == Line 257: Line 257:  {{Bug|32135}} - '''Gramps''': Die Größe des Bereichs kann nicht angepasst werden. Manuelle Behebung [https://bugs.mageia.org/show_bug.cgi?id=32135#c3 im Bugreport] beschrieben. {{Bug|32135}} - '''Gramps''': Die Größe des Bereichs kann nicht angepasst werden. Manuelle Behebung [https://bugs.mageia.org/show_bug.cgi?id=32135#c3 im Bugreport] beschrieben.    −'''BEHOBEN DURCH [https://advisories.mageia.org/MGAA-2023-0077.html EINE AKTUALISIERUNG]:''' im Setember 2023: Nun wird die ext4 Eigenschaft C12 unterstützt. {{Bug|32136}} - '''fsarchiver''' kommt nicht mit [[#Das_ext4_Feature_C12,_wird_nicht_von_älteren_fsck_erkannt|der neuen ext4 Version zurecht]] welches einige andere Distributionen und zukünftige Mageia Veröffentlichungen verwenden (und Mageia 9 bis zur Beta2 nutzte). Das selbe Problem betrifft '''qt-fsarchiver / qt-fsarchiver-terminal''', mit der Hürde, dass  qt-fsarchiver scheinbar im Upstream nicht mehr betreut wird. Probleme bezüglich ''erstellen'' von Datensicherungen - Es funktioniert die alten Datensicherungen wieder herzustellen trotz der Formatierung der Zielpartition, da fsarchiver die Partitionen entsprechend der Sicherung formatiert. '''qt-fsarchiver''' hat einige zusätzliche Macken: es benötigt sudo und fragt ein weiteres Mal nach dem Anwenderkennwort - ''Einzelheiten hierzu finden Sie in den Bugreports.'' Tipp: Fügen Sie sich selbst der "wheel"-Gruppe hinzu.+'''BEHOBEN DURCH [https://advisories.mageia.org/MGAA-2023-0077.html EINE AKTUALISIERUNG]:''' im September 2023: Nun wird die ext4 Eigenschaft C12 unterstützt. {{Bug|32136}} - '''fsarchiver''' kommt nicht mit [[#Das_ext4_Feature_C12,_wird_nicht_von_älteren_fsck_erkannt|der neuen ext4 Version zurecht]] welches einige andere Distributionen und zukünftige Mageia Veröffentlichungen verwenden (und Mageia 9 bis zur Beta2 nutzte). Das selbe Problem betrifft '''qt-fsarchiver / qt-fsarchiver-terminal''', mit der Hürde, dass  qt-fsarchiver scheinbar im Upstream nicht mehr betreut wird. Probleme bezüglich ''erstellen'' von Datensicherungen - Es funktioniert die alten Datensicherungen wieder herzustellen trotz der Formatierung der Zielpartition, da fsarchiver die Partitionen entsprechend der Sicherung formatiert. '''qt-fsarchiver''' hat einige zusätzliche Macken: es benötigt sudo und fragt ein weiteres Mal nach dem Anwenderkennwort - ''Einzelheiten hierzu finden Sie in den Bugreports.'' Tipp: Fügen Sie sich selbst der "wheel"-Gruppe hinzu.     {{Bug|32262}} - '''CodeBlocks''' wurde aus Mageia 9 fälschlicherweise entfernt. Wird wieder hinzugefügt werden. {{Bug|32262}} - '''CodeBlocks''' wurde aus Mageia 9 fälschlicherweise entfernt. Wird wieder hinzugefügt werden. Line 265: Line 265:  '''BEHOBEN DURCH EINE [https://advisories.mageia.org/MGAA-2024-0074.html AKTUALISIERUNG]:''' {{Bug|32467}} - '''Waydroid''' hatte unter Mageia 9 nicht funktioniert. Eine Aktualisierung, welche das Problem behob, wurde am 27. Februar 2024 veröffentlicht. Beachten Sie, dass Sie die richtige Version von lxc installiert haben - Schauen Sie hierfür in den Bugreport 32687, bezüglich lxc, weiter unten! Bei Kernel vor 6.6.14 benötigen Sie dkms-anbox und müssen manuelle Anpassungen, beschrieben im Bugreport, durchführen. *Vermeiden* Sie für Kernel ab 6.6.14 dkms-anbox! Es wird nicht mehr länger benötigt - Siehe Bug 32797 weiter unten. '''BEHOBEN DURCH EINE [https://advisories.mageia.org/MGAA-2024-0074.html AKTUALISIERUNG]:''' {{Bug|32467}} - '''Waydroid''' hatte unter Mageia 9 nicht funktioniert. Eine Aktualisierung, welche das Problem behob, wurde am 27. Februar 2024 veröffentlicht. Beachten Sie, dass Sie die richtige Version von lxc installiert haben - Schauen Sie hierfür in den Bugreport 32687, bezüglich lxc, weiter unten! Bei Kernel vor 6.6.14 benötigen Sie dkms-anbox und müssen manuelle Anpassungen, beschrieben im Bugreport, durchführen. *Vermeiden* Sie für Kernel ab 6.6.14 dkms-anbox! Es wird nicht mehr länger benötigt - Siehe Bug 32797 weiter unten.    −'''BEHOBEN durch eine Aktualisierung''' von {{Bug|32525}} (fontconfig) : '''Beim Rendern von Schriftarten, zum Beispiel bei der PDF Vorschau in Firefox und Thunderbird''', werden einige PDF Dokumente, welche keine standardmäßige Schriftarten verwenden, fehlerhaft angezeigt. ''Workaround in Firefox, bevor die Behebung veröffentlich wurde: Im Adressfeld "about:config" angeben und im anschließenden Suchfeld "browser.display.use_document_fonts", dort den Wert "1" auf "0" ändern.''+'''BEHOBEN durch eine Aktualisierung''' von {{Bug|32525}} (fontconfig) : '''Beim Rendern von Schriftarten, zum Beispiel bei der PDF Vorschau in Firefox und Thunderbird''', werden einige PDF Dokumente, welche keine standardmäßige Schriftarten verwenden, fehlerhaft angezeigt. ''Workaround in Firefox, bevor die Behebung veröffentlicht wurde: Im Adressfeld "about:config" angeben und im anschließenden Suchfeld "browser.display.use_document_fonts", dort den Wert "1" auf "0" ändern.''     {{Bug|32636}} - '''Bitmap Schriftarten fehlerhaft''' durch die fontconfig Aktualisierung {{bug|32525}} {{Bug|32636}} - '''Bitmap Schriftarten fehlerhaft''' durch die fontconfig Aktualisierung {{bug|32525}} Line 275: Line 275:  {{Bug|32806}} - '''rtorrent''' stürzt ab (und wird automatisch neu gestartet). Upstream. {{Bug|32806}} - '''rtorrent''' stürzt ab (und wird automatisch neu gestartet). Upstream.    −{{Bug|33330}} - '''aegisub stürzt beim Starten in eine wayland Session ab. - WORKAROUND:''' Starten Sie diese von der Befehlszeile über folgenden Befehl: {{cmd|<nowiki>env GDK_BACKEND=x11 aegisub</nowiki>}}.+'''BEHOBEN DURCH [https://advisories.mageia.org/MGAA-2025-0055.html EINE AKTUALISIERUNG]''' {{Bug|33330}} - '''aegisub''' stürzt beim Starten in eine wayland Session ab.     '''BEHOBEN DURCH EINE AKTUALISIERUNG''' {{Bug|33366}} -  Nach dem Ausführen von '''neochat''' in einer leichtgewichtigen Desktop-Umgebung, kann keine neue Sitzung gestartet werden, bis Sie die Anwendung über das Symbol in der Taskleiste schließen. Dieses Problem wurde durch eine Aktualisierung behoben, jedoch, wenn Sie bereits auf dieses Problem gestoßen waren, können Sie weiterhin keine neue Sitzung starten. Wir hoffen, dass Sie Ihre Accountdaten kennen, da Sie die Verzeichnisse {{folder|~/.local/share/KDE/neochat}}, {{file|~/.config/neochatrc}}, {{file|~/.config/KDE/neochat.conf}}, {{folder|~/.cache/KDE/neochat}} löschen müssen. '''BEHOBEN DURCH EINE AKTUALISIERUNG''' {{Bug|33366}} -  Nach dem Ausführen von '''neochat''' in einer leichtgewichtigen Desktop-Umgebung, kann keine neue Sitzung gestartet werden, bis Sie die Anwendung über das Symbol in der Taskleiste schließen. Dieses Problem wurde durch eine Aktualisierung behoben, jedoch, wenn Sie bereits auf dieses Problem gestoßen waren, können Sie weiterhin keine neue Sitzung starten. Wir hoffen, dass Sie Ihre Accountdaten kennen, da Sie die Verzeichnisse {{folder|~/.local/share/KDE/neochat}}, {{file|~/.config/neochatrc}}, {{file|~/.config/KDE/neochat.conf}}, {{folder|~/.cache/KDE/neochat}} löschen müssen. Line 431: Line 431:  FEATURE_C12 ist die orphan_file Eigenschaft, welche in e2fsprogs 1.47.0 standardmäßig aktiviert ist. Problem: Andere Systeme die fsck in einer älteren Version anbieten, zum Beispiel Mageia 8, sind nicht in der Lage, diese zu überprüfen. {{Bug|31641}}. '''Diese Eigenschaft wurde vor einiger Zeit in Cauldron aktiviert,''' wurde jedoch aufgrund der Kompatibilität, anhand von Konfigurationseinstellungen in Mageia 9, nun deaktiviert. (metadata_csum_seed und orphan_file wurden aus /etc/mke2fs.conf entfernt) FEATURE_C12 ist die orphan_file Eigenschaft, welche in e2fsprogs 1.47.0 standardmäßig aktiviert ist. Problem: Andere Systeme die fsck in einer älteren Version anbieten, zum Beispiel Mageia 8, sind nicht in der Lage, diese zu überprüfen. {{Bug|31641}}. '''Diese Eigenschaft wurde vor einiger Zeit in Cauldron aktiviert,''' wurde jedoch aufgrund der Kompatibilität, anhand von Konfigurationseinstellungen in Mageia 9, nun deaktiviert. (metadata_csum_seed und orphan_file wurden aus /etc/mke2fs.conf entfernt)    −'' '''Falls Sie Mageia 9 vor mitte Juni 2023''' (Beta 2 oder ältere ISOs) installiert haben und ext4 Partitionen damit formatiert haben, '''besitzen diese die Eigenschaft welche zum Beispiel von Mageia 8 nicht erkannt wird.'' Auch wenn Sie Werkzeuge wie zum Beispiel '''IsoDumper''', von solchen Vorveröffentlichungen verwenden, ohne  /etc/mke2fs.conf zu bearbeiten, wird es eine ext4 Partition (z. B. für Persistenz) erstellen, welche von den Mageia 8 oder 7 Live-Medien nicht verwendet werden kann - {{Bug|32006}}, '''Workaround''' [[Persistent_live_systems#Ext4_option_difference|hier]].''+'' '''Falls Sie Mageia 9 vor Mitte Juni 2023''' (Beta 2 oder ältere ISOs) installiert haben und ext4 Partitionen damit formatiert haben, '''besitzen diese die Eigenschaft welche zum Beispiel von Mageia 8 nicht erkannt wird.'' Auch wenn Sie Werkzeuge wie zum Beispiel '''IsoDumper''', von solchen Vorveröffentlichungen verwenden, ohne  /etc/mke2fs.conf zu bearbeiten, wird es eine ext4 Partition (z. B. für Persistenz) erstellen, welche von den Mageia 8 oder 7 Live-Medien nicht verwendet werden kann - {{Bug|32006}}, '''Workaround''' [[Persistent_live_systems#Ext4_option_difference|hier]].''     Die Eigenschaft, wenn aktiviert, beschleunigt den Workload beim parallelen löschen oder abschneiden von großen Anzahlen an Dateien. Als erstes durch den Linux Kernel 5.15 unterstützt. Die Eigenschaft, wenn aktiviert, beschleunigt den Workload beim parallelen löschen oder abschneiden von großen Anzahlen an Dateien. Als erstes durch den Linux Kernel 5.15 unterstützt. Psyca

Publication date: 28 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-48708 Description gs_lib_ctx_stash_sanitized_arg in base/gslibctx.c in Artifex Ghostscript before 10.05.1 lacks argument sanitization for the # case. A created PDF document includes its password in cleartext. (CVE-2025-48708) References

• https://bugs.mageia.org/show_bug.cgi?id=34307
• https://www.openwall.com/lists/oss-security/2025/05/23/2
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-48708

SRPMS 9/core

• ghostscript-10.05.1-1.mga9

Publication date: 28 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-26540 Description A heap-based buffer overflow in Clmg before 3.3.3 can occur via a crafted file to cimg_library::CImg::_load_analyze. (CVE-2024-26540) References

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

SRPMS 9/core

• cimg-3.2.5-1.1.mga9

Google, Gandi, Tumblr, Oracle, MADB, Scaleway

← Older revision Revision as of 19:06, 28 May 2025 Line 1: Line 1:  [[Category:Sysadmin]] [[Category:Sysadmin]] −Add here each webservice we use, and who has the login and password :+Add here each webservice we use, and who has the login and password:     *  [https://bsky.app/profile/mageialinux.bsky.social bluesky]: codegazer *  [https://bsky.app/profile/mageialinux.bsky.social bluesky]: codegazer  *  [http://cia.vc/stats/project/Mageia cia.vc]: ? *  [http://cia.vc/stats/project/Mageia cia.vc]: ?  *  [https://www.dailymotion.com/tilalo-Mageia DailyMotion]: dams/boklm/ennael/rda/rtp *  [https://www.dailymotion.com/tilalo-Mageia DailyMotion]: dams/boklm/ennael/rda/rtp −*  [https://www.scaleway.com/en/dedibox/ Dedibox] ( rabbit ): misc, ennael+*  [https://www.scaleway.com/en/dedibox/ Dedibox/Scaleway] (rabbit): misc, ennael  *  [https://dlvrit.com/ dlvr.it]: dams/boklm/ennael/rda/rtp *  [https://dlvrit.com/ dlvr.it]: dams/boklm/ennael/rda/rtp  *  [https://hub.docker.com/_/mageia Docker Hub]: juancho *  [https://hub.docker.com/_/mageia Docker Hub]: juancho Line 12: Line 12:  *  [https://www.gandi.net/ Gandi] DNS: neoclust/pterjan/dams/boklm/ennael/rda/rtp *  [https://www.gandi.net/ Gandi] DNS: neoclust/pterjan/dams/boklm/ennael/rda/rtp  *  [https://www.gandi.net/ Gandi] VM: dams/boklm/ennael/rda/rtp *  [https://www.gandi.net/ Gandi] VM: dams/boklm/ennael/rda/rtp −*  [https://plus.google.com/+mageia Google]: dams/boklm/ennael/rda/rtp+*  [https://www.gandi.net/ Gandi] certificates: neoclust  +*  [https://plus.google.com/+mageia Google+]: dams/boklm/ennael/rda/rtp  +*  Google apikeys: pterjan  *  [https://identi.ca/mageia identica]: dams/boklm/ennael/rda/rtp *  [https://identi.ca/mageia identica]: dams/boklm/ennael/rda/rtp  *  [https://www.linkedin.com/company/mageia.org LinkedIn]: ? *  [https://www.linkedin.com/company/mageia.org LinkedIn]: ? −*  [https://matrix.to/#/#mageia-space:matrix.org matrix.org]: ngompa, neoclust, akien+*  [https://matrix.to/#/#mageia-space:matrix.org matrix.org]: ngompa/neoclust/akien  +*  [https://www.oracle.com/cloud/compute/ Oracle cloud (ociaa1)]: pterjan  *  [https://www.ovhcloud.com/ OVH DNS] ([http://bonjourmageia.fr  bonjourmageia.fr]):  ? *  [https://www.ovhcloud.com/ OVH DNS] ([http://bonjourmageia.fr  bonjourmageia.fr]):  ? −*  [https://www.mageialinux-online.com/ nFrance (madb)]: jybz/vouf+*  [https://www.mageialinux-online.org/ nFrance (madb)]: jybz/vouf/papoteur −*  tumbler account (bonjourmageia): dams/boklm/ennael/rda/rtp+*  [https://www.tumblr.com/bonjourmageia Tumbler]: dams/boklm/ennael/rda/rtp  *  [https://twitter.com/mageia_org X/Twitter]: dams/boklm/ennael/rda/rtp *  [https://twitter.com/mageia_org X/Twitter]: dams/boklm/ennael/rda/rtp  *  [https://wordpress.com/ wordpress.com]: neoclust *  [https://wordpress.com/ wordpress.com]: neoclust Line 24: Line 27:  *  [https://www.youtube.com/@MageiaLinux YouTube]: dams/boklm/ennael/rda/rtp *  [https://www.youtube.com/@MageiaLinux YouTube]: dams/boklm/ennael/rda/rtp    −A few credentials are available to those with root on duvel in /etc/puppet/extdata/common.csv+A few of these credentials are available to sysadmins with root on duvel in /etc/puppet/extdata/common.csv     == See also == == See also ==     [[Who has power-rights-credentials?]] [[Who has power-rights-credentials?]] Danf

Publication date: 27 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-3875 , CVE-2025-3877 , CVE-2025-3909 , CVE-2025-3932 , CVE-2025-4918 , CVE-2025-4919 Description Sender Spoofing via Malformed From Header in Thunderbird. (CVE-2025-3875) Unsolicited File Download, Disk Space Exhaustion, and Credential Leakage via mailbox:/// Links. (CVE-2025-3877) JavaScript Execution via Spoofed PDF Attachment and file:/// Link. (CVE-2025-3909) Tracking Links in Attachments Bypassed Remote Content Blocking. (CVE-2025-3932) Out-of-bounds access when resolving Promise objects. (CVE-2025-4918) Out-of-bounds access when optimizing linear sums. (CVE-2025-4919) References

• https://bugs.mageia.org/show_bug.cgi?id=34288
• https://www.thunderbird.net/en-US/thunderbird/128.10.1esr/releasenotes/
• https://www.mozilla.org/en-US/security/advisories/mfsa2025-34/
• https://www.thunderbird.net/en-US/thunderbird/128.10.2esr/releasenotes/
• https://www.thunderbird.net/en-US/thunderbird/128.10.2esr/releasenotes/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-3875
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-3877
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-3909
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-3932
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-4918
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-4919

SRPMS 9/core

• thunderbird-128.10.2-1.mga9
• thunderbird-l10n-128.10.2-1.mga9

Publication date: 27 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-29088 Description In SQLite 3.49.0 before 3.49.1, certain argument values to sqlite3_db_config (in the C-language API) can cause a denial of service (application crash). An sz*nBig multiplication is not cast to a 64-bit integer, and consequently some memory allocations may be incorrect. (CVE-2025-29088) References

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

SRPMS 9/core

• sqlite3-3.40.1-1.2.mga9

Publication date: 27 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-22247 Description VMware Tools contains an insecure file handling vulnerability. A malicious actor with non-administrative privileges on a guest VM may tamper the local files to trigger insecure file operations within that VM. (CVE-2025-22247) References

• https://bugs.mageia.org/show_bug.cgi?id=34271
• https://www.openwall.com/lists/oss-security/2025/05/12/2
• https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YDQBVVMNJB6EXDLSUNBCHZTNRBLXJEFU/
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-22247

SRPMS 9/core

• open-vm-tools-12.3.5-2.1.mga9

Publication date: 27 May 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2025-4918 , CVE-2025-4919 Description Out-of-bounds access when resolving Promise objects. (CVE-2025-4918) Out-of-bounds access when optimizing linear sums. (CVE-2025-4919) References

• https://bugs.mageia.org/show_bug.cgi?id=34287
• https://www.mozilla.org/en-US/firefox/128.10.1/releasenotes/
• https://www.mozilla.org/en-US/security/advisories/mfsa2025-37/
• https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_111.html
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-4918
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-4919

SRPMS 9/core

• rootcerts-20250424.00-1.mga9
• nss-3.111.0-1.mga9
• firefox-128.10.1-2.mga9
• firefox-l10n-128.10.1-1.mga9

First up, since it's short: a quick happy note on Strix Point support in Linux. I blogged about this earlier, with my HP Omnibook 14 Ultra laptop with Ryzen AI 9 365 CPU, and it wasn't going great. I figured out some workarounds, but in fact the video hang thing was still happening at that point, despite all the cargo-cult-y command line args. But as of recent 6.15 RCs, it has been more or less fixed! I can still pretty reliably cause one of these "VCN ring timeout" issues just by playing videos, but now the driver reliably recovers from them; my external display goes blank for a few seconds, then comes back and works as normal. Apparently that should also now be fixed, which is great news. I want to give kudos to the awesome AMD folks working on all these problems, they're doing a great job.

At one point during the 6.15 series suspend/resume broke, but it's been fixed. So as of now, support is looking pretty good for my use cases. I haven't tested lately whether Thunderbolt docking station issues have been fixed, as the cheap USB 3 hub is still working fine for what I need.

OK, onto the AI bit. Yeah, it's another Red Hat person posting about AI! If you're wondering why: it's because we have all been told to Do Something With AI And Write About It. So now you know.

I first tried doing something really-actually-useful-for-work with AI a couple of weeks ago. As part of my work on maintaining openQA for Fedora (the packages and our instances of it), I review the upstream git commit logs. I usually try to update the package at least every few months so this isn't overwhelming, but lately I let it go for nearly a year, so I had a year of openQA and os-autoinst messages to look through, which isn't fun. After spending three days or so going through the openQA logs manually, I figured I'd see how AI did at the same job.

I used Gemini, as we have a corporate account with it. I pasted the entire log into Gemini 2.0 Flash and asked it to summarize it for me from the point of view of a package maintainer. It started out okay, then seized up after handling about ten messages, blurping some clearly-intermediate output on a big batch of commits and stopping entirely.

So I tried 2.5 Pro instead, and it actually did a pretty decent job. It boiled things down a long way into five or six appropriate topic areas, with a pretty decent summary of each. It pretty much covered the appropriate things. I then asked it to re-summarize from the point of view of a system administrator, and again it did really pretty well, highlighting the appropriate areas of change that a sysadmin would be interested in. It wasn't 100% perfect, but then, my Puny Human Brain wasn't either. The AI summary probably had more useful detail than my brain had retained over three days of reading.

So for os-autoinst, I didn't do the puny human brain reading. I got Gemini to do the same two summaries for me, and did the package update and deployment based on those. It flagged up appropriate things for me to look at in the package update and test deployment, and it seems like it did fine, since the package built and the deployment is mostly working. For this purpose, it definitely seems useful.

But when it comes to code...seems like a bit of a different story. At a couple of points in the last couple of weeks I was feeling a bit mentally tired, and decided for a break it'd be fun to throw the thing I was working on at AI and see how it would cope. tl;dr summary: not terrible but not great. Details follow!

The first thing I did was throw this openQA template loading issue at it. This was one of those things that grew and grew, and I eventually spent a week or so on a pretty substantial PR to fix all the stuff I found. But at the time, I was focusing on two issues in the previous state of openqa-dump-templates which meant it would almost never dump any JobTemplates.

One was fairly obvious: the condition checked in line 220 is only ever going to be true if --full or --product was passed. $options{product}->{product_key($r->{product})} is only set in line 213 or as the value of --product, and that block is only hit if $options{full} is truth-y.

The other was much more subtle. The other check that can short-circuit JobTemplates dumping - line 219 - looks like it would only kick in if --group is passed, right? The very first condition is if $options{group}, after all. But in fact, a feature called autovivification causes $options{group} to be defined by a keys call earlier in the script even if --group was not passed at the command line. So due to this check we never dump any JobTemplates with group names (in practice, this is almost all of them) unless --group was passed. A lot of languages have something like autovivification, but the fact that it kicks in on a keys call like this is a pretty odd perl quirk. It took me a few hours to work this one out with my puny human brain.

I figured I'd see if Gemini (2.5 Pro again) could find the same issues. So I dumped the entire script into Gemini and asked it in what cases it would dump job templates. It appeared to analyze what the script does, but its initial conclusion mostly missed the problems:

"The script is designed to dump JobTemplates and will do so successfully if they exist on the server and are not completely filtered out. The most reliable ways to get a potentially non-empty JobTemplates array are to run the script with no arguments, specify JobTemplates explicitly, use --group X --full, or use --product Y JobTemplates. Using only --group X might lead to errors or an empty array due to the interaction with the product filter."

It did sort of notice the problem with the line 220 filter - that's what it means by "the interaction with the product filter" - but seemed to think it would only be an issue if --group was passed, which is not the case.

So I gave it a hint: "This is wrong. JobTemplates output is always empty if no arguments are passed. Can you see why?" It came back with an answer that solely blamed the product filter, which is closer. In retrospect I can see to some extent why it had trouble here: it correctly noticed that the product filter should actually cause the script to crash, not just return empty JobTemplates, because $options{product} is usually going to be undefined at this point. (To be fair, my puny human brain didn't notice this wrinkle at first). That was clearly baffling it a bit, because it hadn't noticed the autovivification problem which means the script never actually got to this filter line at all.

I wanted to try and get it to notice the autovivification problem, so I kept hinting it. I went through four rounds of hinting, giving it progressively more specific information on the nature of the problem and its location, and correcting it when it came up with wrong answers, but it never quite got there. At first it flat out insisted I was wrong, and the product filter was the only issue. Later it came up with a plausible-but-wrong explanation based on option parsing, presented with complete confidence. Eventually, when I pointed it to the exact block where the autovivification happens, it considered four possibilities:

• Is use Mojo::Base -strict less strict than use strict specifically for hash dereferencing?
• Is there a global error handler ($SIG{DIE}) active that catches the error, sets $options{group} somehow, and continues?
• Autovivification Anomaly?
• Version Mismatch / Local Modification?

...but it discarded them all. The full text for "autovivification anomaly" was:

"Autovivification Anomaly? Could keys %{undef} somehow autovivify $options{group} into an empty hash reference {} before crashing or evaluating? Standard autovivification works on assignment to non-existent nested keys, not usually on reads like keys. It's not the standard behavior."

So it clearly didn't know that, yes, perl does autovivify "on reads like keys". So with a lot of hinting it almost got there, but never quite did. This wasn't a "realistic" scenario, though - I could only give it specific hints because I'd already worked out the problem with Human Brain Mk. I. If I hadn't already known what the more difficult problem was, Gemini clearly would not have been able to help me find it. It may have helped me find the easier problem, but then, I found that one myself in about two minutes, so that's not a huge win.

Before the weekend, I gave it another chance. After a week staring at this templates stuff I came out with some ideas for improving the intermediate loader we use in Fedora, which lets us store the templates in a more maintainable and efficient layout than the upstream loader expects, and transforms them into the upstream format before passing them to the upstream loader. One of these was allowing the "profiles" (an intermediate-loader-only concept) to be grouped. Then I realized we could save some more lines by allowing those groups to nest. So I wrote a trivial group recurser to allow for this. That was a pretty straightforward task, so I thought hey, could I have done it with AI?

So I pasted the script into Gemini (2.5 Pro again) and asked it: "Propose a change to make nested ProfileGroups possible. It should be possible for ProfileGroups keys to be the names of other ProfileGroups. The generate_job_templates function should handle these by recursion."

It came back with a modified version of the script with a superficially-plausible recursion handler...and a whole bunch of other changes. It mentioned some of these changes in the explanation it gave, with a heading "Minor Refinements and Robustness", but not all of them. I had not asked for any of these changes. Almost all of them were bikeshedding. Quite a lot were 'correctness' checks that are not necessary because the input data is validated through a JSON schema before we operate on it, which allows us to make various safe assumptions about what data will be present and as what types.

So I asked it: "Please re-do this without the "minor refinements and robustness". Do not change anything unless it is necessary to achieve the goal of nested ProfileGroups. Do not change existing variable names. Do not change existing functions other than generate_job_templates." It replied "Okay, I've revised the script focusing strictly on the nested ProfileGroups functionality and reverting other changes to keep the script as close to your original structure as possible, outside of the necessary modifications for this feature...Other functions have been reverted to their state before my "minor refinements and robustness" changes, unless a modification was an unavoidable consequence of the primary goal. Variable names in existing functions have been kept as they were.", with another version of the script attached. But this was, well, a lie. It had in fact left some code alterations in place, and it included a lot of passive-aggressive comments in place of code changes, like "# Original exit", "# Original script modified item in place", "# Original access"...

I prompted it again with "You still modified unrelated code by adding comments. Please do this again and do not add those comments. Please respect the instruction to only make changes to existing code in the generate_job_templates function." It came back and said it had done it. It had not - it still included many of the passive-aggressive comments ("# Original: no check if 'out' is empty"), and had removed some of the existing code comments.

I tried one final time to prompt it: "No, it does not. For instance, you added the comment "# Original: no check if 'out' is empty", and removed my existing comment "# now produce the output in upstream-compatible format". These are the changes I do not want. I want a minimal change that can easily be reviewed as a patch or pull request without distracting and irrelevant changes to other areas of the script." Once again it came back with a failure - quite an interesting one. In most cases it removed the passive-aggressive comments...but it literally removed just the comment string. So if the original line was foo with no trailing spaces, and it had changed it to foo # passive aggressive comment, it was now foo with a trailing space - Gemini literally removed only the string # passive aggressive comment compared to its previous version! And it did not restore the pre-existing code comments it had removed in previous rounds. I found it kinda interesting that it literally iterates in this way, instead of going back to the original script and trying again.

After three rounds I gave up on getting it to produce a minimal change, as any human coder would (at least after the very first time in their life they got chewed out for a PR with unrelated changes). Let's ignore that large problem and look at the recursion handler it produced:

def _resolve_recursive_profiles(group_name_to_resolve, all_profile_groups_data, current_base_priority, visited_in_path): """ Recursively resolves profiles from a profile group, handling nested groups. This is a new helper function. Args: group_name_to_resolve (str): The name of the profile group to resolve. all_profile_groups_data (dict): The main dictionary containing all profile group definitions. current_base_priority (int): The accumulated priority from parent groups or the initial priority from the TestSuite for this resolution path. visited_in_path (set): A set of profile group names already visited in the current recursion path to detect circular dependencies. Returns: dict: A dictionary of {profile_name: final_priority}. """ if group_name_to_resolve not in all_profile_groups_data: # This print is part of the new logic for handling undefined group references print(f"Warning: ProfileGroup '{group_name_to_resolve}' referenced but not defined. Skipping.") return {} if group_name_to_resolve in visited_in_path: # This print is part of the new logic for handling circular dependencies print(f"Warning: Circular dependency detected in ProfileGroups involving '{group_name_to_resolve}'. Skipping to break loop.") return {} visited_in_path.add(group_name_to_resolve) resolved_profiles_for_this_group = {} current_group_definition = all_profile_groups_data[group_name_to_resolve] for item_key, item_priority_offset in current_group_definition.items(): if item_key in all_profile_groups_data: # It's a nested profile group nested_group_base_priority = current_base_priority + item_priority_offset nested_profiles = _resolve_recursive_profiles( item_key, all_profile_groups_data, nested_group_base_priority, visited_in_path.copy() ) resolved_profiles_for_this_group.update(nested_profiles) else: # It's a direct profile final_profile_priority = current_base_priority + item_priority_offset resolved_profiles_for_this_group[item_key] = final_profile_priority return resolved_profiles_for_this_group

For comparison, here's my version:

def recurse_pgroup(pgroup, baseprio, pgroups, seen): """Recursion handler allowing nested profile groups. Takes the top-level profile group name and priority, the full ProfileGroups dict, and a set for infinite recursion checking. """ profiles = {} for (item, prio) in pgroups[pgroup].items(): if item in seen: sys.exit(f"Infinite recursion between profile groups {pgroup} and {item}") seen.add(item) if item in pgroups: profiles.update(recurse_pgroup(item, prio+baseprio, pgroups, seen)) else: profiles[item] = prio+baseprio return profiles

So, well. Gemini's version is...not wrong, I don't think. I didn't bother running/testing it, but just eyeballing it, it looks like it works. But it is extremely verbose (and that's me saying that!) It uses very long variable names which are not in line with the general variable naming approach the rest of the script uses; because these are very long it has to wrap its self-call across multiple lines, which makes the flow less obvious. It uses trailing comments (I dislike these, so there isn't a single one in the existing script). It unnecessarily assigns variables which are used only once (final_profile_priority and current_group_definition, for e.g.) The overall effect is kind of stultifying to read. An entire codebase written in this style would be a nightmare to work on. The long, public interface-y docstring is arguably fine because I didn't give it any specific instructions, but OTOH, the rest of the script is clearly written in a pretty private, concise style which should have clued it in that this wasn't desired, even if this was a 'public' function.

I could try and fight it even harder to get it not to change unrelated things. I could give it specific instructions about variable naming and how I like comments and how I want it to write docstrings. But...that's more work than just writing the damn function myself, and if you're going to call this thing "AI", it should be reasonable for me to expect it to work these things out without explicit instructions, like I'd expect a human coder to do.

So overall my conclusion from these experiments is: I can see value in using "AI" as a summarizer of long git changelogs. I'll probably keep using it for that kind of task. I didn't yet find any value in trying to use it for a pretty typical "why isn't this working?" process of the kind I do all day long, or for what should have been a pretty trivial "write a simple, common enhancement to this script" operation.

We have always had bots visiting our website. They were mostly kind bots, like the crawlers that keep the databases of search engines up-to-date. Those kind bots start by looking at our robots.txt files before doing anything, and respect the restrictions that are set in those files.

However, things have changed. Like other websites, for instance Wikipedia, we are more and more being visited by AI scrapers, bots that scrape the Internet for anything they can find to train AI applications. They are usually extremely hungry for information, so they download much, much more than an ordinary user would do. Moreover, many of them are impolite: they don’t respect the rules set in our robots.txt files, they hide who they really are, they don’t put a little pause in between requests – on the contrary, they hammer our servers with requests from lots and lots of different IP addresses at the same time. The result is that parts of mageia.org, like our Bugzilla, Wiki and Forums, become unreachable.

Below you can see the CPU load of one of our most important servers, where, amongst other things, our forums and wiki are located:

Even if our infra upgrade had already been finished, this would be really hard to mitigate.

Blocking the used IP addresses is useless because they constantly switch to new ones. One of our sysadmins just told me about a big issue: “mobile proxies” where bots proxy their request through unsuspecting users’ phones. That makes the requests look much more legitimate and hard to block without also blocking real users. A lot of that happens without users even knowing their phone is being used like this. Some applications include proxies along with some game or other app and hide it in fine print in the terms of service. Last year, it was reported that Google had removed a bunch of such applications from their store.

Apart from phones, there are IoT devices and also ordinary computers that ended up in botnets, because they were not well protected. They can be used for AI scraping and probably are now.

Our sysadmins do time and again succeed in mitigating the problem, but it is a “cat and mouse game”, so the problem is likely to reoccur.

If you know people working on AI applications which need to be trained, please ask them to make sure their bots read and respect the robots.txt files they encounter. And, of course, please nudge your friends and family, when you think they need that, to make sure their computers and other smart devices get all security updates as soon as they are released.

Siempre hemos tenido visitas de robots en nuestros sitios. Normalmente, son inofensivos, como los rastreadores, que mantienen actualizados los motores de búsqueda. Esos robots comienzan por revisar nuestros archivos robots.txt, antes de hacer nada y respetan las restricciones contenidas en esos archivos.

Pero las cosas han cambiado, al igual que otros sitios, hemos sido visitados cada vez más frecuentemente por escarbadores IA, robots que indagan en el internet por cualquier cosa que puedan encontrar para entrenar aplicaciones IA. Estos son extremadamente hambrientos de información, así que descargan mucho más de lo que cualquier usuario podría hacer. Peor aún, muchos de ellos son mal educados y no respetan las reglas de nuestros archivos robots.txt, esconden su identidad, y no hacen pausas entre peticiones – al contrario, golpean nuestros servidores con peticiones desde montones de direcciones IP diferentes al mismo tiempo. Como resultado, partes de mageia.org, como Bugzilla, Wiki y Foros, se hacen inaccesibles.

A continuación, pueden ver la carga de la CPU de uno de nuestros servidores más importantes, donde se encuentran, entre otros, nuestros foros y wiki:

Incluso si nuestra actualización de infraestructura ya hubiera terminado, esto sería realmente difícil de mitigar.

Bloquear las direcciones IP es inútil, ya que constantemente están cambiando por otras. Uno de nuestros administradores apunta a un gran problema: “proxis móviles”, los robots dirigen sus peticiones desde teléfonos sin que los usuarios sospechen. Esto hace que las peticiones parezcan legítimas y las hace difíciles de bloquear sin bloquear al usuario real. Mucho de esto pasa sin que los usuarios sepan que sus teléfonos son usados de esta forma, algunos proxis son incluidos en juegos u otras aplicaciones y lo ocultan en las letras pequeñas de los términos de servicio. El año anterior, se reportó que Google elimino montones de este tipo de aplicaciones de su tienda.

Además de los teléfonos, están todos esos dispositivos IoT y computadoras que terminan formando parte de botnets, debido a su mala protección. Ahora quizas esten siendo utilizados por escarbadores IA.

Nuestros administradores de sistemas tienen éxito en mitigar el problema , pero es el «juego del gato y el ratón», así que es un problema recurrente.

Si conocen a personas que estén trabajando en entrenar aplicaciones IA, por favor pídales que se aseguren de que sus robots lean y respeten los archivos robots.txt que encuentren.

Y desde luego, cuando crea necesario, incentive a sus amigos y familiares a asegurarse de que sus computadoras y otros dispositivos inteligentes tengan todas las actualizaciones de seguridad tan pronto como se publiquen.

Traducido por katnatek de la publicación original de marja

In Mageia/9/x86_64: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/9/aarch64: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/9/armv7hl: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/9/i586: Mesa is an OpenGL 4.6 compatible 3D graphics library.

In Mageia/cauldron/x86_64: Rachota is a portable application for timetracking different projects. It runs everywhere. It displays time data in diagram form, creates customized reports and invoices or analyses measured data and suggests hints to improve user's time usage. The totally portable yet personal timetracker.

In Mageia/cauldron/i586: Rachota is a portable application for timetracking different projects. It runs everywhere. It displays time data in diagram form, creates customized reports and invoices or analyses measured data and suggests hints to improve user's time usage. The totally portable yet personal timetracker.