SCAP Content Submission ...

Jan Lieskovsky jlieskov at redhat.com
Tue Dec 9 21:30:27 UTC 2014


----- Original Message -----
> From: "Trey Henefield" <trey.henefield at ultra-ats.com>
> To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> Sent: Tuesday, December 9, 2014 7:04:00 PM
> Subject: RE: SCAP Content Submission ...
> 
> 
> 
> Thanks Jan!
> 
> I have setup a github account today and am getting familiarized with the
> process. It is all new to me.

Some basic info about the GH workflow:
  [1] https://guides.github.com/introduction/flow/index.html
  [2] http://scottchacon.com/2011/08/31/github-flow.html

The GitHub help page might be helpful too:
  [3] https://help.github.com/

> 
> Is there some sort of reference you can point me to that describes the
> check-out check-in process?
> 
> I have created a fork, pulled the fork locally, but can't figure out how to
> commit my changes back to my fork to generate a pull request.

The simplified flow (once you have read [1], [2]) is as follows:
1) for the repository,
2) create a branch for the new feature (via browser):
   https://github.com/blog/1377-create-and-delete-branches

3) checkout that branch (assuming 'my_feature' is branch name)

   $ git clone -b my_feature git at github.com:your_GH_(user|nick)name_here/scap-security-guide.git

4) make the changes & commit them:

   $ git add file*.txt
   $ git commit

5) find out the current status:
   
   $ git status

6) once all changes committed, push the changes to the branch

   $ git push origin my_feature

   It's possible to see the settings by inspecting ".git/config" content

7) return back to the browser & create a pull request:
   https://help.github.com/articles/creating-a-pull-request/

See how new PR entry is created / added here:
   https://github.com/OpenSCAP/scap-security-guide/pulls

& wait for it to be reviewed / accepted.

Once that PR accepted & merged be sure to keep your fork synced
with master repo (to be able to repeat the whole process from 1) -
IOW to contribute other changes) =>
a) configure a remote for a fork:
   https://help.github.com/articles/configuring-a-remote-for-a-fork/
b) sync the fork:
   https://help.github.com/articles/syncing-a-fork/

Hope this helps

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team  

> 
> Best regards,
> 
> 
> Trey Henefield, CISSP
> Senior IAVA Engineer
> 
> Ultra Electronics
> Advanced Tactical Systems, Inc.
> 4101 Smith School Road
> Building IV, Suite 100
> Austin, TX 78744 USA
> 
> Trey.Henefield at ultra-ats.com
> Tel: +1 512 327 6795 ext. 647
> Fax: +1 512 327 8043
> Mobile: +1 512 541 6450
> 
> www.ultra-ats.com
> 
> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org
> [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of Jan
> Lieskovsky
> Sent: Tuesday, December 09, 2014 11:53 AM
> To: SCAP Security Guide
> Subject: Re: SCAP Content Submission ...
> 
> Hello Simon, Trey, folks,
> 
> ----- Original Message -----
> > From: "Simon Lukasik" <isimluk at fedoraproject.org>
> > To: "SCAP Security Guide" <scap-security-guide at lists.fedorahosted.org>
> > Sent: Tuesday, December 9, 2014 2:01:05 PM
> > Subject: Re: SCAP Content Submission ...
> > 
> > Hello Trey,
> > 
> > Thanks for sharing!
> > 
> > There seems to be a lot of changes. However, it is rather tricky to
> > merge them to the main development branch. Usually contribution to
> > opensource project is made as a series of pull requests.
> 
> Well, while this is definitely the way of SCAP content development we would
> like to follow, from time to time there are exceptions when it's worthy to
> step down from explicit requiring of following of this process / development
> model.
> 
> > 
> > Is there any chance that you would create git pull request for the
> > reposotory?
> 
> We have been previously privately contacted by Trey regarding providing the
> contribution in the form of a zip tarball. Given the scope of the change (&
> enhancements it will bring to current SCAP Security Guide
> content,) we agreed to accept the contribution in this form & perform the PR
> creation on our own resources.
> 
> This is definitely not a signal to the community that the patch proposal &
> management process should be moved to the mailing list again. But given (due
> to the scope of the contribution) the fact the Trey's change started to
> exits / started to be created in the moment SCAP Security Guide repository
> got moved to GitHub (IOW given there was some transition period of
> uncertainty which of the repository storage providers will SSG use at the
> end), we decided to accept the change for this time.
> 
> Long story short, I have created issue ticket for this:
> [1] https://github.com/OpenSCAP/scap-security-guide/issues/347
> 
> & unless someone beats me to it, will get to it within this week.
> 
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Technologies Team
> 
> > 
> > Thanks,
> > ~Š.
> > 
> > On 12/04/2014 06:45 PM, Trey Henefield wrote:
> > > 
> > > 
> > > Greetings,
> > > 
> > > I have some content I would like to contribute to the SSG community.
> > > 
> > > The content is attached in a zip file and should be extracted
> > > directly into the repo.
> > > 
> > > The summary of these changes are as follows:
> > > 
> > > -New content has been included to address DISA STIGs for:
> > > 
> > > oFirefox
> > > 
> > > oJava
> > > 
> > > oRed Hat 5 (This content addresses the Red Hat 5 STIG requirements
> > > for Red Hat 5, Red Hat 4, CentOS 5, and CentOS 4)
> > > 
> > > oWebmin
> > > 
> > > -Modified shared/transforms/combinechecks.py to include an actual
> > > timestamp in the oval content when it gets created.
> > > 
> > > -Added shared/transforms/stats.sh to display statistics when
> > > building content. The statistics identify the total number of
> > > requirements, as indicated in the stig_overlay.xml document for each
> > > STIG, the number of checks addressed by STIG requirements, and the
> > > number of fixes addressed by each STIG requirement. In addition, it
> > > also pulls in the DISA STIG information from the references folder
> > > (e.g. RHEL/5/references) and compares it with the STIG requirements
> > > in the stig_overlay.xml to support identifying differences (i.e. STIG
> > > requirements removed or added).
> > > 
> > > -Added shared/transforms/stig_refs.sh to support pulling information
> > > (CCI, CCE, Severity, SVkey, SVrelease, IA controls, and title) from
> > > the DISA STIG and automatically populating that information into the
> > > SCAP content for consistency. There could probably be a better way
> > > to script this capability, but given the large number a requirements
> > > in the RHEL5 STIG, it was a great help. This capability is not
> > > called at build time, but on an as needed basis. When executed, it
> > > should be called from within the SCAP content directory (e.g.
> > > RHEL/5) and also requires the DISA STIG XCCDF file to be available
> > > in the references folder of the SCAP content directory (e.g.
> > > RHEL/5/references). Example: `cd RHEL/5;
> > > ../../shared/transforms/stig_refs.sh`
> > > 
> > > Happy SCAPing!
> > > 
> > > Best regards,
> > > 
> > > Trey Henefield, CISSP
> > > 
> > > Senior IAVA Engineer
> > > 
> > > Ultra Electronics
> > > 
> > > Advanced Tactical Systems, Inc.
> > > 
> > > 4101 Smith School Road
> > > 
> > > Building IV, Suite 100
> > > 
> > > Austin, TX 78744 USA
> > > 
> > > Trey.Henefield at ultra-ats.com
> > > 
> > > Tel: +1 512 327 6795 ext. 647
> > > 
> > > Fax: +1 512 327 8043
> > > 
> > > Mobile: +1 512 541 6450
> > > 
> > > www.ultra-ats.com
> > > 
> > > 
> > 
> > 
> > --
> > Simon Lukasik
> > Security Technologies, Red Hat, Inc.
> > --
> > SCAP Security Guide mailing list
> > scap-security-guide at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> > https://github.com/OpenSCAP/scap-security-guide/
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
> 
> 
> 
> 
> Disclaimer
> The information contained in this communication from
> trey.henefield at ultra-ats.com sent at 2014-12-09 13:04:07 is private and may
> be legally privileged or export controlled. It is intended solely for use by
> scap-security-guide at lists.fedorahosted.org and others authorized to receive
> it. If you are not scap-security-guide at lists.fedorahosted.org you are hereby
> notified that any disclosure, copying, distribution or taking action in
> reliance of the contents of this information is strictly prohibited and may
> be unlawful.
> 
> 
> --
> SCAP Security Guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/


More information about the scap-security-guide mailing list