Re: Debconf 2017 LTS BoF Summary
Hi, On Wed, Aug 09, 2017 at 03:05:31PM +0200, Sébastien Delafond wrote: > On Aug/09, Markus Koschany wrote: > > I intend to submit a patch for reportbug to implement the first part > > of this idea. It basically asks an additional question before the > > question about bccing multiple e-mail addresses but only if the > > reported regression is against a package with a version number > > containing +deb7u1. I am not completely sure if the maintainer of > > reportbug will approve this but we can discuss this in the bug report > > later. > > > > I could also implement a similar feature for stable releases. So if > > the security likes to be informed about regression like that, please > > let me know. > > I believe this would be useful, yes, as opposed to having to proactively > look for such regressions. /\+deb\d+u\d/ sounds like a good starting We need to account for ~ as well /(\+|~)deb\d+u\d+/ to catch things like firefox. Cheers, -- Guido > point. > > Cheers, > > --Seb >
Re: Debconf 2017 LTS BoF Summary
On 2017-08-09 00:17:36, Guido Günther wrote: > * A staging repository on security-master (similar to proposed-updates > for stable releases) would be great since it would do away with > copying to people.d.o, etc. > It would allow people with CI to test packages before they hit > production. It also makes it simple to point "known testers" of > certain types of packages to test them and would hopefully make > more people test updates since they appear at a stable URL. Discussion > on this will continue. FWIW, I mentioned that issue in my latest report here, as part of the larger "ca-certificates|nss in all suites" question: https://anarc.at/blog/2017-07-29-free-software-activities-july-2017/#ca-certificates-updates ... and there's already an issue in the BTS to track this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817286 ... where future communications and discussions should probably be held. Thanks! a. -- Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu. Usenet dans ces conditions, c'est comme le web avec lynx, on prend trop conscience du vide, c'est déprimant. - JLC dans le Guide du linuxien pervers: "Coup de cafard..."
Re: Debconf 2017 LTS BoF Summary
Hi Seb, > > […]It basically asks an additional question before the > > question about bccing multiple e-mail addresses […] > I believe this would be useful, yes, as opposed to having to proactively > look for such regressions. Indeed, I'd like to see this backported. The other thing in this is that regressions, whilst obviously breaking people's setups and that's bad in itself (!), they have an additional embarrassment component given the funding model. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Debconf 2017 LTS BoF Summary
On Aug/09, Markus Koschany wrote: > I intend to submit a patch for reportbug to implement the first part > of this idea. It basically asks an additional question before the > question about bccing multiple e-mail addresses but only if the > reported regression is against a package with a version number > containing +deb7u1. I am not completely sure if the maintainer of > reportbug will approve this but we can discuss this in the bug report > later. > > I could also implement a similar feature for stable releases. So if > the security likes to be informed about regression like that, please > let me know. I believe this would be useful, yes, as opposed to having to proactively look for such regressions. /\+deb\d+u\d/ sounds like a good starting point. Cheers, --Seb
Re: Debconf 2017 LTS BoF Summary
On 08/08/17 23:17, Guido Günther wrote: [...] * We should try to track regressions to security updates more automatically Alternatively - the stable report-bug could offer to cc: the lts team on issues if filed against the corresponding release and version is a security update version (same for stable if wanted) - query UDD (blend script does something like that, Andreas Tille wrote it, see https://anonscm.debian.org/cgit/blends/website.git/tree/webtools/bugs.py) both ways seem worth exploring. I intend to submit a patch for reportbug to implement the first part of this idea. It basically asks an additional question before the question about bccing multiple e-mail addresses but only if the reported regression is against a package with a version number containing +deb7u1. I am not completely sure if the maintainer of reportbug will approve this but we can discuss this in the bug report later. I could also implement a similar feature for stable releases. So if the security likes to be informed about regression like that, please let me know. Regards, Markus Koschany
Wheezy update of cacti?
Dear maintainer(s), The Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of cacti: https://security-tracker.debian.org/tracker/source-package/cacti Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of cacti updates for the LTS releases. Thank you very much. Chris Lamb, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup Regards, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` la...@debian.org / chris-lamb.co.uk `-
Wheezy update of curl?
Dear maintainer(s), The Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of curl: https://security-tracker.debian.org/tracker/source-package/curl Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of curl updates for the LTS releases. Thank you very much. Chris Lamb, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup Regards, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` la...@debian.org / chris-lamb.co.uk `-
Wheezy update of giflib?
Dear maintainer(s), The Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of giflib: https://security-tracker.debian.org/tracker/source-package/giflib Would you like to take care of this yourself? If yes, please follow the workflow we have defined here: https://wiki.debian.org/LTS/Development If that workflow is a burden to you, feel free to just prepare an updated source package and send it to debian-lts@lists.debian.org (via a debdiff, or with an URL pointing to the source package, or even with a pointer to your packaging repository), and the members of the LTS team will take care of the rest. Indicate clearly whether you have tested the updated package or not. If you don't want to take care of this update, it's not a problem, we will do our best with your package. Just let us know whether you would like to review and/or test the updated package before it gets released. You can also opt-out from receiving future similar emails in your answer and then the LTS Team will take care of giflib updates for the LTS releases. Thank you very much. Chris Lamb, on behalf of the Debian LTS team. PS: A member of the LTS team might start working on this update at any point in time. You can verify whether someone is registered on this update in this file: https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup Regards, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Debconf 2017 LTS BoF Summary
On Wed, Aug 09, 2017 at 07:11:16AM -0400, Roberto C. Sánchez wrote: > > * license of CVE text is unclear -> Moritz rewrites from scratch > > - generic description of the issue instead of details of functions > > > Is it still OK to use verbatim text from a DSA in a DLA? It seems like > that should be OK, and it is something I do sometimes, as the DSAs are > frequently published first and I feel like sharing the same summary text > regarding a particular vulnerability keeps everything consistent. Definitely, feel free to do that. My concern was only about the CVE descriptions published at mitre.org Cheers, Moritz
Re: Debconf 2017 LTS BoF Summary
On Aug/09, Roberto C. Sánchez wrote: > Is it still OK to use verbatim text from a DSA in a DLA? It seems > like that should be OK, and it is something I do sometimes, as the > DSAs are frequently published first and I feel like sharing the same > summary text regarding a particular vulnerability keeps everything > consistent. No problem there, you can re-use them at will. Cheers, --Seb
Re: Debconf 2017 LTS BoF Summary
Hi Guido & LTS/Security folks, Thanks very much for publishing this summary. Since I was not able to participate in person I would like add a few thoughts. See my comments below inline. On Wed, Aug 09, 2017 at 12:17:36AM -0300, Guido Günther wrote: > > * BTS is the canonical place for communication about the bug so the idea > is to change bin/contact-maintainer to use the BTS this would avoid > double communication from security and lts team (and maybe also avoid > the maintainers from feeling pushed like we had in the past). Are > there any objections? > I think this is an excellent idea. > * D{S,L}A texts are hand written. Copying texts from other distros, > websites might be problematic due to license so better rewrite from > scratch (which largely rules out further automation). The CVE number > links to all the details so the type of severity (and attribution if > found) is enough, the rest can be found by interested people on the > web. > > * license of CVE text is unclear -> Moritz rewrites from scratch > - generic description of the issue instead of details of functions > Is it still OK to use verbatim text from a DSA in a DLA? It seems like that should be OK, and it is something I do sometimes, as the DSAs are frequently published first and I feel like sharing the same summary text regarding a particular vulnerability keeps everything consistent. -- Roberto C. Sánchez