Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

On 31/08/2024 20:07, Samuel Henrique wrote: Hello everyone, I've written another revision of my proposal, this is version 3 of it, the previous ones are on this email thread on debian-security@lists.debian.org. I did get some feedback from the Security Team privately, it wasn't anything confide

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

Hello everyone, I've written another revision of my proposal, this is version 3 of it, the previous ones are on this email thread on debian-security@lists.debian.org. I did get some feedback from the Security Team privately, it wasn't anything confidential, it's just that some members of the team

Re: Upcoming stable point release (12.7)

On Tue, 2024-07-16 at 21:22 +0100, Jonathan Wiltshire wrote: > The next point release for "bookworm" (12.7) is scheduled for > Saturday, > August 31st. Processing of new uploads into bookworm-proposed-updates > will > be frozen during the preceeding weekend. The archive side of the point release h

Re: Upcoming oldstable point release (11.11)

On Tue, 2024-07-16 at 21:25 +0100, Jonathan Wiltshire wrote: > The next and final point release for "bullseye" (11.11) is scheduled > for > Saturday, August 31st. Processing of new uploads into > bullseye-proposed-updates will be frozen during the preceeding > weekend. The archive side of the poin

Re: Recording for my DebConf talk about CVEs

And for this we thank you. :) Darren On Fri, Aug 30, 2024 at 7:06 AM Sylvain Beucler wrote: > Hello Samuel, > > On 27/08/2024 23:17, Samuel Henrique wrote: > > As I've mentioned before, here's the recording of the CVE talk from this > year's > > DebConf, the talk is titled: "Fixing CVEs on Debi

Re: Recording for my DebConf talk about CVEs

Hello Samuel, On 27/08/2024 23:17, Samuel Henrique wrote: As I've mentioned before, here's the recording of the CVE talk from this year's DebConf, the talk is titled: "Fixing CVEs on Debian: Everything you probably know already" I've provided subtitles (en, pt-br) and chapter markers for the vi

Re: Latent bugs in armel, armhf packages built before t64 transition

[ Martin added to CC ] On 2024-08-16 12:02, Chris Hofstaedtler wrote: > while investigating a test failure in ksh93u+m, it became clear that > packages last built before the time_t-64bit transition can have > latent bugs. > They might very well now FTBFS or fail at runtime (autopkgtest time > or l

Re: bind9 update 9.16.50 -- too many record

Hi Ondrej, On Mon, Jul 29, 2024 at 12:14:01PM +0200, Ondřej Surý wrote: > I've now also ported all the changes to the system tests, so I can > confirm the changes are correct and I've now uploaded the version > with configuration options to security-master. > > This means that information in: >

Re: bind9 update 9.16.50 -- too many record

I've now also ported all the changes to the system tests, so I can confirm the changes are correct and I've now uploaded the version with configuration options to security-master. This means that information in: https://kb.isc.org/docs/rrset-limits-in-zones also applies to bind9_9.16.50-1~deb11u

Re: bind9 update 9.16.50 -- too many record

Hello and thank you all for your answers. Indeed we might push the update to Bookworm four our DNS servers, or wait for the backports version to reach 9.18.28 (where the configuration option exists, which is not yet the case for the 9.16.24 that's available right now). > The source package can be

Re: bind9 update 9.16.50 -- too many record

Hey, I've successfully backported the configuration options from 9.18 to 9.16, so if you need to bump the limits, it will be possible in the next upload. That said, I don't currently have a repository where I can upload the updated packages, so I'll do the upload to security master, but before Sa

Re: bind9 update 9.16.50 -- too many record

Hi, [looping in explicitly Ondrej, maintainer of bind9] On Fri, Jul 26, 2024 at 03:40:30PM -0400, Lee wrote: > On Fri, Jul 26, 2024 at 11:24 AM Guillaume Bienkowski wrote: > > > > Hello, > > Hi > > > We are using bind9 with many SRV entries to allow for dynamic discovery of > > hosts to monito

Re: bind9 update 9.16.50 -- too many record

On Fri, Jul 26, 2024 at 11:24 AM Guillaume Bienkowski wrote: > > Hello, Hi > We are using bind9 with many SRV entries to allow for dynamic discovery of > hosts to monitor in our infrastructure. We have 300+ SRV records for the same > domain name. > > After the security update of tonight (9.16.4

Re: Upcoming stable point release (12.6)

On Wed, 2024-06-12 at 21:07 +0100, Jonathan Wiltshire wrote: > The next point release for "bookworm" (the delayed 12.6 release) is > scheduled for Saturday, 29th June 2024. Processing of new uploads > into bookworm-proposed-updates will be frozen during the preceding > weekend. The archive side of

Re: Upcoming oldstable point release (11.10)

On Wed, 2024-06-12 at 21:13 +0100, Jonathan Wiltshire wrote: > On Wed, Jun 12, 2024 at 09:11:32PM +0100, Jonathan Wiltshire wrote: > > The next point release for "bullseye" (11.10) is scheduled for > > Saturday, > > February 10th. Processing of new uploads into bullseye-proposed- > > updates > > wi

RE: Mini-DebConf in Cambridge, UK - October 10-13 2024

will not be attending Debcamp/Debconf at all this year last week of July/first week of August as I am tired of drama in the Debian community right now and sledge was being an asshole and banned me from OFTC for a month like the transphobic pig he is, however will be attending as an online visito

Re: CVE applicability

Arul Anand MM wrote: > Advisory page on September 14 > https://web.archive.org/web/20230924174231/https://security-tracker.debian.org/tracker/CVE-2023-3390 > states the issue is fixed in 5.10.191-1 No, it doesn't. It states the issue was fixed - for bullseye, i.e. oldstable - in 5.10.179-3 (lowe

Re: CVE applicability

Hi, On Wed, Jun 19, 2024 at 12:04:45AM +0530, Arul Anand MM wrote: > Hello Debian Security Team, > > This is regarding Debian advisory > https://security-tracker.debian.org/tracker/CVE-2023-3390. > > I would like to confirm whether version 5.10.191-1 is impacted by the UAF > and LPE. > > Adviso

Re: Upcoming oldstable point release (11.10)

On Wed, Jun 12, 2024 at 09:11:32PM +0100, Jonathan Wiltshire wrote: > The next point release for "bullseye" (11.10) is scheduled for Saturday, > February 10th. Processing of new uploads into bullseye-proposed-updates > will be frozen during the preceding weekend. The correct date for 11.10 is Satu

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

Hello everyone, Just wondering if the Security team could spend some time availiating my proposal. Feedback from others is always welcomed too, but in order to go ahead I would like to understand where the team stands. Cheers, -- Samuel Henrique

Re: golang-github-disintegration-imaging: CVE-2023-36308

Hi Security team, There's a third party patch for this CVE[2], and at least testing locally with the PoC in[1] seems to mitigate the issue. Do you think this is OK to pick and upload? Maytham Alsudany wrote: > Hi Anthony, > > As you are the uploader for golang-github-disintegration-imaging,

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

Hello everyone, I've done some small updates to the proposal, mostly improving readability and making my suggestion more clear. v2 below: I would like to propose something which will lower the amount of reported false-positive CVEs to our users by about 20%. # tl;dr We don't have a unique way o

Re: RFS: paramspider package

Hello Aquila, > I have taken the initiative to package paramspider for Debian, and the > package is readily accessible in my Salsa repository at > https://salsa.debian.org/aquilamacedo/paramspider > > I would be grateful if you would consider sponsoring the paramspider > package. I am confident th

Re: RFS: assetfinder package

Hello Aquila, > I have taken the initiative to package assetfinder for Debian, and the > package is > readily accessible in my Salsa repository at > https://salsa.debian.org/aquilamacedo/assetfinder I see that the package is currently in NEW by Josenilson. Me and you spoke about this but I'm send

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

* [Wed, Apr 03, 2024 at 11:11:20PM +0100] Samuel Henrique: On the proposed solution I also mention that we can use the "(free text comment)" section to indicate that, while sticking to "not-affected", this would simplify things as no new value is needed. But parsing the cases where only the sourc

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

On Wed, 3 Apr 2024 at 17:04, Gian Piero Carrubba wrote: > > * [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique: > ># Alternative solutions: > >If we really want to distinguish the case when we don't produce any affected > >packages but the source contains the vulnerability (a build with dif

Re: security-tracker: A proposal to significantly reduce reported false-positives (no affected-code shipped)

* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique: # Alternative solutions: If we really want to distinguish the case when we don't produce any affected packages but the source contains the vulnerability (a build with different flags might result in an affected package), we can create a n

Re: xz backdoor prevention and hosts.deny?

* [Sun, Mar 31, 2024 at 09:28:46PM +] Nick Sal: With respect to debian testing, assume we filter SSH access only to a subnet using the files host.{deny,allow} (see below). Would this prevent the attack if a malicious payload was not sent from the allowed subnet? I've not seen any reference

Re: Upcoming stable point release (12.6)

On 17184 March 1977, Gian Piero Carrubba wrote: Due to recent events, the point release has been postponed. A new date will be announced when possible. Given the centrality of xz, and standing that AFAIK the intricacies of the attack are not yet fully understood, should we expect a complete re

Re: Upcoming stable point release (12.6)

* [Fri, Mar 29, 2024 at 10:24:09PM +] Adam D. Barratt: Due to recent events, the point release has been postponed. A new date will be announced when possible. Given the centrality of xz, and standing that AFAIK the intricacies of the attack are not yet fully understood, should we expect a

Re: Upcoming stable point release (12.6)

On Fri, 2024-02-16 at 17:35 +, Jonathan Wiltshire wrote: > The next point release for "bookworm" (12.6) is scheduled for > Saturday, April 6th. Processing of new uploads into bookworm- > proposed-updates will be frozen during the preceeding weekend. Due to recent events, the point release has

Re: c-ares, CVE-2023-31147, CVE-2023-31124

On 23/06/2023 10:21, Moritz Muehlenhoff wrote: But in fact the view in the Debian security is a little misleading, given that it displays "vulnerable" all over the place, e.g. https://security-tracker.debian.org/tracker/CVE-2023-31147 It would be nice if that "unimportant" issues it would instea

Re: CVE-2023-41105 not fixed in bookworm

On 10/03/2024 21:23, StealthMode Hu wrote: Im just going to state this and let yall figure it out. Security Exploits / CVE? Look no matter what OS, or SOFTWARE you run on your electronics hardware. At the end of the day, Electronics has a fatal flaw. And cannot be secured. That flaw has been

Re: CVE-2023-41105 not fixed in bookworm

Im just going to state this and let yall figure it out. Security Exploits / CVE? Look no matter what OS, or SOFTWARE you run on your electronics hardware. At the end of the day, Electronics has a fatal flaw. And cannot be secured. That flaw has been known about since Electronics was invented /

Re: CVE-2023-41105 not fixed in bookworm

Hi, On Fri, Mar 01, 2024 at 09:11:34AM +0100, Richard van den Berg wrote: > Dear security team, > > May I ask why CVE-2023-41105 was marked as " (Minor issue)"[1] ? > > As the CVE description says there are plausible cases where this can lead to > security issues. > > There is a backport availa

Re: Upcoming oldstable point release (11.9)

On Wed, 2024-01-24 at 18:21 +, Adam D. Barratt wrote: > Hi, > > The next point release for "bullseye" (11.9) is scheduled for > Saturday, > February 10th. Processing of new uploads into bullseye-proposed- > updates > will be frozen during the preceding weekend. The archive side of the point r

Re: Upcoming stable point release (12.5)

On Wed, 2024-01-24 at 18:20 +, Adam D. Barratt wrote: > Hi, > > The next point release for "bookworm" (12.5) is scheduled for > Saturday, > February 10th. Processing of new uploads into bookworm-proposed- > updates > will be frozen during the preceding weekend. The archive side of the point r

Re: new redirects for www.d.o/security and www.d.o/lts/security

Hi Thomas, On Fri, Jan 05, 2024 at 12:06:58AM +0100, Thomas Lange wrote: > Hi all, > > we now redirect all DSA/DLA URLs under security and lts/security with > or without having the year in the path and with or without a version > to their announcement mail: > Examples: > /security/dsa-5576 > /sec

SOP migration (was Re: Reaction to potential PGP schism)

Hi! Daniel thanks for all your work on the OpenPGP working group, and on SOP! :) On Wed, 2023-12-20 at 22:16:28 -0500, Daniel Kahn Gillmor wrote: > # What Can Debian Do About This? > > I've attempted to chart one possible path out of part of this situation > by proposing a minimized, simplified

Re: Reaction to potential PGP schism

Hi Daniel, Quick backstory: I stayed away from hardware crypto for a long while since there were so many incompatibilities, partial support, or side patches to get basic things to work. Over time, it seems it got to a point where it's mainstream enough that you can buy a Yubikey without much of a

Re: Reaction to potential PGP schism

Hi Gioele-- On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote: > On 21/12/23 04:16, Daniel Kahn Gillmor wrote: > As the Uploader of rust-sequoia-openpgp, what do you think of the > related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg > that uses sequoia internally)? >

Re: Reaction to potential PGP schism

Interesting point in this talk: The APT team is already working on non- PGP signatures. https://wiki.debian.org/Teams/Apt/Spec/AptSign I can see the advantages of that for release signatures which use a rarely changing set of keys. However, I do not see any good alternative for PGP for personal s

Re: Reaction to potential PGP schism

On Wed, Dec 20, 2023 at 10:16:28PM -0500, Daniel Kahn Gillmor wrote: > # Why is GnuPG on Debian's Critical Path? > > In 2023, I believe GnuPG is baked into our infrastructure largely due to > that project's idiosyncratic interface. It is challenging even for a > sophisticated engineer to figure

Re: Reaction to potential PGP schism

On 21/12/23 04:16, Daniel Kahn Gillmor wrote: # What Can Debian Do About This? I've attempted to chart one possible path out of part of this situation by proposing a minimized, simplified interface to some common baseline OpenPGP semantics -- in particular, the "Stateless OpenPGP" interface, or

Re: Reaction to potential PGP schism

Thank you very much  for your explanation  On Thu, Dec 21, 2023 at 2:13 AM, Christoph Biedl wrote: Daniel Kahn Gillmor wrote...(...)Thanks for your exhaustive description. I'd just like to point out onepoint:> In practice, i think it makes the most sense to eng

Re: Reaction to potential PGP schism

Daniel Kahn Gillmor wrote... (...) Thanks for your exhaustive description. I'd just like to point out one point: > In practice, i think it makes the most sense to engage with > well-documented, community-reviewed, interoperably-tested standards, and > the implementations that try to follow them.

Re: Reaction to potential PGP schism

hey folks-- [ This message won't make sense unless the reader distinguishes clearly between OpenPGP the protocol and GnuPG the implementation! As a community we have a history of fuzzily conflating the two terms, which is one of the reasons that we're in this mess today. Please read expli

Re: Handle jq CVE-2023-49355, which is equal to CVE-2023-50246

On Tue, Dec 19, 2023 at 05:13:34PM +0100, Sylvain Beucler wrote: > On 16/12/2023 11:15, ChangZhuo Chen (陳昌倬) wrote: > > I am jq maintainer, and right now CVE-2023-49355 is listed in security > > tracker [0]. However, this CVE is equal to CVE-2023-50246 according to > > upstream [1], which has been

Re: Handle jq CVE-2023-49355, which is equal to CVE-2023-50246

Hi, On 16/12/2023 11:15, ChangZhuo Chen (陳昌倬) wrote: I am jq maintainer, and right now CVE-2023-49355 is listed in security tracker [0]. However, this CVE is equal to CVE-2023-50246 according to upstream [1], which has been fixed in 1.7.1-1 [2]. In this case, how should I handle CVE-2023-49355?

Re: Reaction to potential PGP schism

On 17077 March 1977, Stephan Verbücheln wrote: How can Debian deal with this? Should Debian intervene to prevent the worst? We, as Debian, look and wait what comes out. And then *MAY* at some point decide to add (or switch to) a new thing, if that appears better. Also, it will be a high bar f

Re: Reaction to potential PGP schism

Hi, Personal view here. Stephan Verbücheln wrote on 14/12/2023 at 11:29:17+0100: > [[PGP Signed Part:No public key for 603542590A3C7C62 created at > 2023-12-14T11:29:17+0100 using EDDSA]] > Hello everyone > > As you probably know, Debian relies heavily on GnuPG for various > purposes, includin

Re: [arm64] secure boot breach via VFIO_NOIOMMU

On Thu, Dec 14, 2023 at 09:26:09AM +0100, Salvatore Bonaccorso wrote: >Hi, > >On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: >> Hi >> >> Over six years ago, support for VFIO without IOMMU was enabled for >> arm64. This is a breach of the integrity lockdown requirement of secure >>

Re: [arm64] secure boot breach via VFIO_NOIOMMU

Hi, On Wed, Dec 13, 2023 at 10:45:01PM +0100, Bastian Blank wrote: > Hi > > Over six years ago, support for VFIO without IOMMU was enabled for > arm64. This is a breach of the integrity lockdown requirement of secure > boot. > > VFIO is a framework for handle devices in userspace. To make > th

Re: Upcoming stable point release (12.3)

On Sun, 2023-11-12 at 17:46 +, Adam D. Barratt wrote: > The next point release for "bookworm" (12.3) is scheduled for > Saturday, > December 9th. Processing of new uploads into bookworm-proposed- > updates > will be frozen during the preceding weekend. The archive side of the point release has

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

On Fri, Oct 27, 2023 at 10:55:48AM +0200, Bastian Blank wrote: > On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote: > > > > ## Image packages contains more version info > > > > > > > > Example: linux-image-6.5.3-cloud-arm64 > > > > > > > It will not longer be possible to reliabl

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote: > > > ## Image packages contains more version info > > > > > > Example: linux-image-6.5.3-cloud-arm64 > > > > > It will not longer be possible to reliably derive the package name from > > > kernel release (see above), as both va

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

OK, it seems my original email got lost somewhere in tech hickups, it's possible the kernel crashed before sending the email, AMD just crashes once or twice a day. So I'm writing this email a bit in a hurry, so it's not quite as thought out as the last one weeks ago, but yesterday's email was pre

Re: Upcoming changes to Debian Linux kernel packages

On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote: > I think that's what you mean by the first-level error. > If not, I'm still confused. > In the second level error case you are talking about is: No, the first level is always: but the new kernel does not work. The second is: I need to u

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

t; kernel release (see above), as both values are not really related > > anymore. > What should work: We define a new control field. It contains both the > kernel name and a version prefix. Or would it be easier to re-use normal dependency resolving, like: Kernel-Provides: linux (&g

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

t two(?). This means: - Images and headers are always kept with the same versions. - Different images (-arm64, -rt-arm64) are always kept together. Counter proposal: Use see the kernel release as debian version and match on the upstream version. But then we need to re-define what we put into the

Re: Upcoming stable (12.2) and oldstable (11.8) point releases

On Fri, Sep 01, 2023 at 05:57:20PM +0100, Jonathan Wiltshire wrote: > The next point releases for "bookworm" (12.2) and "bullseye" (11.8) will > take place on Saturday, October 7th 2023. Processing of new uploads into > the relevant queues will be frozen the preceding weekend. The archive side of

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

Hi On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote: > > Multiple uploads of the same upstream version will have > > the same package name, but those rarely happens. > Those happen fairly often for urgent security updates. We could encode that in the upstream version. Aka to have co

Re: Upcoming changes to Debian Linux kernel packages

Sam Hartman writes: > B) They might already have headers installed. Imagine someone who > installs headers at the same time they install the kernel. Unless they > managed to upgrade the same version of their kernel without also > upgrading their headers, they will still have headers. They can

Re: Upcoming changes to Debian Linux kernel packages

> "Bastian" == Bastian Blank writes: Bastian> The same as now: nowhere, because those packages have been Bastian> removed from the archive already. Bastian> And sadly you did not answer the question why a second Bastian> degree error must not be worse then a worked around fir

Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote: > On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote: > > How will the user get the headers matching this previously-used kernel > > that are required until we provide a kernel with the regression fixed? The same as now: nowhere, becaus

Re: Upcoming changes to Debian Linux kernel packages

Hi Andreas On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote: > That should solve the problem where several source packages need to be > updated together. The problem does not come from multiple source packages that need to be updated together. Instead it comes from the way Debian

Re: Upcoming changes to Debian Linux kernel packages

On 03/10/2023 19.30, Bastian Blank wrote: thread. Or freak out because meta packages remain uninstallable in backports for days. ... plus gcc or we change how backports works. If uninstallable packages in backports are a problem, perhaps backports needs something like britney to migrate pac

Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote: > > On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote: > >... > > The core problem is that people assume they can get headers matching the > > currently running kernel, without upgrading first, see also the parallel > > thread. > >... >

Re: Upcoming changes to Debian Linux kernel packages

On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote: >... > The core problem is that people assume they can get headers matching the > currently running kernel, without upgrading first, see also the parallel > thread. >... If the new kernel has a regression that affects the user, the use

Re: Upcoming changes to Debian Linux kernel packages

e 03/10/2023 à 19:06, Bjørn Mork a écrit : herve writes: concerning the linux-headers. may i explain what happend to me. I reinstalled a debian 11.6 some months ago. and last week i had to make virtualbox functioning again. it had to "compile" some kernel modules and need some "headers". my k

Re: Upcoming changes to Debian Linux kernel packages

Hi Sam On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote: > I still think it would help if you would work more on articulating what > problem you are trying to solve with the linux-headers versioning > change. I have read multiple versions of this proposal, and your > follow-ups, and I

Re: Upcoming changes to Debian Linux kernel packages

herve writes: > concerning the linux-headers. may i explain what happend to me. > > I reinstalled a debian 11.6 some months ago. and last week i had to > make virtualbox functioning again. it had to "compile" some kernel > modules and need some "headers". my kernel (from the install is  > 5.10.0-

Re: Upcoming changes to Debian Linux kernel packages

>> 6.7). So the old gpu module for 6.6 gets removed and a new one is >> built for 6.7 only (since there are only 6.7 headers now). Bastian> Ah, here lays the missconception. No, the 6.6 ones are not Bastian> removed. Why should they be? The system knows it can't Bastian> r

Re: Upcoming changes to Debian Linux kernel packages

> "Bastian" == Bastian Blank writes: Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote: >> On 25/09/2023 00.50, Bastian Blank wrote: >> > Already built modules remain until someone deletes it. So you >> can also > switch back to the still installed old

Re: Upcoming changes to Debian Linux kernel packages

On 2023-10-01, Bastian Blank wrote: > So you upgrade the driver and libaries and suddenly your system fails > until you reboot? Okay, I could imaging NVidia doing something like > tying libraries to kernel modules. At least in the past they replaced > gl libraries that did not longer work with X

Re: Upcoming changes to Debian Linux kernel packages

Hi Michel On Sun, Oct 01, 2023 at 12:19:22PM +0200, Michel Verdier wrote: > On 2023-10-01, Bastian Blank wrote: > > Ah, here lays the missconception. No, the 6.6 ones are not removed. Why > > should they be? The system knows it can't rebuild them. > As the old kernel driver is not rebuild it pe

Re: Upcoming changes to Debian Linux kernel packages

On 2023-10-01, Bastian Blank wrote: >> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6 >> which is kept installed) and a new version of the gpu driver (which adds >> support for 6.7). So the old gpu module for 6.6 gets removed and a new one >> is built for 6.7 only (since

Re: Upcoming changes to Debian Linux kernel packages

On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote: > On 25/09/2023 00.50, Bastian Blank wrote: > > Already built modules remain until someone deletes it. So you can also > > switch back to the still installed older kernel version and it will have > > the still working module availab

Re: SALT

Le jeudi 28 septembre 2023, 22:46:41 UTC Bastien Roucariès a écrit : Hi, An update > Hi > > I am trying to fix the CVE for SALT Salt need to be updated due to a failure on the custom crypto protocol what was broken. Both server and client need to be updated due to protocol change. > > Unfortu

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote: > The current way does not work. See all the bug reports about > uninstallable packages and what not with dkms. > > To build modules against version x, you'll need to install version x of > the headers, not x-1 or x+1. This currently

Re: Upcoming changes to Debian Linux kernel packages

On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote: > On 25/09/2023 00.50, Bastian Blank wrote: > > Already built modules remain until someone deletes it.  So you can > > also > > switch back to the still installed older kernel version and it will > > have > > the still working module availa

Re: Upcoming changes to Debian Linux kernel packages

On 25/09/2023 00.50, Bastian Blank wrote: Already built modules remain until someone deletes it. So you can also switch back to the still installed older kernel version and it will have the still working module available. This is what I expect not to work. Assume I have Linux 6.6 and a third-

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

Hi Ben On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote: > On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: > > The same upstream version in testing and backports will have the same > > package name. > This is not OK, because they will be incompatible on architectures > support

Re: Upcoming changes to Debian Linux kernel packages

Hi Andreas On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote: > On 24/09/2023 15.01, Bastian Blank wrote: > > ## Kernel modules will be signed with an ephemeral key > > > > The modules will not longer be signed using the Secure Boot CA like the > > EFI kernel image itself. Instead

Re: Upcoming changes to Debian Linux kernel packages

On 24/09/2023 15.01, Bastian Blank wrote: ## Kernel modules will be signed with an ephemeral key The modules will not longer be signed using the Secure Boot CA like the EFI kernel image itself. Instead a key will be created during the build and thrown away after. Do I correctly assume that ch

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. >

Re: Bug#894081: closing 894081

[BCCed to everyone that I'm aware of having expressed interest in the bug log] On Tue, 2023-08-29 at 11:49 +0100, Mark Hymers wrote: > close 894081 > thanks > > The debian-security-debug archive is now enabled from the ftp-team > POV. Some mirroring > infrastructure still needs to be set up, th

Re: Old kernel versions cleaned out of packages list

Hi, 30 août 2023, 07:19 de car...@debian.org: > They were cleaned up to make up space, as they are superseeded by > newer versions. > > In future this might even happen more automatically and the old > package auto-decrufted from the archive once new version are present > in the archive. > I tota

Re: Old kernel versions cleaned out of packages list

Hi Salvatore, thank you very much for getting back to me. On Wed, Aug 30, 2023 at 07:18:42AM +0200, Salvatore Bonaccorso wrote: > Hi, > > On Tue, Aug 29, 2023 at 02:52:55PM +0200, Adi Kriegisch wrote: > > Dear maintainers, > > > > I hope this is the correct mailing list for my issue: > > > >

Re: Old kernel versions cleaned out of packages list

Hi, On Tue, Aug 29, 2023 at 02:52:55PM +0200, Adi Kriegisch wrote: > Dear maintainers, > > I hope this is the correct mailing list for my issue: > > Apparently all older kernel versions have been removed from Debian > Security's Packages list some time on August 26th before 19:07[1]. > > As I c

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

Hello, On Fri, 21 Jul 2023, Daniel Gröber wrote: > One mention I found is in Raphaël and Roland's DAH (now in CC): > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade I also saw your associated bug report. Thanks for highlighting this issue to me. I updated https://sa

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

On Sat, 2023-07-22 at 17:45 +0200, Hannes von Haugwitz wrote: > What about to add a warning to apt if *-security or *-updates is > configured in the sources list and `APT::Default-Release` is set but > does not match the security or updates repo? That seems like the right solution here, please fi

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote: > You will have to ask the apt developers and archive admins about this, > but at the end of the day reverting it is unlikely to happen, so > probably it is something everyone will just have to learn to live with. What about to add a warni

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

Hi Paul, On Sat, Jul 22, 2023 at 03:56:02PM +0800, Paul Wise wrote: > > One mention I found is in Raphaël and Roland's DAH (now in CC): > > https://debian-handbook.info/browse/stable/sect.apt-get.html#sect.apt-upgrade > > Probably better to file a bug about this, so it is tracked. Ah, I didn't r

Re: Upcoming stable point release (12.1)

On Wed, Jun 28, 2023 at 08:24:31PM +0100, Jonathan Wiltshire wrote: > The first point release for "bookworm" (12.1) is scheduled for Saturday, > July 22nd. Processing of new uploads into bookworm-proposed-updates will be > frozen during the preceding weekend. The archive side of the point release

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

On Fri, 2023-07-21 at 11:04 +0200, Daniel Gröber wrote: > Do you have any references on how this decision came to be? I think it was about making the suite naming more intuitive, consistent with other suites and possibly also some dak implementation concerns. > One mention I found is in Raphaël

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

Hi Paul, On Fri, Jul 21, 2023 at 10:17:28AM +0800, Paul Wise wrote: > On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote: > > > It seems packages from the debian-security repository are not affected by > > this increased priority and will not get intalled as a result. > > This was documented

Re: Setting APT::Default-Release prevents installation of security updates in bookworm!?

On Thu, 2023-07-20 at 22:12 +0200, Daniel Gröber wrote: > It seems packages from the debian-security repository are not affected by > this increased priority and will not get intalled as a result. This was documented in the release notes for Debian bullseye: https://www.debian.org/releases/bulls

Bug#1040914: dev-ref: update best practices around security (Re: Securing Debian Manual too old?)

package: developers-reference x-debbugs-cc: debian-security@lists.debian.org hi, On Tue, Jul 11, 2023 at 10:46:20PM +0200, Moritz Mühlenhoff wrote: > > I found the Securing Debian Manual > > (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html). > > This version is from 2017.

Re: Securing Debian Manual too old?

Stephan Seitz writes: > Hi! > > I found the Securing Debian Manual > (https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html). > This version is from 2017. This document is in fact too outdated and not in a shape we should prominently present it on the Debian website, thanks for

  1   2   3   4   5   6   7   8   9   10   >