<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 9/3/14, 12:47 PM, Vincent Passaro
      wrote:<br>
    </div>
    <blockquote
      cite="mid:3803C045-4B0D-4A7F-AF58-80B9AB46037C@buddhalabs.com"
      type="cite">
      <p class="MsoNormal"><span
          style="font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
          &quot;Times New Roman&quot;;mso-bidi-font-family:&quot;Times
          New Roman&quot;;color:#262626">I can
          relate to you experienced from your previous employers. It’s
          sometimes very
          difficult to convince leadership to buy off on pushing code
          into the Open
          Source community. <br>
          <br>
          We (the Aqueduct community) would have really liked to see Red
          Hat and their
          Employees set the standard for keeping a community working
          together, rather
          than individuals forking existing code in active projects to
          solve the exact problem. <br>
        </span></p>
    </blockquote>
    <br>
    Many Red Hat staff needed a stable, repeatable process to build a
    customized RHEL6 STIG installation disk. Code from Aqueduct was
    needed to accomplish this goal. <i>And</i> from the Tresys CLIP. <i>And</i>
    from SCAP Security Guide. <i>And</i> from some home-brew gluecode.
    Once these things were mashed together a installation disk was
    churned out in a very predictable manner, serving the purposes of
    those who needed the disks. People noticed the ability to generate
    custom, pre-STIG'd installation media and wanted to create their
    own. So we put the code on GitHub.<br>
    <br>
    Independently tracking each underlying project and figuring out what
    patches/revisions from each are needed is generally to cumbersome to
    the average user. The stig-fix-el6-kickstart [1] and stig-fix-el6
    [2] repositories are not to meant to usurp or undermine any of these
    communities, but rather snapshot each component and turn out an
    installable DVD/ISO file. This represents a very healthy
    upstream/downstream relationship. Every attempt was made to credit
    upstream sources, and you'll notice upstream sources are called out
    in the respective README files [3][4].<br>
    <br>
    Hope this clears up the stig-fix-el6-kickstart repos. They are not
    an attempt at forking any project, or to build a new community. Just
    to organize all the subprojects in a very consumable fashion (which
    is to say, generate installation disks).<br>
    <br>
    <br>
    <blockquote
      cite="mid:3803C045-4B0D-4A7F-AF58-80B9AB46037C@buddhalabs.com"
      type="cite">
      <p class="MsoNormal"><span style="color: rgb(38, 38, 38);
          font-family: Arial; font-size: 10pt;">A community is only as
          strong as it's contributors and Red Hat isn't
          contributing anything.</span></p>
      <p class="MsoNormal"><span
          style="font-size:10.0pt;font-family:Arial;mso-fareast-font-family:
          &quot;Times New Roman&quot;;mso-bidi-font-family:&quot;Times
          New Roman&quot;;color:#262626">
          If you were to pose the concept to the Aqueduct mailing list,
          the community
          would embrace your ideas of ‘allowing the customer to decide
          on what’s best for
          their site/project’ and would help you along the way. As the
          STIG matures and
          issues/fixes are committed, having the source Aqueduct code
          based being reused
          will save all of us a great deal of time. Rather than forcing
          people to pick
          which fork of the day works best for them. Again - a community
          is only as
          strong as it's contributors. <br>
          <br>
          If you’re interested in helping out the Aqueduct community,
          I’d be more than
          happy to sponsor your commit access.</span></p>
    </blockquote>
    <br>
    Hatters helped migrate the DoDBastile code from forge.mil into
    Aqueduct [5], Hatters helped create some of the first "how to use
    Aqueduct" videos [6], Hatters hosted the initial Aqueduct community
    calls [7][8][9], Hatters helped organize Aqueduct community meetups
    (such as before the DC Government Symposium [10]), and Hatters
    invited you to speak at Red Hat Summit 2012 [11]. <br>
    <br>
    Hatters also list Aqueduct as a project of interest off the official
    Red Hat Government webpage:<br>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/en/technologies/industries/government/standards">https://www.redhat.com/en/technologies/industries/government/standards</a><br>
    <br>
    And I personally wrote a blog on using Aqueduct to STIG a RHEL5 box
    (albeit, it's now somewhat outdated):<br>
<a class="moz-txt-link-freetext" href="http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/">http://blog-shawndwells.rhcloud.com/so-you-wanna-stig-a-rhel5-box-part2/</a><br>
    <br>
    My prior role at Red Hat was to cover U.S. Intelligence programs.
    During our 2012 update to Ft Meade -- which had worldwide attendance
    from staffers and contractors -- I specifically called out Aqueduct.
    Reference p91-p96:<br>
<a class="moz-txt-link-freetext" href="http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2012-02-08-MPO-Red-Hat-Update-v2.pdf">http://blog-shawndwells.rhcloud.com/wp-content/uploads/2012/07/2012-02-08-MPO-Red-Hat-Update-v2.pdf</a><br>
    <br>
    Another Hatter called out Aqueduct at Red Hat Summit 2014 as well
    (ref p17):<br>
<a class="moz-txt-link-freetext" href="http://rhsummit.files.wordpress.com/2014/04/seifried_w_0230_cloud_security.pdf">http://rhsummit.files.wordpress.com/2014/04/seifried_w_0230_cloud_security.pdf</a><br>
    <br>
    So, we should perhaps reword slightly: <br>
    "A community is only as strong as it's contributors and Red Hat
    isn't contributing anything <font color="#ff0000"><i><b>to
          Aqueduct, <u>lately</u></b></i></font>"<br>
    <br>
    And lets now address that reworded statement.<br>
    <br>
    On 7-JULY-2011, Hatters began briefing the Aqueduct on initiatives
    regarding SCAP [12][13]. Steve Grubb personally gave a webinar on
    the matter [14]. Then on 28-SEPT-2011, the Aqueduct community was
    informed the SCAP Security Guide project was starting [15]. A
    snippet from that original EMail:<br>
    <br>
    <blockquote type="cite">
      <meta charset="utf-8">
      <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">It is designed to provide security guidance and checking content in the 
SCAP formats.  Specifically, the project goal is to produce --- from a 
single body of content:

1) an informative prose guide, similar in style to NSA's RHEL 5 guide
2) a desktop settings baseline, similar in style to NIST USGCB
3) a server settings baseline,  similar in style to a STIG
4) additional baselines for other network roles (such as LAMP server)
5) a body of automated checking content in the OVAL format</pre>
    </blockquote>
    <br>
    As reflected in the text above, SSG was initially formed to build
    out prose and compliance automation content. Incredibly
    complementary to Aqueduct, which held remediation scripts.<br>
    <br>
    Almost a year later, on 1-AUG-2012, I began the conversation of
    linking SSG (compliance) with Aqueduct (remediation) [16]. My own
    words:<br>
    <blockquote type="cite">
      <meta charset="utf-8">
      <pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Today the scap-security-guide project provides scanning only 
(pass/fail), in the near future we'll start working on remediation. For 
remediation it is envisioned that we'll be able to work together with 
the Aqueduct community to provide a single document (the 
scap-security-guide) which will contain both scanning and remediation 
components.

Functionally you'll deploy RHEL, run "oscap eval --profile STIG-server" 
and receive a report stating what actions you must take to become STIG 
compliant. "oscap fix --profile STIG-server" will perform the 
remediation(s).</pre>
    </blockquote>
    <br>
    Between Sept 2011 and Aug 2012 the SSG project matured greatly. One
    of the maturation points was the establishment of a very large body
    of compliance rules which could be logically organized into profiles
    (STIG, USGCB, NIST, etc). The vision was to have SSG become more of
    an "engine" -- you run a profile, and the variables of that profile
    (say, password length) would auto-populate into human-readable prose
    guides, OVAL, and remediation scripts. This vision would enable
    multiple groups (DoD for STIG, civilian for NIST) to collaborate in
    a central location for all aspects of compliance.<br>
    <br>
    To accomplish that vision the bash scripts needed to be embedded
    inside the SSG content. There was not, nor currently is, any
    feasible way to link to external sources. Aqueduct decided to
    maintain their own bash scripts and not integrate into a
    consolidated prose-&gt;scanning-&gt;remediation process. And that's
    totally fine. But because of this decision, SSG began to embedded
    &lt;fix&gt; tags natively outside of Aqueduct. For the complete
    workflow to be established there wasn't any other choice. <br>
    <br>
    Personally, I've long known individuals attach themselves to shared
    visions, shared purposes, shared callings. But I never fully
    appreciated this until working on the SCAP Security Guide project.
    As our scope expanded from compliance checking (which is, admit it,
    boring) to an integrated compliance workflow (which is incredibly
    useful and spans multiple user communities), our community
    exponentially expanded. Today we have some 47 code committers who
    have pushed an average of 50 commits per author across 226,969 lines
    of code [17]. Our other types of contributors, those working on
    documentation, reporting bugs, and working across their spheres of
    influence advocating the use of SSG, are incredibly hard to measure
    and provide metrics on. But they are there, and they are highly
    valued. 64.14% of SSG's commits come during 0800-1800, core business
    hours [18]. Not only are SSG community members working during their
    personal time, many employers are allowing employees to work on SSG
    during working hours as it provides a direct business impact. In
    fact, the business impact has been so overwhelming that SSG will
    begin shipping natively in RHEL come RHEL 6.6 [19]. Heck, there is
    even a community college giving homework assignments to use SSG to
    harden Linux machines (<i>how cool is that?!</i>) [20].<br>
    <br>
    And the SCAP Security Guide project is but one under the umbrella of
    OpenSCAP family. A core principal of OpenSCAP is that the components
    and peripherals to enable enterprise SCAP usage should be open
    source and freely available. To us Red Hatters, that means we should
    ship them natively in the operating system. And the core components
    are (or will be shortly) shipping natively.<br>
    <br>
    The OpenSCAP interpreter reflects some 4,799 commits across 46
    authors and 1,414,106 lines of code [21]. Even Oracle has submitted
    patches to OpenSCAP [22]!<br>
    <br>
    The SCAP Workbench project, which provides a GUI to using and
    customizing SCAP, reflects some 1,114 commits across 10 authors and
    12,760 lines of code [23].<br>
    <br>
    The OSCAP Anaconda Plugin, which integrates SCAP directly into
    RHEL's installer, reflects some 222 commits across 2 authors and
    6,308 lines of code [24].<br>
    <br>
    Across the 4 core projects -- OpenSCAP interpretter, SSG, Workbench,
    and Anaconda -- there are some 1.66 million lines of source code
    from nearly 80 individual contributors. And that's just the code
    contributors! The community is so, so much more. <br>
    <br>
    <br>
    All this verbosity to provide background for the following: The
    state of technology has allowed us to move from "compliance
    craftsmanship" to "compliance manufacturing." Under this vein
    OpenSCAP has become an empowered movement across multiple
    interrelated communities, all working towards the vision of a
    holistic workflow between prose guides, scanning engines,
    remediation content, and natively provided tools. This fundamental
    shift meant that compliance scripts must be natively integrated into
    the scanning technologies. A side effect of forging unified workflow
    meant that Aqueduct would be put in a position of integrating with
    SSG -- which we welcomed, and continue to welcome, with open arms!
    -- or, unfortunately, would be left behind as the broader community
    forged ahead [yes yes, I realize how "borg"-ish this sounds]. <br>
    <br>
    When it came to the matter of "integrate or forge ahead," and in
    order for progress to be made, I had to make a decision. It was to
    forge ahead. And I beat that drum in a very loud, outspoken manner.
    So yes, when it came to Red Hat contributions, I lobbied for them to
    be made to SSG. This was not out of malintent or anger, and
    certainly not about control. When talking about SSG I proudly refer
    to the Aqueduct as part of our lineage. I state that many of the
    remediation scripts originated from Aqueduct, and I talk about the
    DoDBastile story. I actively state that Aqueduct is a perfect place
    for things like Puppet, which SSG simply isn't ready for yet. <br>
    <br>
    It's disheartening when you make comments insinuating that Red Hat,
    or any of our communities, is falling short. Upon becoming a Hatter,
    everyone is shown this video: <br>
    <a class="moz-txt-link-freetext" href="http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg">http://www.redhat.com/v/ogg/stories/RHS_RedHatWay.ogg</a><br>
    <br>
    It reflects our mission statement, which itself was developed in an
    open source fashion [25]:<br>
    <blockquote type="cite">To be the catalyst in communities of
      customers, contributors, and partners creating better technology
      the open source way.</blockquote>
    <br>
    Vince, and others in the Aqueduct community, I know my decision to
    forge ahead (effectively split from Aqueduct) gave you heartburn. In
    hindsight I can certainly identify moments where I could have been
    far less of, well, a dick. The decision weighed on me, and I often
    reflect on if I made the right one. I carry an element of personal
    guilt about it. Vince, I am sorry for how I handled the divergence
    of Aqueduct and SSG and I am sorry for any perceived role in
    devaluing the Aqueduct community. <br>
    <br>
    But do not take it out on the community. Telling a Red Hatter they
    are effectively falling short on the ethos of open source is a
    dagger to the heart. I really can't think of a more negatively
    impacting statement that cuts to the core of our ideology. Such
    comments devalue the work of people like Simon, Jan, and Martin who
    are professionals that Red Hat employs and who work on OpenSCAP
    projects as their full time job. This is completely uncalled for.<br>
    <br>
    With this long note coming to a close, it would sincerely be great
    to work together and re-unify. There's strength in numbers, and
    strength in a broad base of ideas to accomplish a goal. Constructive
    dialog on that would be incredibly welcome. Hope hasn't been lost
    for a vulcan re-unification [26]*;)<br>
    <br>
    <br>
    <br>
    [1] <a class="moz-txt-link-freetext" href="https://github.com/RedHatGov/stig-fix-el6-kickstart">https://github.com/RedHatGov/stig-fix-el6-kickstart</a><br>
    [2] <a class="moz-txt-link-freetext" href="https://github.com/RedHatGov/stig-fix-el6">https://github.com/RedHatGov/stig-fix-el6</a><br>
    [3] <a class="moz-txt-link-freetext" href="https://github.com/RedHatGov/stig-fix-el6/blob/master/README">https://github.com/RedHatGov/stig-fix-el6/blob/master/README</a><br>
    [4]
    <a class="moz-txt-link-freetext" href="https://github.com/RedHatGov/stig-fix-el6-kickstart/blob/master/README">https://github.com/RedHatGov/stig-fix-el6-kickstart/blob/master/README</a><br>
    [5]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000000.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000000.html</a><br>
    [6]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000004.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000004.html</a><br>
    [7]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000012.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-June/000012.html</a><br>
    [8]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/000034.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/000034.html</a><br>
    [9]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000080.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000080.html</a><br>
    [10]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000062.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-November/000062.html</a><br>
    [11] <a class="moz-txt-link-freetext" href="http://www.vincentpassaro.com/2012/04/01/red-hat-summit-2012-2/">http://www.vincentpassaro.com/2012/04/01/red-hat-summit-2012-2/</a><br>
    [12]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-July/000023.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-July/000023.html</a><br>
    [13]
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-talk.pdf?format=raw">https://fedorahosted.org/aqueduct/attachment/wiki/Call/intro-SCAP-tech-talk.pdf?format=raw</a><br>
    [14]
<a class="moz-txt-link-freetext" href="https://sas.elluminate.com/p.jnlp?psid=2011-07-15.0937.M.A6EDFFACF1B4203F04043FD1E3A67B.vcr&amp;sid=819">https://sas.elluminate.com/p.jnlp?psid=2011-07-15.0937.M.A6EDFFACF1B4203F04043FD1E3A67B.vcr&amp;sid=819</a><br>
    [15]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/000033.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2011-September/000033.html</a><br>
    [16]
<a class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000373.html">https://lists.fedorahosted.org/mailman/private/aqueduct/2012-August/000373.html</a><br>
    [17] <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/ssg-20140904/">http://people.redhat.com/swells/gitstats/ssg-20140904/</a><br>
    [18]
    <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/ssg-20140904/activity.html">http://people.redhat.com/swells/gitstats/ssg-20140904/activity.html</a><br>
    [19]
<a class="moz-txt-link-freetext" href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/6.6_Release_Notes/index.html#bh-chap-security">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/6.6_Release_Notes/index.html#bh-chap-security</a><br>
    [20] <a class="moz-txt-link-freetext" href="http://content.hccfl.edu/pollock/AUnixSec/Proj-C-Harden.htm">http://content.hccfl.edu/pollock/AUnixSec/Proj-C-Harden.htm</a><br>
    [21] <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/20140904-openscap/">http://people.redhat.com/swells/gitstats/20140904-openscap/</a><br>
    [22]
    <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/20140904-openscap/authors.html">http://people.redhat.com/swells/gitstats/20140904-openscap/authors.html</a><br>
    [23]
    <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/20140904-scap-workbench/">http://people.redhat.com/swells/gitstats/20140904-scap-workbench/</a><br>
    [24]
    <a class="moz-txt-link-freetext" href="http://people.redhat.com/swells/gitstats/20140904-oscap-anaconda-addon/">http://people.redhat.com/swells/gitstats/20140904-oscap-anaconda-addon/</a><br>
    [25]
<a class="moz-txt-link-freetext" href="http://www.managementexchange.com/blog/how-red-hat-used-open-source-way-develop-company-mission">http://www.managementexchange.com/blog/how-red-hat-used-open-source-way-develop-company-mission</a><br>
    [26] <a class="moz-txt-link-freetext" href="http://en.memory-alpha.org/wiki/Vulcan_reunification">http://en.memory-alpha.org/wiki/Vulcan_reunification</a><br>
    * I just realized I've been watching way, way to much Star Trek<br>
  </body>
</html>