As the SSG development community grows, so does the need for matured tools and workflow. There's been some discussion of moving to GitHub. On the pro side: * Easier to signup and request commit access * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * Dramatically better ticketing system - labels - user-friendly GUI - git commit hooks (put ticket # in patch title, auto resolves ticket) - multi-developer collaboration on tickets easier through @name calls * "Pull Request" concept: Patches centrally managed and merged, ensures no missed patches on mailing list * Simplified branching (e.g. allows a -stable and -dev branch). Possible on FedoraHosted, not as intuitive * Increased reliability of infrastructure (especially latency of git pulls) On the cons: * Slight developer hassle to migrate SSH keys * "Not hosted by RedHat" -- concern from some that migrating from a redhat/fedora hosted URL will diminish project brand. What does everyone think? _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote: > As the SSG development community grows, so does the need for matured > tools and workflow. There's been some discussion of moving to GitHub. > > On the pro side: > * Easier to signup and request commit access Why is this a good thing? Do you really want _anybody_ able to commit? There has to be strict sign-off or review before committing code in any security sensitive project. > * Most committers likely to have GitHub account for other projects > anyway > * Easier for community to fork SSG code (e.g. gitmachines project) Again, why is this a good thing? Don't we want everyone making a common core of code better? Or do you want one group to fork the code and do it better and not even tell you there are problems? Keeping everyone in the same boat and rowing in the same direction is better all around. > * Dramatically better ticketing system > - labels > - user-friendly GUI > - git commit hooks (put ticket # in patch title, auto > resolves ticket) > - multi-developer collaboration on tickets easier through > @name calls > * "Pull Request" concept: Patches centrally managed and merged, > ensures no missed patches on mailing list > * Simplified branching (e.g. allows a -stable and -dev branch). > Possible on FedoraHosted, not as intuitive > * Increased reliability of infrastructure (especially latency of > git pulls) > > On the cons: > * Slight developer hassle to migrate SSH keys > * "Not hosted by RedHat" -- concern from some that migrating from a > redhat/fedora hosted URL will diminish project brand. How good is github? Its got a reputation for code that is anonymously dumped and not maintained. Another con, github has been hacked...Fedorahosted, not: https://github.com/blog/1068-public-key-security-vulnerability-and-mitiga... I personally think code provenance and supply chain assurance should trump everything else. -Steve _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote: > As the SSG development community grows, so does the need for matured > tools and workflow. There's been some discussion of moving to GitHub. > > On the pro side: > * Easier to signup and request commit access Why is this a good thing? Do you really want _anybody_ able to commit? There has to be strict sign-off or review before committing code in any security sensitive project.

> * Most committers likely to have GitHub account for other projects > anyway > * Easier for community to fork SSG code (e.g. gitmachines project) Again, why is this a good thing? Don't we want everyone making a common core of code better? Or do you want one group to fork the code and do it better and not even tell you there are problems? Keeping everyone in the same boat and rowing in the same direction is better all around.

> * Dramatically better ticketing system > - labels > - user-friendly GUI > - git commit hooks (put ticket # in patch title, auto > resolves ticket) > - multi-developer collaboration on tickets easier through > @name calls > * "Pull Request" concept: Patches centrally managed and merged, > ensures no missed patches on mailing list > * Simplified branching (e.g. allows a -stable and -dev branch). > Possible on FedoraHosted, not as intuitive > * Increased reliability of infrastructure (especially latency of > git pulls) > > On the cons: > * Slight developer hassle to migrate SSH keys > * "Not hosted by RedHat" -- concern from some that migrating from a > redhat/fedora hosted URL will diminish project brand. How good is github? Its got a reputation for code that is anonymously dumped and not maintained. Another con, github has been hacked...Fedorahosted, not: https://github.com/blog/1068-public-key-security-vulnerability-and-mitiga... I personally think code provenance and supply chain assurance should trump everything else.

-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

________________________________ From: Shawn Wells <shawn(a)redhat.com&gt; To: scap-security-guide(a)lists.fedorahosted.org Sent: Tuesday, February 18, 2014 10:32 PM Subject: Re: [RFC] time to move to github? On 2/17/14, 6:19 PM, Spencer Shimko wrote: > On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >> On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote: >>> As the SSG development community grows, so does the need for matured >>> tools and workflow. There's been some discussion of moving to GitHub. >>> >>> On the pro side: >>>      * Easier to signup and request commit access >> Why is this a good thing? Do you really want _anybody_ able to commit? There >> has to be strict sign-off or review before committing code in any security >> sensitive project. > The approval process remains similar to the current situation. Just > because people can signup and request access doesn't mean they are > granted access.  Not everyone can commit that has an account - the > project owners still grant access. Right. GitHub also makes subdivision easier, e.g. commit writes only to documentation vs core SCAP content. On FedoraHosted these would be two project spaces, "SSG Docs," and "SSG Content." On GitHub we can breakout the repos while retaining easy access through a central organizational account. >>>      * Most committers likely to have GitHub account for other projects >>> anyway >>>      * Easier for community to fork SSG code (e.g. gitmachines project) >> Again, why is this a good thing? Don't we want everyone making a common core >> of code better? Or do you want one group to fork the code and do it better and >> not even tell you there are problems? Keeping everyone in the same boat and >> rowing in the same direction is better all around. > Having a central location for decentralized development is pretty > standard and I know you've been using this model for years on other > projects.  Using the term "fork" might be a sticking point.  This > doesn't necessarily mean the traditional connotation where the code > from one project under active development is used as a starting point > for a separate project that no longer contributes back to the first > project at all.  In github forking is seen as a good thing and is > often quite beneficial to the development of the project being forked. > > I fork a project on github when I like the project and want to > contribute a change to the project.  I fork the project (read->clone), > make my changes, push my changes back to my clone on github, then > submit a pull request to the project's owner. My change gets reviewed, > commented on, and hopefully, merged into the upstream to everyone's > satisfaction.  I am making the common core better. In reality, this is > almost exactly like current distributed code development.  Except, > instead of using a mailing list for code review, you use github. > > When a github user forks they use the "fork" button.  This creates a > visible trail that you can use to see who has forked and where they've > gone with it.  As a project lead you now know a bit about the people > who are tracking your project and might be contributing. Spencer's correct; the concept if fork is favorable. Additionally, we can track forks on GitHub however on FedoraHosted we simply have no idea who downstream communities are. > In the end, regardless of where the project is hosted, it is open > source.  You can't guarantee that you're going to get a bug report > propagated upstream. But I think github is more conducive to that > workflow and you are more likely to have people telling you they're > contributing via the fork button, and telling you there are problems, > as opposed to other alternatives. > > Also, note that you don't have to use github for code review etc.  You > can use it just for a central repo.  Development progress can be made > on list without using github for review/etc.  I am still torn on which > method I like more for code review. I'd go out on a limb (branch :)) > though and say that github is more likely to receive drive-by bug > reports and code contributions than a mailing list. A lot of people > just don't want to jump on another ML for a single code change or > minor issue. The flexibility of both mailing list patches + pull requests is very ideal as we grow in content and community. >>>      * Dramatically better ticketing system >>>              - labels >>>              - user-friendly GUI >>>              - git commit hooks (put ticket # in patch title, auto >>> resolves ticket) >>>              - multi-developer collaboration on tickets easier through >>> @name calls >>>      * "Pull Request" concept: Patches centrally managed and merged, >>> ensures no missed patches on mailing list >>>      * Simplified branching (e.g. allows a -stable and -dev branch). >>> Possible on FedoraHosted, not as intuitive >>>      * Increased reliability of infrastructure (especially latency of >>> git pulls) >>> >>> On the cons: >>>      * Slight developer hassle to migrate SSH keys >>>      * "Not hosted by RedHat" -- concern from some that migrating from a >>> redhat/fedora hosted URL will diminish project brand. >> How good is github? Its got a reputation for code that is anonymously dumped >> and not maintained. Another con, github has been hacked...Fedorahosted, not: >> >> https://github.com/blog/1068-public-key-security-vulnerability-and-mitiga... >> >> I personally think code provenance and supply chain assurance should trump >> everything else. > Don't most source code sites have projects that become unmaintained > for various reasons?  I have passing interests myself, and just > because I stop using something I wrote doesn't mean I don't want to > share it, or no longer want it to be shared by others. Unmaintained > projects come along with an open ecosystem developed by people that > like to share things.  Having your project on a site that has projects > that haven't been committed to in a year doesn't impact the pedigree. > > Personally, the reason I like github (etc) is it has great tools and > features that are rather unique.  As I said above, I'm torn on which > development workflow I like better - github or the traditional mailing > list approach.  But I can say with certainty - these sites have a > great set of features that draw me to them and make contributing to > the projects easier and more painless, and I think that says a lot. > > Your supply chain assurance shouldn't come from a statement like "the > site hosting our code hasn't been hacked."  There is a long, long list > of central repositories for code that have been compromised and we all > continue to consume and use code from those sites on a daily basis. > There are numerous ways to achieve higher assurance in this area, > development processes that are actually followed, signing commits, > signing releases, distributed revision control itself, etc. Nothing > about github detracts from code provenance or supply chain assurance. To test things out (as Greg Elin suggested), I merged the code into GitHub: https://github.com/ssgproject It picked up historical changes made by those who have GitHub accounts, e.g: https://github.com/ssgproject/content/commits/master/Makefile As mentioned, GutHub can also host HTML pages, giving us a version controlled repo for the docs. We can CNAME ssgproject.org against this. https://github.com/ssgproject/ssgproject.github.io http://ssgproject.github.io/ A few days ago I also played around with the ticket system: https://github.com/ssgproject/content/issues IMO, this seems like a much better community site. What's the right way to go about this -- "just do it," or perhaps setup a poll? _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On 2/17/14, 6:19 PM, Spencer Shimko wrote: > On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: >> On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote:

To test things out (as Greg Elin suggested), I merged the code into GitHub: https://github.com/ssgproject It picked up historical changes made by those who have GitHub accounts, e.g: https://github.com/ssgproject/content/commits/master/Makefile As mentioned, GutHub can also host HTML pages, giving us a version controlled repo for the docs. We can CNAME ssgproject.org against this. https://github.com/ssgproject/ssgproject.github.io http://ssgproject.github.io/ A few days ago I also played around with the ticket system: https://github.com/ssgproject/content/issues IMO, this seems like a much better community site. What's the right way to go about this -- "just do it," or perhaps setup a poll?

_______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb <sgrubb(a)redhat.com&gt; wrote: > On Sunday, February 16, 2014 04:03:24 PM Shawn Wells wrote: >> As the SSG development community grows, so does the need for matured >> tools and workflow. There's been some discussion of moving to GitHub. >> >> On the pro side: >> * Easier to signup and request commit access > > Why is this a good thing? Do you really want _anybody_ able to commit? There > has to be strict sign-off or review before committing code in any security > sensitive project. The approval process remains similar to the current situation. Just because people can signup and request access doesn't mean they are granted access. Not everyone can commit that has an account - the project owners still grant access. > > >> * Most committers likely to have GitHub account for other projects >> anyway >> * Easier for community to fork SSG code (e.g. gitmachines project) > > Again, why is this a good thing? Don't we want everyone making a common core > of code better? Or do you want one group to fork the code and do it better and > not even tell you there are problems? Keeping everyone in the same boat and > rowing in the same direction is better all around. Having a central location for decentralized development is pretty standard and I know you've been using this model for years on other projects. Using the term "fork" might be a sticking point. This doesn't necessarily mean the traditional connotation where the code from one project under active development is used as a starting point for a separate project that no longer contributes back to the first project at all. In github forking is seen as a good thing and is often quite beneficial to the development of the project being forked. I fork a project on github when I like the project and want to contribute a change to the project. I fork the project (read->clone), make my changes, push my changes back to my clone on github, then submit a pull request to the project's owner. My change gets reviewed, commented on, and hopefully, merged into the upstream to everyone's

satisfaction. I am making the common core better. In reality, this is almost exactly like current distributed code development. Except, instead of using a mailing list for code review, you use github. When a github user forks they use the "fork" button. This creates a visible trail that you can use to see who has forked and where they've gone with it. As a project lead you now know a bit about the people who are tracking your project and might be contributing. In the end, regardless of where the project is hosted, it is open source. You can't guarantee that you're going to get a bug report propagated upstream. But I think github is more conducive to that workflow and you are more likely to have people telling you they're contributing via the fork button, and telling you there are problems, as opposed to other alternatives. Also, note that you don't have to use github for code review etc. You can use it just for a central repo. Development progress can be made on list without using github for review/etc. I am still torn on which method I like more for code review. I'd go out on a limb (branch :)) though and say that github is more likely to receive drive-by bug reports and code contributions than a mailing list. A lot of people just don't want to jump on another ML for a single code change or minor issue.

> > >> * Dramatically better ticketing system >> - labels >> - user-friendly GUI >> - git commit hooks (put ticket # in patch title, auto >> resolves ticket) >> - multi-developer collaboration on tickets easier through >> @name calls >> * "Pull Request" concept: Patches centrally managed and merged, >> ensures no missed patches on mailing list >> * Simplified branching (e.g. allows a -stable and -dev branch). >> Possible on FedoraHosted, not as intuitive >> * Increased reliability of infrastructure (especially latency of >> git pulls) >> >> On the cons: >> * Slight developer hassle to migrate SSH keys >> * "Not hosted by RedHat" -- concern from some that migrating from a >> redhat/fedora hosted URL will diminish project brand. > > How good is github? Its got a reputation for code that is anonymously dumped > and not maintained. Another con, github has been hacked...Fedorahosted, not: > > https://github.com/blog/1068-public-key-security-vulnerability-and-mitiga... > > I personally think code provenance and supply chain assurance should trump > everything else. Don't most source code sites have projects that become unmaintained for various reasons? I have passing interests myself, and just because I stop using something I wrote doesn't mean I don't want to share it, or no longer want it to be shared by others. Unmaintained projects come along with an open ecosystem developed by people that like to share things. Having your project on a site that has projects that haven't been committed to in a year doesn't impact the pedigree. Personally, the reason I like github (etc) is it has great tools and features that are rather unique. As I said above, I'm torn on which development workflow I like better - github or the traditional mailing list approach. But I can say with certainty - these sites have a great set of features that draw me to them and make contributing to the projects easier and more painless, and I think that says a lot. Your supply chain assurance shouldn't come from a statement like "the site hosting our code hasn't been hacked." There is a long, long list of central repositories for code that have been compromised and we all continue to consume and use code from those sites on a daily basis. There are numerous ways to achieve higher assurance in this area, development processes that are actually followed, signing commits, signing releases, distributed revision control itself, etc. Nothing about github detracts from code provenance or supply chain assurance. Thanks, --Spencer > > -Steve > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

From my perspective, the greatest pro is improved project management

As the SSG development community grows, so does the need for matured tools and workflow. There's been some discussion of moving to GitHub. On the pro side: * Easier to signup and request commit access * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * Dramatically better ticketing system - labels - user-friendly GUI - git commit hooks (put ticket # in patch title, auto resolves ticket) - multi-developer collaboration on tickets easier through @name calls * "Pull Request" concept: Patches centrally managed and merged, ensures no missed patches on mailing list * Simplified branching (e.g. allows a -stable and -dev branch). Possible on FedoraHosted, not as intuitive * Increased reliability of infrastructure (especially latency of git pulls) On the cons: * Slight developer hassle to migrate SSH keys * "Not hosted by RedHat" -- concern from some that migrating from a redhat/fedora hosted URL will diminish project brand. What does everyone think? _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On Wed, Feb 19, 2014 at 11:17 AM, Jeffrey Blank&lt;blank(a)eclipse.ncsc.mil&gt; wrote: > >This is a very interesting question. > > > > From my perspective, the greatest pro is improved project management > >options on GitHub (easier branching etc). The others are fairly minor > >(and many are resolved by viewing the project wiki). > > > >I am not sure I view one thing listed as a "pro" to be such, and this is > >the ease of forking. I do not want a variety of government agencies > >creating Frankenstein forks of scap-security-guide. I want them to use > >the profiling mechanisms of XCCDF to select what they need from a single > >high-quality dictionary of compliance checks (for each product for which > >such content exists). One of the unstated goals of the project is to > >keep the variety of government compliance machines under some control by > >providing a solution which meets >95% of use cases. Nothing prevents them from forking now and hosting it on an internal system, forge.mil, etc. This is an open source project, and text-based to begin with, so I think preventing forks by using Fedora Hosted is a losing battle. If you're worried that other source code repositories containing SSG content may confuse people, that is possible. However, I believe the targeted consumers of the SSG content will get it from vendors who know where the proper upstream project resides and knows to pull the content from their repository.

> > > >Also, the association of the project with Red Hat (in this case, by > >providing hosting) is very important from the Government perspective, > >which I represent. Based on interactions on other lists like MIL-OSS and Gov-Sec I think what a lot of the Government customers care about is that it is packaged, shipped, and supported by Red Hat. I might be wrong on this, but there doesn't seem to be a lot of questions raised regarding the site used to host the source code during development.

> > Forking on GitHub is a bit different. Using Greg Elin's GitMachines > project as an example, forking SSG on GitHub would allow us to: > - Track that GitMachines forked SSG; > - Establish a parent/child relationship with downstream projects; > - Remind the GitMachine developers that SSG is the upstream for SCAP > content, hopefully driving them to submit pathes/bugs > This process could help facilitate synchronization between the SSG and the STIG. If Steve Grubb has reservations, however, that should give pause. Regards, -- Leland Steinke, Security+ DISA FSO Technical Support Contractor tapestry technologies, Inc 717-267-5797 (DSN 570) leland.j.steinke.ctr(a)mail.mil (gov't) lsteinke(a)tapestrytech.com (com'l) _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

On 02/19/2014 11:17 AM, Jeffrey Blank wrote: > I do not want a variety of government agencies > creating Frankenstein forks of scap-security-guide. I am unsure whether this is worthy of a fork, but read on. > I want them to use > the profiling mechanisms of XCCDF to select what they need from a single > high-quality dictionary of compliance checks (for each product for which > such content exists). One of the unstated goals of the project is to > keep the variety of government compliance machines under some control by > providing a solution which meets >95% of use cases. Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected. A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full). We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time.

This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either.

From: "Gary Gapinski" <gapinski(a)nasa.gov&gt; To: scap-security-guide(a)lists.fedorahosted.org Sent: Wednesday, February 19, 2014 8:39:39 PM Subject: Re: [RFC] time to move to github? On 02/19/2014 11:17 AM, Jeffrey Blank wrote: > I do not want a variety of government agencies > creating Frankenstein forks of scap-security-guide. I am unsure whether this is worthy of a fork, but read on. > I want them to use > the profiling mechanisms of XCCDF to select what they need from a single > high-quality dictionary of compliance checks (for each product for which > such content exists). One of the unstated goals of the project is to > keep the variety of government compliance machines under some control by > providing a solution which meets >95% of use cases. Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected.

A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full). We intend to do this using a modified benchmark containing a single <Profile>, and applying arbitrary "profiles" to the evaluation results at a subsequent time. This is most easily done using a fork describing the necessary changes. A fork may also ease the task of having a single checklist for RHEL6 and RHEL7 comprised of parts common to both as well as parts peculiar to either. Regards, Gary -- ¹ Actually most, as we will not traipse through terabytes of local storage looking for unowned files, e.g. ² Goes back a ways: http://making-security-measurable.1364806.n2.nabble.com/role-unchecked-er.... _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

> Gary, if I got your use case from this (and your subsequent email from > today) > correctly, > the request being as follows: > * on one hand to have a "profile / checklist" of all rules (grepped by > their > uniqueness) that ever existed for RHEL {6,7} products. All rules would be > selected by default, and > * to have possibility to score only subset of them during scan What does 'grepped by their uniqueness' mean here?

Every single rule is unique in an XCCDF because it has to have a unique ID (enforced by XSD and schematron). Can 2 rules exist in a benchmark that you would consider not unique?

If each rule has @selected=true (this is recommended for all SCAP content), then the default profile serves as such "all rules" profile. Does openscap allow user to select which rules should be included in the score computation? I don't think so. If this feature is desired we have to implement it in openscap first.

> (feel free to correct me if I didn't the request details properly). > > Projected into scap-workbench functionality this means: > * have possibility to merge various profiles (by grepping various but only > unique rules), > * have possibility how to specify the subset of rules (within that > resulting > checklist) that should be scored during scan. > > scap-workbench (SW) currently supports tailoring (e.g. a way how to select > subset of rules from particular profile into new one). From that implies > to me that the first point could be (possibly) reached with currently > supported SW functionality as follows: > 1) Select particular profile. Use tailoring. Select all rules from it, and > save it. > 2) Load another profile in the "Profile:" field of the SW section, load the > previously saved tailoring file, and click customize. Naive view > suggests > SW should in that scenario allow to add rules from the selected profile > to the original tailoring (but didn't try it, so might be wrong) > > If not (Cc-ing Martin for hint on this), there should be a SW ticket: > [1] https://fedorahosted.org/scap-workbench/newticket > > created for this enhancement (please note you need to be logged in to be > able to file new SW ticket). I am having trouble understanding the use-case. Right now SW cannot merge 2 existing profiles into 1.

You can however load a tailoring file and tailor profiles in it, thus changing the profiles.

I believe the latter satisfies 2).

> For what is worthy regarding selecting just of a subset of rules, that > should > be scored during the scan, I don't think this is currently supported / > possible > in SW (Martin pls correct me here too). => This would need another ticket > to > be > filed to cover this scenario. I believe that is the case.

-- Martin Preisler

From: "Gary Gapinski" <gapinski(a)nasa.gov&gt; To: "Jan Lieskovsky" <jlieskov(a)redhat.com&gt;, scap-security-guide(a)lists.fedorahosted.org Sent: Friday, February 21, 2014 1:36:05 PM Subject: Re: [RFC] time to move to github? Hello, Jan: On 02/20/2014 05:30 AM, Jan Lieskovsky wrote: >> Our intent is to score a subset of all checklist items but have all >> items evaluated on all systems. This requires all¹ <Rule>s to be >> selected. > Gary, if I got your use case from this (and your subsequent email from > today) correctly, > the request being as follows: > * on one hand to have a "profile / checklist" of all rules (grepped by > their > uniqueness) that ever existed for RHEL {6,7} products. All rules would > be > selected by default, and > * to have possibility to score only subset of them during scan > > (feel free to correct me if I didn't the request details properly). I'll try to address this from the composite of both of my previous posts. First, to your second itemization… Yes. We wish to evaluate most rules, thus obtaining a record of security posture, while scoring an arbitrary subset. The result of such an evaluation will, subsequent to evaluation, be subjected to further analysis using arbitrary foci in a large data repository. This can be achieved using "select" and "role" attributes on a <refine-rule> element (XCCDF ≥1.2). The schema indicates these are mutable as well as weight and severity. Not so easy to achieve is to alter other parts of the checklist not subject to a tailoring profile. Our compliance metrics infrastructure — currently only XCCDF 1.4 capable — requires that benchmark id and profile id be changed, and the folks responsible wish a only a single profile to be used to reduce complexity. We track revisions using the status and version elements. Excision of unused matter such as unused rules and OCIL is optional but desirable. The altered checklist presented to the compliance metrics infrastructure need not be and is not the same as that presented as a prose document for general reference. In particular, sections such as those dealing with services such as web and email would not necessarily be immediately automated but still used as configuration guidance. I have yet to determine whether such service-specific checklist sections can be routinely automated using special rules that determine the presence or absence of such services (likely using platform qualifiers at the group or rule level). Second, to your first itemization… We intend to use a single checklist for both RHEL6 and RHEL7 (and derivatives), ideally augmented at a subsequent time for use with Debian distributions (the compliance metrics folks want as few checklists as possible: e.g., we just released a combined Internet Explorer 9/10/11 checklist). Such use requires altered platform specificity at the checklist and rule level. We had hoped that SSG use a similar approach at least for RHEL 6 and 7 (single rules and single checks where common; platform-specific checks when platform-specific checks are required, and platform-specific rules when required). In other words, a single checklist for Linux distributions having a single rule for each single security practice common to all, but possibly having different expressions in several. This is rather the same as a compilation obtained from «one "core" content repository being able to handle various use-cases». > Projected into scap-workbench functionality this means: > [snip] > > To sum up: > * either "merging of rules" is currently supported in SW already, and you > could > perform as described above. Or an RFE should be filed for it this to be > possible in the future (let me know, if I should file that ticket on > your > behalf), > * scoring subset of profile rules during scan would require new RFE ticket > (again can file it on your behalf, just let me know). > > The advantage of aforementioned approach (when compared to > scap-security-guide > fork) being in case more users having same request / use case scenario as > you, they > could profit from these (possibly new) SW features without needing to > perform > additional steps (SSG fork & own XSLT transforms implementation). > > Of course, all of the above depends on the fact if underlying standards / > scanner implementation allows this (needs deeper inspection). Stay tuned. I will. Tailoring appears adequate for rule role modification, not obviously so for some of the other desired alterations. Were I to reduce our intended checklist to a simple list, it would be one specifying each desired rule to be obtained from a repository of such individual checklist items, as well its desired select and role attributes, and the desired variable value(s) to be used. Governing this selection would be target platforms. OCIL presence or absence would be arbitrary. The resulting compilation would have an id, title, description, version, status, etc. That is not the same as a <Tailoring> construct.

Though it does not fit easily into the manner of "tailoring" anticipated by those who have devised SCAP, our intended compilation is appropriate for our current needs. > P.S.: Hopefully from the above being visible that (in my opinion) parser > tools > customizations are preferred way rather than SSG content forks (IOW > agree with Jeffrey, > that there should be one "core" content repository being able to > handle various use-cases, rather than dozen of content forks, each > of them bended to serve / handle particular instance expectations). I agree. In our case, we do not wish to perturb the individual rules and associated checks, just the manner in which they are compiled into a checklist. Ours is currently a derivation rather than a compilation. The latter is preferable, the former currently easier. Regards, Gary PS: I like github for many of the reasons thus far mentioned, and would prefer it if it made my tasks easier, which may not have anything to do with forking. The "split" of SSG content for RHEL 6 and 7 does indeed make my tasks more difficult.

Our intent is to score a subset of all checklist items but have all items evaluated on all systems. This requires all¹ <Rule>s to be selected. A <Profile> cannot alter the role² attribute of a <Rule> (to unscored rather than full).

As the SSG development community grows, so does the need for matured tools and workflow. There's been some discussion of moving to GitHub. On the pro side: * Easier to signup and request commit access * Most committers likely to have GitHub account for other projects anyway * Easier for community to fork SSG code (e.g. gitmachines project) * Dramatically better ticketing system - labels - user-friendly GUI - git commit hooks (put ticket # in patch title, auto resolves ticket) - multi-developer collaboration on tickets easier through @name calls * "Pull Request" concept: Patches centrally managed and merged, ensures no missed patches on mailing list * Simplified branching (e.g. allows a -stable and -dev branch). Possible on FedoraHosted, not as intuitive * Increased reliability of infrastructure (especially latency of git pulls) On the cons: * Slight developer hassle to migrate SSH keys * "Not hosted by RedHat" -- concern from some that migrating from a redhat/fedora hosted URL will diminish project brand. What does everyone think? _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Just out of curiosity, what happened with this in the end? I just noticed a few more suggestions that Github-style pull requests would be really useful.

Hi there, from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because: - the process of patch approval was not clear, - communication around a patch is made difficult by mail (which are already follinwg throughout the days) - current open issues are not listed and cannot be discussed by the community (to propose patch for instance) I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :)

my two cents.

From: "Greg Elin" Sent: Tuesday, April 8, 2014 9:16:29 PM I also find the patch by email process confusing.

I consider that my issue, of course, and that I need to just sit down and learn it. Alas, learning patch by email becomes one of those tasks that is very easy to put off in the face of other urgencies.

I'll ask a silly question. What if we put a branch on GitHub to test while continuing to use Fedora hosted? It would be a little extra work for a bit for someone to keep them in sync. But if they are both Git under the hood, shouldn't it be relatively easy to maintain both for a 45 day trial.

Greg Elin personal cell: 917-304-3488 personal email: greg(a)fotonotes.net email: gregelin(a)gitmachines.com On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells < shawn(a)redhat.com > wrote: On 4/8/14, 2:57 PM, Ronald wrote: Hi there, from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because: - the process of patch approval was not clear, - communication around a patch is made difficult by mail (which are already follinwg throughout the days) - current open issues are not listed and cannot be discussed by the community (to propose patch for instance) I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :) The https://fedorahosted.org/scap- security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github. my two cents. Thank you! ______________________________ _________________ scap-security-guide mailing list scap-security-guide@lists. fedorahosted.org https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

From: "Greg Elin" Sent: Wednesday, April 9, 2014 3:07:28 PM Jan, thanks for responding to me. Let's say I want to make a small patch to fix a typo. Do you have a link that explains how I would get started using current process?

Greg Greg Elin P: 917-304-3488 E: gregelin(a)gitmachines.com Sent from my iPhone > On Apr 9, 2014, at 5:59 AM, Jan Lieskovsky <jlieskov(a)redhat.com&gt; wrote: > > Hello Greg, > > thank you for the reply. > > ----- Original Message ----- >> From: "Greg Elin" >> Sent: Tuesday, April 8, 2014 9:16:29 PM >> >> I also find the patch by email process confusing. > > It's confusing because it differs from the GitHub's one? [*] Or you are > missing the Gerrit instance to be able to focus just at the most preferred > issue and have easy way to comment on that one? Or the ticketing system? > Anything else? > >> >> I consider that my issue, of course, and that I need to just sit down and >> learn it. Alas, learning patch by email becomes one of those tasks that is >> very easy to put off in the face of other urgencies. > > So the issue is git-email setup? [*] > >> >> I'll ask a silly question. What if we put a branch on GitHub to test while >> continuing to use Fedora hosted? It would be a little extra work for a bit >> for someone to keep them in sync. But if they are both Git under the hood, >> shouldn't it be relatively easy to maintain both for a 45 day trial. > > Thank you && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > [*] As already mentioned, it's documented at: > https://fedorahosted.org/scap-security-guide/wiki/becomeadeveloper > > but maybe it should be improved to be more elaborated / sophisticated like > e.g. oVirt's one: > http://www.ovirt.org/Working_with_oVirt_Gerrit > > is (so interested contributor could "in five minutes" finish the setup > easily, > and start looking into the issues) > >> >> Greg Elin >> personal cell: 917-304-3488 >> personal email: greg(a)fotonotes.net >> email: gregelin(a)gitmachines.com >> >> >> >> On Tue, Apr 8, 2014 at 3:01 PM, Shawn Wells < shawn(a)redhat.com > wrote: >> >> >> >> On 4/8/14, 2:57 PM, Ronald wrote: >> >> >> Hi there, >> >> from a personal perspective, as a github users (read biased opinion), I've >> been refrained from contributing and publishing diffs because: >> - the process of patch approval was not clear, >> - communication around a patch is made difficult by mail (which are >> already >> follinwg throughout the days) >> - current open issues are not listed and cannot be discussed by the >> community >> (to propose patch for instance) >> >> I have the feeling that a move to github would make lots of things clear >> for >> global collaboration. Although, the fact that the project is hosted at >> fedora is a good quality stamp/branding :) >> >> The https://fedorahosted.org/scap- security-guide/ could remain the same >> (for >> branding, as pointed out), however the underling source repo could be >> moved >> to github. >> >> >> >> >> >> my two cents. >> Thank you! >> >> ______________________________ _________________ >> scap-security-guide mailing list >> scap-security-guide@lists. fedorahosted.org >> https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide >> >> >> _______________________________________________ >> scap-security-guide mailing list >> scap-security-guide(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >>

From: "Frank Caviggia" Sent: Wednesday, April 9, 2014 5:33:36 AM +1 on moving the source repository to GitHub - the projects I've put up there are easy to manage and I've had great interaction with contributors.

----- Original Message ----- From: "Shawn Wells" <shawn(a)redhat.com&gt; To: scap-security-guide(a)lists.fedorahosted.org Sent: Tuesday, April 8, 2014 3:01:37 PM Subject: Re: [RFC] time to move to github? On 4/8/14, 2:57 PM, Ronald wrote: > Hi there, > > from a personal perspective, as a github users (read biased opinion), > I've been refrained from contributing and publishing diffs because: > - the process of patch approval was not clear, > - communication around a patch is made difficult by mail (which are > already follinwg throughout the days) > - current open issues are not listed and cannot be discussed by the > community (to propose patch for instance) > > I have the feeling that a move to github would make lots of things > clear for global collaboration. Although, the fact that the project is > hosted at fedora is a good quality stamp/branding :) The https://fedorahosted.org/scap-security-guide/ could remain the same (for branding, as pointed out), however the underling source repo could be moved to github. > > my two cents. Thank you! _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide -- Frank Caviggia Consultant, Red Hat fcaviggi(a)redhat.com (M) (571) 295-4560 _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Hi there, from a personal perspective, as a github users (read biased opinion), I've been refrained from contributing and publishing diffs because: - the process of patch approval was not clear, - communication around a patch is made difficult by mail (which are already follinwg throughout the days) - current open issues are not listed and cannot be discussed by the community (to propose patch for instance) I have the feeling that a move to github would make lots of things clear for global collaboration. Although, the fact that the project is hosted at fedora is a good quality stamp/branding :) my two cents. Ronald On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells <shawn(a)redhat.com&gt; wrote: > On 4/8/14, 10:16 AM, Trevor Vaughan wrote: > >> Just out of curiosity, what happened with this in the end? >> >> I just noticed a few more suggestions that Github-style pull requests >> would be really useful. >> > > There were valid opinions expressed for both staying on FedoraHosted and > migrating to GitHub. So, effectively, a stalemate. > > The SSG community has grown amazingly -- both in contributors and usage > -- and because of this success Red Hat is preparing to ship SSG in future > versions of RHEL [1]. This exacerbates the need for a manageable ticketing > system with easy patch submission as very shortly every RHEL installation > will have a copy of SSG. FedoraHosted simply wasn't designed to include the > same tooling and developer ecosystem as afforded on GitHub (and that's NOT > a ding against it's designers!). > > The community is a coalition of the willing. Our shared purpose drives > the community, and I strongly feel the need to build out tools that will > allow us to scale. I'm concerned -- likely overly so -- at how to prepare > for a wave of interest once we begin shipping in RHEL. > > With that said, who am I to *mandate* the migration to GitHub? Admittedly > part of me wants to just go ahead and do it, however that could come at > making a non-trivial amount of people (esp. committers, who would be > effected by the change) feel alienated/ignored. Certainly we can't make > everyone happy all the time, though. > > Thoughts would be *most* welcome. > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655 > > > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

Hello Trevor, ----- Original Message ----- > From: "Trevor Vaughan" > Sent: Wednesday, April 9, 2014 2:12:52 AM > > Honestly +1 here. > > I have pretty much all of my repos hosted under Github and their patch and > review process is *easy* Can you be more specific what makes that patch review process easy? Anything else behind having the patch review handled via Gerrit? > particularly when combined with the new Gerrit > system that's free for FOSS projects. So would just request Gerrit instance for SSG project via the Fedora infrastructure solve our obstacles? [*] Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team [*] You to understand I am not against moving to GitHub. Just trying to identify the difference / advantages / improvements, and if some of them would be doable without the move to GitHub (less requirements for the time / resources wrt to actions related with the move) > > Trevor > > > On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle(a)gmail.com > wrote: > > > > Hi there, > > from a personal perspective, as a github users (read biased opinion), I've > been refrained from contributing and publishing diffs because: > - the process of patch approval was not clear, > - communication around a patch is made difficult by mail (which are already > follinwg throughout the days) > - current open issues are not listed and cannot be discussed by the community > (to propose patch for instance) > > I have the feeling that a move to github would make lots of things clear for > global collaboration. Although, the fact that the project is hosted at > fedora is a good quality stamp/branding :) > > my two cents. > > Ronald > > > On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn(a)redhat.com > wrote: > > > > On 4/8/14, 10:16 AM, Trevor Vaughan wrote: > > > Just out of curiosity, what happened with this in the end? > > I just noticed a few more suggestions that Github-style pull requests would > be really useful. > > There were valid opinions expressed for both staying on FedoraHosted and > migrating to GitHub. So, effectively, a stalemate. > > The SSG community has grown amazingly -- both in contributors and usage -- > and because of this success Red Hat is preparing to ship SSG in future > versions of RHEL [1]. This exacerbates the need for a manageable ticketing > system with easy patch submission as very shortly every RHEL installation > will have a copy of SSG. FedoraHosted simply wasn't designed to include the > same tooling and developer ecosystem as afforded on GitHub (and that's NOT a > ding against it's designers!). > > The community is a coalition of the willing. Our shared purpose drives the > community, and I strongly feel the need to build out tools that will allow > us to scale. I'm concerned -- likely overly so -- at how to prepare for a > wave of interest once we begin shipping in RHEL. > > With that said, who am I to *mandate* the migration to GitHub? Admittedly > part of me wants to just go ahead and do it, however that could come at > making a non-trivial amount of people (esp. committers, who would be > effected by the change) feel alienated/ignored. Certainly we can't make > everyone happy all the time, though. > > Thoughts would be *most* welcome. > > > [1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655 > > > ______________________________ _________________ > scap-security-guide mailing list > scap-security-guide@lists. fedorahosted.org > https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide > > > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaughan(a)onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- > > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >

On Apr 9, 2014, at 9:08 AM, Trevor Vaughan <tvaughan(a)onyxpoint.com&gt; wrote: Absolutely! So, patch reviews are made easier by the following: GitHub 1) Syntax highlighting 2) Inline commenting that persists over time 3) Immediate tracing of tickets to code via hashtags 4) Notification of individuals and groups via directed responses (@) 5) Easy raw file downloads Gerrit 1) Syntax highlighting 2) Inline commenting that persists over time 3) Forced clean history based on Gerrit rules 4) Complete tracking of revision history (GitHub doesn't give you this) 5) Ability to restore abandoned changes if necessary 6) Authoritative, uncorruptable (unless you allow direct pushing) repository. If I remember correctly, FedoraHosted will not use any product not packaged with RHEL/Fedora and Gerrit proved to be too difficult to package for whatever reason. There is another Gerrit-like system that the FedoraHosted systems can use but I didn't find it to be as powerful as Gerrit when I last tried to use it. Thanks, Trevor > On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky <jlieskov(a)redhat.com&gt; wrote: > Hello Trevor, > > ----- Original Message ----- > > From: "Trevor Vaughan" > > Sent: Wednesday, April 9, 2014 2:12:52 AM > > > > Honestly +1 here. > > > > I have pretty much all of my repos hosted under Github and their patch and > > review process is *easy* > > Can you be more specific what makes that patch review process easy? Anything > else behind having the patch review handled via Gerrit? > > > particularly when combined with the new Gerrit > > system that's free for FOSS projects. > > So would just request Gerrit instance for SSG project via the Fedora infrastructure > solve our obstacles? [*] > > Thank you && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > [*] You to understand I am not against moving to GitHub. Just trying to identify > the difference / advantages / improvements, and if some of them would be > doable without the move to GitHub (less requirements for the time / resources > wrt to actions related with the move) > > > > > Trevor > > > > > > On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle(a)gmail.com > wrote: > > > > > > > > Hi there, > > > > from a personal perspective, as a github users (read biased opinion), I've > > been refrained from contributing and publishing diffs because: > > - the process of patch approval was not clear, > > - communication around a patch is made difficult by mail (which are already > > follinwg throughout the days) > > - current open issues are not listed and cannot be discussed by the community > > (to propose patch for instance) > > > > I have the feeling that a move to github would make lots of things clear for > > global collaboration. Although, the fact that the project is hosted at > > fedora is a good quality stamp/branding :) > > > > my two cents. > > > > Ronald > > > > > > On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn(a)redhat.com > wrote: > > > > > > > > On 4/8/14, 10:16 AM, Trevor Vaughan wrote: > > > > > > Just out of curiosity, what happened with this in the end? > > > > I just noticed a few more suggestions that Github-style pull requests would > > be really useful. > > > > There were valid opinions expressed for both staying on FedoraHosted and > > migrating to GitHub. So, effectively, a stalemate. > > > > The SSG community has grown amazingly -- both in contributors and usage -- > > and because of this success Red Hat is preparing to ship SSG in future > > versions of RHEL [1]. This exacerbates the need for a manageable ticketing > > system with easy patch submission as very shortly every RHEL installation > > will have a copy of SSG. FedoraHosted simply wasn't designed to include the > > same tooling and developer ecosystem as afforded on GitHub (and that's NOT a > > ding against it's designers!). > > > > The community is a coalition of the willing. Our shared purpose drives the > > community, and I strongly feel the need to build out tools that will allow > > us to scale. I'm concerned -- likely overly so -- at how to prepare for a > > wave of interest once we begin shipping in RHEL. > > > > With that said, who am I to *mandate* the migration to GitHub? Admittedly > > part of me wants to just go ahead and do it, however that could come at > > making a non-trivial amount of people (esp. committers, who would be > > effected by the change) feel alienated/ignored. Certainly we can't make > > everyone happy all the time, though. > > > > Thoughts would be *most* welcome. > > > > > > [1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655 > > > > > > ______________________________ _________________ > > scap-security-guide mailing list > > scap-security-guide@lists. fedorahosted.org > > https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide > > > > > > _______________________________________________ > > scap-security-guide mailing list > > scap-security-guide(a)lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > > > > > > -- > > Trevor Vaughan > > Vice President, Onyx Point, Inc > > (410) 541-6699 > > tvaughan(a)onyxpoint.com > > > > -- This account not approved for unencrypted proprietary information -- > > > > _______________________________________________ > > scap-security-guide mailing list > > scap-security-guide(a)lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan(a)onyxpoint.com -- This account not approved for unencrypted proprietary information -- _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

----- Original Message ----- > From: "Trevor Vaughan" > Sent: Wednesday, April 9, 2014 3:08:13 PM > > Absolutely! > > So, patch reviews are made easier by the following: > > GitHub > > 1) Syntax highlighting > 2) Inline commenting that persists over time > 3) Immediate tracing of tickets to code via hashtags > 4) Notification of individuals and groups via directed responses (@) > 5) Easy raw file downloads > > Gerrit > > 1) Syntax highlighting > 2) Inline commenting that persists over time > 3) Forced clean history based on Gerrit rules > 4) Complete tracking of revision history (GitHub doesn't give you this) > 5) Ability to restore abandoned changes if necessary > 6) Authoritative, uncorruptable (unless you allow direct pushing) > repository. Thank you for your time, Trevor. Looking at that list of such handy features I would say it's definitely worthy to give the move a try. > > If I remember correctly, FedoraHosted will not use any product not packaged > with RHEL/Fedora and Gerrit proved to be too difficult to package for > whatever reason. Yes, other thing to consider (from further look) looks it might not be that easy / straightforward to create own Gerrit instance: https://fedorahosted.org/fedora-infrastructure/ticket/2924 Looks not to be present even in OpenShift yet: https://www.openshift.com/content/instant-application-gerrit-code-review So if we wanted the power of Gerrit, we either need to: * move to GitHub, * administer our own SSG specific instance (another resources consumption) > > There is another Gerrit-like system that the FedoraHosted systems can use > but I didn't find it to be as powerful as Gerrit when I last tried to use > it. Which concrete one you have meant -- got the links? (couldn't find anything like that, but maybe my queries have just wrong keywords) Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > Thanks, > > Trevor > > > On Wed, Apr 9, 2014 at 6:05 AM, Jan Lieskovsky <jlieskov(a)redhat.com&gt; wrote: > > > Hello Trevor, > > > > ----- Original Message ----- > > > From: "Trevor Vaughan" > > > Sent: Wednesday, April 9, 2014 2:12:52 AM > > > > > > Honestly +1 here. > > > > > > I have pretty much all of my repos hosted under Github and their patch > > and > > > review process is *easy* > > > > Can you be more specific what makes that patch review process easy? > > Anything > > else behind having the patch review handled via Gerrit? > > > > > particularly when combined with the new Gerrit > > > system that's free for FOSS projects. > > > > So would just request Gerrit instance for SSG project via the Fedora > > infrastructure > > solve our obstacles? [*] > > > > Thank you && Regards, Jan. > > -- > > Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > > [*] You to understand I am not against moving to GitHub. Just trying to > > identify > > the difference / advantages / improvements, and if some of them would > > be > > doable without the move to GitHub (less requirements for the time / > > resources > > wrt to actions related with the move) > > > > > > > > Trevor > > > > > > > > > On Tue, Apr 8, 2014 at 2:57 PM, Ronald < mini.pelle(a)gmail.com > wrote: > > > > > > > > > > > > Hi there, > > > > > > from a personal perspective, as a github users (read biased opinion), > > I've > > > been refrained from contributing and publishing diffs because: > > > - the process of patch approval was not clear, > > > - communication around a patch is made difficult by mail (which are > > already > > > follinwg throughout the days) > > > - current open issues are not listed and cannot be discussed by the > > community > > > (to propose patch for instance) > > > > > > I have the feeling that a move to github would make lots of things clear > > for > > > global collaboration. Although, the fact that the project is hosted at > > > fedora is a good quality stamp/branding :) > > > > > > my two cents. > > > > > > Ronald > > > > > > > > > On Tue, Apr 8, 2014 at 7:53 PM, Shawn Wells < shawn(a)redhat.com > wrote: > > > > > > > > > > > > On 4/8/14, 10:16 AM, Trevor Vaughan wrote: > > > > > > > > > Just out of curiosity, what happened with this in the end? > > > > > > I just noticed a few more suggestions that Github-style pull requests > > would > > > be really useful. > > > > > > There were valid opinions expressed for both staying on FedoraHosted and > > > migrating to GitHub. So, effectively, a stalemate. > > > > > > The SSG community has grown amazingly -- both in contributors and usage > > -- > > > and because of this success Red Hat is preparing to ship SSG in future > > > versions of RHEL [1]. This exacerbates the need for a manageable > > ticketing > > > system with easy patch submission as very shortly every RHEL installation > > > will have a copy of SSG. FedoraHosted simply wasn't designed to include > > the > > > same tooling and developer ecosystem as afforded on GitHub (and that's > > NOT a > > > ding against it's designers!). > > > > > > The community is a coalition of the willing. Our shared purpose drives > > the > > > community, and I strongly feel the need to build out tools that will > > allow > > > us to scale. I'm concerned -- likely overly so -- at how to prepare for a > > > wave of interest once we begin shipping in RHEL. > > > > > > With that said, who am I to *mandate* the migration to GitHub? Admittedly > > > part of me wants to just go ahead and do it, however that could come at > > > making a non-trivial amount of people (esp. committers, who would be > > > effected by the change) feel alienated/ignored. Certainly we can't make > > > everyone happy all the time, though. > > > > > > Thoughts would be *most* welcome. > > > > > > > > > [1] https://bugzilla.redhat.com/ show_bug.cgi?id=1038655 > > > > > > > > > ______________________________ _________________ > > > scap-security-guide mailing list > > > scap-security-guide@lists. fedorahosted.org > > > https://lists.fedorahosted. org/mailman/listinfo/scap- security-guide > > > > > > > > > _______________________________________________ > > > scap-security-guide mailing list > > > scap-security-guide(a)lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > > > > > > > > > > > -- > > > Trevor Vaughan > > > Vice President, Onyx Point, Inc > > > (410) 541-6699 > > > tvaughan(a)onyxpoint.com > > > > > > -- This account not approved for unencrypted proprietary information -- > > > > > > _______________________________________________ > > > scap-security-guide mailing list > > > scap-security-guide(a)lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvaughan(a)onyxpoint.com > > -- This account not approved for unencrypted proprietary information -- >

Fedorahosted SSG instance has support for ticketing system: https://fedorahosted.org/scap-security-guide/report/1 But you are correct, that last one was filed ~2months ago: https://fedorahosted.org/scap-security-guide/ticket/434 and that from this PoV it might seem, there hasn't been progress on the project from that time (though obviously by count of patches provided in between this clearly isn't true).

----- Original Message ----- > From: "Shawn Wells" <shawn(a)redhat.com&gt; > Sent: Tuesday, April 8, 2014 7:53:38 PM > > On 4/8/14, 10:16 AM, Trevor Vaughan wrote: >> Just out of curiosity, what happened with this in the end? >> >> I just noticed a few more suggestions that Github-style pull requests >> would be really useful. > > There were valid opinions expressed for both staying on FedoraHosted and > migrating to GitHub. So, effectively, a stalemate. > > The SSG community has grown amazingly -- both in contributors and usage > -- and because of this success Red Hat is preparing to ship SSG in > future versions of RHEL [1]. This exacerbates the need for a manageable > ticketing system with easy patch submission as very shortly every RHEL > installation will have a copy of SSG. FedoraHosted simply wasn't > designed to include the same tooling and developer ecosystem as afforded > on GitHub (and that's NOT a ding against it's designers!). > > The community is a coalition of the willing. Our shared purpose drives > the community, and I strongly feel the need to build out tools that will > allow us to scale. I'm concerned -- likely overly so -- at how to > prepare for a wave of interest once we begin shipping in RHEL. > > With that said, who am I to *mandate* the migration to GitHub? > Admittedly part of me wants to just go ahead and do it, however that > could come at making a non-trivial amount of people (esp. committers, > who would be effected by the change) feel alienated/ignored. Certainly > we can't make everyone happy all the time, though. > > Thoughts would be *most* welcome. I think the part problem of the stalemate you mention above being we didn't create the analysis yet: * to identify current bottlenecks, * to identify current features we need, * to identify future features we might need to smoothly support scaling etc. In my opinion it's strange to switch from one hosting vendor to the another without performing this. On one hand as you said the move will take some time / resources, so the motivation should be clearly expressed why it's worthy to spend that time on the move (+ additional time current users to get familiar with the new scheme / process). On the other hand such analysis is necessary yet before we actually perform the move to know for sure, that the move will actually make the things better (that's why we need to identify the bottlenecks). So instead of asking if we should move from Fedorahosted to GitHub, we should try to identify the list of items a smooth and easy patch proposal & review process should have. We can maintain that list on the mailing list (within this thread) or even create a dedicated wiki page for that (gathering such requirements and allowing mailing list participants to offer enhancements). To start with such a list, the items which come to mind are as follows: * bottlenecks: - patch proposal / review process differs from GitHub's one => it's non-trivial for users accustomed to use GitHub way easy to flip to our scheme, - small ratio of using ticketing system functionality => new users don't have a way how to find out list of issues currently being worked at or find the most burning problem, - patch review process not separated by complexity of the fix (in other words same rules are applied for simple typo fixes on one hand, while for the complex rewrites on the other. While obviously simple typo fixes / fixes not actually changing the functionality, but rather fixing some error [failing make etc.] should have higher urgency and could have been [once tested] pushed to the repository without the need for even one ACK),

- missing user's roles on patch review process. One part what Gerrit brings (besides the patches being available online without the need for additional email communication) being the patch reviewer's role separation - there are users with ad hoc / a priori permission to submit patches (selected into the group once they provided required "level of trust") without the need to wait for ACKs (the "core upstream"). Then there are occasional contributors who based on their time possibilities might comment on particular issue / provide a patch for it, but who actually require some of the admins to submit their patch into the repo after the review. I think this point the current email communication doesn't allow us to implement. * the features: ... * the future features: - feel free to comment here what we are currently missing, and might want in the future (what GitHub has support for, and Fedorahosted doesn't) Maybe once there is conclusion from this thread / more points, as proposed we should move it to dedicated wiki page to track the already obtained consensus. Comments welcome. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655 _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

From: "Josh Kayse" Sent: Wednesday, April 9, 2014 3:48:10 PM Forgot to mention, thanks for starting this list.

On Apr 9, 2014, at 5:42 AM, Jan Lieskovsky <jlieskov(a)redhat.com&gt; wrote: > ----- Original Message ----- >> From: "Shawn Wells" <shawn(a)redhat.com&gt; >> Sent: Tuesday, April 8, 2014 7:53:38 PM >> >> On 4/8/14, 10:16 AM, Trevor Vaughan wrote: >>> Just out of curiosity, what happened with this in the end? >>> >>> I just noticed a few more suggestions that Github-style pull requests >>> would be really useful. >> >> There were valid opinions expressed for both staying on FedoraHosted and >> migrating to GitHub. So, effectively, a stalemate. >> >> The SSG community has grown amazingly -- both in contributors and usage >> -- and because of this success Red Hat is preparing to ship SSG in >> future versions of RHEL [1]. This exacerbates the need for a manageable >> ticketing system with easy patch submission as very shortly every RHEL >> installation will have a copy of SSG. FedoraHosted simply wasn't >> designed to include the same tooling and developer ecosystem as afforded >> on GitHub (and that's NOT a ding against it's designers!). >> >> The community is a coalition of the willing. Our shared purpose drives >> the community, and I strongly feel the need to build out tools that will >> allow us to scale. I'm concerned -- likely overly so -- at how to >> prepare for a wave of interest once we begin shipping in RHEL. >> >> With that said, who am I to *mandate* the migration to GitHub? >> Admittedly part of me wants to just go ahead and do it, however that >> could come at making a non-trivial amount of people (esp. committers, >> who would be effected by the change) feel alienated/ignored. Certainly >> we can't make everyone happy all the time, though. >> >> Thoughts would be *most* welcome. > > I think the part problem of the stalemate you mention above being we didn't > create the analysis yet: > * to identify current bottlenecks, > * to identify current features we need, > * to identify future features we might need to smoothly support scaling > etc. > > In my opinion it's strange to switch from one hosting vendor to the another > without performing this. On one hand as you said the move will take some > time / > resources, so the motivation should be clearly expressed why it's worthy to > spend that time on the move (+ additional time current users to get > familiar > with the new scheme / process). On the other hand such analysis is > necessary > yet before we actually perform the move to know for sure, that the move > will > actually make the things better (that's why we need to identify the > bottlenecks). > > So instead of asking if we should move from Fedorahosted to GitHub, we > should > try to identify the list of items a smooth and easy patch proposal & review > process should have. We can maintain that list on the mailing list (within > this thread) or even create a dedicated wiki page for that (gathering such > requirements > and allowing mailing list participants to offer enhancements). > > To start with such a list, the items which come to mind are as follows: > * bottlenecks: > - patch proposal / review process differs from GitHub's one => it's > non-trivial > for users accustomed to use GitHub way easy to flip to our scheme, > > - small ratio of using ticketing system functionality => new users don't > have > a way how to find out list of issues currently being worked at or find > the > most burning problem, > > - patch review process not separated by complexity of the fix (in other > words > same rules are applied for simple typo fixes on one hand, while for the > complex rewrites on the other. While obviously simple typo fixes / fixes > not actually changing the functionality, but rather fixing some error > [failing > make etc.] should have higher urgency and could have been [once tested] > pushed > to the repository without the need for even one ACK), > I’d like to point out that tracking patches on the mailing list seems to be a bottleneck. There have been multiple occasions where contributors have had to remind the list of patch sets that need to be reviewed. This requires the contributor to keep track of what patches need to be approved and what mail message the patch is tied to.

> - missing user's roles on patch review process. One part what Gerrit > brings (besides > the patches being available online without the need for additional email > communication) > being the patch reviewer's role separation - there are users with ad hoc > / a priori > permission to submit patches (selected into the group once they provided > required > "level of trust") without the need to wait for ACKs (the "core > upstream"). Then there > are occasional contributors who based on their time possibilities might > comment on > particular issue / provide a patch for it, but who actually require some > of the admins > to submit their patch into the repo after the review. I think this point > the current > email communication doesn't allow us to implement. > > * the features: > … Based on some of the bottlenecks identified, I believe there needs to be a tool that tracks patch submissions and their status. Additionally there needs to be a ticketing system to identify what needs to be worked on.

> * the future features: > - feel free to comment here what we are currently missing, and might want > in the future > (what GitHub has support for, and Fedorahosted doesn't) > > Maybe once there is conclusion from this thread / more points, as proposed > we should move > it to dedicated wiki page to track the already obtained consensus. > > Comments welcome. > > Thank you && Regards, Jan. > -- > Jan iankko Lieskovsky / Red Hat Security Technologies Team > >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1038655 > _______________________________________________ > scap-security-guide mailing list > scap-security-guide(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide Thanks, -josh _______________________________________________ scap-security-guide mailing list scap-security-guide(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide

For what it's worth, when I was playing around, importing the source from FedoraHosted to >GitHub was exceedingly trivial. It took just minutes. IIRC, I refreshed my local repo, reset my remote origin URL in .git/config to GitHub, and >did a push. Current commiters would need to do the same. Once the URL was updated everything just >worked. Also, as a wonderful surprise, it kept 'git log' information in tact. If your >GitHub EMail matches the one for prior commits, everything syncs up.