Initial experimental CVE checker (port of TingPing's script)

[ahayzen]

This is a very rough hack to get @TingPing 's awesome script into the project. I have put it behind a flag at the moment --experimental-cve-checker. (note it only checks archives). And I started moving some common things into common places.

An example of the output is here

$ ./src/flatpak-external-data-checker --verbose --experimental-cve-checker ~/Downloads/com.skype.Client.json 
DEBUG:root:libsecret-0.18.5.tar.xz is not a debian-repo type ext data
DEBUG:root:libsecret-0.18.5.tar.xz is not a rotating-url type ext data
DEBUG:root:v4l-utils-1.12.5.tar.bz2 is not a debian-repo type ext data
DEBUG:root:v4l-utils-1.12.5.tar.bz2 is not a rotating-url type ext data
DEBUG:root:nss-3.36.1.tar.gz is not a debian-repo type ext data
DEBUG:root:nss-3.36.1.tar.gz is not a rotating-url type ext data
DEBUG:root:skypeforlinux-64.deb is not a debian-repo type ext data
DEBUG:root:skypeforlinux-64.deb is not a rotating-url type ext data
========================= ========
Library                   Version
========================= ========
libsecret                 0.18.5  
nss                       3.36.1  
v4l-utils                 1.12.5  
========================= ========

[ahayzen]

FIXME: remove when #3 lands

[TingPing]

Need to actually parse these files at some point.

[ahayzen]

Yup, I'll create an issue so we don't forget.

[joaquimrocha]

@ahayzen Thanks for doing this. Here are a couple of thoughts about the approach though.

1. There are a lot of changes that don't belong to this PR, such as moving classes out of modules and into the package directly. This should be done in a different PR if there's a good reason for doing this. I'd prefer to keep things more contained for now though.

2. I don't understand why you changed the core of the project instead of simply implementing a checker (a plugin) just like we have for debs and other tarballs. You can even add the metadata you want to the sources, in case you need additional metadata to help your checker. Also, if what's missing is a way to print more debug information about each module that has a CVE then you can add a new state to the ExternalData + extra info where Checkers can add text to inform the user about what's up.

Does this make sense?

[joaquimrocha]

I think this change is out of scope. I don't know how this project will evolve so I prefer to keep things separated like I did.

[ahayzen]

@joaquimrocha Hey

1 - sure, happy to split things up into smaller PRs when the direction is clear and we know what (if anything) needs to moved.
2 - I think I must have misunderstood how the lib/ part of the app works, I thought that lib/externaldata.py was extracting only the extra-data from the JSON file and turning it into an intermediate representation for the checkers. But on a second look it doesn't appear to be doing what I thought. In which case I'll look at moving this into a checker plugin and see if this results in a less intrusive change :-) (i think it also might be easier to do this in another branch)

This makes sense, I'll see how far I can get, thanks for the pointers !

[ahayzen]

@joaquimrocha I have a new version here #8 therefore I'm going to close this pull.