Re: [Bro-Dev] Include C++ header file in plugin function

[Dane Wullen]

Hi Johanna,

I should've asked the question differently - If it is possible AND how I 
can do it. Sorry! :-)

But after a little bit of looking through the bro source code I found it.

%%{
     #include 
%%}

Greetings

Dane


Am 18.05.2018 um 20:33 schrieb Johanna Amann:
>>
>> Unfortunatly, to use "stringstream" I will have to include the 
>>  header file. Is this possible to do in plugin functions?
>>
>
> Sure, plugins include libraries/other headers/etc. all the time.
>
> Johanna

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Include C++ header file in plugin function

[Johanna Amann]

>
> Unfortunatly, to use "stringstream" I will have to include the 
>  header file. Is this possible to do in plugin functions?
>

Sure, plugins include libraries/other headers/etc. all the time.

Johanna
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

[Bro-Dev] Include C++ header file in plugin function

[Dane Wullen]

Hi there,

I want to write a function as a plugin to convert a 4 byte hex string 
like "405f612f" to float/double (3.49031 in this case).


An easy way to do so in C++ is this:

#include

union  ulf
{
unsigned  long  ul;
float  f;
};

int  main()
{
ulf u;
string str ="405f612f";
stringstream ss(str);
ss >> hex >> u.ul;
float  f = u.f;
cout << f << endl;
}

Unfortunatly, to use "stringstream" I will have to include the  
header file. Is this possible to do in plugin functions?


Thanks.

Dane

___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Jon Siwek]

On 5/18/18 11:11 AM, Robin Sommer wrote:

> What I was envisioning is more or less a clean slate: we'd migrate
> over a few tickets, but essentially we'd start with an empty list. I
> realize that sounds pretty harsh. However, I hardly ever see any
> activity on older tickets in JIRA, and I generally believe that the
> less open tickets a tracker has, the easier it is for people to
> understand what's actually relevant and worth spending cycles on.

I see those as independent issues:

(1) There's many open tickets: you solve that by actually addressing the 
tickets

(2) People don't know what tickets are relevant: you solve that by 
organizing (and maintaining) them according to relevance

My take is that there's been a lack of effort in (2) and if that's not 
solved, starting with a clean slate on GitHub now only means it's likely 
to eventually end up in the same situation as JIRA later.  What then? 
Move to another tracker again?

> Tagging tickets may help, but in the end if everybody just filters 95%
> out all the time anyways, I'm not sure what the value is.

The value is actually having a central place for all tickets and knowing 
there won't be ongoing hassle with keeping JIRA updated.

Or in reverse, I'm not sure what the value of keeping JIRA open at all 
is -- we either have to acknowledge its potential to go out of sync with 
GH in terms of duplicate reports, which makes it more of a hindrance 
IMO, or we still have to put effort to maintain it in addition to GH.

> That said, I'm open to a real porting effort if people do believe it's
> helpful to get all the JIRA tickets into GitHub. What do others think?

Pedantically, I'm not saying "port all JIRA tickets", I still want just 
the "valid" ones whatever we decide that to mean.  So more 
clarifications on potential porting criteria:

* Someone is likely to report the same problem again
* There's clear directions on how to reproduce an undesired behavior
* There been a proposed plan of action recently

And many tickets can be ruled out:

* Vague feature requests
* Not enough details  / difficult to reproduce
* Exceptionally old proposals / plans

My plea is: extend the porting criteria beyond "important" and "recent", 
perform a review of all existing tickets, and, if JIRA is going to stick 
around as a read-only archive, leave it in a coherent final state.

- Jon
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Alan Commike]

On Fri, May 18, 2018 at 9:12 AM Robin Sommer  wrote:

>
>
> That said, I'm open to a real porting effort if people do believe it's
> helpful to get all the JIRA tickets into GitHub. What do others think?
>

Having the historical tickets available are useful for searching to see if
someone else had a similar issue and if there's a possible work-around.

How about a solution somewhere in the middle - push all the tickets over
but mark the older/non-critical as 'won't fix'. They'll come up in searches
and can more easily be brought back alive if needed.

   ...alan


>
> Robin
>
> --
> Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Johanna Amann]

I am also more in favor of starting clean and manually letting people 
move tickets that they think are important over.

But - currently there is a lot in the tracker that are nice to have or 
potential problems that I do not ever see getting addressed.

Johanna

On 18 May 2018, at 9:17, Slagell, Adam J wrote:

> On May 18, 2018, at 11:11 AM, Robin Sommer 
> > wrote:
>
> What I was envisioning is more or less a clean slate: we'd migrate
> over a few tickets, but essentially we'd start with an empty list. I
> realize that sounds pretty harsh. However, I hardly ever see any
> activity on older tickets in JIRA, and I generally believe that the
> less open tickets a tracker has, the easier it is for people to
> understand what's actually relevant and worth spending cycles on.
> Tagging tickets may help, but in the end if everybody just filters 95%
> out all the time anyways, I'm not sure what the value is.
>
> That said, I'm open to a real porting effort if people do believe it's
> helpful to get all the JIRA tickets into GitHub. What do others think?
>
> Start clean for BIT. Unless it is marked critical, I don’t think it 
> needs to go over. If people have tickets of their own they want to 
> move over, it should not be too hard to manually recreate a couple.
>
> And after BroCon I think we kill the Jira and wiki completely. We 
> should be done with the project management and event tickets by then.
>
> --
>
> Adam J. Slagell
> Director, Cybersecurity & Networking Division
> Chief Information Security Officer
> National Center for Supercomputing Applications
> University of Illinois at Urbana-Champaign
> www.slagell.info
>
> "Under the Illinois Freedom of Information Act (FOIA), any written 
> communication to or from University employees regarding University 
> business is a public record and may be subject to public disclosure."
>
>
>
>
>
>
>
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Slagell, Adam J]

On May 18, 2018, at 11:11 AM, Robin Sommer 
> wrote:

What I was envisioning is more or less a clean slate: we'd migrate
over a few tickets, but essentially we'd start with an empty list. I
realize that sounds pretty harsh. However, I hardly ever see any
activity on older tickets in JIRA, and I generally believe that the
less open tickets a tracker has, the easier it is for people to
understand what's actually relevant and worth spending cycles on.
Tagging tickets may help, but in the end if everybody just filters 95%
out all the time anyways, I'm not sure what the value is.

That said, I'm open to a real porting effort if people do believe it's
helpful to get all the JIRA tickets into GitHub. What do others think?

Start clean for BIT. Unless it is marked critical, I don’t think it needs to go 
over. If people have tickets of their own they want to move over, it should not 
be too hard to manually recreate a couple.

And after BroCon I think we kill the Jira and wiki completely. We should be 
done with the project management and event tickets by then.

--

Adam J. Slagell
Director, Cybersecurity & Networking Division
Chief Information Security Officer
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign
www.slagell.info

"Under the Illinois Freedom of Information Act (FOIA), any written 
communication to or from University employees regarding University business is 
a public record and may be subject to public disclosure."








___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Robin Sommer]

On Fri, May 18, 2018 at 08:27 -0500, you wrote:

> Doing a half-hearted effort to migrate tickets from JIRA undermines the goal
> of having an authoritative/central location for all code + tickets.  Can we
> instead try to deal with it once and for all?

What I was envisioning is more or less a clean slate: we'd migrate
over a few tickets, but essentially we'd start with an empty list. I
realize that sounds pretty harsh. However, I hardly ever see any
activity on older tickets in JIRA, and I generally believe that the
less open tickets a tracker has, the easier it is for people to
understand what's actually relevant and worth spending cycles on.
Tagging tickets may help, but in the end if everybody just filters 95%
out all the time anyways, I'm not sure what the value is.

That said, I'm open to a real porting effort if people do believe it's
helpful to get all the JIRA tickets into GitHub. What do others think?

Robin

-- 
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Re: [Bro-Dev] Moving to GitHub?

[Jon Siwek]

On 5/17/18 6:27 PM, Robin Sommer wrote:

> That may be a bit too broad though. How about "still valid and either
> (1) quite important or (2) something we expect will be addresses
> reasonably soon"? We have many old tickets that are technically still
> valid but unlikely to see any work anytime soon (otherwise they would
> have been addressed already), and I'm worried that they would just add
> noise without value.

That sounds like a general concern about project/ticket organization and 
management.  What if valid-but-old tickets were moved into GitHub with a 
simple "backlog" tag that you can filter out?  Or we could take the 
opportunity to be better about sorting on other categories as well 
(bug/feature/etc).

There's also the possibility to start a project board page [1] to aid in 
visual organization of tasks/issues and further reduce perceived noise. 
See [2] for an example of what one of those pages could look like.

> The old tickets won't go away, the JIRA will
> remain. If something becomes relevant/active, we can always bring it
> over at that time.

Keeping the JIRA around as a backlog like that decreases 
focus/visibility -- if we want to be optimistic about community 
contributions and bug fixes, we'd have to keep calling attention to 
search in two locations, GH and JIRA, instead of just one.  We'd also 
need to stay on top of maintaining JIRA to be relatively in sync with 
anything that gets resolved in GH else keeping JIRA around may become 
more liability than useful as it gets harder and harder to tell if 
something there has actually been addressed.

Doing a half-hearted effort to migrate tickets from JIRA undermines the 
goal of having an authoritative/central location for all code + tickets. 
  Can we instead try to deal with it once and for all?

- Jon

[1] https://github.com/orgs/bro/projects
[2] https://github.com/git-lfs/git-lfs/projects/3
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev