Re: Contact maintainers via bts [was Re: Debconf 2017 LTS BoF Summary]
Hi, On Wed, Nov 29, 2017 at 08:26:52PM +0100, Guido Günther wrote: > Hi, > On Wed, Aug 09, 2017 at 07:11:16AM -0400, Roberto C. Sánchez wrote: > > 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. > > Attached script when dropped into bin/ of the security-tracker uses the > bts instead of sending mails to the maintainers. Since there was no feedback I went ahead and committed this. So in case somebody wants to try out using the BTS intead of mailing maintainers directly try bin/lts-bts. Cheers, -- Guido
Contact maintainers via bts [was Re: Debconf 2017 LTS BoF Summary]
Hi,
On Wed, Aug 09, 2017 at 07:11:16AM -0400, Roberto C. Sánchez wrote:
> 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.
Attached script when dropped into bin/ of the security-tracker uses the
bts instead of sending mails to the maintainers.
I have removed the non lts parts since the security team is not using
this stuff anyway and I've also removed the no-dsa handling since I
think we got exactly 0 positive replies about handling no-dsa in LTS
from maintainers.
The "downside" of using the bts instead of mailing the maintainers is
that we either need to post to several bugs or resort to only using the
most important one. Currently if several CVEs are given the additional
CVEs will be listed in the bugreport as well like:
| The following additional CVEs are open against this package:
|
| https://security-tracker.debian.org/tracker/CVE-2016-9913
| https://security-tracker.debian.org/tracker/CVE-2016-9913
|
| We intend to address them with the same upload.
But mail is only sent to one bug to not spam maintainers.
I'd appreciate any feedback. I've deliberately used a new script
so we can work on this one while keeping the current workflow alive.
As soon as this look halfway sane I'll commit it.
Invocation is e.g. like:
bin/lts-bts qemu-kvm --skip-cache-update CVE-2017-9374
Cheers,
-- Guido
#!/usr/bin/python3
#
# Similar to contact-maintainers ask for help in fixing the bug in
# the LTS release but use the BTS instead of plain mail
import argparse
import os
import pwd
import subprocess
import sys
import tempfile
import warnings
from tracker_data import TrackerData, RELEASES
from jinja2 import Template
tmpl="""Content-Type: text/plain; charset=utf-8
To: {{ to }}
Cc: {{ cc }}
Subject: Fixing {{ cve }} in {{ package }} in {{ dist }}?
control: found -1 {{ found }}
Dear maintainer(s),
The Debian LTS team would like to fix this security issues
in the {{ dist }} version of {{ package }}.
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 {{ package }} updates
for the LTS releases.
{% if add_cves %}
The following additional CVEs are open against this package:
{% for entry in add_cves -%}
https://security-tracker.debian.org/tracker/{{ entry }}
{% endfor %}
We intend to address them with the same upload.
{% endif %}
Thank you very much.
{{ sender }},
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
"""
def get_full_name():
full_name = os.getenv('DEBFULLNAME')
if full_name:
return full_name
return pwd.getpwuid(os.getuid()).pw_gecos.split(',')[0]
def find_issue(tracker, pkg, cve):
for issue in tracker.iterate_pkg_issues(pkg):
if issue.name == cve.upper():
return issue
else:
raise ValueError("%s is not an issue of %s" % (cve, pkg))
def find_version(release, issue):
for repo in [release + ext for ext in ('-security', '')]:
if repo in issue.data['releases'][release]['repositories']:
return issue.data['releases'][release]['repositories'][repo]
def main():
# Parse command line
parser = argparse.ArgumentParser(
description='Get in touch with package maintainers via bts')
parser.add_argument('--force', action='store_true',
help='Ignore safety checks')
parser.add_argument('--mailer', action='store', default='mutt -H {}',
help='Command executed. Must contain
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
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
Debconf 2017 LTS BoF Summary
Hi,
here's a short summary from the BoF;
* A internal review of the first commits to the security-tracker for new
LTS team members by other LTS team members would be good.
IMHO we should just do that.
* The Security team requests help with keeping the list at
https://security-tracker.debian.org/tracker/status/unreported
down. Got better during the last year for new packages but there's
still a backlog. That's an recurring topic from last year.
* For temp issues request CVEs (http://cve.mitre.org/cve/request_id.html).
Mark status in the tracker to avoid duplication.
Backlog: https://security-tracker.debian.org/tracker/data/fake-names
* 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?
* 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.
* Rules the security team uses for bug severities filed by
bin/report-vuln: early in the release -> RC, later depending on
severity of CVE - in doubt start high.
* 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.
* 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.
Gobby text is at [1] and attached. Thanks to everybody for their
input. Please post corrections if I missed or misunderstood something.
Cheers,
-- Guido
[1]: https://gobby.debian.org/export/debconf17/bof/lts-and-security-team-bof
LTS and Security Team BoF
=
* A internal review of the first commits to the security-tracker for new
LTS team members would be good.
* Security team requests help with keeping the list at
https://security-tracker.debian.org/tracker/status/unreported
down. Got better during the last year for new packages.
* For temp issues request CVE (http://cve.mitre.org/cve/request_id.html).
Mark status in the tracker to avoid duplication.
Backlog: https://security-tracker.debian.org/tracker/data/fake-names
* BTS is the canonical place for communication about the bug
- Version information there is not up-to-date and that is ok <- security
tracker is canonical for that
Should we skip our LTS "do you want to take care of this yourself"
mails and rely on the BTS completely?
* Try to keep inter distro info up-to-date (link???)
* To track regressions after an upload track the BTS for one/two weeks after
a release.
Alternatively
- the stable report-bug could query for security
regressions and puth the lists in cc.
- 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
* cacti has a autopkgtest that includes exploits test
(test suite works with tweaks for older verions)
* bin/check-new-issues (command) in secure-testing helps with new issues.
Some emacs integration for d{l,s}a-needed and data/CVE/list but that
can be improved.
* there was/is a connection with the bts: CVE usertag or tag. Details anyone?
* severity of bugs: early in the release -> RC, later depending on severity of
CVE
- in doubt start high
* license of CVE text is unclear -> Moritz rewrites from scratch
- generic description of the issue instead of details of functions
* s.th. like proposed-updates (a staging repository) for security would be
great for stable and lts since it would do away with "please test ..." and
allows people with CI to test packages before they hit production. It all
so makes it simple to point "known testers" of certain types of packages
to it.
