[Open-scap] C++ Library

[Thomas Jones]

On Thu, Oct 18, 2012 at 9:46 AM, Simon Lukasik <slukasik at redhat.com> wrote:
> On 10/18/2012 03:54 PM, Thomas R. Jones wrote:
>> On Thu, 2012-10-18 at 15:23 +0200, Simon Lukasik wrote:
>>>
>>> Also, without seeing the code. I can hardly answer your question about
>>> me being interested in it. ;-)
>>
>> https://git.gitorious.org/openscap-thomasrjones/oval-openscap-thomasrjones.git
>>
>
> Thanks.
>
> It seems like a lot of XML-parsing code. Why did you decided to parse
> the oval XML yourself compared to letting libxml (or other library) to
> do the low level job? (I am not questioning the decision, just
> wondering, it may turn either good or wrong in the long term).

I chose this avenue of approach for two reasons.
1. libxml validation against a schema is incomplete
2. the lib is 1:1 with the schema. It CANNOT produce invalid oval xml.
Each header provides a type, within each type are the members. These
members are 1:1 with the standard. This includes enumeration values.

Yes it is at a low level. I hope to construct higher level functions
in the near future. However, I intend to keep the lower level
functions public still; at least for the time being. To be honest, I
constructed this library as a resource upon which to start some
applications for myself becoming incorporated. But I am an open source
advocate; life isn't all about money. As such, here it is.

>
> I should also highlight a difference between OpenSCAP and SCAP. SCAP is
> the opened standard at NIST. While OpenSCAP is Fedora hosted project to
> implement this standard. Thus, I believe you are in attempt to implement
> parsing of SCAP component standard -- the OVAL, but not the OpenSCAP. :)

Yes sir. I have other implementations as well. CPE, CVE....even other
releases of the OVAL standard(btw..this one is v5.10). So that
regardless of what standard version is used; the resultant xml is
valid for that version.

I am on a project and soon to be flying out of country; but I intend
to provide a composite library in the future with all the standards
and versions.

Cheers.

>
> Regards,
>
> --
> Simon Lukasik
> Security Technologies