[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: forward-ports to jessie and LTS transition coordination

Chris Lamb <lamby@debian.org> writes:
> Other work that can be done in the meantime include improving our
> triage scripts -- I still have a half-draft of the "renamed packages"
> script, for example.
> IIRC I believe the subject to search for is "Improvement needed to our
> triaging scripts".

Ok, if I understand this, the following concerns need addressing still:

  * as I said in the mailing list discussion, I don't like the usage of the
    undetermined tag... we use it to hide stuff we can't investigate under
    the carpet, I would much prefer that we put it as <removed> directly
    when it's the case, or <unfixed> otherwise.

  * somehow we need to restrict this to a subset of the CVE, otherwise we
    are going to add a lot of undesired entries. We want to add tiff3 for
    new tiff CVE but not for old (already-closed) tiff CVE that date back to
    when we add tiff 2.x for example. I'm not sure what's the proper way to
    handle this... a few ideas:
    - do it only for new CVE that have appeared in the file since the last
    - somehow skip fixed CVE when the fixed version is older than a minimal
      version (i.e. do not add tiff3 if the CVE is fixed in tiff < 3.x)
    - only process CVE of the current year (not ideal because CVE numbers of
      former years can appear, since the year of the CVE is the year the
      issue has been made public, not the year it has been registered)

  * if we get this run under cron, it's OK, but I wonder if it would not
    make more sense to merge this into bin/lts-cve-triage.py somehow.

My comments:

* When should we use <removed> vs when should we use <unfixed>? I am
  unclear on this.

* When I run this script, I get 6 extra items. Is this considered a
  problem? Maybe if/when we add extra packages.

* How would you define "an already closed tiff CVE"? Is this something
  we can check easily in the script?

* I imagine it would be easy to record a "last processed CVE" number
  somewhere and keep track of it for the next run, although this means
  the script no longer has the advantage of being stateless.
Brian May <bam@debian.org>

Reply to: