[Bro-Dev] CBrAN Bro Control Plugin

anthony kasza anthony.kasza at gmail.com
Tue Oct 15 19:09:40 PDT 2013


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