Hello folks,
in effort to increase discoverability of security compliance solutions, Simon created github's entry for OpenSCAP ecosystem yesterday: [1] https://github.com/OpenSCAP
collecting all the relevant tools / products, necessary to perform security compliance checks in automated way. The intention of this ecosystem is to have all the parts available at one place, so people interested in automated SCAP scans wouldn't need to search for: * the scanner, * tailoring / remediation tool, * the content itself at three different locations.
For now those repositories are just mirrors of their parental ones (copies which will get updated on regular basis - Simon can clarify how often).
Together with this change, we have received proposal of icon / logo for the SCAP security guide project. Though yet before you download & inspect the attached tarballs, I need to mention, there are two versions of the icons attached: * one is for current "SCAP Security Guide" project name (SCAP_logos_SCAP_security_guide.tar.gz), * the second to see the proposal if the name of the project would change to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz)
Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
In our opinion, look at OpenSCAP ecosystem [1] might induce the potential user's impression, the whole project being organized properly (all parts being available at one place and all parts named by same prefix, differing just by component's name).
The pros / cons of the name change as I was able to collect are as follows:
Pros: * whole (security compliance) solution can be viewed / looked at like having organized & unified form (distinguished just by component's name / colour of the icon),
* all the necessary bits are reachable at one place (=> lowering the potential user's "start barrier" in effort to get familiar with the concept)
Cons: * user's accustomed to old name might get confused. It might need to take some time till they get accustomed to start using new name,
* the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand) might induce the impression, it's not usable in other tools / scanners than just by OpenSCAP one. This could be overcome by us providing tutorial articles / images pinpointing the use of SCAP Security Guide content with tools (scanners) other than OpenSCAP to disperse the potential confusion (clearly state it's possible to use it in other scanners too).
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
Please express you preference(s).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Attached are icons / logos for both alternatives.
----- Original Message -----
From: "Jan Lieskovsky" jlieskov@redhat.com To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Cc: "Peter Vrabec" pvrabec@redhat.com, "Simon Lukasik" slukasik@redhat.com, "Martin Preisler" mpreisle@redhat.com Sent: Wednesday, April 30, 2014 4:08:04 PM Subject: [RFC] SCAP security guide to become member of larger community - OpenSCAP ecosystem by changing it's name to OpenSCAP security guide?
Hello folks,
in effort to increase discoverability of security compliance solutions, Simon created github's entry for OpenSCAP ecosystem yesterday: [1] https://github.com/OpenSCAP
collecting all the relevant tools / products, necessary to perform security compliance checks in automated way. The intention of this ecosystem is to have all the parts available at one place, so people interested in automated SCAP scans wouldn't need to search for:
- the scanner,
- tailoring / remediation tool,
- the content itself
at three different locations.
For now those repositories are just mirrors of their parental ones (copies which will get updated on regular basis - Simon can clarify how often).
Together with this change, we have received proposal of icon / logo for the SCAP security guide project. Though yet before you download & inspect the attached tarballs, I need to mention, there are two versions of the icons attached:
- one is for current "SCAP Security Guide" project name
(SCAP_logos_SCAP_security_guide.tar.gz),
- the second to see the proposal if the name of the project would change to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz)
Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
In our opinion, look at OpenSCAP ecosystem [1] might induce the potential user's impression, the whole project being organized properly (all parts being available at one place and all parts named by same prefix, differing just by component's name).
The pros / cons of the name change as I was able to collect are as follows:
Pros:
whole (security compliance) solution can be viewed / looked at like having organized & unified form (distinguished just by component's name / colour of the icon),
all the necessary bits are reachable at one place (=> lowering the
potential user's "start barrier" in effort to get familiar with the concept)
Cons:
user's accustomed to old name might get confused. It might need to take some time till they get accustomed to start using new name,
the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand) might induce the impression, it's not usable in other tools / scanners than just by OpenSCAP one. This could be overcome by us providing tutorial articles / images pinpointing the use of SCAP Security Guide content with tools (scanners) other than OpenSCAP to disperse the potential confusion (clearly state it's possible to use it in other scanners too).
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
On 4/30/14, 10:39 AM, Martin Preisler wrote:
----- Original Message -----
From: "Jan Lieskovsky"jlieskov@redhat.com To: "SCAP Security Guide"scap-security-guide@lists.fedorahosted.org Cc: "Peter Vrabec"pvrabec@redhat.com, "Simon Lukasik"slukasik@redhat.com, "Martin Preisler" mpreisle@redhat.com Sent: Wednesday, April 30, 2014 4:08:04 PM Subject: [RFC] SCAP security guide to become member of larger community - OpenSCAP ecosystem by changing it's name to OpenSCAP security guide?
Hello folks,
in effort to increase discoverability of security compliance solutions, Simon created github's entry for OpenSCAP ecosystem yesterday: [1]https://github.com/OpenSCAP
collecting all the relevant tools / products, necessary to perform security compliance checks in automated way. The intention of this ecosystem is to have all the parts available at one place, so people interested in automated SCAP scans wouldn't need to search for:
- the scanner,
- tailoring / remediation tool,
- the content itself
at three different locations.
For now those repositories are just mirrors of their parental ones (copies which will get updated on regular basis - Simon can clarify how often).
Together with this change, we have received proposal of icon / logo for the SCAP security guide project. Though yet before you download & inspect the attached tarballs, I need to mention, there are two versions of the icons attached:
- one is for current "SCAP Security Guide" project name
(SCAP_logos_SCAP_security_guide.tar.gz),
- the second to see the proposal if the name of the project would change to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz)
Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
In our opinion, look at OpenSCAP ecosystem [1] might induce the potential user's impression, the whole project being organized properly (all parts being available at one place and all parts named by same prefix, differing just by component's name).
The pros / cons of the name change as I was able to collect are as follows:
Pros:
whole (security compliance) solution can be viewed / looked at like having organized & unified form (distinguished just by component's name / colour of the icon),
all the necessary bits are reachable at one place (=> lowering the
potential user's "start barrier" in effort to get familiar with the concept)
Cons:
user's accustomed to old name might get confused. It might need to take some time till they get accustomed to start using new name,
the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand) might induce the impression, it's not usable in other tools / scanners than just by OpenSCAP one. This could be overcome by us providing tutorial articles / images pinpointing the use of SCAP Security Guide content with tools (scanners) other than OpenSCAP to disperse the potential confusion (clearly state it's possible to use it in other scanners too).
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
Jan, thank you for starting this conversation! I'm _*very*_ much in favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the interpreter. If we rename SSG to "OpenSCAP Security Guide," the name creates an impression the content would only work with OpenSCAP. For this reason, are you proposing we change the OpenSCAP interpreter as well? e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content, which includes: * OpenSCAP Workbench: Used for tailoring content (formerally scap-workbench) * OpenSCAP Interpreter: A cross platform, open source SCAP interpreter) * OpenSCAP Content: An open source project delivering a large body of SCAP content. Used as upstream for such profiles as the STIG and C2S * OpenSCAP Anaconda Plugin: A project to integrate SCAP scanning into Linux provisioning * OpenSCAP Spacewalk Plugin: A project to integrate centralized SCAP scanning into the Spacewalk/Satellite system management software
Shawn,
I like your explanation and naming of the components. OpenSCAP as the umbrella project name makes sense.
Greg
On Thu, May 1, 2014 at 2:31 PM, Shawn Wells shawn@redhat.com wrote:
On 4/30/14, 10:39 AM, Martin Preisler wrote:
----- Original Message -----
From: "Jan Lieskovsky" jlieskov@redhat.com jlieskov@redhat.com> To: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org scap-security-guide@lists.fedorahosted.org> Cc: "Peter Vrabec" pvrabec@redhat.com pvrabec@redhat.com, "Simon Lukasik" slukasik@redhat.com slukasik@redhat.com, "Martin Preisler"> mpreisle@redhat.com mpreisle@redhat.com> Sent: Wednesday, April 30, 2014 4:08:04 PM> Subject: [RFC] SCAP security guide to become member of larger community - OpenSCAP ecosystem by changing it's name to> OpenSCAP security guide?> > Hello folks,> > in effort to increase discoverability of security compliance solutions,> Simon created github's entry for OpenSCAP ecosystem yesterday:> [1] https://github.com/OpenSCAP%3E > collecting all the relevant tools / products, necessary to perform> security compliance checks in automated way. The intention of this> ecosystem is to have all the parts available at one place, so people> interested in automated SCAP scans wouldn't need to search for:> * the scanner,> * tailoring / remediation tool,> * the content itself> at three different locations.> > For now those repositories are just mirrors of their parental ones> (copies which will get updated on regular basis - Simon can clarify> how often).> > Together with this change, we have received proposal of icon / logo> for the SCAP security guide project. Though yet before you download> & inspect the attached tarballs, I need to mention, there are two> versions of the icons attached:> * one is for current "SCAP Security Guide" project name> (SCAP_logos_SCAP_security_guide.tar.gz),> * the second to see the proposal if the name of the project would change> to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz)> > Since there's effort to create OpenSCAP ecosystem, of which SCAP security> guide> project is its indisputable part, besides cloning the repository, the other> natural subsequent step, coming to mind is to have the project renamed> from SCAP security guide to OpenSCAP security guide.> > In our opinion, look at OpenSCAP ecosystem [1] might induce the potential> user's impression, the whole project being organized properly (all parts> being available at one place and all parts named by same prefix, differing> just by component's name).> > The pros / cons of the name change as I was able to collect are as follows:> > Pros:> * whole (security compliance) solution can be viewed / looked at like> having organized & unified form (distinguished just by component's name /> colour of the icon),> > * all the necessary bits are reachable at one place (=> lowering the> potential> user's "start barrier" in effort to get familiar with the concept)> > Cons:> * user's accustomed to old name might get confused. It might need to take> some time till they get accustomed to start using new name,> > * the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand)> might induce the impression, it's not usable in other tools / scanners> than just by OpenSCAP one. This could be overcome by us providing tutorial> articles / images pinpointing the use of SCAP Security Guide content with> tools (scanners) other than OpenSCAP to disperse the potential confusion> (clearly state it's possible to use it in other scanners too).> > To express my subjective opinion I like the idea of the project to be> renamed to "OpenSCAP Security Guide". But wanted to know wider opinions> from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
Jan, thank you for starting this conversation! I'm *very* much in favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the interpreter. If we rename SSG to "OpenSCAP Security Guide," the name creates an impression the content would only work with OpenSCAP. For this reason, are you proposing we change the OpenSCAP interpreter as well? e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content, which includes: * OpenSCAP Workbench: Used for tailoring content (formerally scap-workbench) * OpenSCAP Interpreter: A cross platform, open source SCAP interpreter) * OpenSCAP Content: An open source project delivering a large body of SCAP content. Used as upstream for such profiles as the STIG and C2S * OpenSCAP Anaconda Plugin: A project to integrate SCAP scanning into Linux provisioning * OpenSCAP Spacewalk Plugin: A project to integrate centralized SCAP scanning into the Spacewalk/Satellite system management software
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 05/01/2014 08:31 PM, Shawn Wells wrote:
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
Jan, thank you for starting this conversation! I'm _*very*_ much in favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the interpreter. If we rename SSG to "OpenSCAP Security Guide," the name creates an impression the content would only work with OpenSCAP. For this reason, are you proposing we change the OpenSCAP interpreter as well? e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content, which includes: * OpenSCAP Workbench: Used for tailoring content (formerally scap-workbench) * OpenSCAP Interpreter: A cross platform, open source SCAP interpreter) * OpenSCAP Content: An open source project delivering a large body of SCAP content. Used as upstream for such profiles as the STIG and C2S * OpenSCAP Anaconda Plugin: A project to integrate SCAP scanning into Linux provisioning * OpenSCAP Spacewalk Plugin: A project to integrate centralized SCAP scanning into the Spacewalk/Satellite system management software
I like this idea.
However, I am afraid we are not able to enforce openscap package rename everywhere to ensure consistent look. OpenSCAP library is spread across to many downstreams. That leads me to conclusion that perhaps we don't need to rename the downstream packages. Perhaps, we can just leverage this idea to better describe ecosystem to newcomers.
Simon, you don't think like versioning new names could be created and gradually over time downstream users would adopt new names as they adopted new versions?
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On May 6, 2014, at 4:35 AM, Simon Lukasik isimluk@fedoraproject.org wrote:
On 05/01/2014 08:31 PM, Shawn Wells wrote:
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
Jan, thank you for starting this conversation! I'm _*very*_ much in favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the interpreter. If we rename SSG to "OpenSCAP Security Guide," the name creates an impression the content would only work with OpenSCAP. For this reason, are you proposing we change the OpenSCAP interpreter as well? e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content, which includes: * OpenSCAP Workbench: Used for tailoring content (formerally scap-workbench) * OpenSCAP Interpreter: A cross platform, open source SCAP interpreter) * OpenSCAP Content: An open source project delivering a large body of SCAP content. Used as upstream for such profiles as the STIG and C2S * OpenSCAP Anaconda Plugin: A project to integrate SCAP scanning into Linux provisioning * OpenSCAP Spacewalk Plugin: A project to integrate centralized SCAP scanning into the Spacewalk/Satellite system management software
I like this idea.
However, I am afraid we are not able to enforce openscap package rename everywhere to ensure consistent look. OpenSCAP library is spread across to many downstreams. That leads me to conclusion that perhaps we don't need to rename the downstream packages. Perhaps, we can just leverage this idea to better describe ecosystem to newcomers.
-- Simon Lukasik Security Technologies _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 5/6/14, 4:35 AM, Simon Lukasik wrote:
On 05/01/2014 08:31 PM, Shawn Wells wrote:
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider
opinions
from the community on the potential translation.
I think it's not necessary to rename the projects themselves. However I am all for promoting the OpenSCAP "umbrella" and cross linking the projects. Renaming the projects would be very costly and confusing for existing users. The benefits aren't worth it IMO.
In my opinion scap-security-guide should stay as is because openscap-security-guide implies a tool lock-in which is not the case.
Jan, thank you for starting this conversation! I'm _*very*_ much in favor of a unified umbrella/naming.
As sgrubb pointed out, OpenSCAP has classically been the interpreter. If we rename SSG to "OpenSCAP Security Guide," the name creates an impression the content would only work with OpenSCAP. For this reason, are you proposing we change the OpenSCAP interpreter as well? e.g.:
OpenSCAP: A portfolio of open source SCAP utilities and content, which includes: * OpenSCAP Workbench: Used for tailoring content (formerally scap-workbench) * OpenSCAP Interpreter: A cross platform, open source SCAP interpreter) * OpenSCAP Content: An open source project delivering a large body of SCAP content. Used as upstream for such profiles as the STIG and C2S * OpenSCAP Anaconda Plugin: A project to integrate SCAP scanning into Linux provisioning * OpenSCAP Spacewalk Plugin: A project to integrate centralized SCAP scanning into the Spacewalk/Satellite system management software
I like this idea.
However, I am afraid we are not able to enforce openscap package rename everywhere to ensure consistent look. OpenSCAP library is spread across to many downstreams. That leads me to conclusion that perhaps we don't need to rename the downstream packages. Perhaps, we can just leverage this idea to better describe ecosystem to newcomers.
Having a 90% solution is better than none; I see no harm if the OpenSCAP library package remains an outlier. As Greg pointed out, the impact of any change could be made over time (e.g. perhaps RHEL7).
Today downstream already follows the openscap-* naming scheme, e.g. from RHEL 6.5:
# yum search openscap ... firstaidkit-plugin-openscap.noarch : OpenSCAP plugin for FirstAidKit openscap-devel.i686 : Development files for openscap openscap-devel.x86_64 : Development files for openscap openscap-engine-sce.x86_64 : Script Check Engine plug-in for OpenSCAP openscap-engine-sce-devel.x86_64 : Development files for openscap-engine-sce openscap-perl.x86_64 : Perl bindings for openscap openscap-python.x86_64 : Python bindings for openscap openscap-utils.x86_64 : Openscap utilities openscap.i686 : Set of open source libraries enabling integration of the SCAP line of standards openscap.x86_64 : Set of open source libraries enabling integration of the SCAP line of standards openscap-content.x86_64 : SCAP content openscap-content.noarch : SCAP content openscap-extra-probes.x86_64 : SCAP probes
Formally changing "SCAP Workbench" to "OpenSCAP Workbench," or SSG to "OpenSCAP Content" seems acceptable.
One catch is that RHEL already has a package "openscap-content." Perhaps we could absorb the name? Or would this cause issues?
On Wednesday, April 30, 2014 10:08:04 AM Jan Lieskovsky wrote:
Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
While the SSG project uses oscap to manipulate the xml, the results are by no means exclusive to openscap. I think the resulting documents should be tool neutral. IOW, its part of a bigger ecosystem "as is".
-Steve
Learning about this baselines and SCAP over past year+ has been confusing.
So I like idea of re naming and rebranding to improve adoption and use.
SCAP, SSG, SSP, etc. I have been in IT for 20 years and have worked for telcos and fed gov. Though I am no stranger to acronyms, SSG is very confusing bc of SSP and not in a good way. OpenSCAP Security Guide remains confusing. Is OpenSCAP a definer of security configuration baselines itself?
I thought OpenSCAP is a tool that can interpret any guide (eg profile) written in SCAP, right?
If I follow SSG do I immediately get a baseline for Federal Desktop or Server? My current understanding is "kinda" only bc the default profile is base on it but "not really" bc you can change the profiles and you are suppose to.
It seems to me OpenSCAP is a tool. And any Guide must be tied to a baseline config from an authority with ability to accept and bless implementations and tests of that config. As a developer or Auditor, isn't what I care about the is the configuration as per an authority issue and approving it?
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Apr 30, 2014, at 7:14 PM, Steve Grubb sgrubb@redhat.com wrote:
On Wednesday, April 30, 2014 10:08:04 AM Jan Lieskovsky wrote: Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
While the SSG project uses oscap to manipulate the xml, the results are by no means exclusive to openscap. I think the resulting documents should be tool neutral. IOW, its part of a bigger ecosystem "as is".
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
On 04/30/2014 04:08 PM, Jan Lieskovsky wrote:
Hello folks,
in effort to increase discoverability of security compliance solutions, Simon created github's entry for OpenSCAP ecosystem yesterday: [1] https://github.com/OpenSCAP
collecting all the relevant tools / products, necessary to perform security compliance checks in automated way. The intention of this ecosystem is to have all the parts available at one place, so people interested in automated SCAP scans wouldn't need to search for:
- the scanner,
- tailoring / remediation tool,
- the content itself
at three different locations.
For now those repositories are just mirrors of their parental ones (copies which will get updated on regular basis - Simon can clarify how often).
Once a while. :)
If any of the projects likes the new location and wants to use it as the upstream. I am prepared to hand over the permissions.
Together with this change, we have received proposal of icon / logo for the SCAP security guide project. Though yet before you download & inspect the attached tarballs, I need to mention, there are two versions of the icons attached:
- one is for current "SCAP Security Guide" project name (SCAP_logos_SCAP_security_guide.tar.gz),
- the second to see the proposal if the name of the project would change to "OpenSCAP Security Guide" (OpenSCAP_logos_SCAP_security_guide.tar.gz)
Since there's effort to create OpenSCAP ecosystem, of which SCAP security guide project is its indisputable part, besides cloning the repository, the other natural subsequent step, coming to mind is to have the project renamed from SCAP security guide to OpenSCAP security guide.
In our opinion, look at OpenSCAP ecosystem [1] might induce the potential user's impression, the whole project being organized properly (all parts being available at one place and all parts named by same prefix, differing just by component's name).
The pros / cons of the name change as I was able to collect are as follows:
Pros:
whole (security compliance) solution can be viewed / looked at like having organized & unified form (distinguished just by component's name / colour of the icon),
all the necessary bits are reachable at one place (=> lowering the potential user's "start barrier" in effort to get familiar with the concept)
Cons:
user's accustomed to old name might get confused. It might need to take some time till they get accustomed to start using new name,
the content being named "OpenSCAP Security Guide" (IOW with OpenSCAP brand) might induce the impression, it's not usable in other tools / scanners than just by OpenSCAP one. This could be overcome by us providing tutorial articles / images pinpointing the use of SCAP Security Guide content with tools (scanners) other than OpenSCAP to disperse the potential confusion (clearly state it's possible to use it in other scanners too).
To express my subjective opinion I like the idea of the project to be renamed to "OpenSCAP Security Guide". But wanted to know wider opinions from the community on the potential translation.
Please express you preference(s).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
P.S.: Attached are icons / logos for both alternatives.
I very much like the unified look of the OpenSCAP* icons. I believe that we don't need to rename the individual projects. However, I like the OpenSCAP brand, and I believe that using OpenSCAP* icons brings a value, i.e. it could be more digestible for newcomers.
scap-security-guide@lists.fedorahosted.org