Lector de Feeds

MGASA-2026-0014 - Updated thunderbird packages fix security vulnerabilities

Mageia Security - 20 Enero, 2026 - 04:25
Publication date: 20 Jan 2026
Type: security
Affected Mageia releases : 9
CVE: CVE-2026-0877 , CVE-2026-0878 , CVE-2026-0879 , CVE-2026-0880 , CVE-2026-0882 , CVE-2025-14327 , CVE-2026-0883 , CVE-2026-0884 , CVE-2026-0885 , CVE-2026-0886 , CVE-2026-0887 , CVE-2026-0890 , CVE-2026-0891 Description Mitigation bypass in the DOM: Security component. (CVE-2026-0877) Sandbox escape due to incorrect boundary conditions in the Graphics: CanvasWebGL component. (CVE-2026-0878) Sandbox escape due to incorrect boundary conditions in the Graphics component. (CVE-2026-0879) Sandbox escape due to integer overflow in the Graphics component. (CVE-2026-0880) Use-after-free in the IPC component. (CVE-2026-0882) Spoofing issue in the Downloads Panel component. (CVE-2025-14327) Information disclosure in the Networking component. (CVE-2026-0883) Use-after-free in the JavaScript Engine component. (CVE-2026-0884) Use-after-free in the JavaScript: GC component. (CVE-2026-0885) Incorrect boundary conditions in the Graphics component. (CVE-2026-0886) Clickjacking issue, information disclosure in the PDF Viewer component. (CVE-2026-0887) Spoofing issue in the DOM: Copy & Paste and Drag & Drop component. (CVE-2026-0890) Memory safety bugs fixed in Firefox ESR 140.7, Thunderbird ESR 140.7, Firefox 147 and Thunderbird 147. (CVE-2026-0891) References SRPMS 9/core
  • thunderbird-140.7.0-1.mga9
  • thunderbird-l10n-140.7.0-1.mga9

MGASA-2026-0013 - Updated nss & firefox packages fix security vulnerabilities

Mageia Security - 20 Enero, 2026 - 04:25
Publication date: 20 Jan 2026
Type: security
Affected Mageia releases : 9
CVE: CVE-2026-0877 , CVE-2026-0878 , CVE-2026-0879 , CVE-2026-0880 , CVE-2026-0882 , CVE-2025-14327 , CVE-2026-0883 , CVE-2026-0884 , CVE-2026-0885 , CVE-2026-0886 , CVE-2026-0887 , CVE-2026-0890 , CVE-2026-0891 Description Mitigation bypass in the DOM: Security component. (CVE-2026-0877) Sandbox escape due to incorrect boundary conditions in the Graphics: CanvasWebGL component. (CVE-2026-0878) Sandbox escape due to incorrect boundary conditions in the Graphics component. (CVE-2026-0879) Sandbox escape due to integer overflow in the Graphics component. (CVE-2026-0880) Use-after-free in the IPC component. (CVE-2026-0882) Spoofing issue in the Downloads Panel component. (CVE-2025-14327) Information disclosure in the Networking component. (CVE-2026-0883) Use-after-free in the JavaScript Engine component. (CVE-2026-0884) Use-after-free in the JavaScript: GC component. (CVE-2026-0885) Incorrect boundary conditions in the Graphics component. (CVE-2026-0886) Clickjacking issue, information disclosure in the PDF Viewer component. (CVE-2026-0887) Spoofing issue in the DOM: Copy & Paste and Drag & Drop component. (CVE-2026-0890) Memory safety bugs fixed in Firefox ESR 140.7, Thunderbird ESR 140.7, Firefox 147 and Thunderbird 147. (CVE-2026-0891) References SRPMS 9/core
  • nss-3.120.0-1.mga9
  • firefox-140.7.0-1.mga9
  • firefox-l10n-140.7.0-1.mga9

CI and LLM review on Fedora Forge with Forgejo Actions

AdamW on Linux and more - 20 Enero, 2026 - 00:19

Hi folks! Over the last couple of weeks, we have migrated nearly all the quality team's repositories from Pagure (the old Fedora forge) to the new, Forgejo-based Fedora Forge. As part of this, I've figured out a process for doing CI with Forgejo Actions. I also came up with a way to do automated LLM pull request reviews, for those interested in that.

For the impatient, you can just look at / copy the two workflows in python-wikitcms, but you'll at least need to read the stuff about runners below.

Forgejo Actions works very similarly to GitHub Actions, by design. You create a .forgejo/workflows directory in your project and define workflows in it. The syntax is almost entirely compatible with GitHub Actions, but with several missing features.

Some very commonly-used shared actions, like actions/checkout, are ported to Forgejo so you can use them directly. Other shared and third-party actions can be used by giving a full URL to them - e.g. uses: https://github.com/actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0 - but whether a given action will work or not depends on whether it's written to assume it's running on public GitHub, and whether Forgejo has all the features it needs.

Probably the most noticeable difference with using GitHub Actions is runner availability and environment. If you have a public GitHub project you can define workflows with something like runs-on: ubuntu-latest; behind the scenes, GitHub maintains a farm of runners with various labels, of which ubuntu-latest is one, and your jobs will run on any available runner with that label. The available environments for public GitHub repos are a handful of Ubuntu, Windows and macOS versions.

The staging instance of Fedora Forge has a few universal runners you can use like this. Currently each has only one, unique, label, so you can't specify workflows with a label like fedora and have them run on any available runner; you have to just pick one of the labels, and your jobs will always run on that runner. Maybe this will get changed at some point. But the runners are available to all repos in the staging instance, so you can just define a workflow and get it run.

Currently the production instance has no universal runners like this; runners are limited to specific organizations. The releng and infra organizations have runners, and now I requested one, the quality organization has one too. If you want to run workflows for projects in a different organization, the first thing you'll need to do is file a ticket to request runner(s) for that organization. If you have admin access to an organization, you can see whether it has runners, and what labels they have, by visiting https://forge.fedoraproject.org/org/<organization>/settings/actions/runners.

Once your org has at least one runner, you can define workflows and they'll run, as long as you set the runs-on value to a label that at least one of the runners has.

However, you might be surprised by the default environment: it's currently Debian Bookworm. Until that gets fixed, you may be interested in the container directive for workflows, which lets you define any arbitrary container image to be used:

container: image: quay.io/fedora/fedora:latest

There is one little gotcha with this, though. Many GitHub actions, including checkout, are written in Node, but Fedora's stock container images don't have Node installed. So you have to install it before running checkout or anything else that uses Node.

Put it all together, and here's the workflow I've defined for doing CI on Python projects with Tox:

name: CI via Tox on: pull_request: types: [opened, synchronize] jobs: tox: runs-on: fedora container: image: quay.io/fedora/fedora:latest steps: - name: Install required packages run: dnf -y install nodejs tox git - uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 with: fetch-depth: 0 - name: Install Python interpreters run: for py in 3.6 3.9 3.10 3.11 3.12 3.13; do dnf -y install python$py; done - name: Test with tox run: tox

That runs whenever a pull request is opened or pushed (the on section). It expects a runner with the fedora label (the runs-on setting). It uses the fedora:latest container image from quay.io (the container setting). From that image, we install packages we're going to need - including nodejs (the first step). Then we run actions/checkout to check out the PR (the second step, the uses one). Then we install all the Python interpreters we need, and run tox (the final two steps). Of course, if your project isn't Python or doesn't use Tox, you'll have to tweak this a bit, but hopefully you get the general idea.

If you're security-minded, you might notice there's no permissions setting in this workflow. That's because Forgejo currently does not support fine-grained permissions in the automatically-generated workflow tokens. In Forgejo, the automatically-generated token always has full read/write privileges unless it's operating on a pull request from a fork, in which case it has only read permissions. Nothing finer-grained is possible at present. If you need something finer-grained, you have to generate a token manually, save it as a repository secret, and adjust your workflow (somehow) to use that and hide the automatically-generated token as far as is practically possible (that's outside the scope of this post).

So that's CI! What about LLM pull request review? Well, if you dislike or are not interested in that, stop reading now. If you are interested, here's a recipe:

name: AI Code Review on: pull_request_target: types: [labeled] jobs: ai-review: if: forgejo.event.label.name == 'ai-review-please' runs-on: fedora container: image: registry.gitlab.com/redhat/edge/ci-cd/ai-code-review:v2.3.0 steps: - name: Run AI Review env: AI_API_KEY: ${{ secrets.GEMINI_API_KEY }} run: ai-code-review --platform forgejo --pr-number ${{ forgejo.event.pull_request.number }} --post # this has to be a separate job because ai-code-review container does not have nodejs in it # also note this does not work for PRs from forks because of a forgejo bug # https://codeberg.org/forgejo/forgejo/issues/10733 remove-label: runs-on: fedora steps: - uses: https://github.com/actions-ecosystem/action-remove-labels@2ce5d41b4b6aa8503e285553f75ed56e0a40bae0 # v1.3.0 with: labels: ai-review-please

That will cause the ai-code-review tool to review the pull request and post its analysis as a comment.

Just a couple of things to note here. I decided to have the LLM review happen only when a pull request is given a special label. LLM reviews are relatively expensive, and also quite verbose; you don't necessarily want one cluttering up the ticket any time a pull request is created or edited, and you may not want to make it possible for someone to charge some LLM usage to your account as often as they like just by creating or editing a pull request.

So, to use this recipe you have to create a label called ai-review-please in your repository. You can do this by going to "Issues", then clicking "Labels", then "New label". Give it whatever color and description you like. Any time you add that label to a PR, the review process will be triggered. Before adding the label to a PR you should probably make sure the PR is well-intentioned and not attempting any kind of prompt injection to get ai-code-review to disclose a secret or mess with the repository.

The other thing is you need an AI provider API key. In this recipe we have a Gemini API key saved as a repository secret called GEMINI_API_KEY. To create repository secrets, go to repository "Settings", then "Actions", then "Secrets", and click "Add secret". In the workflow, we make the repository secret called GEMINI_API_KEY (secrets.GEMINI_API_KEY) available in the container as the environment variable AI_API_KEY; ai-code-review reads it in from there. Gemini is the default LLM provider for ai-code-review. You can also use OpenAI or Anthropic by adding an --ai-provider argument to the ai-code-review call in the workflow (obviously, then, the secret you export as AI_API_KEY must be a valid key for that provider). I'm hoping that in the not-too-distant future, we'll have an LLM model provider in Fedora infra, running open source models, that we can use for this purpose; for now, unfortunately, we have to use the hyperscaler ones.

Finally, as noted in the comment, the workflow is intended to remove the ai-review-please label when it runs (so you don't have to remove it manually, then add it again, if you want another review later), but this does not currently work for pull requests from forks due to a Forgejo bug (because we're using pull_request_target the workflow token should have write permissions even for a fork PR, but it doesn't). If you use it on a fork PR, you'll have to remove the label manually once the workflow has triggered.

You can, of course, change the on block to be the same as the CI recipe if you want to have LLM review run automatically whenever a PR is created or edited - but do make sure whoever's paying the bills for the API key is OK with that, and monitor the repo to make sure nobody starts creating hundreds of PRs to try and blow your budget...and hope/pray nobody manages a successful prompt injection attack. On the whole I'd stick with the label (only repository admins can label PRs, so a non-admin attacker can't apply the label themselves to trigger the review).

Categorías: Otros Blogs

Persistent live systems

Wiki Mageia - 19 Enero, 2026 - 20:29

‎Original kernel: Advanced, links

← Older revision Revision as of 19:29, 19 January 2026 (2 intermediate revisions by the same user not shown)Line 195: Line 195:  # Add 6.6 kernel in skip.list per '''(*)''' above, and uninstall kernel(s) 6.6.x, which should also remove any 6.6.*-latest package. # Add 6.6 kernel in skip.list per '''(*)''' above, and uninstall kernel(s) 6.6.x, which should also remove any 6.6.*-latest package.  It is ''possible'' to [https://bugs.mageia.org/attachment.cgi?id=15306 install nvidia470] - and probably similar for nvidia-current, but seldom worth the work and 1GB space!  The free drivers work well. It is ''possible'' to [https://bugs.mageia.org/attachment.cgi?id=15306 install nvidia470] - and probably similar for nvidia-current, but seldom worth the work and 1GB space!  The free drivers work well.  +  +=== Kernel maintenance ===  +Uninstall kernels to save space.  Never uninstall the original kernel nor the currently running kernel!  Note that in the boot menu you can only select between the original kernel and the latest installed - regardless of version number. So if you want to go back one version, boot on original, remove any you want and (re)install the version you want.  Also see [[#Original_kernel|Original kernel]].  +  +We have a helper: Beginning with Mageia 9 on 64 bit Live like on a 64 bit installed system, {{cmd|rok}}, [[Mageia_9_Release_Notes#remove-old-kernels|remove-old-kernels]] is installed. The updated 1.0.3+ version detects when it runs on a Live system and then keep max 2 kernels (of each flavour - note backport kernel is of another flavour) and does never uninstall the original kernel.  rok runs occasionally in the background which means on slow USB dives the system may suddenly become sluggish for a while, and Xfce file managers pop up {{Bug|34964}}.  To avoid such surprise you may want to disable rok from running automatically by launching it by {{cmd|rok -A0}} as root.     == Custom Live ISO == == Custom Live ISO == Line 451: Line 456:  === Original kernel === === Original kernel ===    −If {{menu|[F1]}} is shown, you can use it to toggle between booting the original kernel in the Live ISO, or the latest installed one in persistence. (The text after [F1] toggles "original" <-> "latest", indicating which is chosen).  +If {{menu|[F1]}} is shown, you can use it to toggle between booting the original kernel in the Live ISO, or [[#Kernel_maintenance|the latest installed one]] in persistence. ''The text after [F1] toggles "original" <-> "latest", indicating which is chosen.''     ''NOTE: When persistence is encrypted, you can not select an updated kernel. See further in [[#Encryption|Encryption]].'' ''NOTE: When persistence is encrypted, you can not select an updated kernel. See further in [[#Encryption|Encryption]].''  +  +''For the advanced user: The "latest" option in the Live boot menu relies solely on the soft links /boot/vmlinuz and /boot/initrd.img. It doesn't care what kernel version they link to, so if you need to restore booting from another kernel, you can do so by manually changing those links.  +[https://bugs.mageia.org/show_bug.cgi?id=34951#c33 ''Further technical details'']''     === Boot command line === === Boot command line === Morgano
Categorías: Wiki de Mageia

Erstellen/Bearbeiten einer Wiki Seite-de

Wiki Mageia - 19 Enero, 2026 - 17:23

← Older revision Revision as of 16:23, 19 January 2026 (One intermediate revision by the same user not shown)Line 503: Line 503:     === Unterstützung für mehrere Sprachen === === Unterstützung für mehrere Sprachen === −Das Mageia Wiki unterstützt verschiedene Sprachen dank dem Willen von verschiedenen Personen, welche Artikel in ihre Muttersprache schreiben. Um zwischen den Seiten und Vorlagen unterscheiden zu können, welche das Mageia Wiki bereichern, werden die mit dem ISO Code der entsprechenden Sprache erweitert.+Das Mageia Wiki unterstützt verschiedene Sprachen dank dem Willen von verschiedenen Personen, welche Artikel in ihre Muttersprache schreiben. Um zwischen den Seiten und Vorlagen unterscheiden zu können, welche das Mageia Wiki bereichern, werden diese mit dem ISO Code der entsprechenden Sprache erweitert.    −{{warning-de|Vorlagen und Kategorienamen werden in '''englisch''' beibehalten, um die Übersetzung in anderen Sprachen zu erleichtern. '''Nur Suffixe''' für die Unterscheidung der Sprache.}}+{{warning-de|Vorlagen und Kategorienamen werden in '''englisch''' beibehalten, um die Übersetzung in andere Sprachen zu erleichtern. '''Nur Suffixe''' für die Unterscheidung der Sprache.}}     Die Vorteile sind: Die Vorteile sind: Line 511: Line 511:  * Kategorisierung der Seiten in der Muttersprache * Kategorisierung der Seiten in der Muttersprache  * Kategorisierung der Vorlagen in der Muttersprache * Kategorisierung der Vorlagen in der Muttersprache −* Kategorisierung der Kategorien in der nativen Sprachen. Für später können Sie selbst entscheiden, wie Sie diese einrichten, da die Kommuniktion bei Mageia hauptsächlich in "'''Englisch'''" stattfindet. Es wird sehr empfohlen, die Kategorie  [[:Category:Dokumentation|'''Dokumentation''']], in der eigenen Sprache zu verwenden um sprachliche indifferenzen zu verhindern und die Artikelsuche zu vereinfachen.+* Kategorisierung der Kategorien in der nativen Sprache. Für später können Sie selbst entscheiden, wie Sie diese einrichten, da die Kommuniktion bei Mageia hauptsächlich in "'''Englisch'''" stattfindet. Es wird sehr empfohlen, die Kategorie  [[:Category:Dokumentation|'''Dokumentation''']], in der eigenen Sprache zu verwenden um sprachliche Indifferenzen zu vermeiden und die Artikelsuche zu vereinfachen.    −==== Übersetzen der ersten Seite und der Vorlangen ====+==== Übersetzen der ersten Seite und der Vorlagen ====    −# Die Template:code-en Vorlage muss als erstes übersetzt werden, damit Sie die Tabellen mit der Vorlagen lesen können.+# Die Template:code-en Vorlage muss als erstes übersetzt werden, damit Sie die Tabellen der Vorlagen lesen können.    −{{warning-de|Die code-en Vorlage ist reine Fiktion in der Tabelle.}}+{{warning-de|Die code-en Vorlage in dieser Tabelle ist reine Fiktion.}}     # Die Seite, welche Sie lesen "How to write a wiki page". # Die Seite, welche Sie lesen "How to write a wiki page".    −{{note-de|Um es einfacher zu machen die Tabelle zu übersetzen, wird das Skelett weiter unten angezeigt. Kopieren Sie dieses in einen Texteditor und ersetzen Sie alle -en Endungen mit "-Ihrem ISO Code".}}+{{note-de|Um es einfacher zu machen die Tabelle zu übersetzen, wird das Skelett weiter unten angezeigt. Kopieren Sie diese in einen Texteditor und ersetzen Sie alle -en Endungen mit "-Ihrem ISO Code".}}     Um anschließend jede Vorlage zu erstellen müssen Sie auf die entsprechenden Links klicken. Um anschließend jede Vorlage zu erstellen müssen Sie auf die entsprechenden Links klicken. Psyca
Categorías: Wiki de Mageia

Mageia 10 Entwicklung-de

Wiki Mageia - 19 Enero, 2026 - 11:48

← Older revision Revision as of 10:48, 19 January 2026 (One intermediate revision by the same user not shown)Line 1: Line 1:  +[[Category:Mageia_development]]  +[[Category:Mageia 10]]  +  {{multi language banner-de|[[Mageia 10 Entwicklung-de|Deutsch]] ; [[Mageia_10_Development|English]] ; [[Mageia_10_Développement-fr|Français]] ; [[Desenvolvimento do Mageia 10-pt-BR|português brasileiro]] ; [[Mageia 10 Ontwikkeling-nl|Nederlands]] ; }} {{multi language banner-de|[[Mageia 10 Entwicklung-de|Deutsch]] ; [[Mageia_10_Development|English]] ; [[Mageia_10_Développement-fr|Français]] ; [[Desenvolvimento do Mageia 10-pt-BR|português brasileiro]] ; [[Mageia 10 Ontwikkeling-nl|Nederlands]] ; }} −      Diese Seite behandelt die Entwicklung von Mageia 10 Diese Seite behandelt die Entwicklung von Mageia 10 Line 23: Line 25:  | 18.01.2026 | 18.01.2026  | Entwickler, Paketersteller | Entwickler, Paketersteller −| +| 19.01.2026  |- |-  | '''Beta''' | '''Beta''' Line 49: Line 51:     Siehe [[FeatureMageia10_Review| Mageia 10 Spezifikationen]] Siehe [[FeatureMageia10_Review| Mageia 10 Spezifikationen]] −  −  −[[Category:Mageia_development]]  −[[Category:Mageia 10]]  Psyca
Categorías: Wiki de Mageia

Mageia 10 Development

Wiki Mageia - 19 Enero, 2026 - 11:39

‎Development Schedule

← Older revision Revision as of 10:39, 19 January 2026 Line 28: Line 28:  | 2026-01-18 | 2026-01-18  | developers, packagers | developers, packagers −| +| 2026-01-19  |- |-  | '''Beta''' | '''Beta''' Bcornec
Categorías: Wiki de Mageia
Feed