Lector de Feeds

Clarify summary, more tweaks

← Older revision Revision as of 00:04, 5 February 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. ''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).+A '''vendored dependency''' is an aggregation of code (such as a package, module or library) that is included in source form 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 recompiled, 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)'' For these reasons, vendored libraries are discouraged in Mageia ''(TBD: point to the policy)'' Line 9: Line 9:  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)''    −'''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.+'''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 all applications with the fixed packages.     For these reasons, static linking is discouraged in Mageia ''(TBD: point to the policy)'' For these reasons, static linking is discouraged in Mageia ''(TBD: point to the policy)'' Line 23: Line 23:  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. 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:+The main reasons for policies against vendoring dependencies are:     # to easily identify which packages need to be updated to fix security issues # 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 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 the work in updating those packages when it becomes necessary  # to reduce time, bandwidth and disk space for users # to reduce time, bandwidth and disk space for users  # to ensure source code is always available to users to fulfill licensing obligations # to ensure source code is always available to users to fulfill licensing obligations Line 49: Line 49:  # Erlang* # Erlang*  # other compiled languages like C# (mono), BASIC (FreeBASIC), FORTRAN (gfortran), Pascal (lazarus) # other compiled languages like C# (mono), BASIC (FreeBASIC), FORTRAN (gfortran), Pascal (lazarus)  +# other interpeted languages like Forth*, Lua*, Scheme*, CLisp     <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules <nowiki>*</nowiki> Interpreted languages that don't statically link dependencies into applications or modules Danf

Add bug links

← Older revision Revision as of 23:27, 4 February 2025 Line 28: Line 28:  * plt/racket http://racket-lang.org/ * plt/racket http://racket-lang.org/  * libequalizer http://www.equalizergraphics.com/ * libequalizer http://www.equalizergraphics.com/  +  +== More ==  +* Bugs listing more packages with bundled dependencies: [https://bugs.mageia.org/33973 33973]  [https://bugs.mageia.org/13167 13167]     == similar pages from other distributions == == similar pages from other distributions ==     https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries Danf

← Older revision Revision as of 23:23, 4 February 2025 Line 43: Line 43:  |- |-  ! colspan="3" style="background: #ccfbff;" | ''' WINDOWS GAMES ''' ! colspan="3" style="background: #ccfbff;" | ''' WINDOWS GAMES '''  +  +|-  +| style="width: 5%"| [[File:App-accessories.png|25px|center]]  +| Beyond Blue  +| werkt heel goed met Heroic Game Launcher en Proton-GE-Proton 9.16     |- |- Scroll44

← Older revision Revision as of 23:22, 4 February 2025 Line 44: Line 44:  ! colspan="3" style="background: #ccfbff;" | ''' WINDOWS GAMES ''' ! colspan="3" style="background: #ccfbff;" | ''' WINDOWS GAMES '''     +|-  +| style="width: 5%"| [[File:App-accessories.png|25px|center]]  +| Beyond Blue  +| works very well with Heroic Game Launcher and Proton-GE-Proton 9.16     |- |- Scroll44

← Older revision Revision as of 23:21, 4 February 2025 Line 45: Line 45:  ! colspan="3" style="background: #ccfbff;" | ''' JEUX WINDOWS ''' ! colspan="3" style="background: #ccfbff;" | ''' JEUX WINDOWS '''     +  +|-  +| style="width: 5%"| [[File:App-accessories.png|25px|center]]  +| Beyond Blue  +| marche très bien avec Heroic Game Launcher and Proton-GE-Proton 9.16     |- |- Scroll44

‎A way forward: C/C++ static binaries, generalized text

← Older revision Revision as of 23:02, 4 February 2025 Line 84: Line 84:  A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'').  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?'' A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'').  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?''    −The various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location. For interpreted languages, the dependencies would instead be installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application and won't be found in the normal search paths). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''+For step 2., the various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location.  +   +For interpreted languages (step 3), the dependencies would instead be installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application and won't be found in the normal search paths). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''  +   +=== C/C++ ===  +   +While C/C++ programs occasionally vendor in dependencies, a bigger problem is those packages that statically link to libc. The build nodes should scan for statically-linked binaries and highlight those in the SBOM alongside their dependencies to ensure the static binaries can be rebuilt to include the security fixes when those dependencies (mostly glibc) are patched. It's also possible for a binary to be partially statically linked and these cases should also be detected (likely with difficulty), either by detecting static libraries in the dependency lists, or by instrumenting the linker.     === Go === === Go === −  −The specifics listed in this section are for handling Go applications, but it can be generalized for other languages in the future. These should be able to be generalized to work for applications in other compiled languages as well. It is possible to develop infrastructure to support interpreted languages as well, but the benefits may not be as clear; any such applications that ship vendored modules ''would'' benefit, but it's unclear how many of those (if any) actually exist.      The ''go list -json'' command can be used to generate the list of dependencies needed by an application (step 1). The ''go list -json'' command can be used to generate the list of dependencies needed by an application (step 1). Danf

Publication date: 04 Feb 2025
Type: security
Affected Mageia releases : 9
CVE: CVE-2024-12425 , CVE-2024-12426 Description Path traversal leading to arbitrary .ttf file write. (CVE-2024-12425) URL fetching can be used to exfiltrate arbitrary INI file values and environment variables. (CVE-2024-12426) References

• https://bugs.mageia.org/show_bug.cgi?id=33941
• https://lists.debian.org/debian-security-announce/2025/msg00008.html
• https://www.libreoffice.org/about-us/security/advisories/cve-2024-12425/
• https://www.libreoffice.org/about-us/security/advisories/cve-2024-12426/
• https://ubuntu.com/security/notices/USN-7228-1
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-12425
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-12426

SRPMS 9/core

• libreoffice-24.2.7.2-1.mga9

Publication date: 04 Feb 2025
Type: bugfix
Affected Mageia releases : 9
Description It corrects a bug which appeared in version 0.6.2 (in conversion of preferences commands). Adds support for DSF files to the library. Reinstates support for AAC files to the library (removed in 0.5.0). References

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

SRPMS 9/core

• guayadeque-0.6.4-1.mga9

‎Team members: even more clean :)

← Older revision Revision as of 15:35, 4 February 2025 Line 51: Line 51:    ! name !! nick !! e-mail address !! preferences !! additional information !! entry last updated on:   ! name !! nick !! e-mail address !! preferences !! additional information !! entry last updated on:    |-   |- −     | Morgan Leijström || morgano || fri [at] tribun [dot] eu ||  ||   | Morgan Leijström || morgano || fri [at] tribun [dot] eu ||  ||    |-   |- Line 58: Line 57:    | Marja van Waes || marja || marja11 [at] freedom [dot] nl|| || '''Deputy''' ||   | Marja van Waes || marja || marja11 [at] freedom [dot] nl|| || '''Deputy''' ||    |-   |- −  | José Alberto Valle Cid || kanatek || j.alberto.vc@gmail.com  ||  ||+  | José Alberto Valle Cid || kanatek || j.alberto.vc@gmail.com || ||  ||    |-   |- −  | Roelof Wobben || RoelofW || r.wobben@home.nl  ||  ||+  | Roelof Wobben || RoelofW || r.wobben@home.nl  ||  ||  || −  ||  −   −    |} |}    Morgano

clean up

← Older revision Revision as of 09:44, 4 February 2025 Line 58: Line 58:    | Marja van Waes || marja || marja11 [at] freedom [dot] nl|| || '''Deputy''' ||   | Marja van Waes || marja || marja11 [at] freedom [dot] nl|| || '''Deputy''' ||    |-   |- −  | Frank Sturm || sturmvogel || sturm-fr [at web [dot] de || ||+  | José Alberto Valle Cid || kanatek || j.alberto.vc@gmail.com || ||    |-   |- − | José Alberto Valle Cid || kanatek || j.alberto.vc@gmail.com  ||+  | Roelof Wobben || RoelofW || r.wobben@home.nl || || − |-  −  | Roelof Wobben || RoelofW || r.wobben@home.nl  ||     ||   ||    Sturmvogel

Robôs_do_IRC-pt-BR

← Older revision Revision as of 00:34, 4 February 2025 (One intermediate revision by the same user not shown)Line 58: Line 58:  *[[Como_usar_o_IRC-pt-BR|Como usar o IRC]] *[[Como_usar_o_IRC-pt-BR|Como usar o IRC]]  *[[Como_criar_uma_página_wiki-pt-BR|Como escrever uma página wiki]] *[[Como_criar_uma_página_wiki-pt-BR|Como escrever uma página wiki]] −*[[IRC bots|Bots do IRC]]+*[[Robôs_do_IRC-pt-BR|Robôs do IRC]]  *[[Mageia IRC Channels Liberachat|Canais de IRC do Mageia na Liberachat]] *[[Mageia IRC Channels Liberachat|Canais de IRC do Mageia na Liberachat]]  *[[Mageia.org user account|Conta de usuário do Mageia.org]] *[[Mageia.org user account|Conta de usuário do Mageia.org]] Xgrind

Add pt-BR

← Older revision Revision as of 00:32, 4 February 2025 Line 3: Line 3:  [[Category:IRC]] [[Category:IRC]]    −{{Multi language banner-fr|[[IRC_bots|English]] ; [[Robot IRC-fr|français]] ; }}+{{Multi language banner-fr|[[IRC_bots|English]] ; [[Robot IRC-fr|français]] ; [[Robôs do IRC-pt-BR|português brasileiro]] ; }}     == Erzulie == == Erzulie == Xgrind

Add pt-BR

← Older revision Revision as of 00:31, 4 February 2025 Line 3: Line 3:  [[Category:Documentation]] [[Category:Documentation]]    −{{multi language banner|[[IRC_bots|English]] ; [[Robot IRC-fr|Français]] ; }}+{{multi language banner|[[IRC_bots|English]] ; [[Robot IRC-fr|Français]] ; [[Robôs do IRC-pt-BR|português brasileiro]] ;}}     == Erzulie == == Erzulie == Xgrind

Criando a página Robôs do IRC-pt-BR

New page

[[Category:IRC]]
[[Category:Howtos]]
[[Category:Documentation]]

{{multi language banner-pt-BR|[[IRC_bots|English]] ; [[Robot IRC-fr|Français]] ; [[Robôs do IRC-pt-BR|português brasileiro]] }}

== Erzulie ==

Erzulie mostra o título de uma página da web (útil quando um relatório de bug é publicado)

== Inigo_Montoya ==

Inigo_Montoya é um meetbot, usado para reuniões, ele produz os relatórios em http://meetbot.mageia.org/

Comandos úteis são: #action #agreed #help #info #idea #link #topic.
E, claro, #startmeeting #chair e #endmeeting

== [mbot ==

[mbot captura o título de uma página da web (como erzulie) e os bugs<br/>
Outros comandos:
*bug XXX ou ,bug XXX : exibe informações de um relatório de bug.
*seen <nick> : retorna a última vez que <nick> foi visto (funciona apenas no canal atual)
*,buglist : cria uma lista de bugs a partir de uma pesquisa ([http://www.bugzilla.org/docs/3.6/en/html/query.html para mais informações])
*,query : igual ao anterior, mas exibe 5 bugs (pode gerar floods)
*,g : pesquisa no Google e clica no primeiro resultado
*,qawiki : pesquisa no espaço de nomes do procedimento de QA nesta wiki
*,wiki : pesquisa na wiki (também usando o Google com site:wiki.mageia.org)
*,wtf : pesquisa na Wikipédia
*,maint <pacote> : retorna o mantenedor do <pacote> (usa a mesma API disponível [http://freeshell.de/~manu67/mageia/intcom.cgi aqui ])
*,svn <pacote>: retorna a lista de commiters (e a quantidade de contribuições) do <pacote> (usa a mesma API disponível [http://freeshell.de/~manu67/mageia/intcom.cgi aqui ])
*,uh <nick> comando : retorna <nick>: <resultado do comando>
*,changelog <lançamento> <rpm> : retorna a URL do Sophie que exibe o registro de alterações de um pacote para o lançamento especificado
*,help <comando> : retorna a ajuda do <comando>

== Sophie ==

[http://sophie.zarb.org/chat Sophie] é um robô de IRC presente em alguns canais do #mageia-* no IRC. Ela oferece funcionalidades muito úteis para obter informações sobre pacotes RPM nos repositórios do Mageia

Saiba mais sobre os comandos da Sophie na [[Sophie-pt-BR|nossa página sobre a Sophie]]

== Xochiquetzal ==

Se Xochiquetzal estiver presente, você pode perguntar quando e onde alguém foi visto pela última vez em um dos canais monitorados pelo robô, simplesmente digitando '''seen <nome de alguém>''' sem mencionar o nome dele.
Quando ele responder, incluirá as últimas palavras ditas por essa pessoa.

== dukelovett ==

dukelovett é um robô Eggdrop que frequenta o canal [ircs://irc.libera.chat:6697/#mageia-social #mageia-social]. Ele roda um conjunto completo de scripts personalizados desenvolvidos por [http://dukelovett.org dukelovett.org]. Regularmente, fornece notícias relacionadas ao Mageia e ao Linux no canal e oferece recursos como feeds RSS, busca por última aparição, pesquisa no Google, sistema de informações, informações de URL, além de funcionalidades básicas do Eggdrop, como chat DCC/partyline e acesso ao servidor de arquivos.

== Voicer ==

Para combater ataques de spam no Freenode, o robô Voicer permite que as pessoas no canal possam escrever após um atraso definido.<br>
O Voicer pode, quando desejado, enviar uma notificação privada ao cliente.<br>
O código-fonte está disponível em: https://framagit.org/jybz/voicer

=== Preparando o canal ===

Somente um operador do canal pode convidar o robô com o comando do Freenode:
<pre>
/invite Voicer
</pre>
O Voicer precisa se tornar um operador do canal com o comando do Freenode:
<pre>
/mode #OCanalAtual +o Voicer
</pre>
O canal deve impedir que as pessoas escrevam ativando a opção "moderado":
<pre>
/mode #OCanalAtual +m
</pre>
Se o canal não permitir pessoas não registradas, o robô será inútil. Nesse caso, desative a opção de acesso apenas para registrados:
<pre>
/mode #OCanalAtual -r
</pre>

=== Configurando o Voicer ===

Notificações relacionadas:
<pre>
#Para iniciar a notificação :
Voicer: start notice
#Para parar a notificação :
Voicer: stop notice
#Para ver a notificação atual :
Voicer get notice
#Definindo uma notificação privada para novas pessoas no canal:
Voicer: set notice "A nova notificação aqui"
</pre>

Segurança relacionada:
Lembre-se de que o Voicer não verifica se o apelido (nick) é falsificado.
<pre>
#Bloqueando a configuração para um único apelido; após ser bloqueada, apenas esse "apelido" poderá alterar a configuração:
Voicer: set lock
#Para saber qual apelido bloqueou a configuração:
Voicer: who lock
#TPara desbloquear a configuração (somente possível pelo apelido que bloqueou a configuração):
Voicer: unlock
</pre>

Voz relacionada:
<pre>
#Definindo o atraso em segundos (observe que NÃO HÁ ESPAÇO entre o número 60 e "sec"):
Voicer: set time 60sec
#Para obter o atraso:
Voicer: get time
#Para iniciar a voz :
Voicer: start voice
#Para parar a voz :
Voicer: stop voice
</pre> Xgrind

‎A way forward: Add a way forward for patched vendored dependencies

← Older revision Revision as of 00:15, 4 February 2025 Line 80: Line 80:  SBOMs will be stored in the [https://spdx.dev/ SPDX] format. SBOMs will be stored in the [https://spdx.dev/ SPDX] format.    −Security updates are assumed to consist of upgrading to a new upstream release. Those that require patching a dependency complicates this flow, since the same patch must then be applied to each vendored instance of that dependency.+Security updates are assumed to consist of upgrading to a new upstream release. Those that require patching a dependency complicates this flow, since the same patch must then be applied to each vendored instance of that dependency. If an unpackaged dependency needs a local patch instead of an upgrade, then we could implement a policy that the dependency much be first be packaged before rebuilds are performed, with that new package added as a dependency to any application that needs it before rebuilding. That avoids carrying the identical patch around in many packages.     A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'').  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?'' A script will be created to take care of the bulk of step 1 for the developer. It would scan the application source code to find out what dependencies are needed, then exclude any dependencies already supplied by packages in ''BuildRequires:'' leaving a list of outstanding ones. These would be downloaded using the language's normal package download mechanism and installed into a private temporary location. All these would then be archived into a compressed tarball along with an SBOM containing all the packaged dependency names and versions and stored in the ''SOURCES/'' directory under a standard name (maybe ''dependencies.tar.xz'').  This file would then be added to ''sha1.lst'' and uploaded to ''binrepo''. This could all be integrated into a ''mgarepo'' subcommand. ''TODO: who is responsible for ensuring that the licenses of all the dependencies are allowed, compatible and that the License: line in the .spec file matches?''    −The various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location. For interpreted languages, the dependencies would instead by installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''+The various RPM build macros would be updated to handle any dependencies stored in ''dependencies.tar.xz''. They would be extracted into a temporary location in ''BUILDROOT/'' and the compile command extended to look for missing dependencies in this location. For interpreted languages, the dependencies would instead be installed ''in the RPM'' in an appropriate location in ''/usr/share/'' (that doesn't conflict with other dependencies), and the application's launch command extended to find these dependencies (since they are private to that one application and won't be found in the normal search paths). ''TODO: how to handle locally patching these dependencies? patching before or after storing in dependencies.tar.xz''     === Go === === Go === Danf