Re: forward-ports to jessie and LTS transition coordination
On 2018-06-08 02:55:14, Brian May wrote:
> 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.
the problem with <removed> is, as I mentioned, that we need to "know"
about those packages. the script lamby wrote is simpler and just adds a
tag without considering the state of the archive.
I know the security tracker knows about the archive, but I haven't found
out quickly how to tap into those resources while at the same time
operating on the list file. In that regard, some scripts operate
directly on data/CVE/list files and others tap into the JSON output and
require network access. I'm not sure mixing the two is such a great idea
but maybe it can just work.
> * 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)
I also faced this problem. The problem is that changes can happen in the
list file at any location or time in the past. We still work on issues
from 2016, for example. Keeping ourselves to the last year won't work in
that regard. Similarly, "last CVE checked" assumes they are issued in
order, which is unfortunately not the case either. We could look at the
git history diff, but then it gets messy quick.
One solution I found here is to bite the bullet and run the script on
the whole file once, maybe with the <ignored> tag, since it's really
the current state anyways. Then new entries can be processed as normal
(<unfixed> or whatever).
> * 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.
This would indeed avoid the whole issue of past entries altogether. That
script also has the advantage that it already taps into the archive
metadata. It would also avoid the issues of possible inconsistencies
between the JSON file and editing data/CVE/list directly by leaving the
triage to the operator. But then it means more manual work.
> My comments:
>
> * When should we use <removed> vs when should we use <unfixed>? I am
> unclear on this.
We should use <removed> when the package was removed from stable or
earlier, as far as I know.
[...]
a.
--
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
- Lee Felsenstein
Reply to: