Chris Lamb <la...@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
run
- 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 <b...@debian.org>
