Re: Security support for pypy and jython
On Thu, Aug 29, 2024 at 05:06:51PM -0300, Santiago Ruano Rincón wrote: > > Following a discussion on IRC, it seems that for bullseye, it would make > more sense to explicitly declare the python 2 ecosystem (python2.7, > pypy, jython) as non supported. This is actually the current status, > since python2.7 didn't receive any security update so far in bullseye. > From the bullseye release notes, we can read: "Python 2 is already > beyond its End Of Life, and will receive no security updates. [1]" > > [1] > https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages > > Also, the entries in the security tracker support this conclusion: > > [bullseye] - python2.7 (Unsupported in Bullseye, only included > to build a few applications) > > I think there is a confusion about what security-support-limited.* is > meant for. At least, I had forgotten to take into account a comment by > Moritz about how the security team understands the packages included in > security-support-limited at the time of a debian release. I hope solving > https://bugs.debian.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
Re: Move tasks from salsa to gitlab?
Hi Ola, On Thu, Aug 22, 2024 at 08:41:06PM +0200, Ola Lundqvist wrote: > Hi fellow LTS and ELTS contributors > > I have gone through the taks list we have for LTS on salsa and noticed > that we should close quite a few there because buster is no longer > part of LTS, but rather ELTS. > > https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues > > For dns-root-data I created a new ticket in gitlab and proposed to > close the two for buster in salsa. > > My question is whether we should close all buster related tickets > there and create new ones in gitlab but only for the packages we > support there? > The short answer is "no". > I think we should but before I go ahead and do that I want to check with you. > > I think we should simple close the EOL ones without creating new ones for ELS. > > And other ideas or objections? > There are three classes of buster-specific issues. Here is what needs to happen for each one: EOL: Santiago needs to ensure that packages which were proposed for EOL in buster are properly marked so that future support requests for them are rejected. This is not done in debian-security-support (because buster is now ELTS, as you point out), but interally. Santiago is already the assignee for those tasks, so they should be left alone. backport to buster: yes, those should be transferred (or closed if they are actually not applicable, since they are created by an automation) 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 or not. Regards, -Roberto -- Roberto C. Sánchez ◈ Freexian SARL https://www.freexian.com
LTS meeting notes
Hello everyone. Here are the notes from today's LTS meeting. Present: - Roberto - Beuc - Santiago - Chris Lamb (lamby) - tobi - guilhem - Jochen - Lee - Emilio - Bastien - Ola - Helmut Apologies: - Adrian Bunk - Sean Whitton Discussion: - Roll Call - Reminder about not conflicting with the last Bullseye PU (santiago) + check https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian@packages.debian.org;tag=pu if there's anything related to the package you picked + a couple we are aware of are referenced in dla-needed.txt, but more might be added, stay alert + scheduled 2024-08-31; probably frozen a bit before (this week-end) - Request: bullseye-lts status (upload open?) (Beuc) + bulleye-security not open yet, still waiting for FTP masters to act + ta contacted but this requires other members of FTP master, whom he pinged already - freexian CLI tool + Who uses it, should we make it more robust to make life easier for newcomers? (Lee) + it shouldn't have features meant for technical tasks, only administrative/accounting + tooling working on e.g. security-tracker would be best kept separate e.g., by improving 'bin/package-operations' which isn't freexian-specific * rouca mentions effort towards merging data/CVE/list Emacs-based tooling within devscripts * roberto reminds about not disrupting secteam's own workflow while working on security-tracker and adding other tools to work there; we need to think on where it's best to integrate LTS improvements * create tickets in lts-extra-tasks explaining the new features needed, and propose MRs + rouca mentions we'd like to override secteam/LTS triage within the ELTS security-tracker, e.g. to change from to non-triaged/ignored/not-affected, etc. + rouca mentions we'd benefit from a way to (better) track regressions (e.g. current apache2 multiple regressions after CVE fixes) - Report reminder: non-public links (roberto) + Reminder from earlier e-mail on the deblts-team list. Don't link e.g., private gitlab freexian projects. + Instead you can mention the work done without a link. - Raphael reducing his direct LTS/ELTS involvement (roberto) + Go through LTS Coordinators Roberto and Santiago first, not through Raphael first - Mini-DebConf Toulouse (roberto) + Mini-DebConf in November in Toulouse (France) + Most of the Freexian collaborators plan to go, everybody in LTS/ELTS Team is invited to come, there could be social gathering + Helmut: One may approach the DPL for individual travel sponsorship to conference and sprints as ususal - LTS Team ARM group runner available now (santiago) + every package in lts-team Salsa namespace should get the CI ARM runner automatically + it was previously available and had to be added manually + roberto: util-linux assumes arch 32/64-bit matches the system 32/64-bit; this isn't the case for the (arm64) runner, there might be specific errors + rouca: arm64 isn't the exact same as armel/armhf, so there might be disprepancies, particularly FPU, and checksum acceleration - AOB + helmut: autopkgtest * we probably won't have a CI queue within Debian (as we do for ELTS) * various solutions were discussed, nothing has been decided + rouca: how to share share packages WIP before actual DLA? * santiago: 'aptly' job in Salsa can be enabled and used for this * however care must be taken with versioning; rouca opened a bug about versioning but waiting for more input: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078505 - Next meeting: 2024-09-26 14:00 UTC [Location: #debian-lts on IRC] More detail is available in the raw notes contained in the meeting agenda: https://pad.riseup.net/p/lts-meeting-agenda Thanks again to everyone for participating. Regards, -Roberto -- Roberto C. Sánchez
Re: gpac end-of-life in stretch (and recommendation for buster/bullseye)
On Thu, Aug 08, 2024 at 11:56:11AM +0200, Sylvain Beucler wrote: > Hi, > > Since then: > - gpac was EOLd in buster > https://salsa.debian.org/debian/debian-security-support/-/commit/a0bfdf01d404aba46893d2971d776f8f7fb5337e > - gpac was removed from bookworm > https://tracker.debian.org/news/1430135/gpac-removed-from-testing/ > - gpac was removed from sid > https://tracker.debian.org/news/1548977/removed-221dfsg1-31-from-unstable/ > > gpac in bullseye still has >100 open CVEs and I don't believe the situation > described by Roberto improved. > > 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
LTS meeting notes
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 - Guilhem Moulin - Sean Whitton - Adrian Bunk - Ben Hutchings - Daniel Leidert - Ola Lundqvist Discussion: - Reminders about long-standing packages in the queue (santiago) + There is a benefit to using Salsa issues, including a more thorough overview being available in one place + Suggestion from buxy: rather than claim the package to get it completely fixed, claim the package with a specific timeframe objective for making one or more discrete improvements in the state of the package + Suggestion from Helmut: use available regression testing capabilities to ensure that individual fix backports are being tested as they are being applied, rather than discovering a regression near the end after applying many updates (and having to perform lots of investigation to know which one introduced the regression) + Consider the possibility of "obligatory" assignment of packages for the purposes of advancing their state incrementally + There is a preference for contributors to voluntarily pick up and work on these long-standing packages, rather than assigning them obligatorily - Short news about the lts-team/pipeline (santiago) + Force pushed on the lts-team/pipeline project, update your working copy if you have one - AOB + In case of more issues with the dcut migrate workflow, contact Helmut. - Next meeting: 2024-07-18 14:00 UTC [Location: #debian-lts on IRC] Thanks to everyone for participating! Regards, -Roberto -- Roberto C. Sánchez
Re: git CVE-2024-32004 & CVE-2024-32020
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". > > My understanding of the situation is that the fix for CVE-2024-32465 > > does fix the issue strictly designated by CVE-2024-32004, and 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. > So, I have read the two commit messages (f4aa8c8bb1 and 7b70e9efb1), but I have not read the actual code changes. It looks to me like the way to confirm your assessment is to take t/t0411-clone-from-partial.sh from the first commit and backport just that part. It should result in new test failures. Then backport the second commit (which fixes CVE-2024-32465 and is somewhat redundant with the first commit) and confirm that the test changes which produced the new test failures are all passing again. Also, given the potential usability regression reported upstream, it would certainly be wise to manually test that a shared repository can be cloned without requiring the configuration change on the server side. This testing should include 3 scenarios: one with the patch applied only on the server side, another with the patch applied only on the client side, and finally one with the patch applied on both sides. Regards, -Roberto -- Roberto C. Sánchez
Re: git CVE-2024-32004 & CVE-2024-32020
Hi Sean, On Fri, May 31, 2024 at 03:05:35PM +0100, Sean Whitton wrote: > Hello, > > Upstream's patches for these CVEs involve making it a lot fiddlier to > use shared repositories where write access is managed using Unix > permissions, rather than by using SSH identities. > And indeed someone has reported a case of this a few days ago: > <https://lore.kernel.org/git/924426.1716570...@dash.ant.isi.edu/T/#u>. > I actually was bitten by this exact issue yesterday after an update to a server running Ubuntu 22. The really annoying thing is that the work-around of setting safe.directory has to be done on the server side. In the case of a server which uses system users but which does not permit shell log in, it would not even be possible for an affected user to set the configuration, unless an administrator sets it per-user or system-wide. It took several hours of troubleshooting to figure this out, as all of the discussions that came up regarding the "dubious permissions" error related to a CVE from 2022 and simply said to set safe.directory (implying that it was a client-side setting). > I think that this regression would be significant enough in an LTS > context -- it's an older way of doing git repository hosting -- that we > should leave these two CVEs unpatched for now. > I concur that the hassle which will almost certainly ensue from patching these CVEs would outweigh any potential benefit. Especially since depending on the specifics of the environment into which an update containing these patches is deployed, it may actually bring a development team's work entirely to a halt. We have reverted patches for lesser impacts, so it seems prudent to not deploy them in the first place for these two CVEs. > 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". > My understanding of the situation is that the fix for CVE-2024-32465 > does fix the issue strictly designated by CVE-2024-32004, and 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
LTS meeting notes
Hello everyone, As today's meeting took place on IRC, the logs/minutes/notes can be seen here: Minutes: http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-05-23-14.00.html Minutes (text): http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-05-23-14.00.txt Log: http://meetbot.debian.net/debian-lts/2024/debian-lts.2024-05-23-14.00.log.html Regards, -Roberto -- Roberto C. Sánchez
LTS meeting notes
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 - Sylvain Beucler - Chris Lamb - Guilhem Moulin - Lee Garrett - Kurt Kremitzki - Bastien Roucariès Apologies: - Adrian Bunk - Tobias Frost - Holger Levsen - Emilio Pozuelo Monfort Discussion: - jitsi.debian.social service is back online, now with OpenID authentication through your Salsa account - Updates to documentation concerning CVE triage (roberto/beuc) - Current docs: https://lts-team.pages.debian.net/wiki/Development.html - Latest changes/diff: https://salsa.debian.org/lts-team/lts-team.pages.debian.net/-/commit/eaf1d75d7bc5e48ade06dda5f9d96e2c3f75b6e5 - Changes summary / approach: https://salsa.debian.org/lts-team/lts-team.pages.debian.net/-/merge_requests/15 Not only impacts FD but also all contributors (when working on a package update and making changes to data/CVE/list). This also confirms dropping as discussed last meeting. - End of buster-LTS recap/plans (following santiago's e-mail to customers this week) buster EOL end of June (June 30th) Try to work on bullseye & bookworm under the responsibility of secteam until bullseye-lts starts officially (August 15th) Cf. date at https://wiki.debian.org/LTS There's also non-security work to pick up during the transition. Raphaël: Also all paid LTS contributors are also ELTS contributors, so spending more time on ELTS is also an option. (As well as updating bullseye for no-dsa CVE that have been fixed in buster) - Merging LTS/ELTS teams New policy: new contributors join both LTS & ELTS Pending coordinator work to finalize this. - ELTS upload process/procedure changes (roberto) Cf. Helmut's mail for details. Always use full source upload. There's a dput-ng hook to remind you of it (also works for security-master https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826193). - Action item still to be done (a.k.a I am late, sorry): Document the differences between salsa-ci's autopkgtest, ci.debian.net and ci.freexian.com, including testing of rdepends (rouca may review) (santiago) Still in progress (?) - Ping for long-standing packages (santiago) Santiago requests for help on these pages: rails (utkarsh), docker, libssh, putty (rouca). samba is done at last! Including cross-distro effort to maintain a long-term branch for Samba. - AOB - Git repository creation policy (santiago) Following Git issues with samba's git repository, do we want to move from fresh forks to maintainers' repo fork ? rouca: way to work-around some problems with aliased branches lee: depends if upstream uses standard gbp layout (e.g. uncommon patches-applied repo in samba), so sometimes a maintainer fork isn't the best option roberto: earlier, there was preference for fresh repos. Now we tend to favor repo forks Benefits of forking: - we can import LTS changes back to main repo and there's a single repo, easier to contribute back - git-blame works better (if maintainer imported the full upstream repo) - should save more space on Salsa - backporting changes from newer dists is easier But again, not necessarily the best in all situations. guilhem: also if an early +deb10uX was already uploaded using the old workflow (gbp import-dsc) then there is no point in changing the workflow for the next +deb10uY right? i see some value in changing preserving the history for a given suite, but the workflow can change for +deb11u1 - rouca: process for reviewing backport-incompatible changes that impact rdeps + how to make sure the upgrade to bullseye still works + how to handle customer customized packages santiago: we probably need to fix rdeps / impacted packages roberto: try fixing bullseye/bookworm along with buster to keep upgrades smooth - rouca: SMTP smuggling / secure defaults some issue remain, sync'ing with Ubuntu issue happens only with customized user configuration => issue actually more complex, actually still under embargo => move to list to explain in further details - rouca: secure defaults same issue with bluetooth stack: due to option not enabled by default enforce secure default or not? roberto: depends on severity of the issue rouca: this also depends on different impacts on different dists, which may lead to inconsistencies if fixed differently Raphaël Hertzog: At the same time, it seems like a per-package decision where we need agreement between package maintainers and security teams. Santiago: please; remind to document breaking changes in the
Re: Remove support for nvidia-cuda-toolkit?
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 -- Roberto C. Sánchez
Re: Remove support for nvidia-cuda-toolkit?
On Mon, Apr 15, 2024 at 10:06:19PM +0200, Ola Lundqvist wrote: > Hi Roberto > > That was an interesting form. There were a few fields that I'm not > sure how to fill in more than the obvious. > > Like what is the impact of full EOL. > Is it as simple as just to tell that we will not provide security > support for this package? Or is it something more? > You will have to assess that. For instance, if we would EOL firefox-esr, the impact would be that many users to would lose access to current versions (with security fixes) of a popular web browser. If we were to EOL commonly used compiler/language runtime, then the ability of users to build with that compiler/language runtime as well as the ability of our team to build package updates could be impacted. So, it is necessary to take a look at how a particular package is meant to be used, how it is actually 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
Re: bind9 patch or new upstream version
Hi Ola, On Sat, Apr 13, 2024 at 12:49:49AM +0200, Ola Lundqvist wrote: > Hi fellow LTS contributors > > Today I started on bind9 and realized one thing. In bullseye the > security update is to release a new upstream version (released as > 1:9.16.48-1) instead of patching the old version > (1:9.16.44-1~deb11u1). For some reason the version used is -1 instead > of ~deb11u1. > I am not entirely sure why -1 was used, but I can tell you that ~deb11u1 was not used because the upload went through proposed-updates. It appears to also have gone to the security queue, but it isn't clear to me why that happened. In any event, an upload to proposed-updates would typically need a version like +bullseye1. However, stable already has a higher version (1:9.18.24-1), which guarantees that on upgrade from bullseye to bookwork the new version in bookworm will take priority. Also, looking at security and proposed-updates for stable shows that the versions there were also uploaded with -1. Either way, it doesn't make a difference and it isn't something that we should worry about. > Since this is not the normal practice I'd like to check so we have a > common agreement that this is the best also for LTS/buster. > > In this case I think it is the safest method. Trying to pick the > individual patches can be risky. Assuming that you are suggesting that we upgrade buster to the bullseye version (9.16.48), then I disagree entirely. We cannot move bind9 to the bullseye version. > Or do we know any specific reason why we should not go this path? > In the case of buster we can't do what what was done for stable and oldstable. If you look at the versions there, here is what happened: stable: 9.18.19 -> 9.18.24 oldstable: 9.16.44 -> 9.16.48 The version in buster is 9.11.5.P4. We cannot upgrade to 9.16.48 without risking breaking changes for users. I haven't looked, but I assume that you are asking this question because there is not a new 9.11.x release that deals with the current vulnerabilities. If 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
Re: Guidance for CVE triage and listing packages in dla-needed.txt
On Thu, Apr 11, 2024 at 10:01:49PM +0200, Ola Lundqvist wrote:
> Hi Roberto
>
> Maybe there is some counting mishap still. We may get double counting
> due to the -A and -B flags. But it should not matter so much because
> the double counting will then be both for corrected and others (at
> least on average). When writing this I think I may get more
> over-counting on the corrected since the DLA tag is on the line just
> below the CVE line so it may hit a CVE before in certain cases. I can
> write a better counting function if you want, but do that matter much
> to the discussion?
>
> Just to check. You commented on the clearly incorrect data. I hope you
> understood that the more correct data was further down in that email,
> right?
> Just want to double-check.
>
Yes, sorry about that. I trimmed off the wrong part. I should rather
have kept this last part quoted:
> So how many did we in fact fix?
>
> 559+621+484+406+247-1-263-361-531-511=650
>
> That is a much larger number. Phew. I should have checked it myself
> because I also found it a little strange.
>
> The total number of buster CVEs were 8165.
>
> We still have 281+209+329+294+199=1312 no-dsa and 71+49+24+38+11=193
> postponed.
>
> We clearly do not fix all no-dsa in any case.
> I'm not completely sure what your list shows. You do not seem to try
> to filter out the CVEs that are related to buster or DLAs. What was
> your intention to show?
>
My intention was to show the total number of CVEs fixed for each of the
years in question.
You seem to have compared the numbers from the start of 2023 and the
start of 2024 to get a count for the year 2023. This does something
similar:
$ for c in $(seq 2023 -1 2019) ; do echo -n "${c}: " ; cat data/DLA/list | sed
-n '242,1587p' | egrep "CVE[-]${c}" | sed -r -e 's/[^-A-Z0-9 ]//g' -e 's/
/\n/g' | egrep "CVE[-]${c}" | sort -u | wc -l ; done
2023: 546
2022: 333
2021: 178
2020: 171
2019: 88
(The lines 242 and 1587 correspend to the end and beginning of the DLAs
for 2023, all of which would have been for buster.)
The total is 546+333+178+171+88 = 1316, more than double the count of
fixed CVEs that your count showed.
I tried re-reading your previous email several times and I am still not
able to figure out what you are trying to demonstrate by your counting.
If the conclusion is as you have it above, "We clearly do not fix all
no-dsa in any case," then I agree. But I don't see what significant
bearing that has on this discussion.
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
Re: How to handle freeimage package
Hi Ola, On Thu, Apr 11, 2024 at 11:11:15PM +0200, Ola Lundqvist wrote: > > What I typically do is to read the description, and the referenced > material to see if the reporter seems to make sense. If there is a fix > available read the fix. The fix typically give a lot of information. > In this case there were no fix, only a reproducer and backtrace > description. They seemed to make sense and therefore I postponed the > ones that were mentioned as DoS class in the same way as the other > issues had been postponed when they were of the same class. > I think that it may help to take a step back and look at the big picture with freeimage. - 42 "vulnerable" or "no-dsa" CVEs dating back to 2019 in the security tracker - 6 of those are "Minor issue" for (old)stable - the other 36 are "Revisit when fixed upstream" - upstream is dormant (maybe dead?) In this particular instance, it seems like a waste of time to dig into individual CVEs for the purpose of triage. Ask yourself, what is to be gained by spending time doing a detailed triage of each CVE? What does seem to make sense is (again, in this particular instance): - copy the secteam triage decision for buster for the CVEs that have not yet been triaged for buster - move on to the next package (since none of the CVEs have fixes available) That said, it would be valid for someone who is an LTS contributor to try to tackle developing fixes for these CVEs (and then also get them submitted upstream and prepare appropriate patches for (old)stable as well). But I also wouldn't blame anyone for looking at this package and thinking that it would be too much trouble. The point, however, is that triage is not meant to consume a great deal of resources. If we were looking at a package with 2 or 3 recent CVEs, then spending some amount of time triaging those CVEs makes sense. It would be necessary to determine their severity because 2 or 3 CVEs of a minor severity may not justify producing an update. In a case like that, assuming that fixes are available, then marking the CVEs "postponed" and waiting for more CVEs to accumulate would potentially be a sensible course of action. However, looking at a package with dozens of CVEs is a different matter. It is necessary to scale the triage approach to a level appropriate for the package under consideration. An exercise of judgment is required in triage just as it is in the other aspects of dealing with a CVE, developing/backporting patches, testing the fix, guarding against regression, etc. Put another way, the state of freeimage is such that one of these two things should 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
Re: undetermined or postponed for freeimage?
On Thu, Apr 11, 2024 at 10:23:13PM +0200, Ola Lundqvist wrote: > Hi fellow LTS contributors > > I hope you do not mind me asking but there is one thing that I would > like to check. > > When I look at this CVE that was previously postponed: > https://security-tracker.debian.org/tracker/CVE-2019-12214 > > The information tells that the vulnerability my in fact not be in > freeimage at all. > For this I think "undetermined" tag is typically used instead of postponed. > Should I change? > I would recommend against changing it. *We* think that it may not be an issue in freeimage, but that is based on Hugo's speculation. I don't think "undetermined" is meant to be used in this case. > I guess so, but since I'm not sure if it has any other implications I > want to check first. > > We will clearly not 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
Re: Guidance for CVE triage and listing packages in dla-needed.txt
Hi Ola,
On Wed, Apr 10, 2024 at 09:42:48PM +0200, Ola Lundqvist wrote:
>
> You can see that in 1 year and 3 months we have fixed
> 2023: 58
> 2022: 15
> 2021: 78
> 2020: 11
> 2019: 1
>
> Total (not counting CVEs for 2018 and earlier) 162.
>
> It is still a low number.
>
> And I think I found the counting mishap. :-)
>
I think that your counting method is still faulty:
$ for c in $(seq 2023 -1 2019) ; do echo -n "${c}: " ; egrep "CVE[-]${c}"
../security-tracker/data/DLA/list | sed -r -e 's/[^-A-Z0-9 ]//g' -e '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
Re: How to handle freeimage package
On Wed, Apr 10, 2024 at 08:08:07PM +0300, Adrian Bunk wrote: > > My point was that an opposite approach of doing only > "file upstream bugs and wait for upstream to fix the CVEs" > is unlikely to have a positive outcome in this case. > > Forwarding fixes upstream is of course desirable, > even when upstream is dead. > Ah, thanks for the clarification. Regards, -Roberto -- Roberto C. Sánchez
Re: How to handle freeimage package
On Mon, Apr 08, 2024 at 07:56:40PM +0300, Adrian Bunk wrote: > On Mon, Apr 08, 2024 at 05:34:47PM +0200, Moritz Muehlenhoff wrote: > > > > So a useful next step would be to break those reports down into separate > > bug reports and file them there so that upstream actually learns about > > them. > > I don't think that makes much sense. > > When I checked, the last activity from upstream in the bug tracker was > a year ago. > > Some of the older CVEs are fixed in the upstream VCS, but there are > unfixed ones in the bug tracker going back to 2020. > > The 2024 CVEs are 21 buffer overflows and 2 NULL pointer dereferences, > there is likely a lot of low hanging fruit one could fix (and then > forward upstream) when spending 2 or 3 days on the package. > Even if upstream is dead, dormant, or not acting on bug reports, I agree with Moritz that submitting the reports upstream (to SourceForge) is still good and something that we should make an effort to do. First, the bugs are in fact upstream bugs and if we can break them down, identify, fix them, and then forward the fixes (as patches or PRs) upstream, others will be able to find the issues and the related fixes. Second, it seems like we would have to do all of those things (except the "forward to upstream" part) in any case to fix the CVEs for LTS, so the "forward to upstream" step is a only a very small additional step. > For 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
Re: Guidance for CVE triage and listing packages in dla-needed.txt
on to try to grade CVEs high/medium/low. In the first scenario, a whole bunch of packages will get added to dla-needed.txt and contributors will pick them, perform more in depth triage of the open CVES (which are most probably already marked 'no-dsa' and 'postponed' by secteam), and then make appropriate decisions. In some cases the CVEs will be fixed, and in other cases they will re-triaged (as either 'postponed'* or 'ignored'). * The re-triage of 'postponed' may be a 'no-dsa' that is not fixed right away, but which we simply leave as 'no-dsa' to avoid unnecessary churn in the security tracker. If there is another change that is needed, e.g., adding or updatign a comment, then changing the 'no-dsa' to 'postponed' would be OK. The second scenario works in much the same way, but just deals with CVEs as they arrive. The key difference is that we are more likely to be making a first pass decision on the CVE as it pertains to LTS, rather than inheriting a previous decision from secteam when the release was not yet under LTS. So, unless I miss something, we can accomplish everything we need, by simply discontinuing new assignments of the type 'no-dsa'. This is what was described in last month's LTS meeting. Here is the propsal that I made: Proposal: discontinue use of "no-dsa" in LTS (and ELTS) triage - Instead, any CVE markings added by FD or another (E)LTS contributor must either be "postponed" or "ignored" - Contributors are encouraged to review "no-dsa" entries when beginning new work on a package and deciding if those CVEs can be fixed as well (which is something that many contributors, perhaps all, already do) - To avoid unnecessary churn in the security tracker, we will not batch update (e.g., marking all LTS "no-dsa" as "postponed" instead); rather individual CVEs will be reviewed and either fixed or (if appropriate) updated to "ignored", "not-affected", etc. Additionally, our practice is to make comments that explain the triage decision and those comments 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
Re: Guidance for CVE triage and listing packages in dla-needed.txt
On Thu, Mar 14, 2024 at 11:39:41PM +0100, Ola Lundqvist wrote: > >I think we should clarify what we mean with "Minor issue". Is it what is >typically written as "(Minor issue)" after "" statement or >something else. >I'm asking since it seems to be a common view that we should fix all minor >issues too. I do not agree to that, but others has expressed that opinion. > Can you suggest what might be a useful statement or description of what constitutes a minor issue? I ask because nothing comes to mind. There are a multitude of factors and considerations that contribute to the severity of an issue, that this seems to me like a clear example of the sort of reason that regular LTS contributors are all experienced DD with security-relevant experience. Each case is a matter of professional judgment. > I think we should add that if LTS has an issue as no-dsa/postponed and >(old-)stable has it fixed, then we should add/keep the package to >dla-needed (or decide to ignore in case it is too invasive) to ensure LTS >gets it fixed as well. At least that was the rule I concluded from the >discussion and why I re-added a few packages back to dla-needed. This seems like something that we already do, or am I mistaken? As in, when a Debian release becomes LTS, one of the things that we do is to review the packages which have outstanding unfixed CVEs and triage them for LTS. >I also think we should add that in the typical case (all >no-dsa/postponed/ignored/fixed and they are few) this means that the >package should be removed from dla-needed.txt. I think it has a merit, >just to keep things tidy. >In fact I think we should typically remove the package from dla-needed if >it should not have been added, with exceptions described above. If we end up moving to a workflow based on Salsa issues, then I think that this will naturally occur. However, if we continue with a workflow based primarily around dla-needed.txt I am 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
Re: Expanding the scope (slightly) of dla-needed.txt
On Fri, Mar 15, 2024 at 06:48:58PM -0300, Santiago Ruano Rincón wrote: > > While I see all the advantages of moving to Salsa issues, I value to > have the most similar method and workflow than the security team for > the LTS work. And that especially if we want to explicitly state when > working on (old)stable is required (and someone has claimed a specific > package). > So, I spent some time looking at dla-needed.txt and dsa-needed.txt. While I agree completely that we want to retain similarity with the security team workflow where possible, I do not see a strong similarity between dla-needed.txt and dsa-needed.txt at this point. This is both in terms of content and in terms of change history/utilization. Of the 42 packages in dsa-needed.txt today, only 9 have a note attached. All 9 notes are a single sentence or sentence fragment. By contrast, fully 2/3 of the 55 packages in dla-needed.txt have substantive notes (i.e., a note other than "added by ..."). Many of the notes in dla-needed.txt span a half dozen sentences or sentence fragments. I do not have a great deal of insight into how the security team functions on a day to day basis, but I gather that they work differently in some key respects. Particularly, they seem less likely to pick up a package, set it down, transfer it between team members, etc. In that sense our workflow demands more thorough note keeping. I would argue that if we wanted to be more similar to the security team (in so far as the management of dla-needed.txt and trying to align it with dsa-needed.txt), then we should migrate to issues in Salsa. As I recall, the original idea that was proposed was that when a package is triaged in dla-needed.txt an issue would be created on Salsa (in the lts-team/lts-update-tasks project, and the creation could be automated). The entry in dla-needed.txt would consist of the name of the package, the person working on it at the time (if any), and a link to the issue in Salsa. This seems like it would bring several benefits: - dla-needed.txt would be far more compact and easier to consume for a human - less churn in the security tracker - a per-package place to discuss the various facets of the work (upstream coordination, testing, MRs, etc) There are also some drawbacks: - there are now two places with information about pending LTS work (dla-needed.txt and Salsa) - the tooling would need to be modified in order to provide an experience similar to the present experience - it would require some reworking of our processes Personally, I see the benefits as greater than the drawbacks and I think that at this point I have sufficient bandwidth to be able to help run a new experiment and then begin the transition process. One thing that we would need to discuss/decide is, assuming a workflow based on issues on Salsa, whether the single issue encompasses all the work (e.g., LTS update and any applicable update to oldstable/stable) or whether two issues are created (one for the LTS update and another for any applicable update to oldstable/stable). There are also opportunities for improvement that follow from this. For instance, with proper use of tags, it would be possible to update the security tracker code so that when you are looking at the status page for a package, there is a section with links to Salsa issues from lts-team/lts-update-tasks related to that packages. In any event, I am happy to work towards reinitializing the Salsa issues experiment to start again in April and then see how it goes from there. What do you think? Regards, -Roberto -- Roberto C. Sánchez
Re: Guidance for CVE triage and listing packages in dla-needed.txt
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 willing to > >change to 'no-dsa' so that a point release fix can be made > > Small nitpick: a CVE 'ignored' for (old)stable can still be fixed via point > release. The sec-team could be contacted to update that triaging, but that's > only ignored for (old)stable-security, not for (old)stable, where other > criteria applies. The reason following the ignored triaging may give some > more insight as to why it was ignored and why it may or may not make sense > to fix in a point release. > Thanks. I was not aware of this distinction. Regards, -Roberto -- Roberto C. Sánchez
Re: Expanding the scope (slightly) of dla-needed.txt
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 needs to > > happen after the DLA is released, specifically working toward an upload > > to (old)stable. > > Those processes can be quite long. So the entry in dla-needed might stay > around with lots of historical comments and with someone assigned that is > not actively doing anything on the package (waiting next > stable update or similar). > > What happens then when a new CVE shows up for that package? > > It might not show up for triaging by frontdesk because the package is > already listed... and the person assigned is not monitoring the list of > CVE of the packages since they are basically waiting the next point > release, or an answer from the security team, etc. > > Thus I have fears that this change might end up with us missing to be > reactive on some updates. > This is a valid concern. > Some alternative proposals to try to be constructive: > > - add "foo/bullseye" or "foo/bookworm" entries to track separately the > work on other releases (you need to check how the triaging script > interact with that kind of entries) > > - use salsa issues to track those (what happened to the experiment to use > salsa issues for regular updates BTW?) > At the moment, the documentation of the FD responsibilities and procedures are a bit of a mess (mostly because I have not had sufficient time to return to the work of revising the documentation). Sylvain has very helpfully fixed some of the most glaring problems, but the comprehensive revision is still needed. I am certainly in favor of using Salsa for the longer-running "non-LTS" parts of the updates. I also prefer Salsa as a solution because as I began thinking about the required tooling revisions to do everything in dla-needed.txt it became apparent that the tooling could be somewhat complicated. Granted, the approach of marking "foo/bullseye" or "foo/bookworm" for the entries would avoid some of that complication. I will have to think about which way the workflow would be more sensible for contributors and then Santiago and I can discuss how to implement. Regards, -Roberto -- Roberto C. Sánchez
Expanding the scope (slightly) of dla-needed.txt
Hello everyone, I have discussed with Santiago the idea of whether we need to somewhat expand the scope of dla-needed.txt. In essence, we need to continue tracking packages as in-work in some cases even after a DLA is released because we might be working with secteam, (O)SRM, and/or the maintainer on an upload to (old)stable. I think that in the past this has been handled somewhat informally (e.g., someone prepared a DLA and then even after the package was done from dla-needed.txt continued working on the (old)stable updates). However, for the sake of transparency and clarity we should be keeping track of this in some way. 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 needs to happen after the DLA is released, specifically working toward an upload to (old)stable. What this means: - if a DLA is published, then the package should only be removed from dla-needed.txt if no other work (as described above) remains - if the preceding point applies, then it may be necessary to manually unstage the changes to dla-needed.txt that gen-DLA will stage automatically - once the other work is completed, then it may be necessary to manually remove the package's entry from dla-needed.txt - these last points clearly indicate that some updates to tooling may be needed - it is important update the notes on packages in dla-needed.txt to indicate what work has been done and what remains - 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
Guidance for CVE triage and listing packages in dla-needed.txt
Hello everyone, After the recent discussions regarding triage decisions and the criteria for keeping packages in dla-needed.txt, I wanted to provide some guidance to help make matters more clear. First, as to the matter of triaging individual CVEs: - we prefer to see all CVEs fixed, absent good technical grounds to the contrary (e.g., minor issue, high risk of regression, too difficult to feasibly backport, etc) - if a CVE is 'fixed' in LTS but still 'no-dsa' in (old)stable, then we should do what we can to coordinate uploads to (old)stable so that the issue is fixed in a future point release - 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 willing to change to 'no-dsa' so that a point release fix can be made - note that 'fixed' in the above items specifically means "fixed by way of a DLA (or earlier DSA), rather than 'not-affected' (since 'not-affected' renders as 'fixed' in the package-level view)" Second, as to the matter of the criteria for keeping packages in dla-needed.txt: - if a package requires work by the LTS team, then it should remain in dla-needed.txt; this includes if a DLA has already been published and we are working to support an upload to (old)stable - if a package is assigned, it must not be removed without first coordinating with whomever has claimed it (this is to avoid confusion about what work is being done and the state of the package) - just because all CVEs for a package are 'no-dsa' (or even 'postponed') in LTS does not mean that the package must be removed from dla-needed.txt; it may be that there are multiple no-dsa or postponed CVEs and that they collectively merit an update Finally, as to the matter of Go and Rust packages (since golang-go.crypto was among the packages caught in the recent discussion on triaging), please note the following from the Debian release notes [0]: 5.2.1.2. Go- and Rust-based packages The Debian infrastructure currently has problems with rebuilding packages of types that systematically use static linking. With the growth of the Go and Rust ecosystems it means that these packages will be covered by limited security support until the infrastructure is improved to deal with them maintainably. In most cases if updates are warranted for Go or Rust development libraries, they will only be released via regular point releases. - in general, we want to be mindful of the fact that updating Go and Rust packages can produce a great deal of churn in the distribution (because the pervasive use of static linking can require rebuilding dozens or even more than a hundred packages) - this particular issue is the subject of ongoing work within Freexian (to try to develop tooling to address the limitations expressed by the secteam in the release notes) - for the time being, particularly serious vulnerabilities in Go and Rust packages are sufficient to potentially justify listing them in dla-needed.txt, but in general we would prefer to not list these packages in dla-needed.txt to avoid the mass number of rebuilds (note that if you are unsure if a CVE rises to the level I have described, you should bring it up for discussion on this list) - if you are specifically intersted in helping to improve the situation for statically linked language ecosystems, then there is an issue [1] in the public lts-extra-tasks project in Salsa Additional information about this particular issue of security updates for ecosystems that use static is available in a recent thread on this list [2]. [0] https://www.debian.org/releases/stable/amd64/release-notes/ch-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
Re: Remove support for nvidia-cuda-toolkit?
On Tue, Mar 12, 2024 at 08:05:15PM +0100, Ola Lundqvist wrote: >Hi all >Before I removed this entry from dla-needed it looked like this. >nvidia-cuda-toolkit > NOTE: 20230514: Added by Front-Desk (utkarsh) > NOTE: 20230514: package listed in packages-to-support; a bunch of CVEs >have > NOTE: 20230514: piled up. (utkarsh) > NOTE: 20230610: Details: >[1]https://lists.debian.org/debian-lts/2023/06/msg00032.html > NOTE: 20230610: my recommendation would be to put the package on the >"not-supported" list. (tobi) >As you can see the suggestion is to declare the package as not supported. >Is that a common view? Hi Ola, I have read the discussion thread from last year and I agree that marking nvidia-cuda-toolkit as not supported seems like the right course of action. Please file an issue in the lts-team/lts-updates-tasks project on Salsa, using the "Proposed EOL of package" issue template. Regards, -Roberto -- Roberto C. Sánchez
Re: Removed docker.io from dla-needed. Objections?
On Sat, Mar 09, 2024 at 11:45:22PM +0100, Ola Lundqvist wrote: >Hi >Since I have been able to to all other tasks as front desk this week I >took the opportunity to look through the items we have in dla-needed and >check whether they are still things to do. >I found a few that were only no-dsa or ignored issues so I removed them. >In some cases because "regular front desk" had considered CVEs no-dsa >after it was triaged for buster. >When doing so I found three CVEs for [1]docker.io that were no-dsa in >bullseye and after marking those as no-dsa for buster as well there were >nothing left to be done. In normal case I would have removed this too from >dla-needed but this time I can see that people have worked on a fix, but 6 >months ago. >I have removed it now but I reach out to you if you have any >objections? If you have I will put it back again. That makes sense. In the case that there were CVEs fixed in buster that remained unfixed (or no-dsa) in bullseye and/or bookworm, we would want to make sure that someone is working on getting an update into (old)stable. However, 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
LTS meeting notes: 2024-02-22
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 Levsen - Daniel Leidert - Sean Whitton (TZ incompat.) - Adrian Bunk - Thorsten - Emilio Discussion: - debian.social Jitsi has been shut down as a result of abuse - Action/ToDo items from previous meeting(s) (santiago) + Commit notifications are now sent to a dedicated list * this will help eliminate noise on the main list * subscription is by request, everyone should be subscribed to it who has requested it + We moved to using pyxian for reporting monthly hours for LTS contributors. This needed some work to support non-Collaborators, it's now reportedly working. Standing long-term action to handle all hour-handling in pyxian. + The dcut workflow has some limitation, tracked later in the minutes. - Contributor hours management (roberto): + Reminder: dormant contributors will have their unused hours reaped starting with the March hours dispatch; warnings sent for January/February + Remember to make your ledger entry *before* the hours dispatch is prepared (on the 3rd of the month) + If you know you won't be able to report hours in time, please reach out to the LTS managers to let them know. They can make it on your behalf. You can update it later. + We will move into enforcement mode for unused hours next month. - Update on the migration to the dcut migrate workflow (santiago) + Version reuse is not properly supported yet: test results will be cached for the previous upload using the same version. * e.g. if you re-upload after finding a regression in your first upload, before migrating it. + An option in the meantime is to get in touch with Helmut and ask him to re-schedule your tests. Helmut is working on being able to do this via an API. + Still planning to move forward to the new workflow soon. + Note that salsa autopkgtest results may not match debci: * debci tests are run under qemu (virtualization-machine) * debci schedules reverse-dependencies to be tested against the new package to find regressions. * Action (Santiago): Document these differences, including testing of rdepends (rouca may review) - LTS for Samba 4.17 (santiago) + Freexian has signed a contract with Catalyst to support Samba in Debian Bookworm for up to 5 years. This includes AD-DC support. - Any other business + None - Next meeting + 2024-03-28 14:00 UTC [Location: #debian-lts on IRC] Please let me know if you think I've missed something or if you have any questions about the items that were discussed. Regards, -Roberto -- Roberto C. Sánchez
Re: Linux Pro Magazine article on Debian LTS
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 column is in, contact > > c...@linuxnewmedia.com in North America or s...@sparkhausmedia.com in the > > rest > > of the world. > > > I am working on getting the responses put together. > Hi Bruce, I have attached a document with your questions and answers to each. Please feel free to follow-up as needed and I'll do my best to answer promptly. Regards, -Roberto -- Roberto C. Sánchez -- -Why did LTS become an option? In particular, how did the Debian project begin? Why is the Old Stable repository not sufficient? Historically, the Security Team had committed to supporting a particular stable release until one year after the release of its successor. During the time when the Debian project was producing new stable releases less frequently than at present, the security support time frame worked out to around 4-5 years. Some years ago, the Debian project decided to move to a more consistent release tempo of approximately 24 months between stable releases. The resources of the Security Team did not allow them to extend the support commitment, as it was not possibile for them to support three Debian stable releases simultaneously. As a result of this, the Security Team is now committed to supporting each Debian stable release for 3 years. However, the popularity of Ubuntu's LTS releases and Red Hat's RHEL demonstrated that demand existed for Linux distributions that have support timeframes of 5 years or more. Your question "how did the Debian project begin?" seems somewhat overly broad, so I am going to proceed with the assumption to that you meant to ask "how did the Debian *LTS* project begin?" In 2014, Debian Developer Raphaël Hertzog, owner of the French IT consultancy Freexian SARL, commenced an initiative to seek out sponsors to provide funding in support of providing an additional 2 years of support for Debian stable (version 6, "squeeze", being the stable release at that time) to provide users a Debian stable release that would receive security updates for 5 years from its initial date of release. Raphaël also set about recruiting interested Debian Developers who could perform the work of preparing the required updates (as well as other tasks associated with providing this security support). The oldstable repository is perhaps not the best way to think about this. Rather, when a stable release is made the particular set of packages present in the archive are frozen. After that, uploads targeting the stable release are permitted only for a small set of reasons (security updates being the most common). When the next stable release is made, the previous stable release continues to exist. The labels 'stable' and 'oldstable' are aliases for the current stable release and its predecessor, respectively. Looking at it that way, the time from when a particular stable release is displaced by its successor (and thus takes on the alias 'oldstable') until the Security Team drops support for it is generally about one year. The LTS effort continues uploading to that same oldstable release target. This means that users do not have to do anything special in order to use LTS. So, for instance, if a user installed Debian 12 bookworm today and configured the standard archive mirror sources (including the security archive), then that user can expect to receive package updates until around mid-2028 for that system (5 years after the initial release of bookworm). The key takeaway is that the efforts of LTS contributors result in package uploads using the same tools and infrastructure as the Security Team's uploads, which results in a nearly seamless experience for users. - What are the reasons/ advantages of using LTS? Any disadvantages? There is not really a concept of "using LTS" that is somehow distinct from using a Debian stable release. Simply put, a user can install a Debian stable release with confidence that it will continue receiving security updates until 5 years from its initial release. That said, there are some disadvantages which can come into play in the latter part of the 5 year timeframe. As software ages, it can become more difficult to maintain. From a user perspective this means that some security updates may be slower to arrive and also that some packages may have to be dropped from support. This is not common and it is something which may also happen during the earlier part of the life of a stable release, meaning that this is not unique to the LTS effort. - Who is the audience for LTS? To what extent are the sponsors of De
Re: debian 10 security firefox-esr upgrade failing
On Sun, Jan 28, 2024 at 03:24:57PM -0500, Jim Rosenberg wrote: > > What is the output of 'apt-cache policy firefox-esr-l10n-zh-tw'? > > 145% apt-cache policy firefox-esr-l10n-zh-tw > firefox-esr-l10n-zh-tw: > Installed: 115.6.0esr-1~deb10u1 > Candidate: 115.7.0esr-1~deb10u1 > Version table: > 115.7.0esr-1~deb10u1 500 > 500 http://security.debian.org buster/updates/main amd64 Packages > 500 http://security.debian.org buster/updates/main i386 Packages > 500 http://security.debian.org/debian-security buster/updates/main > amd64 Packages 500 http://security.debian.org/debian-security > buster/updates/main i386 Packages *** 115.6.0esr-1~deb10u1 100 > 100 /var/lib/dpkg/status > 91.12.0esr-1~deb10u1 500 > 500 http://deb.debian.org/debian buster/main amd64 Packages > 78.15.0esr-1~deb10u1 500 > 500 http://deb.debian.org/debian buster/main i386 Packages > > > I am not sure why the language packs are being held back. Also, I am not > > sure why you need 66 different langauges, but that should not interfere > > with apt. > > I don't need the language packs -- should I uninstall them and then see > what happens? > Aha! I see what's going on! You have your system set up for multi-arch, amd64 and i386. The language packs are architecture independent, so your system sees the language packs at version 115.7.0esr-1~deb10u1 and the firefox-esr package itself (for amd64) at version 115.6.0esr-1~deb10u1. That said, when you supplied the output of 'apt-cache policy firefox-esr' it didn't show any i386 installation candidate and I'm not entirely sure why that is the case. Either way, 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
Re: debian 10 security firefox-esr upgrade failing
Hi Jim, Please note that according to list etiquette top posting is discouraged. On Sun, Jan 28, 2024 at 08:55:16AM -0500, Jim Rosenberg wrote: > 138% sudo apt-get upgrade > [sudo] password for jr: > Reading package lists... Done > Building dependency tree > Reading state information... Done > Calculating upgrade... Done > The following packages have been kept back: > firefox-esr-l10n-ar firefox-esr-l10n-ast firefox-esr-l10n-be > firefox-esr-l10n-bg firefox-esr-l10n-bn firefox-esr-l10n-bs > firefox-esr-l10n-ca firefox-esr-l10n-cs firefox-esr-l10n-cy > firefox-esr-l10n-da firefox-esr-l10n-de firefox-esr-l10n-el > firefox-esr-l10n-en-gb firefox-esr-l10n-eo firefox-esr-l10n-es-ar > firefox-esr-l10n-es-cl firefox-esr-l10n-es-es firefox-esr-l10n-es-mx > firefox-esr-l10n-et firefox-esr-l10n-eu firefox-esr-l10n-fa > firefox-esr-l10n-fi firefox-esr-l10n-fr firefox-esr-l10n-ga-ie > firefox-esr-l10n-gl firefox-esr-l10n-gu-in firefox-esr-l10n-he > firefox-esr-l10n-hi-in firefox-esr-l10n-hr firefox-esr-l10n-hu > firefox-esr-l10n-id firefox-esr-l10n-is firefox-esr-l10n-it > firefox-esr-l10n-ja firefox-esr-l10n-kk firefox-esr-l10n-km > firefox-esr-l10n-kn firefox-esr-l10n-ko firefox-esr-l10n-lt > firefox-esr-l10n-lv firefox-esr-l10n-mk firefox-esr-l10n-mr > firefox-esr-l10n-nb-no firefox-esr-l10n-ne-np firefox-esr-l10n-nl > firefox-esr-l10n-nn-no firefox-esr-l10n-pa-in firefox-esr-l10n-pl > firefox-esr-l10n-pt-br firefox-esr-l10n-pt-pt firefox-esr-l10n-ro > firefox-esr-l10n-ru firefox-esr-l10n-si firefox-esr-l10n-sk > firefox-esr-l10n-sl firefox-esr-l10n-sq firefox-esr-l10n-sr > firefox-esr-l10n-sv-se firefox-esr-l10n-ta firefox-esr-l10n-te > firefox-esr-l10n-th firefox-esr-l10n-tr firefox-esr-l10n-uk > firefox-esr-l10n-vi firefox-esr-l10n-zh-cn firefox-esr-l10n-zh-tw > 0 upgraded, 0 newly installed, 0 to remove and 66 not upgraded. > > -Thanks, Jim > I am not sure why the language packs are being held back. Also, I am 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
Re: debian 10 security firefox-esr upgrade failing
On Sat, Jan 27, 2024 at 10:35:55PM -0500, Jim Rosenberg wrote: > Wow, thanks for the lightning quick response!! > > > When reporting problems like this it is really quite important to > > include complete output. > > 127% apt-cache policy firefox-esr > firefox-esr: > Installed: 115.6.0esr-1~deb10u1 > Candidate: 115.6.0esr-1~deb10u1 > Version table: > *** 115.6.0esr-1~deb10u1 500 > 500 http://security.debian.org buster/updates/main amd64 Packages > 500 http://security.debian.org/debian-security buster/updates/main > amd64 Packages 100 /var/lib/dpkg/status > 91.12.0esr-1~deb10u1 500 > 500 http://deb.debian.org/debian buster/main amd64 Packages > > 128% sudo apt update > [sudo] password for jr: > Hit:1 http://deb.debian.org/debian buster InRelease > Hit:2 http://security.debian.org buster/updates InRelease > Hit:3 http://security.debian.org/debian-security buster/updates InRelease > Hit:4 http://deb.debian.org/debian buster-updates InRelease > Hit:5 https://dbeaver.io/debs/dbeaver-ce InRelease > Reading package lists... Done > Building dependency tree > Reading state information... Done > 66 packages can be upgraded. Run 'apt list --upgradable' to see them. > > 130% apt-get -s upgrade | grep upgraded > 0 upgraded, 0 newly installed, 0 to remove and 66 not upgraded. > > 131% apt-get -s --with-new-pkgs upgrade | grep upgraded > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > Your system doesn't seem to know anything of an unavailable firefox-esr package (it seems to think that the candidate is 115.6.0esr-1~deb10u1). I'll repeat what I said in my last message: > > When reporting problems like this it is really quite important to > > include complete output. You have chosen to run the output of 'apt-get -s upgrade' through 'grep' so that it is not possible to tell what problem apt-get may have encountered or what choice it made in deciding the viable upgrade path(s). By sending the output through 'grep' you have only allowed us to determine that 'apt-get' decided it could not upgrade 66 packages, but it is not possible to determine how or why apt reached that conclusion. Also, note that you have a 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
Re: debian 10 security firefox-esr upgrade failing
Hi Jim, On Sat, Jan 27, 2024 at 09:57:13PM -0500, Jim Rosenberg wrote: > Trying to upgrade firefox-esr from 115.6.0esr to 115.7.0esr-1~deb10u1 > (architecture amd64) -- which apt-update indicates should work -- I get > 66 packages not upgraded. According to the package web page, > > https://packages.debian.org/buster/firefox-esr > > 115.7.0esr-1~deb10u1 seems not to be in the repository for amd64. > Presumably the build failed?? > When reporting problems like this it is really quite important to include complete output. It is correct that the build of 115.7.0esr-1~deb10u1 amd64 failed for amd64. However, it is not clear how apt on your system came to think that 115.7.0esr-1~deb10u1 was a viable installation candidate. > This is exactly like what happened with 115.6.0esr. Could someone fix > please? > What is the output of the following command? 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
Re: Linux Pro Magazine article on Debian LTS
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 column is in, contact > c...@linuxnewmedia.com in North America or s...@sparkhausmedia.com in the > rest > of the world. > I am working on getting the responses put together. Regards, -Roberto -- Roberto C. Sánchez
Re: Linux Pro Magazine article on Debian LTS
On Mon, Jan 22, 2024 at 02:56:53PM -0800, Bruce Byfield wrote: > Hi: > > I would like to feature the Debian LTS project in my next Distro Walk column > in Linux Pro Magazine. > > Is there someone who can answer questions via email or coordinate several > people supplying answers? Or would posting to this list be easier? > > I could send questions in the next day or so, and would need answers in a > week's time. > > (Please cc my address in any replies, since for some reason, I was unable to > subscribe in my browser). > Hi Bruce, 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
Re: Make stable-security build logs public after embargo
Hello again Wanna-build team, On Thu, Jun 01, 2023 at 04:51:56PM +0200, Sylvain Beucler wrote: > Hello Wanna-build team, > > I'm part of the Debian LTS Team, and along with the Security Team, we're > looking into making embargo'd build logs eventually public. > See https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues/51 > > Typical use case: when the LTS Team is working on the first LTS security > upload for buster-security, the previous build logs are not available, while > they are critical to interpret any new build failure. > This also improves the overall transparency of the Debian project. > > So we'd like to make the stable-security build logs eventually public, > preferably early. One approach is to make the build logs available through > https://buildd.debian.org/status/package.php on package release (when the > embargoes for the package and possibly its dependencies are lifted, and the > new packages are publicly distributed by Debian). > Another more straightforward approach, but way more delayed, is to make > these build logs available in batch, when handing over oldstable to the LTS > team. > > Note: the new lts (buster-security) build logs are already made public, here > we're targeting future-lts (bullseye-security) build logs. > > Currently we're not entirely sure on how build logs are injected to the > buildd.debian.org/status/package.php service, so we're contacting you to > determine how feasible this is. Typically: > - Locate and identify publishable logs (in e-mail archives on master?) > - Trigger the publication at the right time (dak hook?) > > I also volunteer to spend some time on the implementation, as part 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
Re: upcoming changes of the web pages /security and /lts/security
Hi Thomas, [I changed lts-secur...@debian.org to debian-lts@lists.debian.org since lts-secur...@debian.org is meant only to reach members of the team approved to deal with embargoed issues. It is not a public list like debian-lts@lists.debian.org.] I read through this message and I am very excited about the coming changes. On Thu, Dec 07, 2023 at 08:38:05PM +0100, Thomas Lange wrote: > Hi all, > > in the past, all security related lists (like the N recent security > advisories, crossreferences, RSS feeds, OVAL) were using the .wml and > .data files which exists for each DSA and DLA. These two files are > still created manually for each DSA and DLA. > > After talking to the security team, my goal is to remove the need of > this manuall work and generate all information automatically from the > primary security sources from the Debian Security Tracker. This also > makes the security information more early available to our users > without waiting for someone to prepare the .wml and .data files. > > > The changes will affect the webwml repository under /security/ and > /lts/security/. > Our workflow for LTS still includes manual generation of .wml and .data files, as you note. As this is a step in the process which presents an opportunity make mistakes, I am pleased that this is being automated. At what point should the LTS team stop generating these? Is that something that we should discontinue right away, or do wait 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
LTS meeting schedule for 2024 has been published
Hello everyone! I have just published the 2024 meeting schedule [0]. As always, meetings are scheduled for 14:00 UTC on the fourth Thursday of the month, except for December*. For those of you who can use an ICS file, there is a new 2024.ics file with all of the meetings listed in it. Regards, -Roberto * The fourth Thursday in December 2024 is the 26th, which is the day after Christmas. Since Christmas is a national holiday for nearly all of us and taking the days between Christmas and New Years off from work is relatively common, I moved the December 2024 meeting one week 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
Re: [SECURITY] [DLA 3676-1] horizon security update
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
LTS meeting summary and notes
Thanks to everyone who participated in today's LTS contributor meeting. As the meeting took place over IRC, everything was recorded by Meetbot. The information can be found at these links: Minutes: http://meetbot.debian.net/debian-lts/2023/debian-lts.2023-11-30-13.57.html Minutes (text): 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
Re: [SECURITY] [DLA 3676-1] horizon security update
On Fri, Dec 01, 2023 at 12:48:19AM +0100, Guilhem Moulin wrote: > On Thu, 30 Nov 2023 at 23:59:28 +0100, Guilhem Moulin wrote: > > - > > Debian LTS Advisory DLA-3676-1debian-lts@lists.debian.org > > https://www.debian.org/lts/security/ Guilhem Moulin > > November 30, 2023 https://wiki.debian.org/LTS > > - > > Crap, that should have been DLA-3678-1… Should I resend a new mail with > the correct ID? > Yes, I would recommend two things. First, re-send the announcement with an updated subject line: [SECURITY] [DLA 3678-1] horizon security update - CORRECTED ANNOUNCEMENT Use the same message text, but include a small bit at the top. Perhaps something along the lines of: == NB: the original message sent included the wrong DLA reference ID. This message corrects the reference ID in the subject line. Everything else about the content of the former message, including the CVEs identified as fixed and the version of the package in which they are fixed, remains the same. == I would also reply to the original (incorrect) message, addressing the reply debian-lts-announce@, with a note along the lines of: == The DLA reference ID in this announcement was incorrect. The correct reference ID is DLA-3678-1. A new announcement has been sent under the correct reference ID. ====== Regards, -Roberto -- Roberto C. Sánchez
Re: Fix for CVE-2020-25648 in nss
Hi Sean,
On Fri, Oct 27, 2023 at 04:08:36PM +0100, Sean Whitton wrote:
> [attempt to resend to correct list address]
>
> Hello,
>
> I am trying to backport the fix for CVE-2020-25648 to nss version 3.42.1
> in Debian 10, "buster". Unfortunately, the four tests added by the fix
> do not pass.
>
> Would someone be able to take a look at the test output, please?
> Perhaps the failed test does not indicate that the fix is ineffective.
> As all the other tests pass, I'm not too concerned about introducing any
> regressions.
>
It seems your backported patch might be faulty. The upstream patch [0]
contains the following change:
ss->ssl3.hs.ws != idle_handshake &&
cText->buf->len == 1 &&
cText->buf->buf[0] == change_cipher_spec_choice) {
-/* Ignore the CCS. */
-return SECSuccess;
+if (ss->ssl3.hs.allowCcs) {
+/* Ignore the first CCS. */
+ss->ssl3.hs.allowCcs = PR_FALSE;
+return SECSuccess;
+}
+
+/* Compatibility mode is not negotiated. */
+alert = unexpected_message;
+PORT_SetError(SSL_ERROR_RX_MALFORMED_CHANGE_CIPHER);
}
if ((IS_DTLS(ss) && !dtls13_AeadLimitReached(spec)) ||
However, your patch has this instead:
cText->buf->buf[0] == change_cipher_spec_choice) {
/* Ignore the CCS. */
return SECSuccess;
+if (ss->ssl3.hs.allowCcs) {
+/* Ignore the first CCS. */
+ss->ssl3.hs.allowCcs = PR_FALSE;
+return SECSuccess;
+}
+
+/* Compatibility mode is not negotiated. */
+alert = unexpected_message;
+PORT_SetError(SSL_ERROR_RX_MALFORMED_CHANGE_CIPHER);
}
if (IS_DTLS(ss) ||
It appears that the code which was added is never reached because the
unconditional 'return SECSuccess;' was not pushed down into the new 'if'
statement.
I tried a few times to run the tests, but I couldn't manage it. So, my
theory is untested, but based on the fact that your failing test output
includes
Got error code (null) expecting SSL_ERROR_RX_MALFORMED_CHANGE_CIPHER
Since it seems like the function is 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
Re: LTS meeting summary and notes
On Thu, Oct 26, 2023 at 08:43:14PM +0200, Dominik George wrote: > Hi, > > > In the discussion, it became clear that there is a > > significant cost to this approach: substantial delays to LTS/ELTS > > updates. > > Why's that? > > IIRC, security 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
LTS meeting summary and notes
plicated packages that would exceed their usual allocations. - Any other business: NOTES/DISCUSSION: Nobody had anything to bring up under AOB Many thanks also to those of you who made notes in the pad during the meeting. And lastly, the next LTS meeting will take place on Thursday 2023-11-23 at 14:00 UTC, via IRC in the #debian-lts channel on OFTC. As always, note your agenda items here: https://pad.riseup.net/p/lts-meeting-agenda Regards, -Roberto -- Roberto C. Sánchez
Re: Ring
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 of the patch applied > > (with a small amount of fuzz) and what didn't apply was fairly > > straightforward to backport. > > > > I have attached to this email what I think is a reasonable attempt at > > backporting upstream's patch of the forked/modified pjsip on top of > > version 20190215.1.f152c98~ds1-1+deb10u2 of ring. Note that I have not > > run any build or done any sort of testing on this. > > > > Could you review the patch and, if you agree that it seems like a > > reasonable backport, then build and test the package? > > Yes but the code in ssl_sock_imp_common.c is in fact here > daemon/contrib/src/pjproject/gnutls.patch :S > > I am a little bit unease about this package. > > So it need to patch a patch queue or to refactor the code and try something > else OK, so I missed the presence of the code there. I feel like the upstream project structure makes it somewhat hard to follow what is going on with the various components. In any event, if my suggestion is not helpful, then please feel free to disregard and take action based on your assessment (and perhaps any insight Thorsten may be able to offer). Regards, -Roberto -- Roberto C. Sánchez ◈ Freexian SARL https://www.freexian.com
Re: Ring
Hi Bastien,
On Fri, Sep 29, 2023 at 09:12:57PM +, Bastien Roucariès wrote:
> Hi,
>
> I tried to fix CVE-2021-32686 by using patch from upstream.
>
> I think the problem is hard to solve:
> - patch does not apply cleanly and backport will be difficult (moreover it
> is hard to test this kind of race condition)
I somewhat disagree with your assessment here. I agree that the patch
does not apply cleanly, but the backport seems fairly straightforward.
You did not mention the source you used for the upstream patch and it is
not linked in the security tracker, so I had to go and do some digging.
I was able to find the commit [0] in savoirfairelinux/pjproject (which
is the project which contains the forked pjsip library which is used by
jami, formerly called ring).
The older pjsip located in that project lacks ssl_sock_imp_common.c but
has the other two files. Most of the remainder of the patch applied
(with a small amount of fuzz) and what didn't apply was fairly
straightforward to backport.
I have attached to this email what I think is a reasonable attempt at
backporting upstream's patch of the forked/modified pjsip on top of
version 20190215.1.f152c98~ds1-1+deb10u2 of ring. Note that I have not
run any build or done any sort of testing on this.
Could you review the patch and, if you agree that it seems like a
reasonable backport, then build and test the package?
> - ring use a heavy patched PJSIP. A solution will be to use the repackaged
> dfsg pjsip from asterisk (debian dir) and try if ring patches apply
>
> However the second solution will take time for something that is DOS by NULL
> pointer deference
>
I agree that this second idea is likely not a good one. We have no way
to feasibly determine if upstream's forked/modified pjsip is entirely
compatible with the pjsip in the Debian archive. The risk would be too
great to switch out an underlying library implementation in this
fashion.
> Maybe a dsa-ignore will be better for this issue
>
Perhaps first consider the patch that I backported and only if that
doesn't solve the issue satisfactorily, then reconsider marking the CVE
as ignored.
All of that said, it is interesting to me that fairly recently (at the
end of August) the ring package in buster was updated to fix 23 CVEs,
but this particular CVE was left open. Perhaps 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.freexian.com
diff -ur ring-20190215.1.f152c98~ds1.orig/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjlib/src/pj/ssl_sock_ossl.c ring-20190215.1.f152c98~ds1/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjlib/src/pj/ssl_sock_ossl.c
--- ring-20190215.1.f152c98~ds1.orig/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjlib/src/pj/ssl_sock_ossl.c 2018-09-04 23:52:06.0 -0400
+++ ring-20190215.1.f152c98~ds1/daemon/contrib/tarballs-unpacked/pjproject-2.8.tar.gz/pjproject-2.8/pjlib/src/pj/ssl_sock_ossl.c 2023-10-06 15:11:16.166154584 -0400
@@ -451,7 +451,8 @@
ERROR_LOG("STATUS_FROM_SSL_ERR", err);
}
-ssock->last_err = err;
+if (ssock)
+ ssock->last_err = err;
return GET_STATUS_FROM_SSL_ERR(err);
}
@@ -468,7 +469,8 @@
/* Dig for more from OpenSSL error queue */
SSLLogErrors(action, ret, err, len);
-ssock->last_err = ssl_err;
+if (ssock)
+ ssock->last_err = ssl_err;
return GET_STATUS_FROM_SSL_ERR(ssl_err);
}
@@ -656,6 +658,13 @@
/* Create OpenSSL application data index for SSL socket */
sslsock_idx = SSL_get_ex_new_index(0, "SSL socket", NULL, NULL, NULL);
+if (sslsock_idx == -1) {
+ status = STATUS_FROM_SSL_ERR2("Init", NULL, -1, ERR_get_error(), 0);
+ PJ_LOG(1,(THIS_FILE,
+ "Fatal error: failed to get application data index for "
+ "SSL socket"));
+ return status;
+}
return status;
}
@@ -683,21 +692,36 @@
}
-/* SSL password callback. */
+/* SSL certificate verification result callback.
+ * Note that this callback seems to be always called from library worker
+ * thread, e.g: active socket on_read_complete callback, which should have
+ * already been equipped with race condition avoidance mechanism (should not
+ * be destroyed while callback is being invoked).
+ */
static int verify_cb(int preverify_ok, X509_STORE_CTX *x509_ctx)
{
-pj_ssl_sock_t *ssock;
-SSL *ossl_ssl;
+pj_ssl_sock_t *ssock = NULL;
+SSL *ossl_ssl = NULL;
int err;
/* Get SSL instance */
ossl_ssl = X509_STORE_CTX_get_ex_data(x509_ctx,
SSL_get_ex_data_X509_STORE_CTX_idx());
-pj_assert(ossl_ssl);
+if (!ossl_ssl) {
+ PJ_LOG(1,(THIS_
Re: Call for tests/review: glib2.0/buster
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.0 update for buster (and I am working for older > > > releases). I think it should be ready, all the test pass. But since > > > there were some regressions with a first set of patches, it would be > > > great if someone could give it a try. > > > > > > The packages are available following these instructions: > > > https://lts-team.pages.debian.net/-/packages/glib/-/jobs/4581183/artifacts/aptly/index.html > > > > > Has anyone been able to help with testing Santiago's glib2.0 update? > > I considered it but I was mostly out of time, I can do some testing next > week. IIUC there was also progress on the older releases since. OK. Thanks. I may also try to help (now that I will have September hours in a few days), so please make sure to replay again if you start working on this (I will do the same if I start) so that we are not duplicating work. Regards, -Roberto -- Roberto C. Sánchez
Re: Call for tests/review: glib2.0/buster
On Sun, Aug 20, 2023 at 06:53:54PM -0300, Santiago Ruano Rincón wrote: > Dear all > > I've prepared a glib2.0 update for buster (and I am working for older > releases). I think it should be ready, all the test pass. But since > there were some regressions with a first set of patches, it would be > great if someone could give it a try. > > The packages are available following these instructions: > https://lts-team.pages.debian.net/-/packages/glib/-/jobs/4581183/artifacts/aptly/index.html > Has anyone been able to help with testing Santiago's glib2.0 update? Regards, -Roberto -- Roberto C. Sánchez
Re: bullseye / libgdbm6:amd64 is a catastrophgy
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 > > and when the maintainer thinks there is a risk of breaking working > > configurations for other users" is somewhat inconsiderate of others and > > shows a disregard for the rather robust process that we try to utilize > > to ensure that we properly balance the needs of everyone involved. > > I don't think that's the claim, to be fair. > > It's more: > > Release gdbm versionStatus > --- - -- > Buster 1.18no pre-read feature > Bullseye1.19pre-read added, no way to disable it > Bookworm1.20reverted back to default behaviour, > added GBM_PREREAD to enable it > > It's a regression in upstream, which upstream agreed with, and upstream > fixed it. That said, it changes nothing of the things that I pointed out. Whether it is a new bug, regression, or whatever originating from upstream, the point is that it works in a particular way in the version that shipped with the release of bullseye. The concern of the maintainer is that applying upstream's change risks breaking other working configurations. > The question is how to get the benefits to Bullseye users. > It seems like if there were a way to get the new upstream release into bullseye that it would address the issue. However, while applying the patch to 1.19 has risks, updating to 1.20 almost certainly has other risks. Even if it can be proven to be a risk-free change, there are very few packages which fall into the category of "circumstances around the package are such that new upstream releases are allowed into the stable releases". Given the reverse dependencies of this package, that seems like an unlikely occurrence here. > > On Fri, Aug 25, 2023 at 01:41:36PM +0200, Christopher Huhn wrote: > > A backport of the bookworm package would be my way to go, I guess. > > This is probably the easiest path, if someone can upload it to > debian backports for Marc. > However, do keep in mind that the -backports repo is not supported by the LTS team. That is to say, once bullseye passes to LTS, there will be no further updates to packages in bullseye-backports. In the event that there is a concern that this package might be affected by a security vulnerability that needs to be patched during the LTS lifespan, it is best to plan for an upgrade to bookworm at the earliest convenience. Regards, -Roberto -- Roberto C. Sánchez
Re: bullseye / libgdbm6:amd64 is a catastrophgy
On Fri, Aug 25, 2023 at 01:41:36PM +0200, Christopher Huhn wrote: > [SNIP a bunch of good recommdnations for getting a patch accepted] Definitely, that is the way to go if someone wants to get a bug fixed in a release before it becomes LTS. > That said, LTS point releases do contain functional changes that are not > security related, so there seems to be no general security-fixes-only policy > for LTS either. Is that correct? > As Sylvain noted, we do fix non-security bugs in LTS from time to time. However, it is very uncommon. There are no LTS point releases because once a release passes from the security team to the LTS team, then the release managers also no longer have responsibility for it. The parts of the archive which are used for producing point releases (e.g., the -pu upload target, and the associated tools for managing and making releases, which includes things like installer images) are not available to the LTS team. We would not have the manpower to manage all of that, even if it were available to us. As I said elsewhere in the thread, the final point release is made shortly before the transition over to LTS team responsibility and then after that 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
Re: bullseye / libgdbm6:amd64 is a catastrophgy
On Fri, Aug 25, 2023 at 06:45:55AM -0400, PICCORO McKAY Lenz wrote: >this bug is not specific, the proble is that not all users report the >problems, just change the distro.. a normal tendency >in my case i downgrade to strecth and just works.. upgrading its not >always the right choose Just as fixing the bug is not always the right choice. As Sylvain noted in another reply to Marc elsewhere in this thread, the LTS team tends to trust the informed opinion of the maintainer. Since the maintainer is of the opinion that a fix to this bug is a risk "since it could break other installations that used to work well", the LTS team is not likely to override that without abundant good reason. >its pretty unconfortable that an important bug will be not solved just cos >"its not popular" (only happened to one user) inclusivelly being >catastrophic! The problem is not that only 1 user reported the bug. Even if 100 or 1000 users reported having the same issue, we would still need to ask the question, "what is the risk to fixing this?" If that risk is too high, then the safer course of action is to allow the bug to remain unfixed. It is not primarily a question of popularity, because the LTS has at times fixed security issues that we are quite confident affect only single user. However, when an issue carries the possibility of disruptive chaneg to many user, the issue in question must be of a severity to justify that risk. The maintainer seems to think that is not the case here. Additionally, as noted in the discussion in the bug and in this thread, there are multiple workarounds/alternate solutions available. Please make use of one of those if this particular bug affects your individual use case. 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 and when the maintainer thinks there is a risk of breaking working configurations for other users" is somewhat inconsiderate of others and shows a disregard for 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
Re: bullseye / libgdbm6:amd64 is a catastrophgy
On Fri, Aug 25, 2023 at 11:24:18AM +0200, Marc SCHAEFER wrote: > Hello, > > AFAIK is bullseye not yet LTS-handled. > That is correct. This transition will happen in mid-2024. > Will LTS fixes important bugs, or only security fixes? > Generally speaking, the LTS team focuses only on fixing security issues. > I reported this: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043023 > > I have a local work-around (keep the buster version), and the maintainer also > proposed another local work-around. Mine is running productively for a few > weeks now. > > Will LTS, when it takes hold of bullseye, fix this important bug? > This bug, while seriously impacting the usability of libgdbm6 for your specific use case, is hardly catastrophic. For that description to be appropriate it would be necessary for the package to be entirely non-functional for all use cases, breaking the functionality of other unrelated packages, and things of a similar nature. As the maintainer noted in his response to your bug report, you have several options available to you, including rebuilding the package locally, upgrading from bullseye to bookworm, and continuing to make use of the workaround. That said, if the bug is not fixed before bullseye makes the transition to LTS, then it almost certainly will not be fixed when bullseye is the responsibility of the LTS team. There are two main reasons for this. The first reason is that bugs of this nature (i.e., bugs that are not of a serious security nature, but which might still require a fix) are handled by the maintainer coordinating with the stable release managers (or oldstable release managers, in this case) to receive approval to upload a fixed package to be included in the next point release. Based on the response from the maintianer in your bug report, this does not appear to be in consideration. The second reason is that LTS (not being under the umbrella of the SRM/OSRM) does not receive point releases. The final point release of bullseye will happen just prior to the transition 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
New LTS Coordinator email alias
Hello everyone, I wanted to announce the creation of a new LTS/ELTS coordinator email address alias: lts-coordina...@freexian.com This alias will be shared by the primary LTS coordinator (me) and all backup/alternate coordinators (at present, Santiago). If you have any concerns that need to be addressed by the coordinator, please use the shared email address rather than emailing one of us directly. This will help ensure that if one or the other is unavailable that a timely decision is made and the response communicated. Some examples of things which might be expected to be addressed to the coordinator: - questions regarding distribution or re-allocation of hours (e.g., monthly dispatch, returning unused hours, allocating substantial hours from Available:Extra) - questions regarding pursuing especially complicated fixes (e.g., when the benefit is not especially clear and the work require may be considerable) - questions regarding potentially disruptive actions (e.g., backporting a new version of a package because the current version cannot be fixed) - scheduling of front desk slots - issues or agenda items to be discussed in the monthly meeting - general policy questions Note that this list is not exhaustive, but rather representative of the matters that have involved the coordinator in the last several months. Naturally, if you are unsure about something, it is certainly better to ask. Additionally, even if you are not a contributor, questions or concerns 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
[LTS meeting agenda item] LTS workflow updates
Hello everyone! Prologue: As the agenda for next week's LTS meeting is getting quite full (and the meeting is via Jitsi), which will make managing the meeting already challenging, I am starting a thread here on the list with a preliminary discussion of an agenda item that I will be bringing up in the meeting. Note that the objective with this thread is that everyone have an opportunity to be made aware, to consider, and to respond/ask questions concerning the proposed agenda item in advance of the meeting. If your responses are suitable for a public ML, then please reply in this thread and let's have the discussion here. If, for some reason, your response would not be suitable or make sense on a public ML, then hold your response/question for the meeting. Agenda Item: LTS workflow - Create tickets to nag about missing LTS contributor monthly reports, or continue with direct emails? Discussion: At present, when we are approaching the time for the LTS coordinator to prepare the monthly LTS report, notifications of missing individual contributor reports are sent via email. As we have moving more in the direction of managing via tickets rather than direct email (in order to facilitate better visbility of outstanding tasks and also to make it easier to share coordinator duties among multiple people), I have considered the possibility of switching missing report notifications to be tickets instead of direct emails. Would anyone have an objection to this or perhaps a reason why continuing with direct emails would be the better choice? - Thoughts about criteria for LTS contributor monthly reports Discussion: Our monthly individual contributor reports are not required to adhere to any specific criteria or follow any particular format. One of the challenges this creates is that it makes the task of drafting the LTS monthly report more difficult (because potentially interesting items that have been accomplished may not come across in some of the very brief reports which some contributors submit). I am considering whether it would be beneficial to establish some loose criteria (and associated examples) for a report format which would be a more useful input to the LTS montly report process. Are there any suggestions of things which should be specifically included or excluded? Are there any concerns about the types of things that, if included, would be burdensome without sufficient associated benefit? - Starting to experiment with issue based workflow, example: https://salsa.debian.org/lts-team/lts-updates-tasks/-/issues/28 Discussion: Is mentioned in the first point above, we have been moving in the direction of utilizing tickets in order to better manage the various activities in the LTS and ELTS projects. We have recently begun to experiment with tickets for DLA/ELA package work as well, as with the example link given above. The overall discussion for the concept is at https://gitlab.com/freexian/services/deblts-team/debian-lts/-/issues/47 . This is being mentioned for the purpose of ensuring that everyone on the team is aware that this is happening. However, if you have worked on a package update being managed 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
Re: firefox on buster
On Tue, Aug 08, 2023 at 11:03:48AM -0400, Chris Frey wrote: > On Tue, Aug 08, 2023 at 12:24:17PM +0200, Emilio Pozuelo Monfort wrote: > > Given that the package is no longer in sid, I had a little trouble preparing > > the backport from the git repository. That's sorted now, and the update > > should go out today or tomorrow, once testing on my part has been done. > > Thank you very much! > > What does it mean that the package is no longer in sid? > It appears that 102 is the main version for all the stable Debians, > so it's surprising to me that there was trouble. He is referring to the fact that 115.x.x ESR has been uploaded to sid. The normal LTS workflow is to take the sid version of firefox-esr and backport it. However, the transition from 102.x.x -> 115.x.x will require a bunch of toolchain work to come with it. We normally do this once per year, but at a time where it won't hold up the update of firefox-esr. Emilio probably meant that the choices were: - delay the buster update to do a bunch of toolchain updates (could take quite a long time) - grab the latest 102.x.x from git, which wouldn't be 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
Re: MariaDB 10.3.39
On Mon, Jul 03, 2023 at 04:29:58PM +0300, Otto Kekäläinen wrote: > Hi! > > FYI, MariaDB did an extra batch of releases in June. This message is > about 10.3 series. > > No MariaDB 10.3.40 did not happen as 10.3 series it out of scope. > However, thinking of cherry-picking 10.4 changes, I did however check > the release notes of 10.4.30. The 3 top issues at > https://mariadb.com/kb/en/mariadb-10-4-30-release-notes/ I tracked > down to be commits: > > https://github.com/MariaDB/server/commit/928012a27ae2d1549f1b3e6975b9d22652bbea3a.patch > https://github.com/MariaDB/server/commit/8f3bf593d24de9cd4744e71c86de80cd502786c7.patch > https://github.com/MariaDB/server/commit/aa713f5ae20513b0c4d9a74ea3ba3ea3bbdcd719.patch > > None of the above applied cleanly on 10.3.39, so I gave up. > > The 4th issue in release notes is reverting a change that I checked > was never on 10.3 series at all, so not relevant. > > As an extra experiment I mass applied all commits from 10.4 branch on > 10.3 that applied easily in > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/38 > and pushed to CI to see how much breaks. > So, if I understand correctly, this suggests that the individual patches are somehow dependent on changes made in other commits which precede them (those additional commits not being security-specific). Is that right? The approach of replaying all of the commits from the 10.4 branch on the 10.3 branch is interesting. > This type of backporting has never been done, so this is a bit of > experimental, but I wanted to try it out and ask thoughts about if > this makes sense from the LTS team. > The main risk that I see is the possibility of instability or a latent fault that comes from transposing an entire sequence of commits in this way. While I can see some value in this approach, I am not convinced that this approach is better than migrating to a supported minor release branch. There is clearly an up front risk in moving away from 10.3 (perhaps to 10.6 or 10.11), but that risk is quantifiable (I think). That said, even if we weren't replaying all of the commits from one branch to an older branch, but instead doing the normal backporting of specific commits that fix specific CVEs, there is still risk of regression. What I mean by all of that is that there is risk on both sides. But even if the "replay all the commits" strategy works in this instance, its long term viability isn't clear. We would potentially be in a similar situation when 10.4 is no longer supported (or prior to that point if we encounter a patch that won'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
Re: Request for suggestions/opinion about triaging decision for renderdoc
Hi Ola, The renderdoc situation certainly seems out of the norm for what we see. On Fri, Jun 16, 2023 at 11:34:25PM +0200, Ola Lundqvist wrote: > Hi > > I'm triaging the package "renderdoc" and it has three open CVEs. More > information about the CVEs are available here with a good description. > https://www.openwall.com/lists/oss-security/2023/06/06/3 > > One of them is clearly a minor issue, but two of them describe the > possibility to execute arbitrate code for a remote attacker as the > user running the software. So that is rather severe. It is only during > the time the person in question run this software and since it is a > debugger it is likely not that common. > Based on the description in that post, the exploitation is rather complex. However, it appears that there is no way for the user to configure the software to stop the bad behavior, so the options for a workaround are very limited to non-existent. > >From the popularity statistics it does not look to be very popular. > > When looking through the patches they will definitely not apply to the > version in buster. To fix the problems at hand someone need to look > through the code with the spirit of the one fixing this and do similar > changes. The code has changed significantly so this is a non-trivial > task. Doable, but will probably take quite some time and effort. > I took a quick look at just one of the relevant upstream commits (in comparison to what is in bullseye) and I agree that a backport is essentially out of the question. Going back even further to buster would be even more difficult. It doesn't help that upstream continues the 1.x branch to be one continuous line of development. So, it seems likely that upstream would have any interest in helping backport the fixes that far into the past. That said, I also looked at the rdeps for all of the binary packages produced by src:renderdoc and it seems like there are no rdeps from other source packages. To my mind, that opens the door to synchronize buster (and presumably bullseye) with a newer upstream release. Looking at the build-depends of renderdoc in sid/trixie/bookworm, it appears that a direct backport to buster will require a bit of work (either to make it work an older gslang, or to backport a newer gslang to buster, though I did not look to see what the potential ramifications of that are). > My conclusion is that the severity is likely high (if the problem > description is correct) if someone can exploit the issues. But the > cost of fixing is quite high, and the likelihood of someone actually > using this software is very low. I mean someone need to use this > debugger on a completely unprotected machine (n public network) where > someone happen to scan for this specific port that only this software > happen to use. It is public information that this vulnerability exists > but since hardly anyone use it I guess such scanners are rare, if even > existing. > > So what do you think? Should I add this package to dla-needed, or what > do you other think? > My opinion is that the package should be added to dla-needed.txt with a note linking to this thread on the mailing list. > If we only follow the regular rules, we should add it do dla-needed, > but should we also the cost aspect for such a rarely used software > component? > > It has not been triaged for bullseye yet. > There should also be a note there to consider backporting a new upstream release once the security team decides what to do for bookworm and bullseye. It may be that the security team decides to bring the latest upstream (1.27) into sid/trixie/bookworm/bullseye, or that they elect to backport the relevant fixes to the version in bookworm (1.24). We wouldn't want to jump on 1.27 for buster only to end up with a higher version in buster than in bullseye. It might be good for whoever claims renderdoc in dla-needed.txt to make an attempt at backporting the commits to 1.24 and then reach out to the security team with assessment (e.g., "yes, backporting is probably going 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
The state of fix for CVE-2019-8457 (especially as concerns db5.3)
Hello Everyone, I have been (re-)investigating CVE-2019-8457 (previously investigated by Jonas [0] and Ola [1]). I am including the Security Team in the CC as the state of this CVE related to db5.3 in stable/testing/unstable is part of the discussion. In my investigation of this CVE, I came to concur with the initial triage decisions made by Salvatore (04f9f1dd86d6) and Markus (aed48caf3603) marking the issue as no-dsa/minor for db5.3 in bullseye, buster, and stretch. However, it seems that in #1010974 the CVE was identified as fixed in db5.3/5.3.28+dfsg1-0.9. Yet, when I investigated the corresponding Debian source package, it seems that the fix was misapplied. First, it seems that the sqlite code is embedded in db5.3 *twice*. It appears once as a properly structured source tree under lang/sql/sqlite. It also appears again with what appears to be all of the sqlite3 code merged into a single source file at lang/sql/generated/sqlite3.c. The version of sqlite3 which is embedded (in both instances) is ancient, being version 3.7.6.2. For reference, the upstream version of sqlite that jessie shipped with was 3.8.7.1. When the CVE-2019-8457 patch was added to db5.3/5.3.28+dfsg1-0.9, the file that was patched was lang/sql/sqlite/ext/rtree/rtree.c (based on the original patch from sqlite3 patching the file ext/rtree/rtree.c). However, in reviewing a recent buildd log [2] I am unable to find any evidence that the file ext/rtree/rtree.c is ever actually built. The file lang/sql/generated/sqlite3.c, however, is built but it is never patched. In fact, the patch which was applied to lang/sql/sqlite/ext/rtree/rtree.c to supposedly to fix CVE-2019-8457 will not compile. One way to know this is that the patch adds calls to the function sqlite3_str_appendf(), which appears nowhere in the code base apart from the CVE-2019-8457 patch file. Jonas' original observation that this patch requires major backporting work to be functional on older versions of sqlite3 would imply that this patch is actually broken/ineffective. Additionally, as obseved by Jonas in his initial investigation, the affected function does not seem to be referenced anywhere at all in any Debian code. Based on the above, I recommend the following actions to the Security Team: - remove the db5.3/5.3.28+dfsg1-0.9 fix-version from #1010974 - re-triage CVE-2019-8457 (for db5.3 in bullseye) as: (vulnerable code is present but unused in Debian, and fix is too risky to backport) The remainder of the discussion below here is specific to LTS/ELTS and the Security Team can safely ignore what follows. Based on the above findings, I have updated the triage of CVE-2019-8457 as follows: diff --git a/data/CVE/list b/data/CVE/list index b67a819a..e029bf25 100644 --- a/data/CVE/list +++ b/data/CVE/list @@ -298717,11 +298717,11 @@ CVE-2019-8458 (Check Point Endpoint Security Client for Windows, with Anti-Malwa CVE-2019-8457 (SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-o ...) - db5.3 5.3.28+dfsg1-0.9 (bug #1010974) [bullseye] - db5.3 (Minor issue) - [buster] - db5.3 (Minor issue) - [stretch] - db5.3 (Minor issue) + [buster] - db5.3 (vulnerable code is present but unused in Debian, and fix is too risky to backport) + [stretch] - db5.3 (vulnerable code is present but unused in Debian, and fix is too risky to backport) - sqlite3 3.27.2-3 (bug #929775) - [stretch] - sqlite3 (Minor issue; can be fixed via point release) - [jessie] - sqlite3 (Minor issue) + [stretch] - sqlite3 (vulnerable code is present but unused in Debian, and fix is too risky to backport) + [jessie] - sqlite3 (vulnerable code is present but unused in Debian, and fix is too risky to backport) - sqlite (rtree extension not present in v2) NOTE: Fixed by: https://www.sqlite.org/src/info/90acdbfce9c08858 NOTE: Make the internal dynamic string interface available to extensions: diff --git a/data/CVE-EXTENDED-LTS/list b/data/CVE-EXTENDED-LTS/list index a7cfc5813f..f6f0e19617 100644 --- a/data/CVE-EXTENDED-LTS/list +++ b/data/CVE-EXTENDED-LTS/list @@ -3624,7 +3624,7 @@ CVE-2019-8428 CVE-2019-8429 [wheezy] - zoneminder CVE-2019-8457 - [jessie] - db5.3 (Minor issue) + [jessie] - db5.3 (vulnerable code is present but unused in Debian, and fix is too risky to backport) CVE-2019-8842 [wheezy] - cups CVE-2019-8904 If anyone has any objections or comments, please speak up. Regards, -Roberto [0] https://lists.debian.org/debian-lts/2019/06/msg00013.html [1] https://lists.debian.org/debian-lts/2019/06/msg00036.html [2] https://buildd.debian.org/status/fetch.php?pkg=db5.3&arch=amd64&ver=5.3.28%2Bdfsg2-1&stamp=1674044225&raw=0 -- Roberto C. Sánchez
Re: CVE-2023-25690: Apache2 mod_proxy for old(old)stable?
On Thu, Apr 20, 2023 at 07:24:39PM +, roucaries bastien wrote: > Hi Philipp, > > I am working hard to reproduce the CVE and close on for good. I have a > regression test for this near ready. > > They are also some regression by applying this patch to perfectly > correct configuration what will be now rejected. > > I am asking the opinion of apache maintainer/security team before releasing. > > Thanks for remainder > > Bastien > Hi Philipp, To clarify, Bastien is working on a fix for CVE-2023-25690 for *both* buster and stretch. Regards, -Roberto -- Roberto C. Sánchez
Re: PostgreSQL 11.19-0+deb10u1
Hi Christoph! On Fri, Feb 10, 2023 at 11:41:56AM +0100, Christoph Berg wrote: > Hi, > > I just uploaded postgresql-11_11.19-0+deb10u1 to buster-security. If > someone could pick that up for the paperwork part, that would be nice. > Thanks for doing the upload. I'll take care of the paperwork just now. Regards, -Roberto -- Roberto C. Sánchez
Discussion of proposed "Package Owner" role for LTS/ELTS
Greetings Team, One of the agenda items for the LTS meeting on IRC this week is a discussion of the "Package Owner" proposal. Essentially, this is a new role being proposed to help improve the outcomes of LTS/ELTS work on packages which could benefit from more direct attention be a particular individual or team and the continuity that comes with that. Attached to this email is a preliminary write up of the proposed role. If you have questions or feedback, please bring them to the IRC meeting or share them via a reply to this mail. Regards, -Roberto -- Roberto C. Sánchez The "Package Owner" Role What Is It? --- One of the challenges with ensuring the packages receive increased attention is overcoming the natural tendency within a group to assume that "someone else will take care of it". It has been observed that at times packages will languish in dla-needed.txt or ela-needed.txt, requiring FD to issue calls for "someone" to step in and handle a package. Sometimes this works and sometimes not. The role of "Package Owner" is proposed as a way to overcome the "someone else will take care of it" problem by ensuring that selected packages have a designated owner or owners. It is also expected to help create a degree of continuity such that the owner or owners are aware of ongoing issues and special considerations related to a particular package. The closest analog to the proposed "Package Owner" role is that of "maintainer" of a package in Debian. The maintainer can be a single individual, more than one individual working together loosely, or a more formally organized time. The "Package Owner" role in LTS/ELTS would function in a very similar way. However, because of the scope of work done in LTS/ELTS the "Package Owner" does not have the same degree of authority and autonomy when it comes to matters outside the scope of LTS/ELTS security work. For instance, a "Package Owner" would not be permitted 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 is supported in both LTS and ELTS) will rest with the same individual or group. Additionally, in some instances it may make sense to group packages together and treat them as a single entity for the purposes of ownership, such as postgresql-*, openjdk-*, etc. There may be instances where being a paid contributor alone is insufficient, for example, if the owner of a particular package requires access to non-public information (specific customer details, security embargoes, etc.). These special situations will be addressed as they are encountered. How Will Owners Be Assigned? Once a package is identified as being in need of an owner, a coordinator or manager will reach out to one or more individuals, or to the contributor group as a whole (depending on the package or packages in question), and make an invitation to take on a package as its owner. Additionally, if a contributor is aware of a package which in their estimation would benefit from having an owner, they are welcome to raise the matter with a coordinator or manager for consideration. Benefits and Drawbacks -- The proposed ownership model has some benefits as well as some drawbacks. The benefits include: * Continuity of knowledge concerning the history of a package * Improved ability to leverage external/additional resources as appropriate * Reduced incidence of packages being "forgotten" and of problematic updates (i.e., those resulting in regressions) * The potential to leverage external help to free up internal contributor time for other tasks * Improved efficiency That said, there are some potential drawbacks as well: * Perception that only the "owner(s)" can work on a particular package * Packages getting stuck when the "owner(s)" are not able to attend to them promptly Note that the "Package Owner" proposal is not meant to be a complete solution to every issue with updating LTS and ELTS packages. Rather, this is intended as a low friction approach to improving outcomes without creating a great of additional bureaucracy. In particular, this seeks to leverage the excellent work which individual contributors perform by further empowering them in specific ways pertaining to specific packages. Suggestions for improvement are most certainly welcome. Expectations and Responsibilities - The "Package Owner" concept brings with it some expectations and responsibilities. On the one hand, management (managers, coordinators, and front d
Re: EOL candidates for security-support-ended.deb10
On Wed, Aug 03, 2022 at 11:54:28AM +0200, Sylvain Beucler wrote: > Hi, > > I think the following stretch EOL entries also apply to buster, because the > rationale still applies to the buster versions: > - ckeditor3 https://lists.debian.org/debian-lts/2022/05/msg00060.html > - gpac https://lists.debian.org/debian-lts/2022/04/msg8.html > - libspring-java https://lists.debian.org/debian-lts/2021/12/msg8.html > I concur with gpac. I had recommended to the Security Team [0] that they EOL for buster and bullseye when we EOL'd for stretch. Regards, -Roberto [0] https://lists.debian.org/debian-lts/2022/05/msg00043.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Re: Help with imagemagick tests / build
On Mon, Jul 04, 2022 at 02:23:37PM +0200, Andreas Rönnquist wrote:
> On Sun, 3 Jul 2022 17:59:53 -0400
> Roberto C. Sánchez wrote:
>
> >On Sat, Jul 02, 2022 at 01:30:26AM +0200, Andreas Rönnquist wrote:
> >> Hello -
> >>
> >> I have updated the imagemagick package in LTS, with fixes for some
> >> CVE's, but then it doesn't build properly on the buildd - some tests
> >> fail on the XBM format -
> >>
> >> The frustrating thing is that it builds just fine locally, both on
> >> amd64 and on i386, but on the buildd it has built finally on amd64 (on
> >> the third try, but on i386 it has done 5 without succeeding). [1]
> >>
> >> And I do not believe it is my changes that does it - it has failed
> >> similarly on earlier versions, but there it hasn't required as many
> >> rebuilds to succeed, so I don't believe that my changes are the cause -
> >> the test failures on the version before the one I uploaded are identical.
> >>
> >> I ask here for help now, after asking on the imagemagick mailinglist
> >> [2] without a reply for some time - so I am getting out of options -
> >>
> >> Help would be very much appreciated.
> >>
> >Hi Andreas,
> >
> >I have looked at your patches for ImageMagick 8:6.9.7.4+dfsg-11+deb9u14
> >and it appears that the patch for CVE-2021-3596 may have an error in the
> >way it was backported.
> >
> >After the commit in question (27f314e2e6), the upstream code has this
> >structure starting at line 3605:
> >
> >if (n > 0)
> > {
> >...
> > }
> >if (svg_info->parser == (xmlParserCtxtPtr) NULL)
> > {
> >...
> > }
> >
> >However, your patch puts the second if statement within the scope of the
> >first, like this:
> >
> >if (n > 0)
> > {
> >...
> >if (svg_info->parser == (xmlParserCtxtPtr) NULL)
> > {
> > ...
> > }
> > }
> >
> >I suspect that may have something to do with the test failures you are
> >observing. It may be necessary to correct the patch and upload again.
> >
>
>
> Oh - you are right - that is indeed a mistake from my side. I will fix
> this and re-upload - however, the version before my upload shows similar
> build errors (even if it managed to build that one on all arches after
> some tries), so I have a slight suspicion that it will fail again, but
> well see - Let's hope for the best!
>
My thought on why it could be related is because there are conditions in
which the backported patch would not free the associated resources.
That seemed like it could be the root cause of the test failure.
> Thank you very much for the help!
>
Certainly and any time!
Note that stretch-security is closed to new uploads. So, you will need
to publish any update by targeting stretch in ELTS.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: Help with imagemagick tests / build
On Sat, Jul 02, 2022 at 01:30:26AM +0200, Andreas Rönnquist wrote:
> Hello -
>
> I have updated the imagemagick package in LTS, with fixes for some
> CVE's, but then it doesn't build properly on the buildd - some tests
> fail on the XBM format -
>
> The frustrating thing is that it builds just fine locally, both on
> amd64 and on i386, but on the buildd it has built finally on amd64 (on
> the third try, but on i386 it has done 5 without succeeding). [1]
>
> And I do not believe it is my changes that does it - it has failed
> similarly on earlier versions, but there it hasn't required as many
> rebuilds to succeed, so I don't believe that my changes are the cause -
> the test failures on the version before the one I uploaded are identical.
>
> I ask here for help now, after asking on the imagemagick mailinglist
> [2] without a reply for some time - so I am getting out of options -
>
> Help would be very much appreciated.
>
Hi Andreas,
I have looked at your patches for ImageMagick 8:6.9.7.4+dfsg-11+deb9u14
and it appears that the patch for CVE-2021-3596 may have an error in the
way it was backported.
After the commit in question (27f314e2e6), the upstream code has this
structure starting at line 3605:
if (n > 0)
{
...
}
if (svg_info->parser == (xmlParserCtxtPtr) NULL)
{
...
}
However, your patch puts the second if statement within the scope of the
first, like this:
if (n > 0)
{
...
if (svg_info->parser == (xmlParserCtxtPtr) NULL)
{
...
}
}
I suspect that may have something to do with the test failures you are
observing. It may be necessary to correct the patch and upload again.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: How to interpret packages-to-support
On Fri, May 20, 2022 at 11:09:47PM +0200, Ola Lundqvist wrote: > Hi LTS team > > I looked at nvidia-graphics-drivers-legacy-340xx who have two CVEs. I > can see that this package is not in "packages-to-support" for LTS. But > I can see that nvidia-graphics-drivers is. > I'm not sure how to interpret this. Do the entry in > packages-to-support mean that all nvidia-graphics-drivers packages > should be supported or just the specific one listed. > > Anyone know this? > Hi Ola, I encountered this some time back when I was doing FD work. My recollection of Raphael's guidance is that packages-to-support really only applies for ELTS (where sponsors decide which specific packages they will pay to support). For LTS, we support all packages except those which the Security Team had previously decided to drop and those which the LTS Team has decided to drop. The LTS triage script retrieves the current list from debian-security-support package, so it should point out which packages are EOL or have limited security support. All other packages are supported as usual. Regards, -Roberto -- Roberto C. Sánchez
What is going on with debian-security-support in stretch?
Hi all, I've not looked at the debian-security-support project in some time and just now looking it for gpac EOL I've noticed that it seems very outdated on stretch. Currently the version of debian-security-support in stretch is 1:9+2021.01.23. The last entry in security-support-ended.deb9 when installing the package on stretch is to drop support for reel on 2021-01-22. Since that release there has been a single commit on the stretch branch for dropping support for keystone. However, it has not been released. Then looking at security-support-ended.deb9 on the master branch, after reel there have been further entries added to drop support for keystone, libspring-java, guacamole-client and gpac (which I just committed a little while ago). It is not clear what the procedure is for ensuring that the package stays updated in stretch. I think Holger was managing that in the past, but it seems to have been somewhat forgotten. It seems like it would be good to bring the stretch branch of debian-security-support up to date to provide an accurate picture of the packages that no longer have security support and then to build and upload. Then the upload should be followed by a DLA (example [0]). If there are no objections, I will go ahead and do this in two or three days. If anyone has any comments or feedback, those would be welcome. Regards, -Roberto [0] https://lists.debian.org/debian-lts-announce/2020/02/msg00011.html -- Roberto C. Sánchez
gpac end-of-life in stretch (and recommendation for buster/bullseye)
LTS and Security Teams, Based on previous discussion [0], I have marked gpac as end-of-life for stretch in commit 0a6147d6b8 of debian-security-support [1]. It seems advisable that the Security Team do the same for gpac in buster and bullseye. Regards, -Roberto [0] https://lists.debian.org/debian-lts/2022/04/msg8.html [1] https://salsa.debian.org/debian/debian-security-support/-/commit/0a6147d6b88d7c19ee7c072a344bbb63a7b1f32c -- Roberto C. Sánchez
Re: How to handle gpac?
Thanks to those who responded. I will go ahead and start working with the security team on declaring gpac EOL. Regards, -Roberto On Thu, Apr 14, 2022 at 11:11:52AM -0400, Roberto C. Sánchez wrote: > Hello everyone, > > I've been working on gpac vulnerabilities. The situation has reached a > point where it seemed wise to seek some input from other folks in the > LTS community before continuing. With this message I am specifically > seeking to start a discussion about the best way forward. > > First, some context from the PTS [0]. > > Versions present in Debian: > > bookworm (and unstable): 2.0.0+dfsg1-2 > bullseye: 1.0.1+dfsg1-4+deb11u1 > buster: 0.5.2-426-gc5ad4e4+dfsg5-5 > stretch: 0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1 > > Open security issues: > > bookworm: 4 > bullseye: 100 > buster: 124 > stretch: 126 > > Most of the open vulnerabilities are tagged either or > with the note "Minor issue". If there were only a small handful, it > might make sense to not worry about them. However, given the sheer > number and the fact that new vulnerabilities are being reported > regularly, leaving things as is does not appear to be a sensible choice. > > As the buster and stretch versions are the same I am working on updating > both at the same time (coordinated with the security team). I've > managed to integrate fixes for about 35 of the open CVEs. I've also > been able to identify that several do not actually affect the buster and > stretch versions of gpac. I have also encountered now two issues where > the proof of concept in the upstream GitHub issue produces a failure, > but not the precise one described by the upstream report and > subsequently assigned CVE. It seems likely that there is at least one > significant vulnerability affecting the older buster/stretch gpac that > hasn't been discovered/reported upstream. I have what seems like a > possible fix for that issue, but it isn't entirely clear that it is the > right approach (I would seek assistance from upstream on that particualr > point). > > The other concern that I have is that as I move into the more recently > reported vulnerabilities, which are necessarily fixed in later versions > by upstream, applying the patches becomes progressivley more > challenging. There are still somewhere around 75 vulnerabilities left > to deal with, which is concerning. > > The specific paths forward that I see include: > > > > 1. continue plodding through the vulnerabilities and upstream patches, > trying to make all the patches work (as noted, this is becoming > increasingly difficult because the newer fixes are made in code that is > vastly different from what is present in buster/stretch) > > 2. drop gpac from stretch LTS support (and buster LTS when it reaches > that stage) > > 3. update the gpac package in one of the following ways: > > 3a. apply fixes to the 100 open issues in the bullseye version > (1.0.1+dfsg1-4+deb11u1) and then backport that to buster and stretch > (either now in coordination with the security team, or later once buster > is LTS); I considered this possibility because the fixes are most likely > more straightforward to apply given the smaller delta betweeen upstream > releases involved > > 3b. backport the bookwork version (2.0.0+dfsg1-2) to bullseye, buster, > and stretch (definitely must be coordinated with the security team) > > 4. don't bother with trying to patch all the vulnerabilities > > > > My concern with trying to continue along the current path (#1) is that > it seems like it will be nearly impossible to properly test this many > patches. Something is bound to break and the amount of testing required > to ensure no breakage or minimal breakage seems very large. > > Dropping support for gpac (#2) or updating (#3) it does have some > additional consequences, as it is not a leaf package. The first package > that would be affected by a significant change to gpac is x264. It has > a build-depends on libgpac-dev and at least one of its binary packages > subsequently depends on the associated libgpac runtime library. > > The second affected package is ccextractor. Starting in bookworm, > ccextractor build depends on libgpac-dev, but its binary package has no > installation dependencies on any gpac binary packages. It would require > a little bit of investigation to determine the specific effect that a > major gpac update would have on it. > > I would very much appreciate feedback/comments/suggestions/etc from > anyone who would like to contribute to the discussion. I am certain > that I have missed things, so feel free to point out any gaps in my > summary/analysis and of course, any suggestions for other possible > solutions I overlooked would be very much appreciated. > > Regards, > > -Roberto > > [0] https://tracker.debian.org/pkg/gpac > > -- > Roberto C. Sánchez -- Roberto C. Sánchez
How to handle gpac?
Hello everyone, I've been working on gpac vulnerabilities. The situation has reached a point where it seemed wise to seek some input from other folks in the LTS community before continuing. With this message I am specifically seeking to start a discussion about the best way forward. First, some context from the PTS [0]. Versions present in Debian: bookworm (and unstable): 2.0.0+dfsg1-2 bullseye: 1.0.1+dfsg1-4+deb11u1 buster: 0.5.2-426-gc5ad4e4+dfsg5-5 stretch: 0.5.2-426-gc5ad4e4+dfsg5-3+deb9u1 Open security issues: bookworm: 4 bullseye: 100 buster: 124 stretch: 126 Most of the open vulnerabilities are tagged either or with the note "Minor issue". If there were only a small handful, it might make sense to not worry about them. However, given the sheer number and the fact that new vulnerabilities are being reported regularly, leaving things as is does not appear to be a sensible choice. As the buster and stretch versions are the same I am working on updating both at the same time (coordinated with the security team). I've managed to integrate fixes for about 35 of the open CVEs. I've also been able to identify that several do not actually affect the buster and stretch versions of gpac. I have also encountered now two issues where the proof of concept in the upstream GitHub issue produces a failure, but not the precise one described by the upstream report and subsequently assigned CVE. It seems likely that there is at least one significant vulnerability affecting the older buster/stretch gpac that hasn't been discovered/reported upstream. I have what seems like a possible fix for that issue, but it isn't entirely clear that it is the right approach (I would seek assistance from upstream on that particualr point). The other concern that I have is that as I move into the more recently reported vulnerabilities, which are necessarily fixed in later versions by upstream, applying the patches becomes progressivley more challenging. There are still somewhere around 75 vulnerabilities left to deal with, which is concerning. The specific paths forward that I see include: 1. continue plodding through the vulnerabilities and upstream patches, trying to make all the patches work (as noted, this is becoming increasingly difficult because the newer fixes are made in code that is vastly different from what is present in buster/stretch) 2. drop gpac from stretch LTS support (and buster LTS when it reaches that stage) 3. update the gpac package in one of the following ways: 3a. apply fixes to the 100 open issues in the bullseye version (1.0.1+dfsg1-4+deb11u1) and then backport that to buster and stretch (either now in coordination with the security team, or later once buster is LTS); I considered this possibility because the fixes are most likely more straightforward to apply given the smaller delta betweeen upstream releases involved 3b. backport the bookwork version (2.0.0+dfsg1-2) to bullseye, buster, and stretch (definitely must be coordinated with the security team) 4. don't bother with trying to patch all the vulnerabilities My concern with trying to continue along the current path (#1) is that it seems like it will be nearly impossible to properly test this many patches. Something is bound to break and the amount of testing required to ensure no breakage or minimal breakage seems very large. Dropping support for gpac (#2) or updating (#3) it does have some additional consequences, as it is not a leaf package. The first package that would be affected by a significant change to gpac is x264. It has a build-depends on libgpac-dev and at least one of its binary packages subsequently depends on the associated libgpac runtime library. The second affected package is ccextractor. Starting in bookworm, ccextractor build depends on libgpac-dev, but its binary package has no installation dependencies on any gpac binary packages. It would require a little bit of investigation to determine the specific effect that a major gpac update would have on it. I would very much appreciate feedback/comments/suggestions/etc from anyone who would like to contribute to the discussion. I am certain that I have missed things, so feel free to point out any gaps in my summary/analysis and of course, any suggestions for other possible solutions I overlooked would be very much appreciated. Regards, -Roberto [0] https://tracker.debian.org/pkg/gpac -- Roberto C. Sánchez
Re: Propose to ignore libxstream-java CVEs
On Thu, Sep 23, 2021 at 05:03:46PM +0200, Markus Koschany wrote: > > You are right that all applications will break which rely on the > deserialization feature of xstream and were not using a whitelist before. > Everything else that just writes a POJO to XML should be unaffected. In > general > we won't be able to support every custom user application that links to a > system library but there is a simple workaround for this problem because you > can override the permissions and even return back to a blacklist. > > So that leaves us with all the dependencies of libxstream-java in Debian. I > don't see any major regressions by this switch but indeed deserialization > without properly initializing xstream will no longer work. libjsap-java has an > optional feature to read configuration parameters from an xml file (jsap > files) > but it still works in normal mode. It should be possible to override > JSAPConfig > but I will file a bug report anyway because this version is from 2006 and it > does not look like it is maintained upstream. > > Quote from upstream: > > "The key message for application developers is that deserializing arbitrary > user-supplied content is a dangerous proposition in all cases." > > "A blacklist for special classes only creates therefore a scenario for a false > security, because no-one can assure, that no other vulnerability is found" > > I agree with him and I believe it is better to use the whitelist instead of > relying on the blacklist. The alternative is to continue with the blacklist > until bullseye is EOL. > I am also in agreement with upstream on this. There is merit in the principle underlying Debian stable releases of not changing interfaces, behaviors, etc. However, this seems like one of those cases where as the world has changed, a condition/approach which might have once been considered "not that bad" (I won't call it "good" because the blacklist approach has essentially never been considered a good one) or adequate, is now in a changed environment much less suitable, to the point of essentially being harmful. The bullseye EOL is far enough into the future that it seems like trying to hang on to the current approach for that long is going to become increasingly problematic. I imagine that upstream support for security vulnerabilities associated with the old approach will either be significantly reduced or just not even there. It seems sensible to make the change now, rather than later after enduring lots more pain trying to hang on to the current approach. Regards, -Roberto -- Roberto C. Sánchez
Re: Tracking related source packages (new tool)
On Mon, Aug 30, 2021 at 10:57:59AM +0200, Sylvain Beucler wrote: > Hi Roberto, > > Thanks for your thorough review :) > I answer a couple comments below: > > On 29/08/2021 05:08, Roberto C. Sánchez wrote: > > On Sat, Aug 28, 2021 at 08:30:56PM +0200, Sylvain Beucler wrote: > > > Here are a few use cases: > > > > > > ... > > > > > # Also report CVE entries that may have been missed for newly branched > > > packages in Debian (e.g. the golang-1.xx set) > > > $ bin/related-cves.py --transitions data/renamed-packages --report > > > --two-way > > > > > This produced much more output, much of which I am not sure would be > > especially useful. Perhaps the security team, dealing with oldstable > > through unstable might benefit from it, though. The year threshold you > > mentioned seems to be useful here, if I understand it correctly. > > Indeed --two-way would be less suitable for 'renamed-packages' (where the > most recent package is canonical and need not be updated with older > entries), but could be more interesting for e.g. a 'forked-packages' (like > qemu/kvm in the past, or golang-1.xx which regularly gets newer versions > that need to be checked). > Ah yes, that makes sense. > We may not use this option daily but I found it useful to experiment, hence > it made a good addition to this toolbox. > Of course. I was not meaning to imply that it shouldn't be there. I was just a bit surprised by how much additional output it produced. > > > It appears that if the data/CVE/list split is implemented that this > > would be another tool that requires updating to deal with the new > > architecture. I wonder if it makes sense to proceed with implementing a > > "list of filenames" that the script operates upon for each parameter > > (e.g., CVE, DSA, DLA, etc.) in order to be ready for the coming change. > > The tool uses the sectracker.parsers interface from lib/ exclusively. Should > the security-tracker architecture changes, I think the interface could be > updated to transparently parse and save a set of split-files (data/CVE/list > -> data/CVE/list.*) without changing the tool itself. > OK. The specific thing that caught my attention with respect to this was the invocation of the Packages2CVEs constructor, which references os.path.dirname(__file__)+'/../data/CVE/list'. But as you are the author, you are in a bettern position to know if architecture is flexible in this regard. Thanks again for the added explanations. Regards, -Roberto -- Roberto C. Sánchez
Re: Tracking related source packages (new tool)
Hi Sylvain,
I have spent some time looking over your code and trying out the tool.
Overall, the code looks good, easy to understand, and useful in
functionality.
On Sat, Aug 28, 2021 at 08:30:56PM +0200, Sylvain Beucler wrote:
>
> Here are a few use cases:
>
> # Report CVE entries that may have been missed for old renamed packages in
> Debian
> $ bin/related-cves.py --transitions data/renamed-packages --report
>
This seems to produce useful output. I looked at some of the reported
findings for lua5.3 and it seems like the CVEs either apply, or or are
close enough that it would make sense to explicitly mark them
.
> # Also report CVE entries that may have been missed for newly branched
> packages in Debian (e.g. the golang-1.xx set)
> $ bin/related-cves.py --transitions data/renamed-packages --report --two-way
>
This produced much more output, much of which I am not sure would be
especially useful. Perhaps the security team, dealing with oldstable
through unstable might benefit from it, though. The year threshold you
mentioned seems to be useful here, if I understand it correctly.
> # Automatically add entries renamed packages in ELTS, in the extended CVE
> list file, restricting to supported packages
> # (can complement the script for automated entries)
> $ bin/related-cves.py --transitions data/renamed-packages.elts --extcve
> data/CVE-EXTENDED-LTS/list --extadv data/ELA/list \
> --start-year 2019 \
> $(awk '{print $1}' < ../extended-lts/packages-to-support)
>
> # Check issues that might affect krfb and vino in Debian (due to embedding
> e.g. libvncserver)
> $ bin/related-cves.py --transitions data/embedded-code-copies --format
> embedded-code-copies --report krfb vino
>
> # Check issues that might affect php5 in ELTS (due to embedding various
> libraries)
> bin/related-cves.py --transitions data/embedded-code-copies --extadv
> data/ELA/list --format embedded-code-copies --report php5
>
>
It appears that if the data/CVE/list split is implemented that this
would be another tool that requires updating to deal with the new
architecture. I wonder if it makes sense to proceed with implementing a
"list of filenames" that the script operates upon for each parameter
(e.g., CVE, DSA, DLA, etc.) in order to be ready for the coming change.
Regards,
-Roberto
--
Roberto C. Sánchez
Re: always check and update (d|e)la-needed.txt (Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do))
On Mon, Aug 09, 2021 at 10:52:00AM +, Holger Levsen wrote: > Hi Roberto, > > On Mon, Aug 09, 2021 at 06:38:15AM -0400, Roberto C. Sánchez wrote: > > It was completely my fault. [...] > > Mistakes happen, thank you for owning yours! > > > The update to dla-needed.txt > > and ela-needed.txt did not even cross my mind. > > Mistakes happen. I'm just emphasizing "the wrongdoing" so everybody > learns and in future updating (d|e)la-ndeed.txt will be forgotten > less often! :) > I know I will be extra careful going forward. This especially as in the past I have been quick to become frustrated at others' mistakes. I appreciate the patience you and Emilio have shown toward me. It is very much appreciated. Regards, -Roberto -- Roberto C. Sánchez
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On Mon, Aug 09, 2021 at 10:32:54AM +, Holger Levsen wrote: > On Mon, Aug 09, 2021 at 06:20:43AM -0400, Roberto C. Sánchez wrote: > > On Mon, Aug 09, 2021 at 08:43:34AM +, Holger Levsen wrote: > > > today three packages were unclaimed for LTS: > > > - openjdk-8 (Emilio) > > > > > > and three for ELTS: > > > - openjdk-8 (Emilio) > > > On this past Friday, Raphaël put me in touch with Thorsten Glaser, who > > had already prepared openjdk-8 package for jessie and stretch. I > > reviewed and sponsored the upload, and the packages were literally in > > the process of uploading when I saw this message. I will publish the > > advisories in a few hours, after all the binary packages are built. > > I'm surprised you (nor anyone else) updated dla-needed.txt in the process. > any idea why not? > It was completely my fault. According to Raphaël and Thorsten, Markus was not responding to emails. I assumed that because Raphaël requested someone get in touch with Thorsten, that I should simply contact Thorsten, review the packages, and upload. The update to dla-needed.txt and ela-needed.txt did not even cross my mind. My apologies if I have over-stepped or caused problems with my oversight. Regards, -Roberto -- Roberto C. Sánchez
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On Mon, Aug 09, 2021 at 08:43:34AM +, Holger Levsen wrote: > hi, > > today three packages were unclaimed for LTS: > - nettle (Emilio) > - openjdk-8 (Emilio) > - pillow (codehelp) > > and three for ELTS: > - nettle (Emilio) > - openjdk-7 (Emilio) > - openjdk-8 (Emilio) > > Utkarsh probably claimed too many packages: > - amd64-microcode > - exiv2 > - ruby2.3 > - usermode > On this past Friday, Raphaël put me in touch with Thorsten Glaser, who had already prepared openjdk-8 package for jessie and stretch. I reviewed and sponsored the upload, and the packages were literally in the process of uploading when I saw this message. I will publish the advisories in a few hours, after all the binary packages are built. Regards, -Roberto -- Roberto C. Sánchez
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On Mon, Feb 01, 2021 at 11:32:13AM +, Holger Levsen wrote: > > One DLA has been reserved but not yet been published: > - DLA 2537-1 (31 Jan 2021) (ffmpeg) > It looks like this was just merged/published. > Have a great week! > You too! Regards, -Roberto -- Roberto C. Sánchez
Re: Regression in lxml in buster/stretch
On Fri, Dec 18, 2020 at 10:27:11AM +0100, Emilio Pozuelo Monfort wrote: > On 18/12/2020 00:05, Roberto C. Sánchez wrote: > > Uggh. If only I had waited a few more hours to upload. I have the > > advisory text ready but have not yet published the DLA. Your changes > > for deb9u3 look good. Would you go ahead and upload deb9u3 and I will > > publish the advisory once it is built. > > Done, it's building now (it may take a bit longer than previous builds due > to the newly enabled test suite). I have verified (both through the test > suite and through manual testing of the package) that the module can now be > imported. > Thanks! I have published the DLA to the announcement list and submitted a Salsa MR for the website publication of the advisory. Regards, -Roberto -- Roberto C. Sánchez
Re: Suggestions for handling of condor update
On Fri, Jul 17, 2020 at 07:45:33PM -0500, Tim Theisen wrote: > Hello Roberto, > > I have just returned from a two week canoe camping trip (no electricity, > no internet). I saw this bug report just as I left town. I will be able > to review your work next week. > > I will have bit to catch up on Monday. I will take a look at this after > I catch up. > > Thank you for putting in the time to address this issue. You will hear > from me again next week. > > I should be able to review that the changes are correct and test on the > various distributions. > Hi Tim, This sort of fell off my radar. Is it still possible that you might be able to review the condor updates? Regards, -Roberto -- Roberto C. Sánchez
Re: Regression in lxml in buster/stretch
On Thu, Dec 17, 2020 at 09:10:44PM +0100, Emilio Pozuelo Monfort wrote: > Hi, > > There's a regression in both buster and stretch in the last update of lxml > when running under Python 2: > > >>> import lxml.html.clean > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.7/dist-packages/lxml/html/clean.py", line 73, in > > r' AttributeError: 'module' object has no attribute 'ASCII' > >>> > > The fix is [1]. > > I recently added support to run the tests to lxml (see #976148). When > enabling the test suite, this bug is exposed (tested in stretch, should be > similar in buster): > > python2.7 test.py -vv > Traceback (most recent call last): > File "test.py", line 625, in > exitcode = main(sys.argv) > File "test.py", line 562, in main > test_cases = get_test_cases(test_files, cfg, cov=cov) > File "test.py", line 268, in get_test_cases > module = import_module(file, cfg, cov=cov) > File "test.py", line 209, in import_module > mod = __import__(modname) > File "/build/lxml-3.7.1/src/lxml/html/tests/test_clean.py", line 6, in > > from lxml.html.clean import Cleaner, clean_html > File "/build/lxml-3.7.1/src/lxml/html/clean.py", line 73, in > r' AttributeError: 'module' object has no attribute 'ASCII' > > And with the patch applied, the tests run, although some of the clean tests > are failing, probably because the last patch didn't backport the test suite > changes (which was not a problem as the tests weren't being run). > > Roberto, my changes for stretch are in [3]. Would you like to take a look at > this and finish it (probably backporting the test changes from [2]) or > should I? > Uggh. If only I had waited a few more hours to upload. I have the advisory text ready but have not yet published the DLA. Your changes for deb9u3 look good. Would you go ahead and upload deb9u3 and I will publish the advisory once it is built. Regards, -Roberto -- Roberto C. Sánchez
Re: How to handle an update that includes a regression fix and a new fix?
Thanks Ola and Emilio both for the helpful pointers. Regards, -Roberto On Tue, Dec 15, 2020 at 12:30:17PM +0100, Emilio Pozuelo Monfort wrote: > On 15/12/2020 02:16, Roberto C. Sánchez wrote: > > I am curious if there is a policy or best practice for how to handle a > > package update containing both a regression fix and also a fix for a new > > vulnerability. > > > > If such a thing is not advisable or permissible, then is it best to > > handle the regression as one update and then follow-up with the new > > vulnerability fix as a subsequent update? > > Just one update, and one announcement as a new DLA (-1) mentioning the > regression fix. See e.g. > > https://lists.debian.org/debian-security-announce/2020/msg00139.html > https://lists.debian.org/debian-lts-announce/2019/02/msg00032.html > https://lists.debian.org/debian-lts-announce/2020/06/msg00012.html > -- Roberto C. Sánchez
How to handle an update that includes a regression fix and a new fix?
I am curious if there is a policy or best practice for how to handle a package update containing both a regression fix and also a fix for a new vulnerability. If such a thing is not advisable or permissible, then is it best to handle the regression as one update and then follow-up with the new vulnerability fix as a subsequent update? Regards, -Roberto -- Roberto C. Sánchez
Re: Incomplete fix for CVE-2019-20218/sqlite3
On Thu, Dec 10, 2020 at 08:53:58AM -0500, Roberto C. Sánchez wrote: > On Tue, Dec 08, 2020 at 10:04:13AM -0500, Roberto C. Sánchez wrote: > > Hi Moritz & Chris, > > > > On Tue, Dec 08, 2020 at 02:37:14PM +, Chris Lamb wrote: > > > Hi Moritz, > > > > > > > CVE-2019-20218 isn't fixed in Stretch/LTS. Running the reproducer: > > > > > > > Thanks for reporting this. It seems I overlooked something in my > > update. I should have taken greater care. > > > > > > > > Roberto, can you follow-up on this? > > > > > I have claimed the package in dla-needed.txt. I will get this > > straightened out (including properly confirming that the vulnerability > > is fixed) in the coming days. > > > I have backported the additional commit, tested the fix for > completeness, prepared the updated package and uploaded it. However, > since archive processing is currently suspended pending the resolution > of the recently reported python-apt bug, it will probably wait in the > upload queue until archive processing resumes. Once the ACCEPT message > comes through I will prepare and publish the DLA. I did not see an announcement that archive processing had resumed, but a short while ago I received the ACCEPT message and the package built and was uploaded and installed on all architectures. I went ahead and published the DLA as well. Regards, -Roberto -- Roberto C. Sánchez
Re: Incomplete fix for CVE-2019-20218/sqlite3
On Tue, Dec 08, 2020 at 10:04:13AM -0500, Roberto C. Sánchez wrote: > Hi Moritz & Chris, > > On Tue, Dec 08, 2020 at 02:37:14PM +, Chris Lamb wrote: > > Hi Moritz, > > > > > CVE-2019-20218 isn't fixed in Stretch/LTS. Running the reproducer: > > > > Thanks for reporting this. It seems I overlooked something in my > update. I should have taken greater care. > > > > > Roberto, can you follow-up on this? > > > I have claimed the package in dla-needed.txt. I will get this > straightened out (including properly confirming that the vulnerability > is fixed) in the coming days. > I have backported the additional commit, tested the fix for completeness, prepared the updated package and uploaded it. However, since archive processing is currently suspended pending the resolution of the recently reported python-apt bug, it will probably wait in the upload queue until archive processing resumes. Once the ACCEPT message comes through I will prepare and publish the DLA. Regards, -Roberto -- Roberto C. Sánchez
Re: Incomplete fix for CVE-2019-20218/sqlite3
Hi Moritz & Chris, On Tue, Dec 08, 2020 at 02:37:14PM +, Chris Lamb wrote: > Hi Moritz, > > > CVE-2019-20218 isn't fixed in Stretch/LTS. Running the reproducer: > Thanks for reporting this. It seems I overlooked something in my update. I should have taken greater care. > > Roberto, can you follow-up on this? > I have claimed the package in dla-needed.txt. I will get this straightened out (including properly confirming that the vulnerability is fixed) in the coming days. Regards, -Roberto -- Roberto C. Sánchez
Re: MongoDB license change and security support
On Wed, Nov 25, 2020 at 07:25:57PM +0530, Utkarsh Gupta wrote: > Hello, > > On Wed, Nov 25, 2020 at 2:57 PM Sylvain Beucler wrote: > > Consequently I believe we're not in a position to offer MongoDB security > > support in LTS nor ELTS, and we need to drop it from our supported packages. > > > > What do you think? > > This does make sense. And I suppose the same applies for buster? > I've CCed the Security team to take their opinion as well! > The mongodb package was remove prior to the buster release. As Sylvain pointed out, it is only available in stretch (LTS) and jessie (ELTS). Regards, -Roberto -- Roberto C. Sánchez
Re: MongoDB license change and security support
On Wed, Nov 25, 2020 at 10:27:16AM +0100, Sylvain Beucler wrote: > Hi, > > On 2018-10 MongoDB changed its license from AGPL to SSPL. > https://jira.mongodb.org/browse/SERVER-37651 > > In broad terms, the main change is requiring service providers to make > available the source of not only MongoDB (like AGPL) but also of other parts > of their service. > > The SSPL was generally considered incompatible with the DFSG: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537 > and the package was removed from unstable in 2020-02: > https://tracker.debian.org/news/1104058/removed-13418-2-from-unstable/ > so it's only available in stretch-lts (3.2) and jessie-elts (2.4) now. > > The development repository has multiple branches: > - 3.4: stayed AGPL but EOL'd in early 2020, > - 3.6 and later: all switched to SSPL in 2018-10 > > This means that when backporting new upstream security fixes: > - we're introducing DFSG-incompatible code in Debian main > - we're violating MongoDB's license by combining incompatible licenses > > (something we may have overlooked in DLA-2344-1) > The functional part of the upstream patch which I integrated in that update was quite small: 2 files changed, 7 insertions(+), 1 deletion(-) That said, I can definitely see how that decision could be considered questionable. > Moreover, the database engine code is complex, so patches cannot reasonably > be rewritten by non-specialists. This is very much correct. Additionally, since the versions in jessie and stretch are EOL upstream and the more recent development branches have diverged considerably from the older releases. Even assessing whether a particular vulnerability is present or whether a given patch addresses the vulnerability could prove quite challenging. > They are also large enough to be covered by copyright. > This is likely to be the case for any significant patch. > Consequently I believe we're not in a position to offer MongoDB security > support in LTS nor ELTS, and we need to drop it from our supported packages. > One other thing to note is that MongoDB supplies upstream-produced packages for all major distros for all supported versions of the MongoDB server. I find it unlikely that many of the users with the "mongodb" package installed from Debian sources are really using it in a way that warrants the amount of effort that is likely to be required to continue support. To be clear, my vote would be to drop support. Regards, -Roberto -- Roberto C. Sánchez
Re: samba backport from stable/testing to oldstable.
On Tue, Nov 10, 2020 at 12:30:42PM +0530, Jaikumar Sharma wrote: > > oldstable (aka stretch) is now EOL'ed and has gone into the hands of > > the LTS team. > > Well, the good news is that Roberto (CC'ed here) is working on the > > samba update to fix those vulnerabilities in stretch and I think it > > should be rolled out really soon! > Great, Thanks a lot Utkarsh for quick info. :) > Regards, > Jaikumar Utkarsh is correct. I am actively working on the update. I hope to have it completed and ready for upload this week. Regards, -Roberto -- Roberto C. Sánchez
Re: Request for patch review (brotli)
On Sun, Oct 25, 2020 at 02:04:30PM -0400, Roberto C. Sánchez wrote: > Hi fellow LTS folks, > > I am working on the update for brotli as it relates to CVE-2020-8927. > The upstream Git project contains a commit [0] which fixes the issue > along with several other issues in the same commit. However, there does > not appear to be any available information regarding the specifics of > the vulnerability nor is there a PoC that can be used to validate the > fix. There also appears to be no prior iteration of the PR which > contains the changes in separate commits. > > That said, I have done my best to exclude the parts of the upstream > commit that do not appear related to CVE-2020-8927 and then to backport > the remainder to brotli as it exists in stretch. I would like it if > someone else could review the attached patch, comparing it to the > upstream commit, and provide feedback on the completeness of the patch. > > Please make sure to follow-up with a reply to the list before reviewing > so that there is not duplicate work on this. > Since two weeks have elapsed since I made my request, I intend to upload the brotli package within the next 24 hours. Regards, -Roberto -- Roberto C. Sánchez
Request for patch review (brotli)
Hi fellow LTS folks,
I am working on the update for brotli as it relates to CVE-2020-8927.
The upstream Git project contains a commit [0] which fixes the issue
along with several other issues in the same commit. However, there does
not appear to be any available information regarding the specifics of
the vulnerability nor is there a PoC that can be used to validate the
fix. There also appears to be no prior iteration of the PR which
contains the changes in separate commits.
That said, I have done my best to exclude the parts of the upstream
commit that do not appear related to CVE-2020-8927 and then to backport
the remainder to brotli as it exists in stretch. I would like it if
someone else could review the attached patch, comparing it to the
upstream commit, and provide feedback on the completeness of the patch.
Please make sure to follow-up with a reply to the list before reviewing
so that there is not duplicate work on this.
Regards,
-Roberto
[0]
https://github.com/google/brotli/commit/223d80cfbec8fd346e32906c732c8ede21f0cea6
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
>From 223d80cfbec8fd346e32906c732c8ede21f0cea6 Mon Sep 17 00:00:00 2001
From: Eugene Kliuchnikov
Date: Wed, 26 Aug 2020 12:32:27 +0200
Subject: [PATCH] Update (#826)
* IMPORTANT: decoder: fix potential overflow when input chunk is >2GiB
[rcs: backport; also note that the upstream PR has many additional changes which were excluded from backporting]
---
common/constants.c | 15 +++
common/constants.h | 18 ++
dec/bit_reader.c | 11 +++
dec/bit_reader.h | 19 +++
dec/decode.c |9 +
dec/prefix.h | 18 --
setup.py |1 +
7 files changed, 57 insertions(+), 34 deletions(-)
--- a/dec/bit_reader.c
+++ b/dec/bit_reader.c
@@ -15,6 +15,17 @@
extern "C" {
#endif
+const uint32_t kBrotliBitMask[33] = { 0x,
+0x0001, 0x0003, 0x0007, 0x000F,
+0x001F, 0x003F, 0x007F, 0x00FF,
+0x01FF, 0x03FF, 0x07FF, 0x0FFF,
+0x1FFF, 0x3FFF, 0x7FFF, 0x,
+0x0001, 0x0003, 0x0007, 0x000F,
+0x001F, 0x003F, 0x007F, 0x00FF,
+0x01FF, 0x03FF, 0x07FF, 0x0FFF,
+0x1FFF, 0x3FFF, 0x7FFF, 0x
+};
+
void BrotliInitBitReader(BrotliBitReader* const br) {
br->val_ = 0;
br->bit_pos_ = sizeof(br->val_) << 3;
--- a/dec/bit_reader.h
+++ b/dec/bit_reader.h
@@ -11,6 +11,7 @@
#include /* memcpy */
+#include "../common/constants.h"
#include "../common/types.h"
#include "./port.h"
@@ -26,16 +27,7 @@
typedef uint32_t reg_t;
#endif
-static const uint32_t kBitMask[33] = { 0x,
-0x0001, 0x0003, 0x0007, 0x000F,
-0x001F, 0x003F, 0x007F, 0x00FF,
-0x01FF, 0x03FF, 0x07FF, 0x0FFF,
-0x1FFF, 0x3FFF, 0x7FFF, 0x,
-0x0001, 0x0003, 0x0007, 0x000F,
-0x001F, 0x003F, 0x007F, 0x00FF,
-0x01FF, 0x03FF, 0x07FF, 0x0FFF,
-0x1FFF, 0x3FFF, 0x7FFF, 0x
-};
+ATTRIBUTE_VISIBILITY_HIDDEN extern const uint32_t kBrotliBitMask[33];
static BROTLI_INLINE uint32_t BitMask(uint32_t n) {
if (IS_CONSTANT(n) || BROTLI_HAS_UBFX) {
@@ -43,7 +35,7 @@
"Unsigned Bit Field Extract" UBFX instruction on ARM. */
return ~((0xU) << n);
} else {
-return kBitMask[n];
+return kBrotliBitMask[n];
}
}
@@ -92,8 +84,11 @@
}
/* Returns amount of unread bytes the bit reader still has buffered from the
- BrotliInput, including whole bytes in br->val_. */
+ BrotliInput, including whole bytes in br->val_. Result is capped with
+ maximal ring-buffer size (larger number won't be utilized anyway). */
static BROTLI_INLINE size_t BrotliGetRemainingBytes(BrotliBitReader* br) {
+ static const size_t kCap = (size_t)1 << 30;
+ if (br->avail_in > kCap) return kCap;
return br->avail_in + (BrotliGetAvailableBits(br) >> 3);
}
--- /dev/null
+++ b/common/constants.c
@@ -0,0 +1,15 @@
+/* Copyright 2013 Google Inc. All Rights Reserved.
+
+ Distributed under MIT license.
+ See file LICENSE for detail or copy at https://opensource.org/licenses/MIT
+*/
+
+#include "./constants.h"
+
+const BrotliPrefixCodeRange
+_kBrotliPrefixCodeRanges[BROTLI_NUM_BLOCK_LEN_SYMBOLS] = {
+{1, 2}, {5, 2}, {9, 2}, {13, 2},{17, 3},{25, 3},
+{33, 3},{41, 3},{49, 4}, {65, 4},{81, 4},{97, 4},
+{113, 5}, {145, 5}, {177, 5}, {209, 5}, {241, 6}, {305, 6},
+{369, 7}, {497, 8}, {753, 9}, {1265, 10}, {2289, 11}, {4337, 12},
+{8433, 13}, {16625, 24}};
--- a/common/constants.h
+++ b/common/constants.h
@
Re: RFT: squid3 3.5.23-5+deb9u5, please test
On Tue, Sep 29, 2020 at 12:11:24AM +0200, Markus Koschany wrote: > [adding Andreas and Kevin to CC who helped with testing past squid3 updates] > > Hello, > > I have uploaded a new version of squid3 for Stretch to people.debian.org. > > https://people.debian.org/~apo/lts/squid3/stretch/ > > It contains fixes for CVE-2020-15049, CVE-2020-15810, CVE-2020-15811 and > CVE-2020-24606. Let me know if you find any regressions from > the current released version 3.5.23-5+deb9u4. > The changes look excellent to me. Regards, -Roberto -- Roberto C. Sánchez
Re: Thoughts on CVE-2020-15049/squid3?
On Fri, Sep 25, 2020 at 10:39:25PM +0200, Markus Koschany wrote: > > Yes, I have done the backport already but I wanted to wait for the > feedback of a user who reported another parsing issue in #965012. At the > moment I believe the current header parsing is correct but I am still > investigating why the reported problem exists in the first place. Since > I have not received any other reports, it could be a server > configuration issue. If I don't find the underlying problem this > weekend, I will upload the new update to people.debian.org and send a > RFT to debian-lts. I would appreciate testing and feedback from you and > other contributors because the package is obviously still used by > several users and companies but they don't seem to be subscribed to > debian-lts. That is good to know. I have restored the note in dla-needed.txt and ela-needed.txt and also included the note from dla-needed.txt in the ela-needed.txt entry for clarity. Once you send the next RFT I will take a look. Regards, -Roberto -- Roberto C. Sánchez
Re: Thoughts on CVE-2020-15049/squid3?
On Fri, Sep 25, 2020 at 10:04:59PM +0200, Markus Koschany wrote: > Hello Roberto, > > Am 25.09.20 um 21:25 schrieb Roberto C. Sánchez: > > Hello fellow LTS people, > > > > I am working on an update for the squid3 package. At this time there > > are 4 open CVEs, of which 3 have patches that apply with little or no > > change required. However, the patch for CVE-2020-15049 does not apply > > at all. > > You should have been aware that I have prepared the last update of > squid3. I have just noticed that the NOTE on the squid entry in > dla-needed.txt was removed but the last status was that the package > simply needs more testing. Hence I didn't bother to readd myself but the > NOTE was self-explaining (in ELTS and LTS). > Hmm. The note removal is unfortunate :-/ > [...] > > Based on the above findings, I am inclined to triage CVE-2020-15049 as > > : > > The patch for CVE-2020-15049 cannot be backported as is. The code that > was added in the meantime must be taken into consideration as well. > > > [stretch] - squid3 (complete fix is too invasive to backport) > > > > There appears to be precedent for taking this approach when a fix is far > > too invasive and where there does not appear to be an alternate approach > > to address the vulnerability. > > > > Unless there are any serious objections in the next few days I will > > proceed with uploading the update I have prepared and will update the > > security tracker entry as I have described. (Note: the same applies > > both for the package in stretch LTS and in jessie ELTS.) > > It is not possible to "fix" the remaining CVE if you ignore > CVE-2020-15049. The real fix was to backport the new header parsing code > which includes additional improvements, some of them could be considered > bug fixes for CVE, but upstream did not request identifiers for them. The backport seemed to me like it would require too much additional code change to be feasible without a great deal of additional risk. > Even if you addressed only the reported CVE, the fix would be incomplete > because of the missing sanity checks that were additionally added in the > past. > That is consistent with what I concluded. So, what is the best way to proceed? I presume based on your above comment that you have already prepared the packages for upload. Are those the same packages you referenced in your RFT message on 1st July? (I had to go hunting through the archive to locate the reference.) Should I review the backported code? The time I have spent digging through the Git history should be beneficial in such a review. Regards, -Roberto -- Roberto C. Sánchez
Thoughts on CVE-2020-15049/squid3?
Hello fellow LTS people, I am working on an update for the squid3 package. At this time there are 4 open CVEs, of which 3 have patches that apply with little or no change required. However, the patch for CVE-2020-15049 does not apply at all. Based on the commit message and an examination of the content of the patch, it does not appear feasible to fix CVE-2020-15049. Here is a bullet-formatted summary of my findings: - The patch (upstream commit ea12a34) indicates that the change essentially completes a fix that was begun in an earlier commit (upstream commit a1b9ec2) - The prior commit referenced in the patch (upstream commit a1b9ec2) itself refactors a substantial amount of code; the associated commit message indicates that the change fixed numerous defects with regards to squid's handling of invalid Content-Length header values - There are changes between a1b9ec2 and ea12a34 which would necessitate adapting ea12a34 to some degree - The changes introduced in a1b9ec2 also depend on code which was itself introduced in an earlier commit as a refactor of yet a previous version of said code - By my reckoning, the state of the code in the current squid3 package (based on upstream version 3.5.23) has undergone at least 4 substantial changes leading to the fix for CVE-2020-15049 - An alternate approach would be to develop an entirely new fix for CVE-2020-15049 based on the current state of the squid3 package; given the history of the code this will likely leave many exploitable vulnerabilities related to Content-Length handling Based on the above findings, I am inclined to triage CVE-2020-15049 as : [stretch] - squid3 (complete fix is too invasive to backport) There appears to be precedent for taking this approach when a fix is far too invasive and where there does not appear to be an alternate approach to address the vulnerability. Unless there are any serious objections in the next few days I will proceed with uploading the update I have prepared and will update the security tracker entry as I have described. (Note: the same applies both for the package in stretch LTS and in jessie ELTS.) Regards, -Roberto -- Roberto C. Sánchez
Re: slirp / CVE-2020-7039 / CVE-2020-8608
On Wed, Aug 12, 2020 at 08:55:43AM +1000, Brian May wrote: > I am seriously thinking that slirp from unstable should be ported as is > from sid to buster and stretch. This is not a new upstream version, it > has bug fixes and security updates only. Probably the same changes I > would have to make myself in fact. Such as replacing sprintf calls with > snprintf calls for example. > > This would fix CVE-2020-7039 and provide the prerequisite to fixing > CVE-2020-8608. > > Only thing, I am not sure what to do with the versioning: > > stretch 1:1.0.17-8 > buster 1:1.0.17-8 > sid 1:1.0.17-10 > > In fact, because stretch and buster has the same version, does this mean > I can't make any security uploads to stretch? > > On the other hand the security team has marked both these as no-DSA, in > buster meaning maybe I should do the same thing too? I would ask the Security Team if they are open to considering taking 1:1.0.17-10 into buster. The version would be 1:1.0.17-10~deb10u1. If they agree, then you could subsequently upload to stretch with version 1:1.0.17-10~deb9u1. If they are not open to considering it, then it seems that the only viable course of action is the mark them no-dsa. Regards, -Roberto -- Roberto C. Sánchez
Re: roundcube: CVE-2020-16145: XSS vulnerability via HTML messages with malicious SVG or math content
On Tue, Aug 11, 2020 at 01:40:48PM -0400, Roberto C. Sánchez wrote: > On Tue, Aug 11, 2020 at 07:11:57PM +0200, Guilhem Moulin wrote: > > Dear security team, > > > > In a recent post roundcube webmail upstream has announced the following > > security fix for #968216: > > > > Cross-site scripting (XSS) via HTML messages with malicious SVG > > or math content (CVE-2020-16145) > > > > AFAICT CVE-2020-16145 is only about SVG not math, but the upstream > > commit addresses both so I opened a single bug: > > https://github.com/roundcube/roundcubemail/commit/589d36010048300ed39f4887aab1afd3ae98d00e > > > > Debdiff tested and attached, but I'd appreciate if you could take care > > of the DLA :-) > > > > Thanks! > > Cheers, > > -- > > Guilhem. > > Hi Guilhem, > > I'll take care of it shortly. > I have uploaded the updated, published the DLA to the mailing list and submitted a Salsa MR for the advisory update on the website. Regards, -Roberto -- Roberto C. Sánchez
Re: roundcube: CVE-2020-16145: XSS vulnerability via HTML messages with malicious SVG or math content
On Tue, Aug 11, 2020 at 07:11:57PM +0200, Guilhem Moulin wrote: > Dear security team, > > In a recent post roundcube webmail upstream has announced the following > security fix for #968216: > > Cross-site scripting (XSS) via HTML messages with malicious SVG > or math content (CVE-2020-16145) > > AFAICT CVE-2020-16145 is only about SVG not math, but the upstream > commit addresses both so I opened a single bug: > https://github.com/roundcube/roundcubemail/commit/589d36010048300ed39f4887aab1afd3ae98d00e > > Debdiff tested and attached, but I'd appreciate if you could take care > of the DLA :-) > > Thanks! > Cheers, > -- > Guilhem. Hi Guilhem, I'll take care of it shortly. Regards, -Roberto -- Roberto C. Sánchez
Re: Suggestions for handling of condor update
On Fri, Jul 17, 2020 at 07:45:33PM -0500, Tim Theisen wrote: > Hello Roberto, > > I have just returned from a two week canoe camping trip (no electricity, > no internet). I saw this bug report just as I left town. I will be able > to review your work next week. > > I will have bit to catch up on Monday. I will take a look at this after > I catch up. > > Thank you for putting in the time to address this issue. You will hear > from me again next week. > > I should be able to review that the changes are correct and test on the > various distributions. > Hi Tim, I somehow missed your reply. I hope you have been able to catch up on your backlog. If I can do anything to help you with reviewing the changes, please let me know. Regards, -Roberto -- Roberto C. Sánchez
Re: Suggestions for handling of condor update
Condor maintainers, Could you provide your thoughts/feedback on the below? Regards, -Roberto On Sun, Jul 12, 2020 at 07:44:40AM -0400, Roberto C. Sánchez wrote: > Hello all, > > Your feedback on the condor update situation (described below) would be > appreciated. > > Several weeks ago I prepared updates for condor for jessie (then-LTS), > stretch, and buster (the latter two still under the security team > ubmrella) to address CVE-2019-18823. The description of the fix is "an > information disclosure of authentication credentials could allow an > attacker to impersonate an authenticated user and perform actions as > that user." > > I messaged the security team to seek counsel regarding the best way to > proceed with the update in stretch and buster with the intent of > resolving that question before proceeding with the jessie update. The > security team asked about what sort of testing had been performed. Not > being a user of condor my ability test the changes is limited, and since > the changes involve the authentication mechanisms, it would perhaps be > unwise to publish the update without some form of testing. Thus far I > have not taken further action. > > One the one hand it seems a shame to discard the prepared update, but on > the other hand the security team's concern regarding potential > regressions is quite correct. > > Does anyone have any specific suggestions? That is, is anyone able to > offer to test these packages or know someone who might be able to? > Apart from that, might there be an approach to minimize the possibility > of a regression? > > Regards, > > -Roberto > > -- > Roberto C. Sánchez -- Roberto C. Sánchez
Re: Suggestions for handling of condor update
On Mon, Jul 13, 2020 at 10:13:34AM +0200, Sylvain Beucler wrote: > Hi Roberto, > > On 12/07/2020 13:44, Roberto C. Sánchez wrote: > > Your feedback on the condor update situation (described below) would be > > appreciated. > > > > Several weeks ago I prepared updates for condor for jessie (then-LTS), > > stretch, and buster (the latter two still under the security team > > ubmrella) to address CVE-2019-18823. The description of the fix is "an > > information disclosure of authentication credentials could allow an > > attacker to impersonate an authenticated user and perform actions as > > that user." > > > > I messaged the security team to seek counsel regarding the best way to > > proceed with the update in stretch and buster with the intent of > > resolving that question before proceeding with the jessie update. The > > security team asked about what sort of testing had been performed. Not > > being a user of condor my ability test the changes is limited, and since > > the changes involve the authentication mechanisms, it would perhaps be > > unwise to publish the update without some form of testing. Thus far I > > have not taken further action. > > > > One the one hand it seems a shame to discard the prepared update, but on > > the other hand the security team's concern regarding potential > > regressions is quite correct. > > > > Does anyone have any specific suggestions? That is, is anyone able to > > offer to test these packages or know someone who might be able to? > > Apart from that, might there be an approach to minimize the possibility > > of a regression? > > If not already, I would suggest contacting the Debian package > maintainers since this isn't fixed in unstable yet. > They can also give more pointers. > That is an excellent suggestion. It had not even crossed my mind. Thanks. Regards, -Roberto -- Roberto C. Sánchez
Suggestions for handling of condor update
Hello all, Your feedback on the condor update situation (described below) would be appreciated. Several weeks ago I prepared updates for condor for jessie (then-LTS), stretch, and buster (the latter two still under the security team ubmrella) to address CVE-2019-18823. The description of the fix is "an information disclosure of authentication credentials could allow an attacker to impersonate an authenticated user and perform actions as that user." I messaged the security team to seek counsel regarding the best way to proceed with the update in stretch and buster with the intent of resolving that question before proceeding with the jessie update. The security team asked about what sort of testing had been performed. Not being a user of condor my ability test the changes is limited, and since the changes involve the authentication mechanisms, it would perhaps be unwise to publish the update without some form of testing. Thus far I have not taken further action. One the one hand it seems a shame to discard the prepared update, but on the other hand the security team's concern regarding potential regressions is quite correct. Does anyone have any specific suggestions? That is, is anyone able to offer to test these packages or know someone who might be able to? Apart from that, might there be an approach to minimize the possibility of a regression? Regards, -Roberto -- Roberto C. Sánchez
