_____________________________
From: Back, Greg <
gback@mitre.org>
Sent: Wednesday, October 5, 2016 4:34 PM
Subject: [cti] Git Submodules (was: RE: [cti] Status of CTI OASIS Open Repositories)
To: Ted Bedwell (tebedwel) <
tebedwel@cisco.com>, Robin Cover <
robin@oasis-open.org>
Cc: Terry MacDonald <
terry.macdonald@cosive.com>, <
cti@lists.oasis-open.org>,
Kirillov, Ivan A. <
ikirillov@mitre.org>, Jason Keirstead <
jason.keirstead@ca.ibm.com>,
Bret Jordan (CS) <
bret_jordan@symantec.com>
In my experience, Git submodules introduce a lot of confusion for people, and don't solve the "collection of disparate tools" problem very well. In contrast to Subversion, Git doesn't let you clone one part of a repo, but submodules aren't a great solution
to that problem either. From what I've seen, submodules are best when one project A depends on a specific state of another project B, when it isn't easy to package up B, or you want to re-use B in multiple places For example.
* the STIX 1.2 schemas include CybOX 2.1 as a submodule.
* the CybOX Patterning Grammar could be split into its own repo, and the pattern validator could incorporate that as a submodule. You could also re-use the grammar in non-Python applications via this submodule. (note that this isn't currently the state of thing
in the CTI OASIS Open repos).
If you wanted to re-use the pattern-validator in another project, it would make more sense to distribute the pattern-validator as a Python package than use a submodule. Not to keep bringing up pre-OASIS STIX/CybOX examples, but this is the approach used for
"mixbox" in python-stix, python-cybox, and python-maec.
Greg
> -----Original Message-----
> From: Robin Cover [
mailto:robin@oasis-open.org]
> Sent: Tuesday, October 04, 2016 6:02 PM
> To: Ted Bedwell (tebedwel) <
tebedwel@cisco.com>
> Cc: Terry MacDonald <
terry.macdonald@cosive.com>; Bret Jordan (CS)
> <
Bret_Jordan@symantec.com>;
cti@lists.oasis-open.org; Jason Keirstead
> <
Jason.Keirstead@ca.ibm.com>; Kirillov, Ivan A. <
ikirillov@mitre.org>;
Back,
> Greg <
gback@mitre.org>
> Subject: Re: [cti] Status of CTI OASIS Open Repositories
>
> Another resource on submodules
>
> "Working with submodules" (February 01, 2016)
>
https://github.com/blog/2104-working-with-submodules
>
>
> -rcc
>
> On Tue, Oct 4, 2016 at 3:56 PM, Ted Bedwell (tebedwel)
> <
tebedwel@cisco.com <
mailto:tebedwel@cisco.com>
> wrote:
>
>
> For the other git neophytes out there:
>
>
https://git-scm.com/book/en/v2/Git-Tools-Submodules <
https://git-
>
scm.com/book/en/v2/Git-Tools-Submodules>
>
>
http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/
> <
http://blogs.atlassian.com/2013/03/git-submodules-workflows-tips/>
>
>
>
> This seems like a viable approach.
>
>
>
> From: <
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-
>
open.org> > on behalf of Terry MacDonald <
terry.macdonald@cosive.com
> <
mailto:terry.macdonald@cosive.com> >
> Date: Tuesday, October 4, 2016 at 3:19 PM
> To: "Bret Jordan (CS)" <
Bret_Jordan@symantec.com
> <
mailto:Bret_Jordan@symantec.com> >
> Cc: "
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-
>
open.org> " <
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-open.org>
>,
> Robin Cover <
robin@oasis-open.org <
mailto:robin@oasis-open.org>
>, Jason
> Keirstead <
Jason.Keirstead@ca.ibm.com
> <
mailto:Jason.Keirstead@ca.ibm.com> >, "Kirillov, Ivan A."
> <
ikirillov@mitre.org <
mailto:ikirillov@mitre.org>
>, "Back, Greg"
> <
gback@mitre.org <
mailto:gback@mitre.org>
>
> Subject: Re: [cti] Status of CTI OASIS Open Repositories
>
>
>
> Couldn't we do a git repo containing submodules? Then each
> tool can have its own git repo, and it can be linked a submodules into the
> overall tools collection repo.
>
> This then makes it easy for everyone to get a copy of all three
> rows from one place, and yet we avoid the problems with many different
> people who only need access to parts of the git tree...
>
> Cheers
> Terry MacDonald
> Cosive
>
>
>
> On 4 Oct. 2016 9:09 am, "Bret Jordan (CS)"
> <
Bret_Jordan@symantec.com <
mailto:Bret_Jordan@symantec.com>
>
> wrote:
>
> The problem with all of this is that it is not a collection
> of repos, but rather specific repos. Including multiple projects in a single
> repo is considered "bad form". Yes, you can do funky things with TAGS and
> you can even use different directories in the same repo. But that kind of
> break the git model. So instead of OASIS creating a oasis-open project with a
> bunch of arrant TC repos underneath, it seems like OASIS should setup a TC
> specific "projects". Then the TC can create as many repos on the project that
> it wants.
>
>
>
> Bret
>
> ________________________________
>
> From:
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-
>
open.org> <
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-open.org>
> on
> behalf of Robin Cover <
robin@oasis-open.org <mailto:robin@oasis-
>
open.org> >
> Sent: Thursday, September 29, 2016 8:28:43 AM
> To: Jason Keirstead
> Cc: Kirillov, Ivan A.; Back, Greg; OASIS CTI TC
> Discussion List; Robin Cover
> Subject: Re: [cti] Status of CTI OASIS Open
> Repositories
>
>
>
> On Thu, Sep 29, 2016 at 9:14 AM, Jason Keirstead
> <
Jason.Keirstead@ca.ibm.com <
mailto:Jason.Keirstead@ca.ibm.com>
>
> wrote:
>
> RE "I don't quite understand your meaning
> here:
>
>
> "... so the public is basically only able to
> contribute to things that already exist, not contribute anything new (unless
> they proxy through a member)""
>
> It is basically tied back to the need, currently,
> to be a TC member and make a motion if you want to make a new repository
>
> OK, I understand. I'll raise the issue with Staff:
> can/should we support some means whereby a non-TC Member can easily
> make request for a new OASIS Open Repository where it's perceived that no
> existing Open Repository repository is suitable.
>
> , combined with these repositories being tied
> to very specific projects and not having a generic top-level repository.
>
> In the case at hand: the CTI TC can create an OASIS
> Open Repository described as "generic": that is your choice. I suppose you
> could also characterize some new OASIS Open Repository as "top-level"
> (notionally) if the TC members wanted to do that.
>
>
>
>
> Imagine a non-TC member has some brand
> new code they want to contribute, but it does not fall into any of these
> existing open repository categories, and we have no "generic" type of
> repository. They can not make a new repository, or even motion to make
> one, as they are not a TC member. They're stuck. The only way they could
> donate this code, would be to try to proxy through another TC member to
> get the repository created for them to commit it to. I strongly suspect that
> instead of that hassle they would just put it up on their own Github.
>
>
>
> Thanks for the clarification via examples. I'll certainly
> raise the issue with Staff. All such suggestions for improvement are
> welcome.
>
>
>
> Kindest regards and best wishes,
>
>
>
> - Robin
>
>
>
>
>
>
> -
> Jason Keirstead
> STSM, Product Architect, Security
> Intelligence, IBM Security Systems
>
www.ibm.com/security
> <
http://www.ibm.com/security> |
www.securityintelligence.com
> <
http://www.securityintelligence.com>
>
> Without data, all you are is just another
> person with an opinion - Unknown
>
>
> Robin Cover ---09/29/2016 09:28:30 AM---On
> Thu, Sep 29, 2016 at 7:02 AM, Jason Keirstead <
Jason.Keirstead@ca.ibm.com
> <
mailto:Jason.Keirstead@ca.ibm.com> > wrote:
>
> From: Robin Cover <
robin@oasis-open.org
> <
mailto:robin@oasis-open.org> >
> To: Jason Keirstead/CanEast/IBM@IBMCA
> Cc: "Kirillov, Ivan A." <
ikirillov@mitre.org
> <
mailto:ikirillov@mitre.org> >, "Back, Greg" <
gback@mitre.org
> <
mailto:gback@mitre.org> >, OASIS CTI TC Discussion List <
cti@lists.oasis-
>
open.org <
mailto:cti@lists.oasis-open.org> >, Robin Cover <robin@oasis-
>
open.org <
mailto:robin@oasis-open.org> >
> Date: 09/29/2016 09:28 AM
> Subject: Re: [cti] Status of CTI OASIS Open
> Repositories
> Sent by: <
cti@lists.oasis-open.org
> <
mailto:cti@lists.oasis-open.org> >
>
> ________________________________
>
>
>
>
> On Thu, Sep 29, 2016 at 7:02 AM, Jason
> Keirstead <
Jason.Keirstead@ca.ibm.com
> <
mailto:Jason.Keirstead@ca.ibm.com> > wrote:
>
> I hear what you are saying and there are
> definitely pros and cons to having some more generic repositories - but I am
> trying to envision the near future where we will hopefully have a whole
> bunch of various code contributions from vendors, members and hopefully
> non-members alike. This is just my opinion of course, but I think we should
> try to make the process to contribute code to the TC as light-weight as
> possible, to encourage people to contribute to our open repositories vs. just
> throw it up on their own Github account - as if they do that, then IPR and
> access is not as assured. Having to make a motion to create a new repository
> every time someone wants to contribute some new code, is a fairly
> heavyweight process in my opinion. It also means that only TC members can
> contribute any "new things", because the public can't trigger a vote on
> making a new repository - so the public is basically only able to contribute to
> things that already exist, not contribute anything new (unless they proxy
> through a member).
>
>
> Jason, I'll raise the matter of requiring a
> motion/ballot with Staff. We probably want some kind of confirmation from
> the TC Chairs(s) -- indicating that there was consensus on the key elements
> of the request (name, Maintainers, choice of FOSS license, etc)
>
> Re:
> > a whole bunch of various code
> contributions from vendors, members and hopefully non-members alike
>
> That sounds great, and OASIS Open
> Repositories are intended to support that. It's a TC decision whether you
> want more or fewer repositories. It's a TC decision as to whether the repos
> are described as "generic" or having closely defined focus.
>
> I don't quite understand your meaning here:
>
> "... so the public is basically only able to
> contribute to things that already exist, not contribute anything new (unless
> they proxy through a member)"
>
> For the OASIS Open Repositories, once the
> repo is created, anyone from "the public" (non-TC member) can be a full
> participant, including Maintainer, per consensus. They can contribute "new
> things" in the same way as anyone can contribute new things to any GitHub
> public repository. Perhaps I misunderstand your concern....
>
> I have assumed, maybe incorrectly, that your
> mention of a new repository (additional to those reported by Greg Back [1])
> meant you want a new OASIS Open Repository (
https://www.oasis-
>
open.org/resources/open-repositories <
https://www.oasis-
>
open.org/resources/open-repositories> )
>
> - Robin
>
>
> [1]
>
> cti-stix2-json-schemas
> cti-pattern-validator
> cti-marking-prototype
> cti-stix-visualization
> cti-stix-validator
> cti-documentation
> cti-cybox3-json-schemas
>
>
>
>
> -
> Jason Keirstead
> STSM, Product Architect, Security
> Intelligence, IBM Security Systems
>
www.ibm.com/security
> <
http://www.ibm.com/security> |
www.securityintelligence.com
> <
http://www.securityintelligence.com/>
>
> Without data, all you are is just another
> person with an opinion - Unknown
>
>
> Robin Cover ---09/28/2016 10:35:01 PM---
> Jason, The decision about creating something like "stix-tools" is (of course) a
>
> From: Robin Cover <
robin@oasis-open.org
> <
mailto:robin@oasis-open.org> >
> To: Jason Keirstead/CanEast/IBM@IBMCA
> Cc: "Kirillov, Ivan A." <
ikirillov@mitre.org
> <
mailto:ikirillov@mitre.org> >, "Back, Greg" <
gback@mitre.org
> <
mailto:gback@mitre.org> >, OASIS CTI TC Discussion List <
cti@lists.oasis-
>
open.org <
mailto:cti@lists.oasis-open.org> >, Robin Cover <robin@oasis-
>
open.org <
mailto:robin@oasis-open.org> >
> Date: 09/28/2016 10:35 PM
> Subject: Re: [cti] Status of CTI OASIS Open
> Repositories
> Sent by: <
cti@lists.oasis-open.org
> <
mailto:cti@lists.oasis-open.org> >
>
> ________________________________
>
>
>
>
> Jason,
>
> The decision about creating something like
> "stix-tools" is (of course) a decision for the TC members, and I have no horse
> in the race.
>
> Some might think "-tools" itself is too broad,
> and encourage minting a name more specific to the kind of tool (or tools) you
> want to develop in the repository.
>
> One of the OASIS (SSO/SDO) peers has taken
> a position that specific-purpose GitHub repos works well, as opposed to (an
> arguably equally competent) design that uses folders within a single
> repository. Using separate repos means less work (design work, workday-
> work) when creating and applying labels to issues and pull requests: you
> don't have to permute out name elements that are scoped to the sub-
> projects within the repo. Just use one taxonomy of types/labels without
> namespace worries. And: you can five write privs to relatively more of the
> interested parties with fewer discussions about (uh) "who can/should "
> maintain which sub-projects...
>
> But as always: it's up to the TC, and I am no
> expert here.
>
> - Robin
>
> On Wed, Sep 28, 2016 at 7:48 PM, Jason
> Keirstead <
Jason.Keirstead@ca.ibm.com
> <
mailto:Jason.Keirstead@ca.ibm.com> > wrote:
>
> Hello all;
>
> IBM has been developing a STIX 2 generator,
> useful for testing tools. It is rudimentary at this point, but we will continue to
> improve upon it - and would like to share it with the community for both
> collaboration and improvement.
>
> It doesn't seem to fit into any of these
> repositories as they are named so specifically. Should we make some more
> generic one called something like "stix-tools" to cover this and also future
> potential contributions that would not fit into these buckets?
>
> --
> Sent from my mobile device, please excuse
> any typos.
>
> Kirillov, Ivan A. --- Re: [cti] Status of CTI OASIS
> Open Repositories ---
>
> From:
>
> "Kirillov, Ivan A." <
ikirillov@mitre.org <
mailto:ikirillov@mitre.org>
>
>
> To:
>
> "Back, Greg" <
gback@mitre.org <
mailto:gback@mitre.org>
>,
cti@lists.oasis-
>
open.org <
mailto:cti@lists.oasis-open.org>
>
> Date:
>
> Wed, Sep 28, 2016 2:09 PM
>
> Subject:
>
> Re: [cti] Status of CTI OASIS Open Repositories
>
> ________________________________
>
>
> Great news! Trey and I hope to begin
> populating the CybOX 3 JSON schema repo soon :-)
>
> Regards,
> Ivan
>
> On 9/28/16, 12:04 PM, "
cti@lists.oasis-
>
open.org <
mailto:cti@lists.oasis-open.org> on behalf of Back, Greg"
> <
cti@lists.oasis-open.org <
mailto:cti@lists.oasis-open.org>
on behalf of
>
gback@mitre.org <
mailto:gback@mitre.org> > wrote:
>
> >The following OASIS Open repositories have
> been created and populated with content that MITRE has been developing
> on behalf of DHS.
> >
> >- cti-stix2-json-schemas
> >- cti-pattern-validator
> >- cti-marking-prototype
> >- cti-stix-visualization
> >- cti-stix-validator
> >
> >There are two other repositories that exist,
> but do not (yet) have any content:
> >
> >- cti-documentation
> >- cti-cybox3-json-schemas
> >
> >The open repositories are meant to assist
> with the development of the TC's work products (but do not contain work
> products directly). Both TC members and non-members are able to
> contribute to the repositories, but in order to do so, you must sign a
> Contributor License Agreement (CLA):
https://www.oasis-
>
open.org/resources/open-repositories/cla <
https://www.oasis-
>
open.org/resources/open-repositories/cla> . This applies *even to TC
> members*.
> >
> >We welcome participation from other
> members of the TC (or even non-members who have an interest in the TC's
> work). Please use GitHub for any issues/enhancement requests for the
> code/schemas themselves. Feel free to respond to this email if you have
> questions about the process, etc.
> >
> >You can find the repositories here:
>
https://github.com/oasis-open <
https://github.com/oasis-open>
> >
> >Thanks,
> >
> >Greg Back
> >MITRE
> >
> >------------------------------------------------------
> ---------------
> >To unsubscribe from this mail list, you must
> leave the OASIS TC that
> >generates this mail. Follow this link to all
> your TCs in OASIS at:
> >
https://www.oasis-
>
open.org/apps/org/workgroup/portal/my_workgroups.php
> <
https://www.oasis-
>
open.org/apps/org/workgroup/portal/my_workgroups.php>
> >
>
>
>
>
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>