The editor part of scap-workbench has been in a semi-broken state for a long time. The codebase is very convoluted and organic which makes refactoring very hard. It also doesn't allow undo/redo so any serious work involves many close/load cycles.
In the meantime there have been a few new workflow ideas revolving around building the final content from many small files. This helps with version control and collaboration of multiple authors. Small files and limited scope of each rule makes editing easier and less error prone than jumping around in 2 huge XMLs. In my opinion, this is the way to go for big professional content creation. For an example of this, see https://fedorahosted.org/scap-security-guide/
A GUI tool for creating *just XCCDF checklists* may be useful for creating small-scale custom content. The question is if there is demand for such a tool. In any case, writing the editor from scratch with a different approach (MVC, each change is a command -> undo/redo) is less effort than refactoring.
If anyone is strongly against this decision, now is the best time to be heard :-) Otherwise I am dropping the editor from the next release.
On Thu, 3 Jan 2013 13:34:57 -0500 (EST) Martin Preisler mpreisle@redhat.com wrote:
The editor part of scap-workbench has been in a semi-broken state for a long time. The codebase is very convoluted and organic which makes refactoring very hard. It also doesn't allow undo/redo so any serious work involves many close/load cycles.
In the meantime there have been a few new workflow ideas revolving around building the final content from many small files. This helps with version control and collaboration of multiple authors. Small files and limited scope of each rule makes editing easier and less error prone than jumping around in 2 huge XMLs. In my opinion, this is the way to go for big professional content creation. For an example of this, see https://fedorahosted.org/scap-security-guide/
A GUI tool for creating *just XCCDF checklists* may be useful for creating small-scale custom content. The question is if there is demand for such a tool. In any case, writing the editor from scratch with a different approach (MVC, each change is a command -> undo/redo) is less effort than refactoring.
If anyone is strongly against this decision, now is the best time to be heard :-) Otherwise I am dropping the editor from the next release.
I've been doing quite a bit of searching for a tool (GUI) for a customer to do one purpose:
1) edit an existing xccdf file to turn on, turn off entries in a profile and 2) edit and add/change any "fixtext" or "fix" enties in a Rule.
They are very happy with the various xccdf & oval files from CIS, USGCB, or the xccdf provided by the scap-security-guide project. They are interested only in the ease of adding "fix"es for remediation.
So the workbench-editor really does a good job for that.
scap-workbench@lists.fedorahosted.org
-
Brian Millett -
Martin Preisler