Hi,
we have lot of same files in SSG - especially OVAL checks and remediations and it becoming hard to maintain such many files. Every new product means copy&paste of many new files. Bugfix in one product doesn't fix same files in another product. We are not able to see, that we forgot remediation for OVAL check, etc.
Currently, I am trying to remove generated files and update old csv & templates.
I would like to introduce new structure to allow sharing of files between products. Do you have any ideas/requirements? https://github.com/OpenSCAP/scap-security-guide/issues/1668
Thank you
Z.
I would structure it as a 3NF or 5NF XML database with join files.
Absolutely minimizes repetition and make is both easier to maintain and extend.
Trevor
On Mon, Feb 13, 2017 at 4:50 AM, Zbynek Moravec zmoravec@redhat.com wrote:
Hi,
we have lot of same files in SSG - especially OVAL checks and remediations and it becoming hard to maintain such many files. Every new product means copy&paste of many new files. Bugfix in one product doesn't fix same files in another product. We are not able to see, that we forgot remediation for OVAL check, etc.
Currently, I am trying to remove generated files and update old csv & templates.
I would like to introduce new structure to allow sharing of files between products. Do you have any ideas/requirements? https://github.com/OpenSCAP/scap-security-guide/issues/1668
Thank you
Z. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
Hi,
database sounds like interesting idea. I didn't think about it in that way. In my opinion, XML DB could be way how to store many SSG "items", not only OVALs/remediations.
If I understood it correctly, only overhead of adding of new remediation would be adding bindings to product, right?
I don't have own experience with XML databases. What does rest of SSG community think about it?
Z. ----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, February 15, 2017 3:14:33 PM Subject: Re: SSG structure without duplicates (OVAL/remediations)
I would structure it as a 3NF or 5NF XML database with join files.
Absolutely minimizes repetition and make is both easier to maintain and extend.
Trevor
On Mon, Feb 13, 2017 at 4:50 AM, Zbynek Moravec < zmoravec@redhat.com > wrote:
Hi,
we have lot of same files in SSG - especially OVAL checks and remediations and it becoming hard to maintain such many files. Every new product means copy&paste of many new files. Bugfix in one product doesn't fix same files in another product. We are not able to see, that we forgot remediation for OVAL check, etc.
Currently, I am trying to remove generated files and update old csv & templates.
I would like to introduce new structure to allow sharing of files between products. Do you have any ideas/requirements? https://github.com/OpenSCAP/scap-security-guide/issues/1668
Thank you
Z. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
That's exactly correct. Basically, you would add a rule binding line for each type of connection that you want to make.
It can (and in my opinion should) be used across the board.
Thanks,
Trevor
On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec zmoravec@redhat.com wrote:
Hi,
database sounds like interesting idea. I didn't think about it in that way. In my opinion, XML DB could be way how to store many SSG "items", not only OVALs/remediations.
If I understood it correctly, only overhead of adding of new remediation would be adding bindings to product, right?
I don't have own experience with XML databases. What does rest of SSG community think about it?
Z. ----- Original Message -----
From: "Trevor Vaughan" tvaughan@onyxpoint.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Wednesday, February 15, 2017 3:14:33 PM Subject: Re: SSG structure without duplicates (OVAL/remediations)
I would structure it as a 3NF or 5NF XML database with join files.
Absolutely minimizes repetition and make is both easier to maintain and extend.
Trevor
On Mon, Feb 13, 2017 at 4:50 AM, Zbynek Moravec < zmoravec@redhat.com > wrote:
Hi,
we have lot of same files in SSG - especially OVAL checks and
remediations
and it becoming hard to maintain such many files. Every new product means copy&paste of many new files. Bugfix in one product doesn't fix same
files
in another product. We are not able to see, that we forgot remediation
for
OVAL check, etc.
Currently, I am trying to remove generated files and update old csv & templates.
I would like to introduce new structure to allow sharing of files between products. Do you have any ideas/requirements? https://github.com/OpenSCAP/scap-security-guide/issues/1668
Thank you
Z. _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec zmoravec@redhat.com wrote:
Hi,
database sounds like interesting idea. I didn't think about it in that way. In my opinion, XML DB could be way how to store many SSG "items", not only OVALs/remediations.
If I understood it correctly, only overhead of adding of new remediation would be adding bindings to product, right?
I don't have own experience with XML databases. What does rest of SSG community think about it?
Personally I don't like it. It doesn't work well with our git workflow. I don't think this is what the SQL XML databases are for.
The term 'relational database' may be misleading.
What I want is a relational pairing between data segments so that later changes can be done in a traditional manner. We don't actually need to create full on tables in XML and do all that fun.
I do understand that it may break the git workflow and it will certainly break the build scripts. However, I think that it will increase the user experience and, therefore, help adoption of the suite.
I've asked before about being able to create micro data streams and extract very small parts of the standards without having to lug around the entire repo through my few hundred projects. Presently, this is not possible but decoupling the data model should make it possible.
Thanks,
Trevor
On Mon, Feb 20, 2017 at 5:54 PM, Martin Preisler mpreisle@redhat.com wrote:
On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec zmoravec@redhat.com wrote:
Hi,
database sounds like interesting idea. I didn't think about it in that
way.
In my opinion, XML DB could be way how to store many SSG "items", not
only OVALs/remediations.
If I understood it correctly, only overhead of adding of new remediation
would be
adding bindings to product, right?
I don't have own experience with XML databases. What does rest of SSG
community think about it?
Personally I don't like it. It doesn't work well with our git workflow. I don't think this is what the SQL XML databases are for.
-- Martin Preisler _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
1) It seems that your scripts do not properly "interact with/query your repo" to verify, for example, if a check already exists before (re)creating it. Leading to duplicates (no reuse of states/objects/tests...)
2) It seems that you don't have a relationship between OVAL content (Definitions) and Products, making it difficult to manage or clone the OVAL Definitions for a new Product, etc.
While you could do the queries with the lxml.etree XPath-like and play with Concept drift, you can clearly use a (very simple) relational database approach for more efficient management, speed (for this use case of OVAL content generation), and object relational mapping.
On Tue, Feb 21, 2017 at 10:39 PM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
The term 'relational database' may be misleading.
What I want is a relational pairing between data segments so that later changes can be done in a traditional manner. We don't actually need to create full on tables in XML and do all that fun.
I do understand that it may break the git workflow and it will certainly break the build scripts. However, I think that it will increase the user experience and, therefore, help adoption of the suite.
I've asked before about being able to create micro data streams and extract very small parts of the standards without having to lug around the entire repo through my few hundred projects. Presently, this is not possible but decoupling the data model should make it possible.
Thanks,
Trevor
On Mon, Feb 20, 2017 at 5:54 PM, Martin Preisler mpreisle@redhat.com wrote:
On Mon, Feb 20, 2017 at 9:08 AM, Zbynek Moravec zmoravec@redhat.com wrote:
Hi,
database sounds like interesting idea. I didn't think about it in that
way.
In my opinion, XML DB could be way how to store many SSG "items", not
only OVALs/remediations.
If I understood it correctly, only overhead of adding of new
remediation would be
adding bindings to product, right?
I don't have own experience with XML databases. What does rest of SSG
community think about it?
Personally I don't like it. It doesn't work well with our git workflow. I don't think this is what the SQL XML databases are for.
-- Martin Preisler _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
scap-security-guide@lists.fedorahosted.org