[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<ME0P300MB07133CFFF9E6AA1309869788EEF6A@ME0P300MB0713.AUSP300.PROD.OUTLOOK.COM>
Date: Fri, 17 Oct 2025 00:08:42 +0000
From: Peter Gutmann <pgut001@...auckland.ac.nz>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
Douglas Bagnall <douglas.bagnall@...alyst.net.nz>
Subject: Re: Samba security releases for CVE-2025-10230 and
CVE-2025-9640
Demi Marie Obenour <demiobenour@...il.com> writes:
>On 10/15/25 22:18, Douglas Bagnall wrote:
>> Anyway, the summary is the Samba 3/4 history has left us with
>> unmaintained pockets within our codebase that we ignore because we
>> assume nobody is using them, but which we don't delete because maybe
>> somebody is using them. There may not be very many more.
>
>Would it make sense to announce that they are deprecated, and then remove
>them in the next release?
That doesn't work, people don't read and/or ignore the announcement
(particularly if it's buried in a three-page shopping list below "patched a
flobblenortz bug in the Wombat 68000 port") and then complain in the next
release when it vanishes.
The process I use is:
n: Present.
n+1: Warn of deprecation.
n+2: #ifdef out
n+3: #error inside the #ifdef, "Contact the maintainer if you see this message".
n+4: As above.
n+5: As above.
n+6: Remove code.
This assumes there's enough time throughout, so a few years, for everyone to
catch up. If you're doing releases every few weeks or months you'll need to
spread it out a bit more.
Peter.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
