Re: making Debian secure by default

2024-03-29 Thread David Wright
On Fri 29 Mar 2024 at 10:31:09 (+0100), Emanuel Berg wrote:
> David Wright wrote:
> 
> >> Ah, surely it can't refer to that as that would be
> >> completely ridiculous as it would imply "wanna install
> >> stuff? sure, but then it isn't secure anymore".
> >
> > It's not clear what "isn't secure anymore" means. [...]
> 
> It means as soon as you start doing stuff with the software,
> it isn't secure anymore.

As you wrote. But software isn't just "secure" or "not secure",
all or nothing. Security, in any aspect of life, is gradational.

> Which is comical to some extent as
> doing stuff is the purpose of computers.
> 
> So to base security boasting on people having the most
> minimal, restricted and inactive system, it is like boasting
> this marvelous piece of body armor is guaranteed to not have
> a single infantryman killed - just don't go to war.

You don't expect people working at HQ to get shot or blown up,
but that is a more likely fate for those fighting at the front.
As well as variations with seniority and physical position,
there will be temporal variations, just like in civilian life,
1 through 5 or green through red etc.

> (Note that now I'm just making fun at the slogan and boasting,
> not saying anything negative of their OS necessarily - I've
> used it myself, it send pretty good and, indeed, secure.)
> 
> >  "Secure by Default"
> >
> >  "To ensure that novice users of OpenBSD do not need to
> >   become security experts overnight (a viewpoint which other
> >   vendors seem to have), we ship the operating system in
> >   a Secure by Default mode. All non-essential services are
> >   disabled. As the user/administrator becomes more familiar
> >   with the system, he will discover that he has to enable
> >   daemons and other parts of the system. During the process
> >   of learning how to enable a new service, the novice is
> >   more likely to learn of security considerations."
> >
> > from https://www.openbsd.org/security.html
> > OTOH:
> >
> >  "There are many applications one might want to use on an
> >   OpenBSD system. To make this software easier to install
> >   and manage, it is ported to OpenBSD and packaged. The aim
> >   of the package system is to keep track of which software
> >   gets installed, so that it may be easily updated or
> >   removed. In minutes, a large number of packages can be
> >   fetched and installed, with everything put in the
> >   right place."
> >
> >  "The ports collection does not go through the same thorough
> >   security audit that is performed on the OpenBSD base
> >   system. Although we strive to keep the quality of the
> >   packages high, we just do not have enough resources to
> >   ensure the same level of robustness and security."
> >
> > from https://www.openbsd.org/faq/faq15.html (Package
> > Management).
> 
> The more you install, the less secure it gets. Yeah, can't
> base the security model on that.

Not a base; it's just inevitable, both in software and life.
You're increasing your attack surface as you install and use
more software, just like driving, visiting bars, attending
concerts, or going on foreign or adventure holidays.

> They should do it the other way around, write a piece of
> software that breaks everything. Install in on OpenBSD and if
> it breakes it, OpenBSD is not more secure than anyone else.
> If nothing happens tho most likekly you are safe.

I don't know about OpenBSD specifically, but in general it's
already done, by such methods as exposing software to malicious
and random inputs, corner cases, and so on. That doesn't have
to mean it's done /instead of/ auditing.

Cheers,
David.



Products!!

2024-03-29 Thread Diane Fralano
Hello,


We would like to purchase your product. Are you still exporting?


Thank you,

Diane



Re: making Debian secure by default

2024-03-29 Thread debian-user
Curt  wrote:
> On 2024-03-28, to...@tuxteam.de  wrote:
> >
> > Security, as Bruce Schneier [1] says, is a process. Not a product. 
> 
> A process that is essentially out of your control.

I would hope it is, given how little I or most people understand about
security.

> This is the elephant in the room that you do not wish to address.

There's no such elephant since most people understand it well, and
just live with it. As we live with not being in control of our
governments, or financial institutions, or (here in the UK) building
control or post office or ... (there are lots more examples)

> Anyway, dream on.



Re: making Debian secure by default

2024-03-29 Thread Andy Smith
Hello,

On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jońca wrote:
> Andy Smith  writes:
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > (Upstream xz/lzma project compromised, hostile code inserted into
> > sshd in Debian sid and other leading edge distros.)
> 
> O-o, is there any simple test to check if I have infected version or
> not?

Reading the link fully would show you how, but as far as Debian ics
concerned it only made it to testing and sid. If you run either of
those then Debian's own security announcements cover it.

Thanks,
Andy

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



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

2024-03-29 Thread Andy Smith
Hello,

On Fri, Mar 29, 2024 at 01:52:18PM -0400, Jeffrey Walton wrote:
> Seems relevant since Debian adopted xz about 10 years ago.

Though we do not know how or why this developer has come to recently
put apparent exploits in it, so we can't yet draw much of a
conclusion beyond "sometimes people do bad stuff to good software".

Sounds like it'll be an interesting story though. It's going to
drive a lot of conspiracy theories.

Thanks,
Andy

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



Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

2024-03-29 Thread Lucas B. Cohen

On Fri 29 Mar 2024 at 11:06:45 (-0400), Henning Follmann wrote:

On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:

Hi,

I've had a bit of a headache understanding why my Debian bookworm system
suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
the first of my two menuentries in grub.cfg were no longer specifying the
linux root by its device UUID (as I was expecting it to do, by honoring
GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
device node/file (/dev/md0 in this case, hence the kernel panic).



Was there any error message during the update?
I think what might have gone wrong, that you ran out of space on /boot.


Space on /boot couldn't have been the issue, I have 1GB allocated to 
that partition, and those 2 kernels only take up about a third of that 
space.


The was no visible error message at the time, as it's all hidden from 
the user's view by Gnome, right before power off. However I'm checking 
my /var/log/apt/term.log where it was handily stored, and here's what 
I'm seeing:


- seems that grub-mkconfig (the grub script called by Debian's 
update-grub wrapper) was in fact never called during that update 
sequence! (Therefore Gnome's handling of updates is off the hook.) 
Perhaps it was because of some bad dkms and linux-headers interaction. 
Some module failed to build, which cascaded into leaving the kernel and 
headers packages into the 'unconfigured' state:


Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j12 modules 
KERNEL_UNAME=6.1.0-18-amd64...(bad exit status: 2)

Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more 
information.

Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-18-amd64 (--configure):
 installed linux-image-6.1.0-18-amd64 package post-installation script 
subprocess returned error exit status 1


dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.1.0-18-amd64 (= 
6.1.76-1); however:

  Package linux-headers-6.1.0-18-amd64 is not configured yet.

- Consequence: my grub.cfg was only regenerated two days later, 
incidentally , during a scheduled unattended-upgrades run. Where


Log started: 2024-03-28  09:56:03
[...]
Removing linux-image-6.1.0-15-amd64 (6.1.66-1) ...
/etc/kernel/prerm.d/dkms:
[...]
depmod...
/etc/kernel/postrm.d/initramfs-tools:
[...]
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.1.0-18-amd64
Found linux image: /boot/vmlinuz-6.1.0-17-amd64
Found initrd image: /boot/initrd.img-6.1.0-17-amd64
Warning: Not executing os-prober.
done
[...]
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 11
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-18-amd64.postinst line 11.

dpkg: error processing package linux-headers-6.1.0-18-amd64 (--configure):
 installed linux-headers-6.1.0-18-amd64 package post-installation 
script subprocess returned error exit status 1

dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-18-amd64 (= 6.1.76-1); 
however:

  Package linux-image-6.1.0-18-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.1.0-18-amd64 (= 
6.1.76-1); however:

  Package linux-headers-6.1.0-18-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-18-amd64
 linux-headers-6.1.0-18-amd64
 linux-image-amd64
 linux-headers-amd64
Log ended: 2024-03-28  09:58:24

Something's now apparent: the initrd hadn't been created for this new 
-18 kernel until after grub-mkconfig's execution. My backed up erroneous 
grub.cfg confirms this. Maybe grub-mkconfig doesn't allow the use of 
UUID= absent an initrd? That would be enough to explain everything.


Anyway, this is not an easy thing to reproduce. I guess it just calls 
attention to the danger of unattended/automatic upgrades in odd cases 
like these.


Thanks Henning, and thank you David for your help. (Apologies for not 
replying to your messages; I'd forgotten to 

Re: making Debian secure by default

2024-03-29 Thread Andy Smith
Hi,

On Fri, Mar 29, 2024 at 05:43:22PM -, Curt wrote:
> On 2024-03-29, Andy Smith  wrote:
> >> 
> >> It makes no fucking difference, because your important data is elsewhere
> >> and completely out of your control.
> >
> > I WAS going to gently suggest that you have a lie down in a cool,
> > shaded room, but which of us had this on our 2024 bingo card?
> 
> This is not a rational response or argument to the reality of the
> situation. You are not in control of your essential data if you are
> integrated into modern society. I have demonstrated my point with the
> French health-care system. If you have a counter-argument, I'd love to
> hear it. But you manifestly do not, and resort childish retorts that
> mean nothing.

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.

Thanks,
Andy

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



Re: making Debian secure by default

2024-03-29 Thread Jeffrey Walton
On Thu, Mar 28, 2024 at 5:17 PM Lee  wrote:
>
> > Hope this helps a little bit.
>
> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

Robert Morris Sr. has some good advice,
: It is
easy to run a secure computer system. You merely have to disconnect
all dial-up connections and permit only direct-wired terminals, put
the machine and its terminals in a shielded room, and post a guard at
the door.

You may remember his son, Robert Tappan Morris. He's the author of the
Morris worm from the late 1980s.

Jeff



Re: making Debian secure by default

2024-03-29 Thread Stefan Monnier
> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

I think to a significant extent, Debian maintainers do aim to make Debian
"secure by default", to the extent possible (i.e. based on what is
expected to be a "normal/typical" use of the system).

Admittedly, "dummies" is not really the target audience for Debian, so
maybe the defaults aren't quite up to *that* task.


Stefan



Re: Comment installer Bookworm sur un HP elite Mini 600 G9 ?

2024-03-29 Thread Lamourec Alain

Bonjour

Vois-tu ta clé dans les médias du BIOS ?
Utilises-tu Ventoy pour booter l'ISO ?
Sinon change de clé, ça arrive qu'il y a des clés qui sont 
capricieuses


Olivier  writes:


Bonjour,

Je viens d'acquérir un HP elite Mini 600 G9 d'occasion sur 
lequel

Windows 11 est installé (BIOS U21 Ver 02.05.00 du 08/23/2022).
Je souhaite installer Bookworm à la place.

J'arrive à accéder au BIOS.
J'ai désactivé le Secure Boot et autorisé le boot depuis une clé 
USB.
Le BIOS contient de multiples options exotiques de 
configuration.


Avec le menu de choix de media de boot, la clé USB sur laquelle 
j'ai

installé l'installeur Debian n'est pas proposée.

Que faire ?

Slts



--
Lamourec Alain



Re: making Debian secure by default

2024-03-29 Thread Roberto C . Sánchez
On Fri, Mar 29, 2024 at 07:02:54PM +0100, Kamil Jońca wrote:
> Andy Smith  writes:
> 
> [...]
> > https://www.openwall.com/lists/oss-security/2024/03/29/4
> >
> > (Upstream xz/lzma project compromised, hostile code inserted into
> > sshd in Debian sid and other leading edge distros.)
> >
> > Thanks,
> > Andy
> 
> O-o, is there any simple test to check if I have infected version or
> not?
> KJ

Yes. It is mentioned in Andres' email and provided as an attachement at
the end.

Regards,

-Roberto
-- 
Roberto C. Sánchez



Re: making Debian secure by default

2024-03-29 Thread Kamil Jońca
Andy Smith  writes:

[...]
> https://www.openwall.com/lists/oss-security/2024/03/29/4
>
> (Upstream xz/lzma project compromised, hostile code inserted into
> sshd in Debian sid and other leading edge distros.)
>
> Thanks,
> Andy

O-o, is there any simple test to check if I have infected version or
not?
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/



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

2024-03-29 Thread Roberto C . Sánchez
On Fri, Mar 29, 2024 at 01:52:18PM -0400, Jeffrey Walton wrote:
> Seems relevant since Debian adopted xz about 10 years ago.
> 
Also note that this has been addressed in Debian:
https://lists.debian.org/debian-security-announce/2024/msg00057.html

Provided here for the benefit those who are not subscribed to
debian-security-announce.

Regards,

-Roberto

-- 
Roberto C. Sánchez



Re: making Debian secure by default

2024-03-29 Thread Curt
On 2024-03-29, Joe  wrote:
>
> He's actually referring to credentials stored externally being

Jesus, what a genius.



Re: making Debian secure by default

2024-03-29 Thread Curt
On 2024-03-29, Andy Smith  wrote:
>> 
>> It makes no fucking difference, because your important data is elsewhere
>> and completely out of your control.
>
> I WAS going to gently suggest that you have a lie down in a cool,
> shaded room, but which of us had this on our 2024 bingo card?
>

This is not a rational response or argument to the reality of the
situation. You are not in control of your essential data if you are
integrated into modern society. I have demonstrated my point with the
French health-care system. If you have a counter-argument, I'd love to
hear it. But you manifestly do not, and resort childish retorts that
mean nothing.




Comment installer Bookworm sur un HP elite Mini 600 G9 ?

2024-03-29 Thread Olivier
Bonjour,

Je viens d'acquérir un HP elite Mini 600 G9 d'occasion sur lequel
Windows 11 est installé (BIOS U21 Ver 02.05.00 du 08/23/2022).
Je souhaite installer Bookworm à la place.

J'arrive à accéder au BIOS.
J'ai désactivé le Secure Boot et autorisé le boot depuis une clé USB.
Le BIOS contient de multiples options exotiques de configuration.

Avec le menu de choix de media de boot, la clé USB sur laquelle j'ai
installé l'installeur Debian n'est pas proposée.

Que faire ?

Slts



Re: Paquetes snap sin snap.

2024-03-29 Thread JavierDebian




El 29/3/24 a las 14:11, Listas escribió:

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




El paquete en cuestión es Geogebra.
Los repositorios están sólo hasta la versión 4.
En una distro de por ahí, creo que Arch, está empaquetada la 5.
Pero la actual 6 sólo por snap para instalar, o un "standalone" que
funciona como api autónoma de Chrome, que es la que estoy usando
ahora.
Pero no es algo que me guste.

Tenían un repositorio, www.geogebra.net, que desapareció.
Y encontrar la api, cuesta mucho dado que la página de descarga esta
hecha por un tuerto con glaucoma.
Si se pulsa la descarga, sólo aparece Windows.
Pero si se revuelve el sitio, hay otras opciones, como la api esta
que
mencioné.
https://download.geogebra.org/installers/6.0

Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso
más
"natural".


Veo que tienen un repositorio en https://github.com/geogebra/geogebra
Siguiendo las instrucciones puedes hacerlo funcionar en local en
versión desktop o servidor web.

Un saludo



Sí, la versión 5.

JAP



Re: Installation minimaliste

2024-03-29 Thread Alex PADOLY

Bonsoir à tous,

Si on veut effectuer une installation minimaliste, faut-il choisir le 
mode expert à l'installation pour maitriser le maximum de chose à 
l'installation.


Merci.

Alex PADOLY

Le 2024-03-25 22:33, Jean Louis Giraud a écrit :

A ma connaissance Lxde n'est plus maintenu depuis 2021 et a fusionné 
avec un autre projet pour donner LXQt


https://fr.m.wikipedia.org/wiki/LXDE

Envoyé de mon iPhone


Le 25 mars 2024 à 14:21, Frederic Zulian  a écrit :


Lxde, lxqt, 

Il y a le choix + limiter les services.

On Mon, 25 Mar 2024, 12:06 ajh-valmer,  wrote: 
Linux light :

https://medium.com/lesenfantsdu-net/des-distributions-linux-light-a121d6019d5d

https://technochouette.istocks.club/les-8-plus-petits-distributions-linux-minimales-et-legeres/2021-04-24/

Hope it helps !

On Sunday 24 March 2024 17:25:23 Alex PADOLY wrote:

Je souhaite faire une installation minimaliste ayant pour objectifs de
regarder des vidéos et d'écouter de la musique uniquement.
Dois-je à l'installation choisir une configuration minimale ou
m'orienter vers une distribution légère basée sur Debian.
Enfin, connaissez-vous un paquet Debian permettant de gérer 
l'archivage
de vidéo et de musique et gérant la lecture de ces deux types de 
médias.

Re: making Debian secure by default

2024-03-29 Thread Joe
On Fri, 29 Mar 2024 16:53:04 +
Andy Smith  wrote:

> Hello,
> 
> On Thu, Mar 28, 2024 at 05:47:44PM -, Curt wrote:
> > On 2024-03-28, Greg Wooledge  wrote:  
> > >
> > > A more proactive endeavor would be to document known best
> > > practices  
> > 
> > It makes no fucking difference, because your important data is
> > elsewhere and completely out of your control.  
> 
> I WAS going to gently suggest that you have a lie down in a cool,
> shaded room, but which of us had this on our 2024 bingo card?
> 
> https://www.openwall.com/lists/oss-security/2024/03/29/4
> 
> (Upstream xz/lzma project compromised, hostile code inserted into
> sshd in Debian sid and other leading edge distros.)
> 

Hah! Most of us remember Heartbleed.

He's actually referring to credentials stored externally being
compromised. I'm not sure what can be done about that: maybe make some
kind of, you know, law, about storing sensitive data, and prosecuting
people who are responsible for failure to keep it secure... nothing
like accountability for discouraging negligence.

-- 
Joe



Re: Paquetes snap sin snap.

2024-03-29 Thread Listas
El vie, 29-03-2024 a las 09:07 -0300, JavierDebian escribió:
> 
> 
> 
> El paquete en cuestión es Geogebra.
> Los repositorios están sólo hasta la versión 4.
> En una distro de por ahí, creo que Arch, está empaquetada la 5.
> Pero la actual 6 sólo por snap para instalar, o un "standalone" que 
> funciona como api autónoma de Chrome, que es la que estoy usando
> ahora.
> Pero no es algo que me guste.
> 
> Tenían un repositorio, www.geogebra.net, que desapareció.
> Y encontrar la api, cuesta mucho dado que la página de descarga esta 
> hecha por un tuerto con glaucoma.
> Si se pulsa la descarga, sólo aparece Windows.
> Pero si se revuelve el sitio, hay otras opciones, como la api esta
> que 
> mencioné.
> https://download.geogebra.org/installers/6.0
> 
> Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso
> más 
> "natural".

Veo que tienen un repositorio en https://github.com/geogebra/geogebra
Siguiendo las instrucciones puedes hacerlo funcionar en local en
versión desktop o servidor web.

Un saludo



Re: making Debian secure by default

2024-03-29 Thread Andy Smith
Hello,

On Thu, Mar 28, 2024 at 05:47:44PM -, Curt wrote:
> On 2024-03-28, Greg Wooledge  wrote:
> >
> > A more proactive endeavor would be to document known best practices
> 
> It makes no fucking difference, because your important data is elsewhere
> and completely out of your control.

I WAS going to gently suggest that you have a lie down in a cool,
shaded room, but which of us had this on our 2024 bingo card?

https://www.openwall.com/lists/oss-security/2024/03/29/4

(Upstream xz/lzma project compromised, hostile code inserted into
sshd in Debian sid and other leading edge distros.)

Thanks,
Andy

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



Re: making Debian secure by default

2024-03-29 Thread Curt
On 2024-03-28, to...@tuxteam.de  wrote:
>
> Security, as Bruce Schneier [1] says, is a process. Not a product.
>

A process that is essentially out of your control.

This is the elephant in the room that you do not wish to address.

Anyway, dream on.





subir paquete

2024-03-29 Thread Deiby Herrera
saludos resulta que photoprinter dejo de funcionar para lo unico que la
usaba era para imprimir fotos tamaño pasaporte de mera que escribi o
desarrolle una propia llamada PotoPassport la con c++ y qt creator hace eso
inserta 4 fotos y las manda imprimir tamaño pasaporte ahora quiero subir la
a los repositorio de debian  y no se por donde aguno con experiencia.

en subir paquetes ya tengo el deb
auxilio


Ujjnkkk

2024-03-29 Thread Bucakk Bucakk



iPhone’umdan gönderildi


Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

2024-03-29 Thread David Wright
On Fri 29 Mar 2024 at 11:06:45 (-0400), Henning Follmann wrote:
> On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:
> > 
> > I've had a bit of a headache understanding why my Debian bookworm system
> > suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
> > the first of my two menuentries in grub.cfg were no longer specifying the
> > linux root by its device UUID (as I was expecting it to do, by honoring
> > GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
> > device node/file (/dev/md0 in this case, hence the kernel panic).
> 
> Was there any error message during the update?
> I think what might have gone wrong, that you ran out of space on /boot.
> 
> > I've poured through the grub scripts a bit but they're quite complex. I've
> > noticed that :
> 
> Yeah, don't do that. These files are all automatically managed.
> All changes should be done in /etc/default/grub or in the config files in
> /etc/default/grub.d
> Then the grub config files are created by running
> update-grub
> 
> > - uninstalling the second of two kernels caused the remaining one to
> > correctly use the device UUID in grub.cfg ;
> 
> and that might have freed enough space on /boot.
> So now everything works again :)
> 
> > - reinstalling that second kernel caused grub.cfg to use UUIDs in all
> > menuentries, as expected.
> > 
> > (Kernel were the two most recent stable ones: 6.1.0-17 and -18.)
> > 
> > This leads me to suspect that my grub.cfg might have been damaged in the way
> > described above because update-grub might have been called in some unusual,
> > limited execution environment. I'd very recently powered off my system and
> > let the default "install pending software updates" option checked by
> > accident, which caused every updated package from the 12.5 release mark to
> > be pulled. I'm guessing that linux-image-6.1.0-18 was part of it.

I'd write "upgraded" rather than "pulled", if that's what you meant.

> > Has anyone witnessed something similar? Would anyone here care to check this
> > somehow? Or should I open a bug against gnome-desktop without waiting?
> >
> Usually it requires some trickery to install a new kernel on machines which
> might not have enough remaining space on the boot partition.
> 
> For simple housekeeping it often is sufficient to run 
> apt autoremove
> after recent updates (after you confirmed that the newly installed kernel
> boots fine).
> That usually frees enough space for a possible new update. 

You can also reduce the space taken up by initrd files, which are
getting rather large nowadays if they are built with MODULES=most
rather than MODULES=dep.

When you have at least two working kernels, remove any unnecessary
backups, copy the older kernel's initrd somewhere else, then rebuild
it with MODULES=dep. If that kernel still boots ok, then you probably
have a lot more room available now for the next kernel upgrade.
Finally, reboot the newer kernel.

Cheers,
David.



Re: Installer le noyau 6.6 sur Bookworm [RESOLU]

2024-03-29 Thread Olivier
Comme espéré dans ce fil de discussion, le dépôt Bookworm-backport
contient maintenant la version 6.6.13 du noyau et la commande apt -y
upgrade
déclenche le passage de la 6.5 précédente à la nouvelle version 6.6.

Ce passage est sans doute lié au fait que le version 6.6 est LTS.

Le ven. 8 mars 2024 à 14:09, Patrick ZAJDA  a écrit :
>
> Bonjour,
>
> Peut-on penser qu'il dépendra un jour d'un paquet
> linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
> pour tout le cycle d'utilisation de Bookworm ?
>
>
> ça dépend si un backport est fait, pour ce qui est du kernel ça suit 
> généralement la version de testing avec un décalage le temps que ça soit 
> éprouvé dans testing et en suite après l'upload c'est assez long le temps du 
> build et ça passe généralement par une validation des ftp masters.
>
> En résumé la réponse est oui, c'est fort probable. Il faut patienter...
>
>
> Le 08/03/2024 à 09:28, Olivier a écrit :
>
> 1. À Michel:
> Je ne vois moi aussi que les paquets:
> linux-image-6.6.13+bpo-amd64-dbg
> linux-image-6.6.13+bpo-amd64-unsigned
>
>
> 2. Il y a quelques semaines, j'ai installé le noyau 6.5 avec la commande:
> apt -y install linux-image-amd64 -t bookworm-backports
>
> Ce paquet linux-image-amd64 du repo backports dépend du seul paquet
> linux-image-6.5.0-0.deb12.4-amd64
> Peut-on penser qu'il dépendra un jour d'un paquet
> linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
> pour tout le cycle d'utilisation de Bookworm ?
>
> 3. Au quotidien, comment met-on à jour un paquet linux-image-amd64 ou
> linux-image-6.6.X-Y.deb12.Z-amd64 ?
> Une commande apt upgrade ou apt dist-upgrade suffit-elle ?
>
> Le jeu. 7 mars 2024 à 17:57, Michel Verdier  a écrit :
>
> Le 7 mars 2024 Olivier a écrit :
>
> J'ai une machine UN305 (processeur Intel Alder lake) sur laquelle j'ai
> installé Bookworm puis le noyau 6.5.
> J'ai besoin d'y installer le noyau 6.6 (pour corriger un problème graphique).
>
> En backport tu as la 6.6.13 disponible. Bizarrement il n'y a que la
> unsigned ou alors j'ai mal regardé :
> linux-image-6.6.13+bpo-amd64-unsigned
> Les sources sont aussi dispo si tu compile ton kernel.
> Et les headers si tu as des drivers à compiler :
> linux-headers-6.6.13+bpo-amd64
>
>
> --
> Patrick ZAJDA



Re: making Debian secure by default

2024-03-29 Thread Jeffrey Walton
On Wed, Mar 27, 2024 at 8:37 PM Lee  wrote:
>
> I just saw this advisory
>   Escape sequence injection in util-linux wall (CVE-2024-28085)
> https://seclists.org/fulldisclosure/2024/Mar/35
> where they're talking about grabbing other users sudo password.
>
> Apparently the root of the security issue is that wall is a setguid program?
>
> Even more fun is the instructions
>   To make sure the PoC will work, make sure your victim user can
>   actually receive messages. First check that mesg is set to y
>   (`mesg y`). If a user does not have mesg turned on, they are not
>   exploitable.
>
> WTF??  I've never heard of a mesg, but
>   $ which mesg
>   /usr/bin/mesg
>
> So.  There is a program called 'mesg',  hrmmm..
>   man mesg
> ...
>   Traditionally, write access is allowed by default.  However,  as  users
>   become  more  conscious  of various security risks, there is a trend to
>   remove write access by default, at least for the primary  login  shell.
>   To  make  sure  your ttys are set the way you want them to be set, mesg
>   should be executed in your login scripts.
>
> oof.  Are there instructions somewhere on how to make Debian secure by 
> default?

There are Security Technical Implementation Guides (STIG) for Red Hat,
Solaris, SUSE, and Ubuntu. Unfortunately, nothing for Debian. See
.
More generally, for Operating Systems, see
.

Jeff



Re: Could Gnome's "install pending software updates" cause installation scripts to misbehave?

2024-03-29 Thread Henning Follmann
On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote:
> Hi,
> 
> I've had a bit of a headache understanding why my Debian bookworm system
> suddenly panicked at boot with an 'unable to mount root fs' error. Turns out
> the first of my two menuentries in grub.cfg were no longer specifying the
> linux root by its device UUID (as I was expecting it to do, by honoring
> GRUB_DISABLE_LINUX_UUID != true) ; instead these menuentries were using the
> device node/file (/dev/md0 in this case, hence the kernel panic).
> 

Was there any error message during the update?
I think what might have gone wrong, that you ran out of space on /boot.


> I've poured through the grub scripts a bit but they're quite complex. I've
> noticed that :

Yeah, don't do that. These files are all automatically managed.
All changes should be done in /etc/default/grub or in the config files in
/etc/default/grub.d
Then the grub config files are created by running
update-grub


> 
> - uninstalling the second of two kernels caused the remaining one to
> correctly use the device UUID in grub.cfg ;

and that might have freed enough space on /boot.
So now everything works again :)

> 
> - reinstalling that second kernel caused grub.cfg to use UUIDs in all
> menuentries, as expected.
> 
> (Kernel were the two most recent stable ones: 6.1.0-17 and -18.)
> 
> This leads me to suspect that my grub.cfg might have been damaged in the way
> described above because update-grub might have been called in some unusual,
> limited execution environment. I'd very recently powered off my system and
> let the default "install pending software updates" option checked by
> accident, which caused every updated package from the 12.5 release mark to
> be pulled. I'm guessing that linux-image-6.1.0-18 was part of it.
> 
> Has anyone witnessed something similar? Would anyone here care to check this
> somehow? Or should I open a bug against gnome-desktop without waiting?
>

Usually it requires some trickery to install a new kernel on machines which
might not have enough remaining space on the boot partition.

For simple housekeeping it often is sufficient to run 
apt autoremove
after recent updates (after you confirmed that the newly installed kernel
boots fine).
That usually frees enough space for a possible new update. 


-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com



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

2024-03-29 Thread Eric DEGENETAIS
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: Paquetes snap sin snap.

2024-03-29 Thread JavierDebian




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.
Los repositorios están sólo hasta la versión 4.
En una distro de por ahí, creo que Arch, está empaquetada la 5.
Pero la actual 6 sólo por snap para instalar, o un "standalone" que 
funciona como api autónoma de Chrome, que es la que estoy usando ahora.

Pero no es algo que me guste.

Tenían un repositorio, www.geogebra.net, que desapareció.
Y encontrar la api, cuesta mucho dado que la página de descarga esta 
hecha por un tuerto con glaucoma.

Si se pulsa la descarga, sólo aparece Windows.
Pero si se revuelve el sitio, hay otras opciones, como la api esta que 
mencioné.

https://download.geogebra.org/installers/6.0

Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso más 
"natural".


Saludos

JAP







Could Gnome's "install pending software updates" cause installation scripts to misbehave?

2024-03-29 Thread Lucas B. Cohen

Hi,

I've had a bit of a headache understanding why my Debian bookworm system 
suddenly panicked at boot with an 'unable to mount root fs' error. Turns 
out the first of my two menuentries in grub.cfg were no longer 
specifying the linux root by its device UUID (as I was expecting it to 
do, by honoring GRUB_DISABLE_LINUX_UUID != true) ; instead these 
menuentries were using the device node/file (/dev/md0 in this case, 
hence the kernel panic).


I've poured through the grub scripts a bit but they're quite complex. 
I've noticed that :


- uninstalling the second of two kernels caused the remaining one to 
correctly use the device UUID in grub.cfg ;


- reinstalling that second kernel caused grub.cfg to use UUIDs in all 
menuentries, as expected.


(Kernel were the two most recent stable ones: 6.1.0-17 and -18.)

This leads me to suspect that my grub.cfg might have been damaged in the 
way described above because update-grub might have been called in some 
unusual, limited execution environment. I'd very recently powered off my 
system and let the default "install pending software updates" option 
checked by accident, which caused every updated package from the 12.5 
release mark to be pulled. I'm guessing that linux-image-6.1.0-18 was 
part of it.


Has anyone witnessed something similar? Would anyone here care to check 
this somehow? Or should I open a bug against gnome-desktop without waiting?


Thank you for any insight.

Apologies for possible e-mail client misconfiguration.

Regards,

--
Lucas



Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

2024-03-29 Thread Greg Wooledge
On Fri, Mar 29, 2024 at 11:49:06AM +0100, Bernard wrote:
> Hi to Everyone,
> 
> The text quoted below has already been sent to the list, 2-3 days ago,
> someone had replied to it (but the message has been lost, I no longer see it
> on the list. I had replied again, which reply disappeared too.)
> So, I want to say again that the errors shown in the text below (S instead
> of $, ` inst of ') are not errors that I made in the php script, which
> scripts I write using old vi (vim). This was due to the fact that some parts
> of my messages here were typed using LibreOffice and parts were copy/pasted
> here.

That was something you wrote in a private reply to me, not to the list.



Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

2024-03-29 Thread Bernard

Hi to Everyone,

The text quoted below has already been sent to the list, 2-3 days ago, 
someone had replied to it (but the message has been lost, I no longer 
see it on the list. I had replied again, which reply disappeared too.)
So, I want to say again that the errors shown in the text below (S 
instead of $, ` inst of ') are not errors that I made in the php script, 
which scripts I write using old vi (vim). This was due to the fact that 
some parts of my messages here were typed using LibreOffice and parts 
were copy/pasted here.


So, my actual concern still is that I can't get a php 7.4 script to call 
for a value entry, as I did years ago with older version.

 $nom = S_GET [‘nom’] ;
>
> no longer operates with php 7.4. This code is simply ignored. S_REQUEST,
> $_POST do not work either.
I spent hours searching for a way to get php to ask for an entry, but I 
didn't find anything.


On 28/03/2024 10:33, Bernard wrote:
Yes, this list (exactly the same here) shows that mysqli.so is loaded. 
In any case, as said before, this function does operate as I have checked.


But I've found more problems, concerning $_REQUEST, $_GET...

The old way that I used 11 yrs ago no longer works :

$nom = S_GET [‘nom’] ;

no longer operates with php 7.4. This code is simply ignored. S_REQUEST, 
$_POST do not work either.


Could someone show me how I should write these few lines dating 2010… 
(worked at least till 2013), which code is now ignored by php 7.4 with 
no explanations since I don’t have debugging function active. This 
example code comes from Kevin Yanks' s book dating 2010 :




These lines are now ignored by php 7.4

In any case, I’ve checked my php.ini (which I sent here a few days ago), 
and it seems to say that cookies are activated as well as $_REQUEST and 
other concerned functions.


On 26/03/2024 10:38, Bernard wrote:

ls -Al /usr/lib/php/20190902




Re: Paquetes snap sin snap.

2024-03-29 Thread Listas
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



Re: making Debian secure by default

2024-03-29 Thread Emanuel Berg
David Wright wrote:

>> Ah, surely it can't refer to that as that would be
>> completely ridiculous as it would imply "wanna install
>> stuff? sure, but then it isn't secure anymore".
>
> It's not clear what "isn't secure anymore" means. [...]

It means as soon as you start doing stuff with the software,
it isn't secure anymore. Which is comical to some extent as
doing stuff is the purpose of computers.

So to base security boasting on people having the most
minimal, restricted and inactive system, it is like boasting
this marvelous piece of body armor is guaranteed to not have
a single infantryman killed - just don't go to war.

(Note that now I'm just making fun at the slogan and boasting,
not saying anything negative of their OS necessarily - I've
used it myself, it send pretty good and, indeed, secure.)

>  "Secure by Default"
>
>  "To ensure that novice users of OpenBSD do not need to
>   become security experts overnight (a viewpoint which other
>   vendors seem to have), we ship the operating system in
>   a Secure by Default mode. All non-essential services are
>   disabled. As the user/administrator becomes more familiar
>   with the system, he will discover that he has to enable
>   daemons and other parts of the system. During the process
>   of learning how to enable a new service, the novice is
>   more likely to learn of security considerations."
>
> from https://www.openbsd.org/security.html
> OTOH:
>
>  "There are many applications one might want to use on an
>   OpenBSD system. To make this software easier to install
>   and manage, it is ported to OpenBSD and packaged. The aim
>   of the package system is to keep track of which software
>   gets installed, so that it may be easily updated or
>   removed. In minutes, a large number of packages can be
>   fetched and installed, with everything put in the
>   right place."
>
>  "The ports collection does not go through the same thorough
>   security audit that is performed on the OpenBSD base
>   system. Although we strive to keep the quality of the
>   packages high, we just do not have enough resources to
>   ensure the same level of robustness and security."
>
> from https://www.openbsd.org/faq/faq15.html (Package
> Management).

The more you install, the less secure it gets. Yeah, can't
base the security model on that.

They should do it the other way around, write a piece of
software that breaks everything. Install in on OpenBSD and if
it breakes it, OpenBSD is not more secure than anyone else.
If nothing happens tho most likekly you are safe.

-- 
underground experts united
https://dataswamp.org/~incal



Re: Paquetes snap sin snap.

2024-03-29 Thread Camaleón
El 2024-03-28 a las 14:59 -0300, JavierDebian escribió:

> Buenas tardes.
> 
> Proyecto para mi fin de semana:

Aquí en España tenemos un fin de semana «extendido» de 4 días (en 
algunas comunidades) por ser festivo de Pascua :-)
 
> Instalar paquetes de SNAP sin instalar Snap.
> Odio Snap.
> 
> ¿Alguien tiene alguna idea o intentó algo?

Se supone que la ventaja (ejem) de usar Snap es la facilidad (que la 
proporciona snapd) y la seguridad (que la proporciona squashfs y 
Apparmor).

De hecho, en Debian el paquete snapd depende¹ de squashfs, apparmour y 
systemd. 

Pero técnicamente debería ser posible ejecutar un paquete snap sin tener
la morralla instalada. Ahora bien... el resultado puede funcionar o no 
(apartado «Running snaps without snapd»):

Canonical shows how to use Snaps without the Snap Store
https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/

Sin tener instalado snapd auguro problemas habituales de dependencias 
no satisfechas y bibliotecas incompatibles, es decir, problemas mil 
dependiendo de cómo esté «esnapeada» (empaqueteda) cada aplicación.

En suma, que te espera una buena «penitencia» >:-)

¹https://packages.debian.org/bookworm/snapd

Saludos,

-- 
Camaleón 



Re: OT: Lista de correo sobre HARDWARE

2024-03-29 Thread Camaleón
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.

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 



Re: making Debian secure by default

2024-03-29 Thread Ralph Aichinger
On Thu, 2024-03-28 at 14:12 -0400, Lee wrote:

> 
> Yes, it does.  I was hoping for something simple but it's becoming
> clear to me that there's no simple "make Debian secure for dummies"
> checklist to follow.

Making "Debian secure for dummies" and having a multi-user system at
the same time does not sense, IMO. If you want to secure your Debian
system, one of the easiest and most important steps is: Don't give
anyone access who you do not trust. 

Having a true multi-user system that shields users from each other is
much much harder, and certainly nothing "dummies" or beginners should
even try.

/ralph