----- Original Message ----- > From: "Trey Henefield" <[email protected]> > To: "SCAP Security Guide" <[email protected]> > 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 [email protected]: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 > > [email protected] > Tel: +1 512 327 6795 ext. 647 > Fax: +1 512 327 8043 > Mobile: +1 512 541 6450 > > www.ultra-ats.com > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] 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" <[email protected]> > > To: "SCAP Security Guide" <[email protected]> > > 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 > > > > > > [email protected] > > > > > > 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 > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > https://github.com/OpenSCAP/scap-security-guide/ > -- > SCAP Security Guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ > > > > > Disclaimer > The information contained in this communication from > [email protected] 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 > [email protected] and others authorized to receive > it. If you are not [email protected] 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 > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
