High level wrapper for parsing binaries

[Shnatsel]

Performs the parsing in a single function call instead of requiring assembling the pieces yourself and also doing your own error handling.

Resolves #50

[Shnatsel]

@pinkforest you wanted to use this, so let me know if this fits your use cases.

It still needs docs but other than that should be good to go.

[Shnatsel]

I'll keep refining it in-tree, but I still do want feedback on this.

[pinkforest]

thought this was going to be auditable-info ?

[Shnatsel]

I wanted a clean separation between the high-level crate and the low-level ones, but maybe this will just create confusion with the rust-audit-info binary.

We could still switch if you think auditable-info is better.

[pinkforest]

Yeah I think auditable-info is best around those considerations re: confusion.

[pinkforest]

if we are to change to auditable-info in case or another have to change here as well

[pinkforest]

btw what we'll be doing with the public API as I think whilst the raw_ etc. fn's are a okay for MVP we can probably design something more sugary that doesn't care about raw data

[Shnatsel]

The raw_* functions are needed for rust-audit-info which doesn't perform JSON parsing/validation, so that step is unnecessary. It would be perhaps nice to return a String for clarity, but that performs a potentially useless UTF-8 validation.

Perhaps I should indeed make it return String - that will be a lot easier to understand, and the UTF-8 validation overhead should not be too big. And if someone needs a lower-level interface, the modular crates are right there.

[pinkforest]

Hm. Maybe I need to explain what I would expect from a high level auditable-info API -

The high level API should be kept with consumer in mind and it should be easy to consume e.g. provide Iterables and like

Consumer should not need to care about messing with dependency tree structure and stuff like that or even care about whether the data structure is JSON or something else - that is implementation detail to auditable.

I can understand it for the low-level API but if we are to provide high-level API then it should be something like this:

Maybe one could use JSON Path ? but then that ties into a data format which is supposed to be implementation detail

info = auditable::Info::from(T); // T generic can be `File` | `OssString` | ..

info.path('json_path')

Above would assume auditable crate would have Info interface / re-exports from auditable-info on it's public interface

[Shnatsel]

Based on the experience with integrating it into cargo-audit and Trivy, the API of just exposing the format directly appears to be the right level of abstraction. The scanners then convert it into their native data structures, which are fairly close to the JSON format. And since the format is stable, just exposing the format is the most API-stable thing we can do.

[Shnatsel]

I believe you are correct about this not really being a high-level API, but I don't have any use cases for a high-level API, so I cannot design an API that will actually be useful that way. So for now I'm leaving it at the level of abstraction that is useful in cargo audit, rust-audit-info and Trivy.

[pinkforest]

Yeah I think we need consumer use-cases in order to design that - if any. correct