[Bro-Dev] [Auto] Merge Status
Open Merge Requests === IDComponentReporterAssigneeUpdated For Version PrioritySummary --- -- -- -- - -- -- BIT-1531 [1] Bro,BTestDaniel Thayer - 2016-01-28 2.5 Normal Use of mktemp command should be more portable BIT-1527 [2] Bro Johanna Amann - 2016-01-26 2.5 Normal Please merge topic/johanna/cve-2015-3194 BIT-1507 [3] Bro Jan Grashoefer Seth Hall 2016-01-25 - Low Intel framework does not match mail addresses properly Open Fastpath Commits == Commit ComponentAuthor DateSummary --- --- - -- -- be0d2d6 [4] bro-aux Daniel Thayer 2016-01-28 Fix the init-plugin script to be more portable Open GitHub Pull Requests = IssueComponentUserUpdated Title --- --- -- -- - #52 [5] bro J-Gras [6] 2016-01-18 Fixed matching mail address intel [7] [1] BIT-1531 https://bro-tracker.atlassian.net/browse/BIT-1531 [2] BIT-1527 https://bro-tracker.atlassian.net/browse/BIT-1527 [3] BIT-1507 https://bro-tracker.atlassian.net/browse/BIT-1507 [4] be0d2d6 https://github.com/bro/bro-aux/commit/be0d2d639a0757d0a9664d3e8f22d26a78e2814c [5] Pull Request #52 https://github.com/bro/bro/pull/52 [6] J-Gras https://github.com/J-Gras [7] Merge Pull Request #52 with git pull --no-ff --no-commit https://github.com/J-Gras/bro.git topic/jgras/bit-1507 ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1531) Use of mktemp command should be more portable
[ https://bro-tracker.atlassian.net/browse/BIT-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1531: - Assignee: Robin Sommer > Use of mktemp command should be more portable > - > > Key: BIT-1531 > URL: https://bro-tracker.atlassian.net/browse/BIT-1531 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro, BTest >Reporter: Daniel Thayer >Assignee: Robin Sommer > Fix For: 2.5 > > > The use of the mktemp command breaks on some platforms, because > we only use three Xs in our templates, but some platforms require at > least six Xs. -- This message was sent by Atlassian JIRA (v7.1.0-OD-05-006#71001) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1531) Use of mktemp command should be more portable
[ https://bro-tracker.atlassian.net/browse/BIT-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24007#comment-24007 ] Tim Yardley commented on BIT-1531: -- I would suggest changing the fix to represent the generic template recommendation of XX rather than just going to 6. By default, gnu coreutils mktemp uses ‘tmp.XX’ if the template is not specified. > Use of mktemp command should be more portable > - > > Key: BIT-1531 > URL: https://bro-tracker.atlassian.net/browse/BIT-1531 > Project: Bro Issue Tracker > Issue Type: Task > Components: Bro, BTest >Reporter: Daniel Thayer >Assignee: Robin Sommer > Fix For: 2.5 > > > The use of the mktemp command breaks on some platforms, because > we only use three Xs in our templates, but some platforms require at > least six Xs. -- This message was sent by Atlassian JIRA (v7.1.0-OD-05-006#71001) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1527) Please merge topic/johanna/cve-2015-3194
[ https://bro-tracker.atlassian.net/browse/BIT-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1527: -- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Please merge topic/johanna/cve-2015-3194 > > > Key: BIT-1527 > URL: https://bro-tracker.atlassian.net/browse/BIT-1527 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro >Affects Versions: git/master >Reporter: Johanna Amann > Fix For: 2.5 > > > Please merge topic/johanna/cve-2015-3194. The branch contains a test that > checks if a machine is vulnerable to cve-2015-3194 and - if yes - raises a > test error. > Note that we should assure that all our jenkins machines have a current > OpenSSL before merging this to master. -- This message was sent by Atlassian JIRA (v7.1.0-OD-05-006#71001) ___ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] [JIRA] (BIT-1530) protocol_confirmation event cannot be hooked by plugin
[
https://bro-tracker.atlassian.net/browse/BIT-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24008#comment-24008
]
Robin Sommer commented on BIT-1530:
---
Yeah, I think I agree this should be changed. The original motivation was to
trigger that event as quickly as possible, but not sure it's really worth going
a non-standard route for that; in particular now that we have plugins hooking
into the standard route.
I'm not sure but there may indeed be a couple more places avoiding the normal
event queueing in the same way, might be worth checking them as well.
> protocol_confirmation event cannot be hooked by plugin
> --
>
> Key: BIT-1530
> URL: https://bro-tracker.atlassian.net/browse/BIT-1530
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
>Affects Versions: 2.4
>Reporter: Jeff Barber
>
> The way the 'protocol_confirmation' event is raised bypasses the plugin
> event-hook mechanism. Plugin event hooks are triggered via
> EventMgr.QueueEvent which is in the usual event generation interface.
> However, protocol_confirmation is generated via this code in
> src/analyzer/Analyzer.cc:
> {{
> // We immediately raise the event so that the analyzer can quickly
> // react if necessary.
> ::Event* e = new ::Event(protocol_confirmation, vl, SOURCE_LOCAL);
> mgr.Dispatch(e);
> }}
> The EventMgr.Dispatch method doesn't invoke the hook so at present it's not
> possible for a plugin to hook this event. It would be nice if this were
> orthogonal with other events.
--
This message was sent by Atlassian JIRA
(v7.1.0-OD-05-006#71001)
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[Bro-Dev] get_event_peer() with Broker
I was looking at how to extend the get_event_peer() bif to work with Broker events and realized that there's problem I hadn't thought about so far: when a event comes into Bro through Broker, there's no way right now to tell which peer it was sent from. If I'm not missing anything, the event comes only with event name and arguments, but no meta information of any kind that would point to its source. I think adding such meta information would be quite valuable, however it's actually not trivial to do that, as it would change the signature for incoming events across the whole Broker code base, including language bindings etc. Any ideas? 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
