Open adamdecaf opened 6 years ago
The response from zlint is pretty easy to parse. I've included a full response:
Here's an example parsing the output. https://play.golang.org/p/-6gCyT3xSWu
Would we want to store the entire response? The result
field is limited to just a few values. We could probably get away with only storing info, warn, error, and fatal.
Note: NE refers to checks which are date related, but aren't applicable during evaluation. See: https://github.com/zmap/zlint/blob/88032a5e59f98690016d7dd312a3620cecb3e2e0/lints/base.go#L76-L79
Values: https://github.com/zmap/zlint/blob/88032a5e59f98690016d7dd312a3620cecb3e2e0/lints/result.go#L54
cc @jvehent thoughts?
I agree we should avoid storing passing tests results in the database. I think a list of failing tests (or info, warn, etc.) is really what we want.
Also, I'd rather not update the worker every time zlint adds a new check, which would be needed right now because they use check names as json keys (a bad practice, IMO). Could the worker be written in a way that parses the json as map[string]result
where string
is the test name? That would allow us to update to upstream zlint without having to modify the worker's go code.
Could the worker be written in a way that parses the json as map[string]result where string is the test name?
I believe that's exactly what my example parser does. I was thinking we could delete
from that map any NA, NE, or pass
checks and save the resulting map in our db.
There's no way I want to encode specific zlint checks into tls-observatory. That's just going to be a nightmare to maintain.
I can it as technically possible to try and parse out BR sections, human readable descriptions, etc from that spreadsheet though. I'd probably save that for a second PR as it's probably messy to do and might require google auth.
Similar to https://github.com/mozilla/tls-observatory/issues/187, https://github.com/mozilla/tls-observatory/issues/257, and https://github.com/mozilla/tls-observatory/issues/258, but to run zmap/zlint over the certificates.
This tool is pretty complete and has most of the BR checks included. (List: https://docs.google.com/spreadsheets/d/1ywp0op9mkTaggigpdF2YMTubepowJ50KQBhc_b00e-Y/edit#gid=0)
zlint looks to be gaining steam from (at least one) CA over their own tools. https://cabforum.org/pipermail/public/2018-April/013233.html Either way it's a really complete validator.