Le 02/01/2018 à 20:39, Shawn Wells a écrit :
On 1/2/18 6:58 AM, Marek Haicman wrote:
> Hello Olivier,
> great to hear that you were able to solve the issue! Response times
> are slower here over the holidays...
> For the cpe problem, I suggest to use datastreams. It has CPE bundled
> within, so it works out-of-the-box so to say. It wasn't so important
> in the past, where we used only standard CPEs, as these are also
> shipped as part of oscap. But now, as we included support for
> containerized environments (using SSG-based cpe:/a:machine and
> cpe:/a:container), using default will show lots of stuff not applicable.
> And I have checked the patch and merged it, thank you!
Thanks Oliver for sending your notes to the mailing list.... even if you
felt if you were just talking to yourself over the holidays :)
As a community we haven't focused much on developing a good
FAQ/knowledge base/something that archives commonly asked questions.
There's been some talk about potentially using stack overflow for this.
Would that be better than keeping a GitHub wiki page?
IMHO it would, because of the amount of developers that try stack
On the other side, most people are subscribed to the mailing list and
may not actively monitor stack overflow...
Hello Shawn, Marek and the community,
First of all, thanks for having accept my first patch into the
scap-security-guide master branch. I will try to provide other OVAL
checks and associated remediations for missing STIG rules in the next
In order to answer your questions, as a total newbie into the SSG
community so I guess with a complete external point of view, I think the
Github wiki page is the good place to add the developer rules. When I
tried to write my first check, the documentation I read was the
developer guide. In my opinion, I think it would be nice to add things
into that documentation.
Considering my small experience, I would add for example the advices
provided by Marek like using the DS file in stead of the XCCDF. In a
more general way, what about adding a chapter telling the commands to
use for validating our new checks and remediations.
For me, there is already interesting stuff in the developper guide. For
me, it was a good starting point for doing my first contributions.
Maybe I am old school but compared to SO, I prefer the documentation on
the Github pages because it's a centralized place where we can find
interesting information. And added to that, the mailing list is also a
good channel for additional support because it's also centralized with
an easy way to search for data using the archives.
Here are my 2 cents.