include advisories for amazon linux extras

[piax93]

This fixes #267.

The implementation is not terribly fast, as it iterates through a bunch of URLs. On a very standard home internet connection it still completes in just about under a minute, which seems reasonable for something which is going to run just a few times a day. I can work on parallelizing it if you are aiming for a bit higher performance target.

[CLAassistant]

All committers have signed the CLA.

[knqyf263]

How do we distinguish between regular packages and extras packages? I think we need to apply the extras advisories only to extras packages.

[piax93]

@knqyf263 mmm, that's a good point, as many package names will be the same of what's available via the main channel. In terms of distinguishing the advisories, that's pretty easy, as they have a different numbering format, i.e. ALAS2<pkgname>-<year>-<number> compared to just ALAS2-<year>-<number>. On the other hand, I think packages will pretty much look the same when enumerated out of the rpm database, so the best bet is likely looking at the packages' major version, and just compare with advisories that have the same, although it's a bit of a heuristic.

[knqyf263]

so the best bet is likely looking at the packages' major version, and just compare with advisories that have the same, although it's a bit of a heuristic.

For example, Golang has the same major version for standard and extras packages, right?

[piax93]

That's true as well, instead of "major version" I should have probably said "non-patch version", although that may make things even more complicated... Maybe the least terrible option is just to keep the comparison as is, and give the option to users to include the extras advisories through some parameter.

[knqyf263]

Ideally, we'd want to identify the extras packages somehow, but we don't know of a good way to do it yet.

An option for extras sounds interesting.

[piax93]

I'll close this as it's pretty much lost in the sands of time.