Re: Drop support for libqb?
On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > We usually mark affected CVE as in data/CVE/list and just > > add the package to security-support-ended.deb8 in > > debian-security-support. We then upload new versions of the package > > periodically and announce it via DLA. I believe now is a good time to do it. > Thanks for the information. I will start working on it today. As any DD can commit to debian-security-support.git and also can upload that package, just make sure to call it a team upload in d/changelog to appease lintian and possibly other tools. And then it would be ideal to upload the package to unstable and then file a SRM bug to update the package in stretch, in addition to uploading to jessie. (Probably this should also result in a DLA, not 100% sure though. Thoughts & comments definitly welcome.) I believe it's fine if the version contraints (package version in unstable higher than testing higher than stable higher than oldstable) are temporarily not met, but I also believe it's important that they are in the long run & most of the time. If doing all this work is too much or tedious to you, please shout and I will be happy to finish this. Please just do at least the initial change in git to security-support-ended.deb8. Thanks! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: (E)LTS report for October
On Tue, Nov 12, 2019 at 11:03:17AM +0100, Sylvain Beucler wrote: > I believe it's a matter of magnitude: the doc's example is about a 10% > excess, while this was about a ~200% excess. this, exactly. > 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. also. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > > We usually mark affected CVE as in data/CVE/list and just > > > add the package to security-support-ended.deb8 in > > > debian-security-support. We then upload new versions of the package > > > periodically and announce it via DLA. I believe now is a good time to do > > > it. > > Thanks for the information. I will start working on it today. > > As any DD can commit to debian-security-support.git and also can upload > that package, just make sure to call it a team upload in d/changelog to > appease lintian and possibly other tools. > I had not yet seen this message so I already submitted a MR. Should I close that and make a direct commit? > And then it would be ideal to upload the package to unstable and then > file a SRM bug to update the package in stretch, in addition to > uploading to jessie. (Probably this should also result in a DLA, not > 100% sure though. Thoughts & comments definitly welcome.) > Looking at the previous updates, a DLA seems appropriate. I am in the process of drafting the text. > I believe it's fine if the version contraints (package version in > unstable higher than testing higher than stable higher than oldstable) > are temporarily not met, but I also believe it's important that they are > in the long run & most of the time. > > If doing all this work is too much or tedious to you, please shout and I > will be happy to finish this. Please just do at least the initial > change in git to security-support-ended.deb8. > If I close the MR and commit directly, is it then a simple matter of build and upload to unstable? That is, no other special steps are required? Regards, -Roberto -- Roberto C. Sánchez
Re: Drop support for libqb?
On Thu, Nov 14, 2019 at 01:31:27PM -0500, Roberto C. Sánchez wrote: > On Thu, Nov 14, 2019 at 05:19:03PM +, Holger Levsen wrote: > > On Wed, Nov 13, 2019 at 08:24:55AM -0500, Roberto C. Sánchez wrote: > > > > We usually mark affected CVE as in data/CVE/list and just > > > > add the package to security-support-ended.deb8 in > > > > debian-security-support. We then upload new versions of the package > > > > periodically and announce it via DLA. I believe now is a good time to > > > > do it. > > > Thanks for the information. I will start working on it today. > > > > As any DD can commit to debian-security-support.git and also can upload > > that package, just make sure to call it a team upload in d/changelog to > > appease lintian and possibly other tools. > > > I had not yet seen this message so I already submitted a MR. Should I > close that and make a direct commit? > > > And then it would be ideal to upload the package to unstable and then > > file a SRM bug to update the package in stretch, in addition to > > uploading to jessie. (Probably this should also result in a DLA, not > > 100% sure though. Thoughts & comments definitly welcome.) > > > > Looking at the previous updates, a DLA seems appropriate. I am in the > process of drafting the text. > > > I believe it's fine if the version contraints (package version in > > unstable higher than testing higher than stable higher than oldstable) > > are temporarily not met, but I also believe it's important that they are > > in the long run & most of the time. > > > > If doing all this work is too much or tedious to you, please shout and I > > will be happy to finish this. Please just do at least the initial > > change in git to security-support-ended.deb8. > > > If I close the MR and commit directly, is it then a simple matter of > build and upload to unstable? That is, no other special steps are > required? > Some additional follow-up: - Can I go ahead and mark the CVE in question as in data/CVE/list even before the update to debian-security-support is complete? - Any feedback on this proposed DLA text? Package: debian-security-support Version: 2019.11.15~deb8u1 debian-security-support, the Debian security support coverage checker, has been updated in jessie. This marks the end of life of the libqb package in jessie. A recently reported vulnerability against libqb which allows users to overwrite arbitrary files via a symlink attack cannot be adequately addressed in libqb in jessie. Upstream no longer supports this version and no packages in jessie depend upon libqb, thus making it a leaf package. We recommend that if your systems or applications depend upon the libqb package provided from the Debian archive that you upgrade your systems to a more recent Debian release or find an alternate and up to date source of libqb packages. Regards, -Roberto -- Roberto C. Sánchez
automatically strip no-dsa tags by gen-DLA
In an attempt to complete this TODO item from the wiki: automatically strip no-dsa tags by gen-DLA https://wiki.debian.org/LTS/TODO#automatically_strip_no-dsa_tags_by_gen-DLA This is my very early attempt to modify the CVE parser so that it can write the results back to the CVE file again. Meaning we can made deliberate modifications to the data before doing so. https://salsa.debian.org/snippets/354 Unfortunately in making the required changes, it is no longer compatible with the previous API. As we need to keep track of all the data in such away that any modifications are reversible. Which is why I copied the files completely rather then trying to edit in place. The original parser makes certain changes that are not reversible and can produce slightly different results (e.g. different ordering of values, different white-space, etc). Currently it produces a file with the following differences (see diff below), the first two changes are due to twp tab characters being replaced by spaces (not sure it matters enough to try and fix this...) and the last was due to deliberate filtering (line 273). The filtering is currently hard coded, this should be called somehow by gen-DLA. Any comments or suggestions? === cut === --- data/CVE/list 2019-11-12 16:54:16.835792742 +1100 +++ a 2019-11-15 16:51:09.043817845 +1100 @@ -354371,7 +354371,7 @@ NOT-FOR-US: Trend Micro Anti-Rootkit Common Module CVE-2007-0855 (Stack-based buffer overflow in RARLabs Unrar, as packaged in WinRAR an ...) - rar 1:3.7b1-1 (high; bug #410582) - [sarge] - rar (Non-free) + [sarge] - rar (Non-free) [etch] - rar (Non-free) - unrar-nonfree 1:3.7.3-1 (high; bug #410580) [sarge] - unrar-nonfree 1:3.5.2-0.2 @@ -359261,7 +359261,7 @@ NOT-FOR-US: BytesFall Explorer (bfExplorer) CVE-2006-5718 (Cross-site scripting (XSS) vulnerability in error.php in phpMyAdmin 2. ...) - phpmyadmin 4:2.9.0.3-1 (low; bug #396638) - [sarge] - phpmyadmin (Vulnerable code not present) + [sarge] - phpmyadmin (Vulnerable code not present) CVE-2006-5717 (Multiple cross-site scripting (XSS) vulnerabilities in Zend Google Dat ...) NOT-FOR-US: Zend Google Data Client Library (ZendGData) CVE-2006-5716 (Directory traversal vulnerability in aff_news.php in FreeNews 2.1 allo ...) @@ -376628,7 +376628,6 @@ NOT-FOR-US: Sun Java System Directory Server CVE-2005-3268 (yiff server (yiff-server) 2.14.2 on Debian GNU/Linux runs as root and ...) - yiff 2.14.2-8 (bug #334616; low) - [sarge] - yiff (Only a minor privacy leak) CVE-2005-3267 (Integer overflow in Skype client before 1.4.x.84 on Windows, before 1. ...) NOT-FOR-US: Skype CVE-2005-3266 === cut === -- Brian May
