On Mon, 2014-02-17 at 18:19 -0500, Spencer Shimko wrote:
On Sun, Feb 16, 2014 at 10:37 PM, Steve Grubb
<sgrubb(a)redhat.com> 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
Git workflow is definitely something that would need to looked at. A
similar workflow used by the Fedora infrastructure team is those with
commit access instead create a branch on the various projects repo. Switch
to that branch, make changes there, push it back to the remote branch on
github, then submit a pull request from that branch back into maste. The
rest of the process is similar, review, ACK'd, someone (any of the github
members with organization repo commiters) merges the pull request. The
branch is typically then deleted by the creator.
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.
The Fedora infrastructure team also have written some stuff to sync their
"upstream" github (fedora-infra) projects back into their infrastructure.
So we could always pull it back into fedorahosted as a "clean" backup
periodically.
>
>
>> * 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