[Bro-Dev] CBrAN Bro Control Plugin

anthony kasza anthony.kasza at gmail.com
Mon Oct 21 22:02:50 PDT 2013


Robin,

Were you thinking of chatting off list? If so, how and when?

-AK

On Tue, Oct 15, 2013 at 7:09 PM, anthony kasza <anthony.kasza at gmail.com> wrote:
> I like the idea of associating a commit hash to a version of a
> package. I didn't consider that and it's clever. That would make
> development of package much more fluid and assure a 'point in time'
> version of any package.
>
> My thoughts were to offer zero guarantee around package stability or
> trustworthiness to users (other than the package will install,
> uninstall, etc with broctl) unless the package is included in the Bro
> project. This would prevent the Bro team from having to manage too
> much. Package versioning, stability, and questions/support would be
> left up to package authors and package trustworthiness would be up to
> public reputation. This is generally how community apps are handled
> for Splunk.
>
> No matter how versioning is done, an announcement to all package
> authors should go out when new version of Bro are cut so to ensure
> interoperability.
>
> -AK
>
> On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke
> <jsiwek at illinois.edu> wrote:
>>
>> On Oct 14, 2013, at 7:24 PM, anthony kasza <anthony.kasza at gmail.com> wrote:
>>
>>> My thought was for the universe database to contain the following
>>> pieces of information (taken from the project page): name, URL,
>>> author, tags, package version, Bro version, dependencies, license,
>>> description.
>>
>> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front.  Maybe one question to answer first:  what level of stability and trustworthiness is expected from the universe?
>>
>> I'd say a git commit hash for versioning could give some of both.  Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version.  Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash.  Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme).
>>
>> - Jon
>
>
> On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke
> <jsiwek at illinois.edu> wrote:
>>
>> On Oct 14, 2013, at 7:24 PM, anthony kasza <anthony.kasza at gmail.com> wrote:
>>
>>> My thought was for the universe database to contain the following
>>> pieces of information (taken from the project page): name, URL,
>>> author, tags, package version, Bro version, dependencies, license,
>>> description.
>>
>> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front.  Maybe one question to answer first:  what level of stability and trustworthiness is expected from the universe?
>>
>> I'd say a git commit hash for versioning could give some of both.  Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version.  Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash.  Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme).
>>
>> - Jon
>
>
> On Tue, Oct 15, 2013 at 9:46 AM, Siwek, Jonathan Luke
> <jsiwek at illinois.edu> wrote:
>>
>> On Oct 14, 2013, at 7:24 PM, anthony kasza <anthony.kasza at gmail.com> wrote:
>>
>>> My thought was for the universe database to contain the following
>>> pieces of information (taken from the project page): name, URL,
>>> author, tags, package version, Bro version, dependencies, license,
>>> description.
>>
>> I think that sounds ok, though details of how package versioning will work may need some fleshing out up front.  Maybe one question to answer first:  what level of stability and trustworthiness is expected from the universe?
>>
>> I'd say a git commit hash for versioning could give some of both.  Stability in that external repos can progress as fast as they want, but the universe metadata should still point to a valid version.  Trustworthiness in that it's known a universe maintainer reviewed the code associated with the hash.  Problem is that a git commit hash is per-repository, but per-package versioning might be needed (i.e. limit of one package per repo w/ this scheme).
>>
>> - Jon



More information about the bro-dev mailing list