[Open-scap] C++ Library

[Martin Preisler]

Hi,
don't take this the wrong way but you are going to hit one huge roadblock with this approach - lack of backward compatibility. SCAP 1.2 requires the tool to be able to interpret various versions, which means that you will need multiple XSD schemas, in various combinations. I don't see how you would be able to achieve that with your approach without some really complex XSD schema merging or custom patches applied after the generation of the model.

As said previously all this is so far is a serialisation project - it can load and save the data. Loading, saving and accessing the model is not a particularly hard problem, creating a thin wrapper around DOM would get you mostly the same thing. Interpreting the model is a lot more work. Do you think creating another SCAP tool completely from scratch is the way to go? What are your issues with openscap? Is there something that needs to be changed? You said that you found bugs in openscap, wouldn't addressing those be less work than writing another solution from scratch?

PS: Confidential and proprietary makefiles?

-- 
Martin Preisler

----- Original Message -----
> From: "Thomas Jones" <thomas at opensuse.us.com>
> To: "Simon Lukasik" <slukasik at redhat.com>
> Cc: retention at opensuse.us.com, open-scap-list at redhat.com
> Sent: Thursday, October 18, 2012 5:57:58 PM
> Subject: Re: [Open-scap] C++ Library
> 
> 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
> 
> _______________________________________________
> Open-scap-list mailing list
> Open-scap-list at redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list
>