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
Hi,
I believe CVE-2024-23944 should be marked ignored for older release:
- Persistent (and p-recursive) watches were introduced by ZOOKEEPER-1416, which
only exists in 3.6+. This is needed for exploit
- according to upstream classical watches are used (<< 3.6), it seems that to
trigger for nod
Hello,
CVE-2024-39331 allows arbitrary code execution simply by opening an e-mail in
Emacs. It's pretty bad.
Could you add emacs for buster, org-mode for buster, and emacs24/emacs25 for
jessie and stretch, to dla-needed/ela-needed and assign to me, please?
Thanks.
--
Sean Whitton
Hi,
Here is my public monthly report.
Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors
In april I spend my time on LTS as:
- fixing apache2 CVE-2023-25690 CVE-2023-27522. CVE-2023-25690 created
Hi,
Here is my public monthly report.
Thanks to our sponsors for making this possible, and to Freexian for
handling the offering.
https://www.freexian.com/services/debian-lts.html#sponsors
In march (my first month) I spend my time on LTS as
- creating the right environment (pbuilder, tools) to
d to make unilateral changes to a package in unstable.
Who Will This Involve?
--
To be a "Package Owner" for LTS/ELTS it is necessary to be a paid contributor.
To reduce complexity and overhead, the ownership responsibility for a package
in LTS and ELTS (assuming it
Hi Emilio
See below inline.
On Tue, 12 Jul 2022 at 22:31, Emilio Pozuelo Monfort wrote:
>
> Hi,
>
> On 12/07/2022 13:51, Ola Lundqvist wrote:
> > Hi Emilio
> >
> > Sorry for this. I used the lts-cve-triage.py script and noticed a ton
> > of things to do.
>
> Heh. Salvatore predicted that that sc
Hi,
On 12/07/2022 13:51, Ola Lundqvist wrote:
Hi Emilio
Sorry for this. I used the lts-cve-triage.py script and noticed a ton
of things to do.
Heh. Salvatore predicted that that script would suggest triaging buster, and
this would happen. I thought my emails would be enough, but as usual he
acker
> >
> >
> > Commits:
> > 55001d9c by Ola Lundqvist at 2022-07-11T23:23:41+02:00
> > Wrote a script to bulk add EOL entries for LTS buster.
> >
> > - - - - -
> > b4c0adda by Ola Lundqvist at 2022-07-11T23:23:43+02:00
> > Bulk added EOL entri
Hi Ola,
On 11/07/2022 23:24, Ola Lundqvist (@opal) wrote:
Ola Lundqvist pushed to branch master at Debian Security Tracker /
security-tracker
Commits:
55001d9c by Ola Lundqvist at 2022-07-11T23:23:41+02:00
Wrote a script to bulk add EOL entries for LTS buster.
- - - - -
b4c0adda by Ola
Hi,
"Issues postponed for stretch, but fixed in buster via DSA or point
releases" is now almost empty. Hopefully it won't scare off FDs anymore ;)
For the 30ish other packages, I either revisited the triage, or could
add them to dla-needed.txt (and some to ela-needed.txt).
We got several b
Hi Anton
That is a way to view it. Interesting point. Is this the common view?
I'm asking since:
- the list is long and it does not look like previous front desk did that.
- I thought postponed meant that there is no need for a DLA, but we can fix
that later on when such a need appears.
I'm happy
Hi,
On 17/05/2022 15:37, Anton Gladky wrote:
As far as I understand all of those packages can be
added into the dla-needed without pre-review? Why not just
put all of them together.
Some can be added to dla-needed.txt, some need finer triage (e.g. no-dsa
-> ignored); and some may be false pos
As far as I understand all of those packages can be
added into the dla-needed without pre-review? Why not just
put all of them together.
OK, maybe with the short note "needs manual checking" or
similar.
Regards
Anton
Am Di., 17. Mai 2022 um 14:43 Uhr schrieb Sylvain Beucler :
>
> Hi,
>
> On 17/
Hi,
On 17/05/2022 08:44, Ola Lundqvist wrote:
When doing triaging this week as part of the front desk assignment I
realized that the lts-cve-triage.py script outputs the following
section "Other issues to triage for stretch (not yet triaged for
buster)" after "Issues postponed for stretch, but f
in/lts-cve-triage.py
@@ -64,9 +64,6 @@ LIST_NAMES = (
('triage_possible_easy_fixes',
('Issues not yet triaged for {lts}, but already fixed in {next_lts}')
.format(**RELEASES)),
-('triage_possible_missed_fixes',
- ('Issues postponed for {l
Hi Sylvain,
Thanks for the update and fixing the unintended commit!
I do really encourage you to use the merge-request
mechanism next time. It is really useful, helps to keep
a discussion in one place and provides easier testing.
Best regards!
Anton
Am Do., 21. Apr. 2022 um 09:08 Uhr schrieb
Hi Anton,
Thanks for testing the patch.
I see you committed it by mistake while triaging; I reverted and
recommitted with proper authorship and commit information (linking this
thread).
Newly identified packages are ready to be triaged :)
Cheers!
Sylvain
On 21/04/2022 08:15, Anton Gladky w
Hi Sylvian,
I have just tested the patch and it really produces much more packages
to be triaged and they are really reasonable!
I would propose to merge it into the master branch and start to use it.
Thanks for that!
Anton
Am Mi., 20. Apr. 2022 um 20:54 Uhr schrieb Sylvain Beucler :
> Hi An
Hi Anton,
There's no need for a MR for this short lts-specific patch, and I
believe this list has better visibility for the LTS team than the
security-tracker salsa project (where lts-cve-triage.py resides).
Cheers!
Sylvain
On 20/04/2022 18:09, Anton Gladky wrote:
Hi Sylvian,
thanks for yo
Hi Sylvian,
thanks for your work! Could you please create a merge request,
so we can discuss this nice improvement there?
Regards
Anton
Am Mi., 20. Apr. 2022 um 17:33 Uhr schrieb Sylvain Beucler :
> Now with the patch.
>
> On Wed, Apr 20, 2022 at 05:08:20PM +0200, Sylvain Beucler wrote:
> >
rce-package/mailman
> [3] https://security-tracker.debian.org/tracker/source-package/ark
> [4]
> https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
diff --git a/bin/lts-cve-triage.py b/bin/lts-cve-triage.py
index bda1606819..6590f975a5 100755
-
Hi,
During my last front-desk week I noticed that we tend to miss or delay
some buster security updates, in particular those that come in point
releases, and a few batches of minor postponed fixes. See for
instance, 'dpdk' [1] or 'mailman' [2].
Attached is a patch to 'bin/lts-cve-triage.py' to h
On Tue, 28 Sep 2021 11:46:13 +0100
"Chris Lamb" wrote:
> Hi Ola,
>
> > My guess has been that we should not generally fix lintian warnings
> > unless they are really important.
>
> (Agree with this, of course.)
>
> > So I assume quite a few of them could be removed. But maybe I'm
> > wrong h
On Mon, Sep 27, 2021 at 04:58:02PM -, Chris Lamb wrote:
> Hi,
>
> Whilst I think of it, are there any changes to Lintian that folks
> here might consider particularly useful when doing LTS development?
To which lintian?
Running stretch lintian tends to give more useful information for
packa
Hi Ola,
> My guess has been that we should not generally fix lintian warnings
> unless they are really important.
(Agree with this, of course.)
> So I assume quite a few of them could be removed. But maybe I'm wrong
> here.
That could work, although it would have the drawback of potentially
hid
Hi Chris and others
My guess has been that we should not generally fix lintian warnings unless
they are really important.
So I assume quite a few of them could be removed. But maybe I'm wrong here.
Cheers
// Ola
On Mon, 27 Sept 2021 at 18:58, Chris Lamb wrote:
> Hi,
>
> Whilst I think of it,
Hi,
Whilst I think of it, are there any changes to Lintian that folks
here might consider particularly useful when doing LTS development?
I've already implemented some changes to not emit some specific
warnings when doing security updates, particularly to do with version
numbering. This is on the
On Tue, Apr 23, 2019 at 12:46:54PM +0200, Ondřej Surý wrote:
> Hey,
>
> the jessie-backports removal itself is a logical step and it’s good that it
> was done.
>
> That said, it complicates things a lot when backporting packages to Jessie.
> Usually, it’s fine to just pull $random extra library
Hey,
the jessie-backports removal itself is a logical step and it’s good that it was
done.
That said, it complicates things a lot when backporting packages to Jessie.
Usually, it’s fine to just pull $random extra library to the extra repository,
but debhelper and friends is a different beast,
-installer/index.wml that 8.11.1 is only
available for LTS arches.
* The result (attached) is a bit ugly, IMO, with 2 rows of links to
images for each type. I couldn't find the way to put all the
architectures in the same row. I tried to add some label "LTS" and "non
LTS"
Hello Emilio, hi Moritz,
Am 08.07.2018 um 12:01 schrieb Emilio Pozuelo Monfort:
> On 07/07/18 11:44, Carsten Schoenert wrote:
>> Hello Emilio and Security-Team,
>>
>> while preparing the stretch-security package for Thunderbird upstream
>> has announced just right now via the private driver mailin
On 07/07/18 11:44, Carsten Schoenert wrote:
> Hello Emilio and Security-Team,
>
> while preparing the stretch-security package for Thunderbird upstream
> has announced just right now via the private driver mailing list to stop
> the current automatic updates for 52.9.0 due a critical issue [1] tha
LTS team workflow. Guido gave me some hints but I guess it better to ask
>> and clarify.
>>
>> I'm preparing right now the packages for stretch-security and will
>> upload them over the weekend to security. So do you have an opinion on
>> how to continue with Thunde
ity. So do you have an opinion on
> how to continue with Thunderbird for jessie-security? I'm fine if you
> want to do the packages for LTS on your own, the git tree for
> thunderbird is up to date for debian/sid.
Since I had done the previous updates for wheezy, I did this one for jes
low. Guido gave me some hints but I guess it better to ask
and clarify.
I'm preparing right now the packages for stretch-security and will
upload them over the weekend to security. So do you have an opinion on
how to continue with Thunderbird for jessie-security? I'm fine if you
want to do
On 2018-06-29 21:44:36, Roberto C. Sánchez wrote:
[...]
> This does not appear to be a good approach at the moment, given the
> considerable differences between 8.0 and 8.5.
>
> For the time being, it seems like the best approach is to patch the
> current jessie package for the two outstanding CV
On Wed, Jun 27, 2018 at 08:33:48AM -0400, Antoine Beaupré wrote:
>
> As an outsider not very familiar with Tomcat, I guess the main question
> I would like to answer before figuring this out would be what kind of
> compatibility garantees does Tomcat provide between versions. If it
> respects semv
Hi everybody,
for the sake of completeness: all configurations for Jessie LTS have been
done.
The dak configuration says: 'AllowSourceOnlyUploads "true";'.
Anyway, arch:all packages need to be uploaded.
Thorsten
On 2018-06-25 18:40:06, Roberto C. Sánchez wrote:
> Security Team & Tomcat Maintainers,
>
> I began working on a jessie LTS update for tomcat8 and sought some
> guidance from Markus Koschany, as he prepared a tomact7 update recently.
> He pointed out that the tomcat8 package in jessie is based on t
Security Team & Tomcat Maintainers,
I began working on a jessie LTS update for tomcat8 and sought some
guidance from Markus Koschany, as he prepared a tomact7 update recently.
He pointed out that the tomcat8 package in jessie is based on the 8.0.x
upstream relases, which will reach EOL on 30th Jun
Hi ftp-team,
the last point release for Jessie will happen tomorrow. Afterwards we
would appreciate it if you configured dak for the new Jessie LTS cycle,
meaning removing the policy queue in front and changing the architecture
list to amd64, i386, armel and armhf. Also any uploads to Jessie shoul
Hi,
On Sat, Sep 30, 2017 at 11:03:13AM +0200, Moritz Muehlenhoff wrote:
> Hi,
> when we're marking issues as for the suites supported
> by the security team and if that issue is also marked in wheezy
> (or whatever is LTS at the time), ok to also mark the LTS suite as
> or do you want to do dea
On 30/09/17 11:03, Moritz Muehlenhoff wrote:
> Hi,
> when we're marking issues as for the suites supported
> by the security team and if that issue is also marked in wheezy
> (or whatever is LTS at the time), ok to also mark the LTS suite as
> or do you want to do deal with that by yourself?
>
Hi,
when we're marking issues as for the suites supported
by the security team and if that issue is also marked in wheezy
(or whatever is LTS at the time), ok to also mark the LTS suite as
or do you want to do deal with that by yourself?
Specific example of such a change: r56270
Cheers,
Hi Jens,
On Mon, May 29, 2017 at 07:54:30PM +0200, Jens Korte wrote:
> Hi
> I would like to update the timetable in [2], if nobody else does. I
> would like to make sure, that I use the correct dates.
Thanks for having a look!
>
> If Stretch is released on 2017-June-17 [1] Jessie gets oldstable.
Hi
I would like to update the timetable in [2], if nobody else does. I would like
to make sure, that I use the correct dates.
If Stretch is released on 2017-June-17 [1] Jessie gets oldstable. Am I right,
that the security support for oldstable will be dropped on 2018-June-16 and it
gets LTS? T
Hi Emilio,
On Tue, Apr 25, 2017 at 01:30:39PM +0200, Emilio Pozuelo Monfort wrote:
> On 25/04/17 13:26, Ola Lundqvist wrote:
> > Hi
> >
> > Just for my understanding what is the reason for waiting for the jessie
> > uplozd?
>
> Not having a higher version in wheezy than in jessie.
I'm planning
Hi
Just for my understanding what is the reason for waiting for the jessie
uplozd?
/ Ola
Sent from a phone
Den 24 apr 2017 13:46 skrev "Emilio Pozuelo Monfort" :
> On 24/04/17 07:41, Lars Tangvald wrote:
> > Hi,
> >
> > The debian/wheezy branch should now be updated.
>
> Thanks Lars. Test pack
On 25/04/17 13:26, Ola Lundqvist wrote:
> Hi
>
> Just for my understanding what is the reason for waiting for the jessie
> uplozd?
Not having a higher version in wheezy than in jessie.
Emilio
On 24/04/17 07:41, Lars Tangvald wrote:
> Hi,
>
> The debian/wheezy branch should now be updated.
Thanks Lars. Test packages for amd64 are available at
https://people.debian.org/~pochu/lts/mysql/
I did some smoke testing, but we have to wait for the jessie update, so if
someone wants to give th
Hi Balint,
Am 19.09.2016 um 18:59 schrieb Bálint Réczey:
> Please use clean chroot (sbuild/pbuilder/etc.) for LTS uploads.
> This would prevent accidental regressions related to additional
> installed packages or some VM related issues such as funny symlink
> handling of vboxsf.
So
Hi All,
Please use clean chroot (sbuild/pbuilder/etc.) for LTS uploads.
This would prevent accidental regressions related to additional
installed packages or some VM related issues such as funny symlink
handling
of vboxsf.
I have updated https://wiki.debian.org/LTS/Development with reminders
I've committed these changes to the kernel Subversion repository
(squeeze-security branch) for a future squeeze-lts update. However I'm
not sure any of these are important enough to upload yet. At present
I'm intending to defer these until a more critical issue needs fixing.
Ben.
linux-2.6 (2.6
Hi,
Raphael commented about textpattern: "NOTE: Has been dropped from newer
releases. Should we instead mark it unsupported?" and looking at
https://qa.debian.org/popcon.php?package=textpattern (installed: 6, vote: 1)
and CVE-2014-4737 (XSS vulnerability) I tend to agree.
If noone disagrees i
On 15.07.2014 22:47, Thorsten Alteholz wrote:
> Hi,
>
> the packages for libxml2 can be found at [1].
>
> Can you please test them and give some feedback whether they are ready
> for upload?
Tested on a squeeze system with noch ill effects.
-- Guido
>
> Thanks!
> Thorsten
>
>
> [1] http://
Hi,
this is my debdiff for fixing CVE-2014-3515, CVE-2014-0207, CVE-2014-3480
and CVE-2014-4721 in php5.
Please give the packages from [1] some real-world testing before I upload
them to squeeze-lts.
Thanks!
Thorsten
[1] http://people.debian.org/~alteholz/packages/php5/
diff -u php5-5
Hi,
the packages for libxml2 can be found at [1].
Can you please test them and give some feedback whether they are ready for
upload?
Thanks!
Thorsten
[1] http://people.debian.org/~alteholz/packages/libxml2/
--
To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org
with a subject of
On Sun, Jul 13, 2014 at 10:25:08PM +0200, Thorsten Alteholz wrote:
> Hi,
>
> this is my debdiff for CVE-2014-0191 in libxml2.
>
> I used the patch for wheezy as template.
LGTM, this will need some testing, though to rule out side effects in
applications. Maybe you can put the debs on people.debi
Hi,
this is my debdiff for CVE-2014-0191 in libxml2.
I used the patch for wheezy as template.
Thorsten
diff -u libxml2-2.7.8.dfsg/parser.c libxml2-2.7.8.dfsg/parser.c
--- libxml2-2.7.8.dfsg/parser.c
+++ libxml2-2.7.8.dfsg/parser.c
@@ -2554,6 +2554,23 @@
xmlChar start[4];
On Thu, Jul 10, 2014 at 08:06:02PM +0200, Thorsten Alteholz wrote:
> Hi,
>
> according to the security tracker there are three CVEs[1] for dbus which
> shall all affect Squeeze (DSA-2971-1).
>
> As far as I understand CVE-2014-3532 is for kernels above 2.6.37-rc4 but
> only 2.6.32 is in Squeeze
Hi,
according to the security tracker there are three CVEs[1] for dbus which
shall all affect Squeeze (DSA-2971-1).
As far as I understand CVE-2014-3532 is for kernels above 2.6.37-rc4 but
only 2.6.32 is in Squeeze.
The code that will be patched for CVE-2014-3533 is not available in
Squeeze.
Hi,
this is my debdiff for CVE-2013-4243 in tiff.
I used the patch for wheezy as template.
Thorsten
diff -Nru tiff-3.9.4/debian/changelog tiff-3.9.4/debian/changelog
--- tiff-3.9.4/debian/changelog 2013-08-24 17:23:06.0 +0200
+++ tiff-3.9.4/debian/changelog 2014-06-26 19:43:04.
On Sun, Jun 22, 2014 at 06:58:16PM +0200, Thorsten Alteholz wrote:
> Hi,
>
> this is my debdiff for CVE-2014-3146 in lxml.
LGTM.
> I used the patch for wheezy as template. I am sure there are some kind of
> scripts/descriptions on how to test this. Are those available somewhere?
I've used the
Hi,
this is my debdiff for CVE-2014-3146 in lxml.
I used the patch for wheezy as template. I am sure there are some kind of
scripts/descriptions on how to test this. Are those available somewhere?
Thorsten
diff -u lxml-2.2.8/debian/changelog lxml-2.2.8/debian/changelog
--- lxml-2.2.8/deb
Hi,
On Mon, Jun 16, 2014 at 07:05:55PM +0200, Moritz Mühlenhoff wrote:
> On Sat, Jun 14, 2014 at 10:47:23PM +0200, Thorsten Alteholz wrote:
> > Hi,
> >
> > here is my debdiff for the minor issue with scheme48. Do you have any
> > objections?
>
> LGTM.
I know I come a bit late with this reply. D
On Sat, Jun 14, 2014 at 10:47:23PM +0200, Thorsten Alteholz wrote:
> Hi,
>
> here is my debdiff for the minor issue with scheme48. Do you have any
> objections?
LGTM.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
Hi,
here is my debdiff for the minor issue with scheme48. Do you have any
objections?
Thorsten
diff -u scheme48-1.8+dfsg/debian/changelog scheme48-1.8+dfsg/debian/changelog
--- scheme48-1.8+dfsg/debian/changelog
+++ scheme48-1.8+dfsg/debian/changelog
@@ -1,3 +1,11 @@
+scheme48 (1.8+dfsg-1
Hi *,
DSA 2956-1 fixed five CVEs in icinga for wheezy. Two of them do not
affect squeeze, the other three do.
I have backported the patches to 1.0.2 and prepared an upload, you can
find it here: http://people.debian.org/~evgeni/tmp/lts/
My "problem" is, that I do not have any 1.0 Icinga setup
69 matches
Mail list logo
