Re: Drop support for libqb?
On Tue, Nov 12, 2019 at 06:53:19PM +0100, Markus Koschany wrote: > Hi, > > Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: > [...] > > With that in mind, does this seem like a package for which we should > > declare the end of support? > > That sounds reasonable to me. > Is it as simple as updating the debian-security-support package? Do we customarily send out a DLA when a package is dropped from support? Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
Hi, Am 12.11.19 um 18:11 schrieb Roberto C. Sánchez: [...] > With that in mind, does this seem like a package for which we should > declare the end of support? That sounds reasonable to me. Cheers, Markus signature.asc Description: OpenPGP digital signature
Drop support for libqb?
Hello all, In recent days I made an attempt at backporting fixes made upstream in libqb to address CVE-2019-12779. I requested a review from upstream in the related GitHub issue [0]. The essence of the discussion is that some important parts of the upstream changes do not apply to the libqb in Jessie, because libqb in Jessie is considerably older than the releases for which upstream has provided a fix. Chris and Brian have both made assessments of the degree of vulnerability in libqb [1]. The comments from upstream appear to be in line with those observed by Chris and Brian. That said, Ferenc Wágner, who is the current maintainer of libqb in Debian and also has contributed upstream joined the conversation. He asked what packages depend on libqb. I must confess that it never even occurred to me to look. The answer is that no packages depend on libqb in Jessie, making it a leaf package. Based on that and the vast differences between libqb 0.11.1, in Jessie, and 1.0.5, in which the fixes have been made available, Ferenc's assessment, and mine, is that additional effort on this package would be a waste. From Ferenc's point of view, anybody on such an old release of Debian would have used 0.17.2 or 1.0.1 from jessie-backports. Neither of those will be updated by the security team. Updating to a current upstream release would be low risk from the standpoint of it being a leaf package, but that does not seem right either. With that in mind, does this seem like a package for which we should declare the end of support? Regards, -Roberto [0] https://github.com/ClusterLabs/libqb/issues/338 [1] https://lists.debian.org/debian-lts/2019/06/msg00015.html -- Roberto C. Sánchez
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi Sylvain, hi all, On Thu, 7 Nov, 2019, 3:19 PM Sylvain Beucler, wrote: > Hi, > > On 06/11/2019 21:14, Utkarsh Gupta wrote: > > On 06/11/19 11:47 am, Brian May wrote: > >> Utkarsh Gupta writes: > >> > >>> I am not quite sure about what should we do here because the update > (DLA > >>> 1956-1) doesn't quite fix the CVE completely and also brings some login > >>> problems as reported in #125. > >>> Because for now, #121 + #126 = actual CVE fix. But the login problem > >>> remains. > >> I guess we have three options: > >> > >> 1. Do nothing. > >> 2. Revert the #121 patch, because it could break. I haven't seen any > >> complaints however... > > Whilst that is true, I'd rather not want someone to face an "unexpected > > response" error. > > Though I hope no one is using that feature yet :) > > > >> 3. Apply the #126 patch too. Not 100% convinced this is a justified > >> change for LTS, but it "looks right". > >> 4. Wait longer for possible upstream solution to #125. > >> > >> Any opinions? > > I'd be a +1 on the 2nd and/or the 4th option. And a +0.5 on the 3rd. > Do the package maintainers have an opinion on this? > This can help. > I recently fixed (by fixing, I mean importing the CVE fix, not the problem it causes) this in unstable and I'm one of the package maintainers now :) Raphael, given that this package is low popcon and the vulnerability is > fuzzy, do you know if the sponsor for this package would be willing to > test fixes? > Given Raphael's last mail, I'm not sure if it could *really* be tested. What makes sense now is to wait for the upstream fix *until* someone who uses this library grumbles :) Best, Utkarsh >
Re: Security issues in standards (ruby-openid / CVE-2019-11027)
Hi, (Sylvain, please cc me if you want me to read something in any timely fashion) On Thu, 07 Nov 2019, Sylvain Beucler wrote: > Raphael, given that this package is low popcon and the vulnerability is > fuzzy, do you know if the sponsor for this package would be willing to > test fixes? The sponsor is a web hoster who is listing packages used by all their customers. I doubt that they can easily test. I'm bccing them in case they want to chip in and express their interest in testing fixes. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: (E)LTS report for October
Hi, On 10/11/2019 21:41, Brian May wrote: > Holger Levsen writes: > >> then, just for the record, this was discussed with Raphael and me. Please >> don't do more hours than assigned without coordination. See "What should >> I do if I work more than the hours allocated?" in debian-lts.git for >> more info. > Huh? I don't see anything about requiring coordination here. Just bill > the hours for your next month. Did I miss something? I believe it's a matter of magnitude: the doc's example is about a 10% excess, while this was about a ~200% excess. Coordination allows to average the workload and reactivity, for instance by adding more people to a task, reassigning the task, reconsidering the task's scope, etc. In this particular case it seems they decided to move the hours, but that's not something one can decide on their own, at this scale. (There may also be legal issues with billing hours while no hours were done that particular month, AINAL.) Cheers! Sylvain
