https://pad.dc25.debconf.org/p/106-debian-lts-bof
- Next meeting: 2025-07-24 [Location: #debian-lts on IRC]
+ Decide if we maintain that meeting depending on the BoF
Present:
Roberto
Beuc
Thorsten Alteholz
guilhem
Lucas Kanashiro
Faidon Liambotis
tobi
Santiago
rouca
Lee
Jochen
Charles
Paride
Apologies:
Adrian
Helmut
--
Roberto C. Sánchez
LTS team, and for the ideas that develop to the
point where they might be actionable more broadly, we can transfer the
salient parts to new issues in the tracker project.
Regards,
-Roberto
--
Roberto C. Sánchez
he one referencing bookworm.
Regards,
-Roberto
[0] https://gitlab.isc.org/isc-projects/bind9/-/issues/5300
--
Roberto C. Sánchez
ts/2025/05/msg00073.html
--
Roberto C. Sánchez
-Roberto
--
Roberto C. Sánchez
, maybe subtask
> etc ... yes I agree that we can start tracking the tasks around the
> nonissue state as issue in the tracker.
>
> So to move it outside of a mail thread directly to the salsa.
>
For the sake of completeness, here is the issue that Samuel has written:
https://salsa.debian.org/security-tracker-team/security-tracker/-/issues/32
Regards,
-Roberto
--
Roberto C. Sánchez
ners are working on it for the
next point release?
Regards,
-Roberto
--
Roberto C. Sánchez
eady to make any major changes,
but I am genuinely intersted to see where this discussion goes and what
points are raised.
Regards,
-Roberto
--
Roberto C. Sánchez
On Sat, Apr 26, 2025 at 12:38:50PM +0300, Adrian Bunk wrote:
> On Wed, Apr 23, 2025 at 09:38:47PM +0200, Sylvain Beucler wrote:
> >...
> > On 06/04/2025 09:25, Roberto C. Sánchez wrote:
> > > As you go about tasks which require interacting with the security
> > >
On Fri, May 23, 2025 at 10:42:56PM +0200, Bastien Roucaries wrote:
> Le vendredi 23 mai 2025, 21:34:26 heure d’été d’Europe centrale Roberto C.
> Sánchez a écrit :
>
> > To me, that specifically requires that the krb5 maintainers be in
> > agreement with fixing this in book
ling then I recommend
contacting the maintainers and starting the conversation with them.
Regards,
-Roberto
--
Roberto C. Sánchez
Hello everyone,
Since the May LTS contriburor meeting was on IRC, the meeting minutes
and logs are avialable here:
http://meetbot.debian.net/debian-lts/2025/debian-lts.2025-05-22-14.00.html
Regards,
-Roberto
--
Roberto C. Sánchez
things and
made mistakes. Please make sure to suggest improvements, modifications
to the issue list, etc.
Regards,
-Roberto
--
Roberto C. Sánchez
minimize
the possibility of unnecessary and/or duplicate work. However, since you
have already preapred the update and are ready to upload and issue the
DLA, there isn't much of a need to first list the package in
dla-needed.txt.
So, in this case, don't worry about having the package show up in
dla-needed.txt first. You are free to upload and issue the DLA.
Regards,
-Roberto
--
Roberto C. Sánchez
t Xen
+ rouca: help with embargoe'd issue related to 32bit/sobump transitions
- Next meeting: 2025-05-22 14:00 UTC [Location: #debian-lts on IRC]
--
Roberto C. Sánchez
scussion I would consider "git blame takes an
unreasonably long time to be particularly useful" as a valid statement
of a pain point, and I would hesitate to favor a specific possible
solution.
Regards,
-Roberto
--
Roberto C. Sánchez
w up, I'll grab them as well.
Regards,
-Roberto
--
Roberto C. Sánchez
kages.
>
> It would make sense if the same person fixes the CVEs in all copies of
> the bson code in all releases.
>
Agreed.
Chris,
Can you confirm that it's OK for me to go ahead and take over your
claims on mongo-c-driver?
Regards,
-Roberto
--
Roberto C. Sánchez
:mongo-c-driver builds as well libbson binary package and
> superseeds src:libbson
> +mongo-c-driver
> + - libbson-xs-perl (embed)
> + NOTE: src:mongo-c-driver builds as well libbson binary package and
> superseeds src:libbson/stretch
>
> spdlog
> - rap
On Mon, Mar 31, 2025 at 10:25:54AM -0400, Roberto C. Sánchez wrote:
>
> one who developed the patch to this specific CVE).
>
By "this specific CVE" I refer to the most recent CVE (CVE-2025-0755),
but I plan to take care of the other no-dsa CVEs along the way.
Regards,
-Rob
the pressure of an open (critical)
CVE that can't/won't get fixed.
Have you (or can you) assess whether we are more likely to land on one
side or the other?
Regards,
-Roberto
--
Roberto C. Sánchez
-operations script*.
Regards,
-Roberto
* OK, OK. The script was not at all confused. It made the request, got
back a 404 and said "nothing there". The operator, however, was
another story.
--
Roberto C. Sánchez
x, so if anyone is looking for
something that can be done in just a few hours, then please have a look.
Regards,
-Roberto
--
Roberto C. Sánchez
t is easy for pages to be added later for other concerns.
Regards,
-Roberto
--
Roberto C. Sánchez
t
Log:
http://meetbot.debian.net/debian-lts/2025/debian-lts.2025-01-23-14.00.log.html
Regards,
-Roberto
--
Roberto C. Sánchez
ead and prepare the
package for both stable and LTS, and then wait for the LTS upload until
at least the stable version is accepted in proposed updates.
Regards,
-Roberto
--
Roberto C. Sánchez
me minor
> - it will be hard to fix (no upstream support EOL upstream)
>
> So ignored for me
>
After reviewing your summary and the related informationi in the
security tracker, I agree that CVE-2024-23944 should be marked
for LTS and ELTS releases.
Regards,
-Rober
On Thu, Dec 12, 2024 at 03:51:06AM +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2024 at 07:19:50PM -0500, Roberto C. Sánchez wrote:
> >...
> > We can look at our various tasks as follows:
> >
> > - creation of a DLA (requires preparing the update, uploading the
&g
On Thu, Dec 12, 2024 at 03:51:06AM +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2024 at 07:19:50PM -0500, Roberto C. Sánchez wrote:
> >...
> > We can look at our various tasks as follows:
> >
> > - creation of a DLA (requires preparing the update, uploading the
&g
ping again
- ELTS autopkgtests: arm64 work, armhf being worked on as inucs-lxc, LTS
autopkgtests shall use Debusine eventually
+ Action: Helmut to ensure this is documented for LTS use
- AOB
+ None
- Next meeting: 2025-01-23 14:00 UTC [Location: #debian-lts on IRC]
--
Roberto C. Sánchez
as created (i.e., it
seems that no LTS work was done in the repo), I went ahead and deleted
it directly (rather than archiving it and waiting 6 months as we
typically do).
Regards,
-Roberto
--
Roberto C. Sánchez ◈ Freexian SARL
https://www.freexian.com
On Thu, Dec 12, 2024 at 12:59:46AM +0200, Adrian Bunk wrote:
> On Wed, Dec 11, 2024 at 02:35:00PM -0500, Roberto C. Sánchez wrote:
> > >
> > Only they aren't necessarily incomplete DLAs.
> >...
>
> I thought submitting DLA fixes also to (old)stable was part of
On Wed, Dec 11, 2024 at 04:33:20PM -0500, Roberto C. Sánchez wrote:
>
> In summary: let's not prepare DLAs for only one or two low priority CVEs
> (for the reasons discussed above), but let's certainly include the fixes
> when fixing other high priority CVEs. This should be
VEs
(for the reasons discussed above), but let's certainly include the fixes
when fixing other high priority CVEs. This should be fairly close to
what we are already doing.
--
Roberto C. Sánchez
and tooling.
Let me encourage you to write up an issue in lts-team/lts-extra-tasks to
capture this. Ideally, real examples would be part of that issue write
up, to aid in developing and testing the tool.
Regards,
-Roberto
--
Roberto C. Sánchez
interested in working on one and the issue is already assigned, contact
the assigned individual and workout a change of assignment.
If you have any questions, please let me know.
Regards,
-Roberto
--
Roberto C. Sánchez
Hi Simon,
On Wed, Nov 13, 2024 at 10:15:48AM +, Simon McVittie wrote:
>
> I believe Debian 11 is also vulnerable; LTS team cc'd for visibility.
>
Thanks for letting us know. I have added glib2.0 to our work queue.
Regards,
-Roberto
--
Roberto C. Sánchez
ed.txt?ref_type=heads#L113
[1] https://lts-team.pages.debian.net/wiki/Development.html
--
Roberto C. Sánchez
to rouca for providing work on long-standing difficult
packages (mariadb, apache2...)
- Next meeting: 2024-11-28 14:00 UTC [Location: #debian-lts on IRC]
Recap: bullseye-lts started, buster-elts, thanks for all the work
(Thanks to Sylvain for keeping excellent notes during the meeting!)
Present
On Mon, Sep 30, 2024 at 04:18:51PM +, Bastien Roucariès wrote:
> Hi,
>
> Can someone test why libreoffice fail under bullseye ?
>
I tested this and it worked on my system. The build log is too large to
send to the list, so I am sending it via direct email.
--
Roberto C. Sánchez
ot sure.
>Anyone objecting to this? Please let me know.
I'd like Sean to weigh in, since he recently prepared LTS and ELTS
updates for git. Plus I'm biased since the Ubuntu's handling of the fix
for this issue caused me lots of problems. Another objective opinion
here would be helpful.
Regards,
-Roberto
--
Roberto C. Sánchez
to say, the problems
which would result from fixing this would outweigh the benefits.
Regards,
-Roberto
--
Roberto C. Sánchez
http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-09-26-14.00.log.html
Regards,
-Roberto
--
Roberto C. Sánchez
bian.org/1053462 would help to better understand the
> status of such packages.
>
> If there are no objections, I will create a MR to move python2.7, pypy
> and jython from security-support-limited.deb11 to
> security-support-ended.11.
>
I agree with moving python2.7, pypy, and jython from limited to ended.
Regards,
-Roberto
--
Roberto C. Sánchez
utomation)
failing autopkgtest: reported autopkgtest failures need to be tested in
two ways; first, they must be confirmed to still be present when
building on buster, and second, the bullseye version must be built on
bullseye to see if the autopkgtest for that package on bullseye is
working
/pad.riseup.net/p/lts-meeting-agenda
Thanks again to everyone for participating.
Regards,
-Roberto
--
Roberto C. Sánchez
> Do we want to mark gpac EOL for bullseye as well?
>
Given the circumstances and the state of the package, yes I agree that
we should move ahead with EOL. Could you file an EOL issue in GitLab?
Regards,
-Roberto
--
Roberto C. Sánchez
Hello everyone.
Here are the notes from today's LTS meeting.
Present:
- Raphaël Hertzog
- Santiago Ruano Rincón
- Roberto C. Sánchez
- Helmut Grohne
- Thorsten Alteholz
- Sylvain Beucler
- Emilio Pozuelo Monfort
- Bastien Roucariès
- Lee Garrett
Apologies:
- Chris Lamb
- Tobias Frost
- Gu
On Fri, May 31, 2024 at 10:41:44AM -0400, Roberto C. Sánchez wrote:
> On Fri, May 31, 2024 at 03:05:35PM +0100, Sean Whitton wrote:
>
> > I also note: the commit message for the fix for CVE-2024-32465 says that
> > it renders the fix for CVE-2024-32004 "somewhat redundant
d without
> the sort of usability regression linked above.
>
> Could someone review this assessment, please?
>
I haven't assessed this, but I will and then I will reply to this thread
again with my assessment.
Regards,
-Roberto
--
Roberto C. Sánchez
http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-05-23-14.00.log.html
Regards,
-Roberto
--
Roberto C. Sánchez
Hello everyone.
Here are the notes from today's LTS meeting, with many thanks to Sylvain
for agreeing to act as the note taker.
Present:
- Roberto C. Sánchez
- Santiago Ruano
- Stefano Rivera
- Raphael Hertzog
- Sean Whitton
- Thorsten Alteholz
- Utkarsh Gupta
- Jochen Sprickerhof
- Sy
On Mon, Apr 15, 2024 at 11:32:14PM +0200, Ola Lundqvist wrote:
> Hi Roberto
>
> Got it. I will assess. I guess also the popularity of the package
> counts in this case.
>
Yes, the popularity of a package is a factor in the process of making an
EOL decision.
Regards,
-Roberto
ally being used, and then assess how those
intended and actual use cases would be affected by an EOL decision.
Regards,
-Roberto
--
Roberto C. Sánchez
f it happens to be the
case that there is a new 9.11.x release that addresses the
vulnerabilities, then that is potentially a path we could take. If there
is not a 9.11.x version that we could migrate to, then we will need to
carefully backport the patches and ensure that everything is rigorously
tested.
Regards,
-Roberto
--
Roberto C. Sánchez
ussion.
At this point, I don't see a good reason to continue this discussion.
Let me have an opportunity to think about how the FD and triage
guidelines should be articulated and then if there are still questions
after that we can revisit the topic.
Regards,
-Roberto
--
Roberto C. Sánchez
happen:
- what I suggested above (copy secteam decisions and move on to the next
package)
- dive in and start developing fixes to the individual CVEs
Either way, expending the tremendous effort that we have expended on the
specific triage decisions strikes me as a poor use of time.
Regards,
-Roberto
--
Roberto C. Sánchez
be able to fix it in any case because we do not
> have enough information to tell what the problem was in the first
> place.
>
> While I'm at it I'm removing postponed tag for a few CVEs now, because
> they are postponed until patches are available and now patches are
> available in fedora.
>
Regards,
-Roberto
--
Roberto C. Sánchez
's/ /\n/g'
| egrep "CVE[-]${c}" | sort -u | wc -l ; done
2023: 643
2022: 962
2021: 900
2020: 1098
2019: 983
Regards,
-Roberto
--
Roberto C. Sánchez
of course desirable,
> even when upstream is dead.
>
Ah, thanks for the clarification.
Regards,
-Roberto
--
Roberto C. Sánchez
or me it was an "I don't want to do that right now" and I didn't work
> on the package at that point, but I don't see a technical reason against
> someone fixing the CVEs.
>
So, whoever is working on freeimage (Ola?) should take into account that
this is part of what needs to be done.
Regards,
-Roberto
--
Roberto C. Sánchez
ts are always more verbose than "Minor issue".
So, if we are applying a 'postponed' or 'ignored' tag and making an
explanatory comment with it, that seems to me like just what we need to
be doing.
Do you think that this would be sufficient? Or did I miss something that
would make the use of high/medium/low priorities potentially beneficial?
This proposal came out of the discussion from when I first started this
thread nearly a month ago. That is to say, it was after a substantial
discussion had already developed. I am inclined to prefer a simpler
approach and the fewer triage states that we have to manage, the better.
Regards,
-Roberto
--
Roberto C. Sánchez
m not certain where we would
keep track of these packages which need work but perhaps not directly
for a DLA.
Regards,
-Roberto
--
Roberto C. Sánchez
Regards,
-Roberto
--
Roberto C. Sánchez
On Mon, Mar 18, 2024 at 01:01:28PM +0100, Emilio Pozuelo Monfort wrote:
> On 14/03/2024 21:36, Roberto C. Sánchez wrote:
> > - if a CVE is 'fixed' in LTS but 'ignored' in (old)stable, then the
> >security team should be contacted to see if they would be will
On Fri, Mar 15, 2024 at 11:06:10AM +0100, Raphael Hertzog wrote:
> Hello Roberto,
>
> On Thu, 14 Mar 2024, Roberto C. Sánchez wrote:
> > Santiago and I are in agreement that at the moment the best available
> > option is to use dla-needed.txt even for tracking work that need
- FD should be confirming that package removals from dla-needed.txt are
valid (i.e., that the package does not require any work towards an
upload to (old)stable)
Your help with this is very much appreciated.
Regards,
-Roberto
--
Roberto C. Sánchez
information.en.html#limited-security-support
[1] https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/60
[2] https://lists.debian.org/debian-lts/2023/12/msg00035.html
Regards,
-Roberto
--
Roberto C. Sánchez
ssue in the lts-team/lts-updates-tasks project on Salsa,
using the "Proposed EOL of package" issue template.
Regards,
-Roberto
--
Roberto C. Sánchez
r, that
is not the case here.
That said, if someone were inclined to work on the no-dsa CVEs (assuming
that there are not other higher priority tasks), then that is fine as
well.
Regards,
-Roberto
--
Roberto C. Sánchez
Hello everyone. Here are the notes from the LTS meeting held today via
Jitsi:
Present:
- Roberto C. Sánchez
- Santiago Ruano
- Raphael Hertzog
- Stefano Rivera
- Sylvain Beucler
- Bastien Roucaries
- Santiago
- Helmut
- Thorsten
- Chris Lamb
- Guilhem
- Utkarsh
Apologies:
- Tobias Frost
- Holger
On Wed, Jan 24, 2024 at 03:19:27PM -0500, Roberto C. Sánchez wrote:
> On Tue, Jan 23, 2024 at 02:30:27PM -0800, Bruce Byfield wrote:
> >
> > I will need answers by Monday, January 29. Please cc to bbyfi...@axion.net.
> > If
> > you want a hardcopy of the issue the co
if you don't need all the language packs, then go ahead and
uninstall them and you should stop getting the annoying message about
packages being held back.
Regards,
-Roberto
--
Roberto C. Sánchez
not
sure why you need 66 different langauges, but that should not interfere
with apt.
What is the output of 'apt-cache policy firefox-esr-l10n-zh-tw'?
Regards,
-Roberto
--
Roberto C. Sánchez
third-party source in the mix (dbeaver.io)
and since you didn't provide the output of 'apt-get -s upgrade' it isn't
clear what influence (if any) the presence of that source is having on
the situation.
Please provide the full output so that we can help you determine what is
going on.
Regards,
-Roberto
--
Roberto C. Sánchez
mmand?
apt-cache policy firefox-esr
Also, what is the full output of the failing installation command that
you attempted?
Regards,
-Roberto
--
Roberto C. Sánchez
in the
> rest
> of the world.
>
I am working on getting the responses put together.
Regards,
-Roberto
--
Roberto C. Sánchez
I act as the coordinator for the LTS team and I would be the primary POC
for this sort of inquiry. That said, I would prefer if you could post
your questions to this list, unless for some reason you are not able to
post your questions to a public list.
Regards,
-Roberto
--
Roberto C. Sánchez
of my
> work on LTS.
>
> Do you think this can be achieved, and how?
>
Has there been any progress or discussion regarding this? The LTS team
will be responsible for bullseye starting in August and it would be
beneficial if there could be a resolution to this.
Is there anything that we could do from our side to help move things
along?
Regards,
-Roberto
--
Roberto C. Sánchez
for a formal
announcement to let us know that these should no longer be generated
when a DLA is released?
Regards,
-Roberto
--
Roberto C. Sánchez
earlier to December 19th (similar to what we are doing with the
December 2023 meeting).
[0] https://lts-team.pages.debian.net/wiki/Meetings.html
--
Roberto C. Sánchez
On Fri, Dec 01, 2023 at 02:05:42AM +0100, Guilhem Moulin wrote:
> On Thu, 30 Nov 2023 at 19:47:42 -0500, Roberto C. Sánchez wrote:
> > Yes, I would recommend two things.
>
> Done, thanks Roberto!
>
You're welcome!
--
Roberto C. Sánchez
http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-11-30-13.57.txt
Log:
http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-11-30-13.57.log.html
Regards,
-Roberto
--
Roberto C. Sánchez
1. A new announcement has been sent under the
correct reference ID.
======
Regards,
-Roberto
--
Roberto C. Sánchez
returning SECSuccess and that that
added code is where the SSL_ERROR_RX_MALFORMED_CHANGE_CIPHER value is
set, all of that makes me think that my theory is a likely explanation
for your unexpected test failure.
Regards,
-Roberto
[0]
https://hg.mozilla.org/projects/nss/rev/57bbefa793232586d27cee83e74411171e128361
--
Roberto C. Sánchez
ty updates can pass unstable within a day.
>
Uploads to unstable require maintainer coordination. That alone has the
potential to introduce a delay (e.g., in the case of an unresponsive
maintainer).
Perhaps "potential delays" would have been a better phrasing than
"substantial delays".
Regards,
-Roberto
--
Roberto C. Sánchez
OFTC. As always,
note your agenda items here: https://pad.riseup.net/p/lts-meeting-agenda
Regards,
-Roberto
--
Roberto C. Sánchez
On Tue, Oct 10, 2023 at 09:53:58AM +, Bastien Roucariès wrote:
> Le vendredi 6 octobre 2023, 19:31:43 UTC Roberto C. Sánchez a écrit :
> >
> > The older pjsip located in that project lacks ssl_sock_imp_common.c but
> > has the other two files. Most of the remainder
ps it would be worthwhile to
find out from Thorsten (who prepared the most recent update) why that
decision was made.
Regards,
-Roberto
[0]
https://github.com/savoirfairelinux/pjproject/commit/d5f95aa066f878b0aef6a64e60b61e8626e664cd
--
Roberto C. Sánchez ◈ Freexian SARL
https://www.free
On Fri, Sep 01, 2023 at 08:59:50PM +0200, Sylvain Beucler wrote:
> Hi,
>
> On 30/08/2023 02:13, Roberto C. Sánchez wrote:
> > On Sun, Aug 20, 2023 at 06:53:54PM -0300, Santiago Ruano Rincón wrote:
> > > Dear all
> > >
> > > I've prepared a glib2.
update?
Regards,
-Roberto
--
Roberto C. Sánchez
On Fri, Aug 25, 2023 at 11:02:35PM -0400, Chris Frey wrote:
> On Fri, Aug 25, 2023 at 07:02:07AM -0400, Roberto C. Sánchez wrote:
> > To claim that "because this bug affects me, it *must* be
> > fixed, even when it does not meet the criteria for a normal security bug
> &g
at it is normal "security" uploads only (which, as already
stated, can occasionally include some non-security bug fixes but
generally not).
Regards,
-Roberto
--
Roberto C. Sánchez
or the rather robust process that we try to utilize
to ensure that we properly balance the needs of everyone involved.
Regards,
-Roberto
--
Roberto C. Sánchez
ansition
to LTS. Once that happens there will be no further point releseas, only
security updates.
You should not expect that this bug will be fixed in bullseye.
Regards,
-Roberto
--
Roberto C. Sánchez
which might not be appropriate for a public mailing list can be directed
to the coordinator email address.
Regards,
-Roberto
--
Roberto C. Sánchez
signature.asc
Description: PGP signature
ged by one of these tickets and/or if
you have comments/ideas/thoughts related to the experiment or the
overall concept, please feel free to bring them up.
Regards,
-Roberto
--
Roberto C. Sánchez
quite as quick as
a normal update for us (since the unstable packaging work wouldn't
have been done on it, as the maintainer already moved to the next
version), but is still much quicker than waiting on the toolchain
stuff
Regards,
-Roberto
--
Roberto C. Sánchez
7;t support a straightforward
backoport), and then we would have to decide at that point whether to
try to apply the strategy using 10.5 as a source branch, or to migrate
to a newer version altogether.
Regards,
-Roberto
--
Roberto C. Sánchez
ing
to work" or "no, that doesn't seem feasible and the latest upstream
release might be the only viable route") and then perhaps offer to
assist with the work.
Regards,
-Roberto
--
Roberto C. Sánchez
1 - 100 of 461 matches
Mail list logo
