From noreply at bro.org Sun Jun 1 00:00:16 2014 From: noreply at bro.org (Merge Tracker) Date: Sun, 1 Jun 2014 00:00:16 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406010700.s5170GMB010287@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- -------------- ---------- ------------- ---------- --------------------------------------- BIT-1195 [1] Bro Anthony Verez Bernhard Amann 2014-05-30 2.3 Normal SSL: subject overflow in issuer_subject Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------------------------------------- cb76145 [2] broctl Daniel Thayer 2014-05-30 Fix for capstats to display correct interface name 4aae8da [3] broctl Daniel Thayer 2014-05-29 Fix for capstats with PF_RING+DNA pfdnacluster_master Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------ ------------ ---------- -------------------------------------------- #9 [4] bro Mraoul [5] 2014-05-19 New Logging Writers based on librabbitmq [6] #3 [7] pysubnettree kitterma [8] 2014-05-30 Update MANIFEST.in [9] [1] BIT-1195 https://bro-tracker.atlassian.net/browse/BIT-1195 [2] cb76145 https://github.com/bro/broctl/commit/cb76145399484198c4079767a08f80db41c03363 [3] 4aae8da https://github.com/bro/broctl/commit/4aae8daace0774636824c808310cf0d244cc8357 [4] Pull Request #9 https://github.com/bro/bro/pull/9 [5] Mraoul https://github.com/Mraoul [6] Merge Pull Request #9 with git pull https://github.com/MITRECND/bro.git topic/rabbit_writers [7] Pull Request #3 https://github.com/bro/pysubnettree/pull/3 [8] kitterma https://github.com/kitterma [9] Merge Pull Request #3 with git pull https://github.com/kitterma/pysubnettree.git master From noreply at bro.org Mon Jun 2 00:00:21 2014 From: noreply at bro.org (Merge Tracker) Date: Mon, 2 Jun 2014 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406020700.s5270L3I016667@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- -------------- ---------- ------------- ---------- --------------------------------------- BIT-1195 [1] Bro Anthony Verez Bernhard Amann 2014-05-30 2.3 Normal SSL: subject overflow in issuer_subject Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ----------------------------------------------------- cb76145 [2] broctl Daniel Thayer 2014-05-30 Fix for capstats to display correct interface name 4aae8da [3] broctl Daniel Thayer 2014-05-29 Fix for capstats with PF_RING+DNA pfdnacluster_master Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ------------ ------------ ---------- -------------------------------------------- #9 [4] bro Mraoul [5] 2014-05-19 New Logging Writers based on librabbitmq [6] #3 [7] pysubnettree kitterma [8] 2014-05-30 Update MANIFEST.in [9] [1] BIT-1195 https://bro-tracker.atlassian.net/browse/BIT-1195 [2] cb76145 https://github.com/bro/broctl/commit/cb76145399484198c4079767a08f80db41c03363 [3] 4aae8da https://github.com/bro/broctl/commit/4aae8daace0774636824c808310cf0d244cc8357 [4] Pull Request #9 https://github.com/bro/bro/pull/9 [5] Mraoul https://github.com/Mraoul [6] Merge Pull Request #9 with git pull https://github.com/MITRECND/bro.git topic/rabbit_writers [7] Pull Request #3 https://github.com/bro/pysubnettree/pull/3 [8] kitterma https://github.com/kitterma [9] Merge Pull Request #3 with git pull https://github.com/kitterma/pysubnettree.git master From robin at icir.org Mon Jun 2 08:51:30 2014 From: robin at icir.org (Robin Sommer) Date: Mon, 2 Jun 2014 08:51:30 -0700 Subject: [Bro-Dev] [Auto] Merge Status In-Reply-To: <201406010700.s5170GMB010287@bro-ids.icir.org> References: <201406010700.s5170GMB010287@bro-ids.icir.org> Message-ID: <20140602155130.GA83893@icir.org> On Sun, Jun 01, 2014 at 00:00 -0700, you wrote: > cb76145 [2] broctl Daniel Thayer 2014-05-30 Fix for capstats to display correct interface name > 4aae8da [3] broctl Daniel Thayer 2014-05-29 Fix for capstats with PF_RING+DNA pfdnacluster_master Merging these. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From jira at bro-tracker.atlassian.net Mon Jun 2 08:52:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 2 Jun 2014 10:52:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1195) SSL: subject overflow in issuer_subject In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1195: --------------------------------- Assignee: Robin Sommer (was: Bernhard Amann) > SSL: subject overflow in issuer_subject > --------------------------------------- > > Key: BIT-1195 > URL: https://bro-tracker.atlassian.net/browse/BIT-1195 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.2 > Environment: Tested on Debian and Security Onion > Reporter: Anthony Verez > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: 2.2_logs.tar.gz, capture.pcap, master_logs.tar.gz > > > Hi, > I found a string overflow of subject into issuer_subject that can be seen in both ssl.log (2.2 and master) and x509.log (master) > Steps to reproduce: > 1. Start capturing > 2. openssl s_client -connect 63.245.215.80:443 > 3. Stop capturing > 4. Load the pcap in Bro > Problem: > * cat -t master_logs/ssl.log -> "Orga^Inization" > * cat -t master_logs/x509.log -> "Orga^Inization" > * cat -t 2.2_logs/x509.log -> "Orga^Inization" > Whereas the openssl command above gives > subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/serialNumber=C2543436/street=650 Castro St Ste 300/postalCode=94041/C=US/ST=CA/L=Mountain View/O=Mozilla Foundation/CN=bugzilla.mozilla.org > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1 > I have attached: > * the pcap > * logs in both 2.2 and master (bro -r capture.pcap) > Great job on beta 2.3 :-) -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Mon Jun 2 16:37:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Mon, 2 Jun 2014 18:37:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1198) Input framework's READER_ASCII can't handle DOS files In-Reply-To: References: Message-ID: grigorescu created BIT-1198: ------------------------------- Summary: Input framework's READER_ASCII can't handle DOS files Key: BIT-1198 URL: https://bro-tracker.atlassian.net/browse/BIT-1198 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: grigorescu Priority: Low Attachments: test.intel DOS files use CR+LF for newlines, while Linux uses only LF. I've heard of a number of cases where people generate files designed to be read with the input framework on Windows (e.g. exporting from Excel). It'd be nice if we could support that. Trying to load the attached sample file results in: {code} error: test.intel/Input::READER_ASCII: Did not find requested field meta.source in input data file test.intel. error: test.intel/Input::READER_ASCII: Init: cannot open test.intel; headers are incorrect error: test.intel/Input::READER_ASCII: Init failed error: test.intel/Input::READER_ASCII: terminating thread {code} -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Mon Jun 2 16:54:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Mon, 2 Jun 2014 18:54:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1199) Better error messages for input file errors in READER_ASCII In-Reply-To: References: Message-ID: grigorescu created BIT-1199: ------------------------------- Summary: Better error messages for input file errors in READER_ASCII Key: BIT-1199 URL: https://bro-tracker.atlassian.net/browse/BIT-1199 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: grigorescu Priority: Low Attachments: test.intel This came up on the mailing list a few weeks ago. If one tries to load the attached file as Intelligence, Bro will error out, with: {code} internal error: Value not found in enum mappimg. Module: GLOBAL, var: , var size: 0 {code} The attached file contains an extra tab after downloader.com. It'd be nice if Bro would tell you that this was an issue with the input reader, which file it occurred in, and a line number. I think generally speaking, if there's an issue with an input file, it'd be nice to know the line number. (Also, there's a typo in mappimg in the error message that's currently displayed). -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Mon Jun 2 17:05:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Mon, 2 Jun 2014 19:05:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-250) Binpac wrong boundary check In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-250: --------------------------- Status: Merge Request (was: Open) > Binpac wrong boundary check > --------------------------- > > Key: BIT-250 > URL: https://bro-tracker.atlassian.net/browse/BIT-250 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 1.5.2 > Reporter: lorenzo simionato > Attachments: test.pac > > > I'm trying to create a parser for a simple protocol, described by the following type: > {noformat} > type Test_PDU = record { > header: uint32; > msg_length: uint32; > msg_data: uint32; > } &byteorder=littleendian, &length=msg_length; > {noformat} > The code generated by BinPAC, when you compile the attached .pac file is wrong. > In fact the code generated for the parsing of the message is something like: > {noformat} > switch ( buffering_state_ ) { > case 0: > .......... > t_flow_buffer->NewFrame(8, false); > buffering_state_ = 1; > .......... > break; > > case 1: { > buffering_state_ = 2; > // Checking out-of-bound for "Test_PDU:msg_data" > if ( (t_begin_of_data + 8) + (4) > t_end_of_data ) > { > // Handle out-of-bound condition > throw ExceptionOutOfBound("Test_PDU:msg_data", > (8) + (4), > (t_end_of_data) - (t_begin_of_data)); > } > // Parse "msg_length" > msg_length_ = FixByteOrder(byteorder(), *((uint32 const *) ((t_begin_of_data + 4)))); > t_flow_buffer->GrowFrame(msg_length()); > } > break; > } > {noformat} > As you can see at first buffer's length is set to 8, than it will throw an ExceptionOutOfBound because 12>8. > I've looked into the issue and i think that the problem is in the method: > bool RecordField::AttemptBoundaryCheck(Output* out_cc, Env* env) > (pac_record.cc) > In this method the boundary check for the field "msg_length" leads to the boundary check of the field "msg_type", because > quoting the comment on the method: "If my next field can check its boundary, then I don't have to check mine, and it will save me a boundary-check." > As a temporary fix i commented out the "optimization" to check the next field in the AttemptBoundaryCheck method. > How to fix this issue properly? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Mon Jun 2 17:05:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Mon, 2 Jun 2014 19:05:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-250) Binpac wrong boundary check In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-250: --------------------------- Status: Open (was: Merge Request) > Binpac wrong boundary check > --------------------------- > > Key: BIT-250 > URL: https://bro-tracker.atlassian.net/browse/BIT-250 > Project: Bro Issue Tracker > Issue Type: Problem > Components: BinPAC > Affects Versions: 1.5.2 > Reporter: lorenzo simionato > Attachments: test.pac > > > I'm trying to create a parser for a simple protocol, described by the following type: > {noformat} > type Test_PDU = record { > header: uint32; > msg_length: uint32; > msg_data: uint32; > } &byteorder=littleendian, &length=msg_length; > {noformat} > The code generated by BinPAC, when you compile the attached .pac file is wrong. > In fact the code generated for the parsing of the message is something like: > {noformat} > switch ( buffering_state_ ) { > case 0: > .......... > t_flow_buffer->NewFrame(8, false); > buffering_state_ = 1; > .......... > break; > > case 1: { > buffering_state_ = 2; > // Checking out-of-bound for "Test_PDU:msg_data" > if ( (t_begin_of_data + 8) + (4) > t_end_of_data ) > { > // Handle out-of-bound condition > throw ExceptionOutOfBound("Test_PDU:msg_data", > (8) + (4), > (t_end_of_data) - (t_begin_of_data)); > } > // Parse "msg_length" > msg_length_ = FixByteOrder(byteorder(), *((uint32 const *) ((t_begin_of_data + 4)))); > t_flow_buffer->GrowFrame(msg_length()); > } > break; > } > {noformat} > As you can see at first buffer's length is set to 8, than it will throw an ExceptionOutOfBound because 12>8. > I've looked into the issue and i think that the problem is in the method: > bool RecordField::AttemptBoundaryCheck(Output* out_cc, Env* env) > (pac_record.cc) > In this method the boundary check for the field "msg_length" leads to the boundary check of the field "msg_type", because > quoting the comment on the method: "If my next field can check its boundary, then I don't have to check mine, and it will save me a boundary-check." > As a temporary fix i commented out the "optimization" to check the next field in the AttemptBoundaryCheck method. > How to fix this issue properly? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From vladg at cmu.edu Mon Jun 2 17:07:50 2014 From: vladg at cmu.edu (Vlad Grigorescu) Date: Tue, 3 Jun 2014 00:07:50 +0000 Subject: [Bro-Dev] [JIRA] (BIT-250) Binpac wrong boundary check In-Reply-To: References: Message-ID: <80D7F54D-88C3-4B06-8354-BB9835576BEF@andrew.cmu.edu> Please ignore... Inadvertent mouse click. :-) On Jun 2, 2014, at 8:05 PM, grigorescu (JIRA) wrote: > > [ https://bro-tracker.atlassian.net/browse/BIT-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > grigorescu updated BIT-250: > --------------------------- > Status: Merge Request (was: Open) > >> Binpac wrong boundary check >> --------------------------- >> >> Key: BIT-250 >> URL: https://bro-tracker.atlassian.net/browse/BIT-250 >> Project: Bro Issue Tracker >> Issue Type: Problem >> Components: BinPAC >> Affects Versions: 1.5.2 >> Reporter: lorenzo simionato >> Attachments: test.pac >> >> >> I'm trying to create a parser for a simple protocol, described by the following type: >> {noformat} >> type Test_PDU = record { >> header: uint32; >> msg_length: uint32; >> msg_data: uint32; >> } &byteorder=littleendian, &length=msg_length; >> {noformat} >> The code generated by BinPAC, when you compile the attached .pac file is wrong. >> In fact the code generated for the parsing of the message is something like: >> {noformat} >> switch ( buffering_state_ ) { >> case 0: >> .......... >> t_flow_buffer->NewFrame(8, false); >> buffering_state_ = 1; >> .......... >> break; >> >> case 1: { >> buffering_state_ = 2; >> // Checking out-of-bound for "Test_PDU:msg_data" >> if ( (t_begin_of_data + 8) + (4) > t_end_of_data ) >> { >> // Handle out-of-bound condition >> throw ExceptionOutOfBound("Test_PDU:msg_data", >> (8) + (4), >> (t_end_of_data) - (t_begin_of_data)); >> } >> // Parse "msg_length" >> msg_length_ = FixByteOrder(byteorder(), *((uint32 const *) ((t_begin_of_data + 4)))); >> t_flow_buffer->GrowFrame(msg_length()); >> } >> break; >> } >> {noformat} >> As you can see at first buffer's length is set to 8, than it will throw an ExceptionOutOfBound because 12>8. >> I've looked into the issue and i think that the problem is in the method: >> bool RecordField::AttemptBoundaryCheck(Output* out_cc, Env* env) >> (pac_record.cc) >> In this method the boundary check for the field "msg_length" leads to the boundary check of the field "msg_type", because >> quoting the comment on the method: "If my next field can check its boundary, then I don't have to check mine, and it will save me a boundary-check." >> As a temporary fix i commented out the "optimization" to check the next field in the AttemptBoundaryCheck method. >> How to fix this issue properly? > > > > -- > This message was sent by Atlassian JIRA > (v6.3-OD-06-017#6327) > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140603/c5c5ce33/attachment.bin From noreply at bro.org Tue Jun 3 00:00:20 2014 From: noreply at bro.org (Merge Tracker) Date: Tue, 3 Jun 2014 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406030700.s5370KPF007826@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- --------------------------------------- BIT-1195 [1] Bro Anthony Verez Robin Sommer 2014-06-02 2.3 Normal SSL: subject overflow in issuer_subject Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [2] bro Mraoul [3] 2014-05-19 New Logging Writers based on librabbitmq [4] [1] BIT-1195 https://bro-tracker.atlassian.net/browse/BIT-1195 [2] Pull Request #9 https://github.com/bro/bro/pull/9 [3] Mraoul https://github.com/Mraoul [4] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Tue Jun 3 12:39:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 3 Jun 2014 14:39:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1195) SSL: subject overflow in issuer_subject In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1195: ------------------------------ Status: Closed (was: Merge Request) > SSL: subject overflow in issuer_subject > --------------------------------------- > > Key: BIT-1195 > URL: https://bro-tracker.atlassian.net/browse/BIT-1195 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.2 > Environment: Tested on Debian and Security Onion > Reporter: Anthony Verez > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: 2.2_logs.tar.gz, capture.pcap, master_logs.tar.gz > > > Hi, > I found a string overflow of subject into issuer_subject that can be seen in both ssl.log (2.2 and master) and x509.log (master) > Steps to reproduce: > 1. Start capturing > 2. openssl s_client -connect 63.245.215.80:443 > 3. Stop capturing > 4. Load the pcap in Bro > Problem: > * cat -t master_logs/ssl.log -> "Orga^Inization" > * cat -t master_logs/x509.log -> "Orga^Inization" > * cat -t 2.2_logs/x509.log -> "Orga^Inization" > Whereas the openssl command above gives > subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/serialNumber=C2543436/street=650 Castro St Ste 300/postalCode=94041/C=US/ST=CA/L=Mountain View/O=Mozilla Foundation/CN=bugzilla.mozilla.org > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1 > I have attached: > * the pcap > * logs in both 2.2 and master (bro -r capture.pcap) > Great job on beta 2.3 :-) -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Tue Jun 3 12:40:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 3 Jun 2014 14:40:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1195) SSL: subject overflow in issuer_subject In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1195: ------------------------------ Status: Reopened (was: Closed) > SSL: subject overflow in issuer_subject > --------------------------------------- > > Key: BIT-1195 > URL: https://bro-tracker.atlassian.net/browse/BIT-1195 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.2 > Environment: Tested on Debian and Security Onion > Reporter: Anthony Verez > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: 2.2_logs.tar.gz, capture.pcap, master_logs.tar.gz > > > Hi, > I found a string overflow of subject into issuer_subject that can be seen in both ssl.log (2.2 and master) and x509.log (master) > Steps to reproduce: > 1. Start capturing > 2. openssl s_client -connect 63.245.215.80:443 > 3. Stop capturing > 4. Load the pcap in Bro > Problem: > * cat -t master_logs/ssl.log -> "Orga^Inization" > * cat -t master_logs/x509.log -> "Orga^Inization" > * cat -t 2.2_logs/x509.log -> "Orga^Inization" > Whereas the openssl command above gives > subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/serialNumber=C2543436/street=650 Castro St Ste 300/postalCode=94041/C=US/ST=CA/L=Mountain View/O=Mozilla Foundation/CN=bugzilla.mozilla.org > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1 > I have attached: > * the pcap > * logs in both 2.2 and master (bro -r capture.pcap) > Great job on beta 2.3 :-) -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Wed Jun 4 00:00:15 2014 From: noreply at bro.org (Merge Tracker) Date: Wed, 4 Jun 2014 00:00:15 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406040700.s5470FxJ007031@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Wed Jun 4 08:37:09 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Wed, 4 Jun 2014 10:37:09 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1200) CloneSerializer cannot handle recursive records In-Reply-To: References: Message-ID: grigorescu created BIT-1200: ------------------------------- Summary: CloneSerializer cannot handle recursive records Key: BIT-1200 URL: https://bro-tracker.atlassian.net/browse/BIT-1200 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: grigorescu Running something like this will result in an infinite loop in the serializer: {code} type conn_with_ts: record { c: connection; ts: time; }; redef record connection += { conn_with_ts: conn_with_ts &optional; }; event connection_established(c: connection) { local oops = copy(c); } {code} -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Thu Jun 5 00:00:19 2014 From: noreply at bro.org (Merge Tracker) Date: Thu, 5 Jun 2014 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406050700.s5570JSV004512@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From balint.martina at gmail.com Thu Jun 5 03:54:56 2014 From: balint.martina at gmail.com (Martina Balintova) Date: Thu, 5 Jun 2014 11:54:56 +0100 Subject: [Bro-Dev] [BinPac] ParserBuffer with case not producing correct code Message-ID: Hi, binpac parser for flow (flowunit) has probably small bug. In my foo-protocol.pac, I have record like this: // foo.pac flow FOO_Flow(is_orig: bool) { flowunit = FOO_PDU(is_orig) withcontext(connection, this); }; // foo-protocol.pac type FOO_PDU(is_orig: bool) = record { header: FOO_Header(is_orig); xbody: case header.flag of { 1 -> plain_body: FOO_Body(header); 0 -> encrypt_body: Encrypted_Body; } &length = header.length &requires (header.flag); } &byteorder = bigendian; Code that I am getting after binpac parsing is something like this: FOO_PDU::FOO_PDU(bool is_orig) { header_ = 0; xbody_case_index_ = -1; plain_body_ = 0; encrypt_body_ = 0; buffering_state_ = 0; buffering_state_ = 0; is_orig_ = is_orig; byteorder_ = bigendian; proc_foo_header_ = 0; parsing_state_ = 0; parsing_state_ = 0; } bool FOO_PDU::ParseBuffer(flow_buffer_t t_flow_buffer, ContextFOO * t_context) { // SOME CODE ... // switch ( parsing_state_ ) { // ... case 0: ... case 1: { bool t_header_parsing_complete; t_header_parsing_complete = false; while ( ! t_header_parsing_complete && t_flow_buffer->ready() ) { // SOME MORE CODE } if ( ! (t_header_parsing_complete) ) goto need_more_data; } // Parse "xbody" if ( ! xbody_ ) { } // SOME MORE CODE here As you can see, compiler is complaining that error: ?xbody_? was not declared in this scope. It is missing in constructor of FOO_PDU. When I checked snmp analyzer, It is doing this process correctly in int v3Header::Parse(const_byteptr const t_begin_of_data, const_byteptr const t_end_of_data, ContextSNMP * t_context) - it does not check for scoped_pdu_data_. Could you help me to find out what am I doing incorrectly? Thank you Martina -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140605/20c94b3d/attachment.html From jira at bro-tracker.atlassian.net Thu Jun 5 07:10:07 2014 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Thu, 5 Jun 2014 09:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Vallentin updated BIT-1140: ------------------------------------ Status: Merge Request (was: Open) > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Matthias Vallentin > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 5 07:10:07 2014 From: jira at bro-tracker.atlassian.net (Matthias Vallentin (JIRA)) Date: Thu, 5 Jun 2014 09:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800#comment-16800 ] Matthias Vallentin commented on BIT-1140: ----------------------------------------- I could reproduce the issue with your examples, thanks for providing them. This is now fixed with 1d508742 in {{topic/matthias/bloomfilter-fix}}. > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Matthias Vallentin > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jsiwek at illinois.edu Thu Jun 5 08:13:23 2014 From: jsiwek at illinois.edu (Siwek, Jon) Date: Thu, 5 Jun 2014 15:13:23 +0000 Subject: [Bro-Dev] [BinPac] ParserBuffer with case not producing correct code In-Reply-To: References: Message-ID: On Jun 5, 2014, at 5:54 AM, Martina Balintova wrote: > // foo-protocol.pac > type FOO_PDU(is_orig: bool) = record { > header: FOO_Header(is_orig); > xbody: case header.flag of { > 1 -> plain_body: FOO_Body(header); > 0 -> encrypt_body: Encrypted_Body; > } &length = header.length &requires (header.flag); > } &byteorder = bigendian; > > compiler is complaining that error: ?xbody_? was not declared in this scope. It is missing in constructor of FOO_PDU. When I checked snmp analyzer, It is doing this process correctly One difference is that the xbody field of FOO_PDU has the &length attribute apply to the entire case field. I?d be suspicious that the generated parser has a problem with that. And it may make more sense to instead have each condition of the case use header.length however it needs to. E.g. type FOO_PDU(is_orig: bool) = record { header: FOO_Header(is_orig); xbody : case header.flag of { 1 -> plain_body: FOO_Body(header); 0 -> encrypt_body: Encrypted_Body(header); }; } &byteorder = bigendian; # I?m just making up the following for demonstration: type FOO_Body(header: FOO_Header) = record { tag: uint8; data: bytestring &length = header.length - 1; }; type Encrypted_Body(header: FOO_Header) = record { data: bytestring &length = header.length &transient; }; - Jon From jira at bro-tracker.atlassian.net Thu Jun 5 14:42:09 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 5 Jun 2014 16:42:09 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1140: --------------------------------- Assignee: Robin Sommer (was: Matthias Vallentin) > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 5 14:51:07 2014 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Thu, 5 Jun 2014 16:51:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801#comment-16801 ] Aashish Sharma commented on BIT-1140: ------------------------------------- Thanks for the fix Matthias. I am testing your topic/matthias/bloomfilter-fix branch with my policies. Give me a couple of days. So far looks alright. > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 5 14:54:11 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 5 Jun 2014 16:54:11 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1140: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Fri Jun 6 00:00:18 2014 From: noreply at bro.org (Merge Tracker) Date: Fri, 6 Jun 2014 00:00:18 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406060700.s5670Ivp022113@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Fri Jun 6 12:57:07 2014 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Fri, 6 Jun 2014 14:57:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1201) merge topic/bernhard/ssl-new-events In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-1201: -------------------------------- Status: Merge Request (was: Open) > merge topic/bernhard/ssl-new-events > ----------------------------------- > > Key: BIT-1201 > URL: https://bro-tracker.atlassian.net/browse/BIT-1201 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Bernhard Amann > Fix For: 2.3 > > > Please merge topic/bernhard/ssl-new-events. It adds two more SSL events that might be useful in the future and fixes repeated firings of ssl_established in case SSL::disable_analyzer_after_detection=F -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Fri Jun 6 12:57:07 2014 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Fri, 6 Jun 2014 14:57:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1201) merge topic/bernhard/ssl-new-events In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernhard Amann updated BIT-1201: -------------------------------- Assignee: Robin Sommer > merge topic/bernhard/ssl-new-events > ----------------------------------- > > Key: BIT-1201 > URL: https://bro-tracker.atlassian.net/browse/BIT-1201 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Bernhard Amann > Assignee: Robin Sommer > Fix For: 2.3 > > > Please merge topic/bernhard/ssl-new-events. It adds two more SSL events that might be useful in the future and fixes repeated firings of ssl_established in case SSL::disable_analyzer_after_detection=F -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Fri Jun 6 12:57:07 2014 From: jira at bro-tracker.atlassian.net (Bernhard Amann (JIRA)) Date: Fri, 6 Jun 2014 14:57:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1201) merge topic/bernhard/ssl-new-events In-Reply-To: References: Message-ID: Bernhard Amann created BIT-1201: ----------------------------------- Summary: merge topic/bernhard/ssl-new-events Key: BIT-1201 URL: https://bro-tracker.atlassian.net/browse/BIT-1201 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: Bernhard Amann Fix For: 2.3 Please merge topic/bernhard/ssl-new-events. It adds two more SSL events that might be useful in the future and fixes repeated firings of ssl_established in case SSL::disable_analyzer_after_detection=F -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Fri Jun 6 13:34:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 6 Jun 2014 15:34:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1201) merge topic/bernhard/ssl-new-events In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1201: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > merge topic/bernhard/ssl-new-events > ----------------------------------- > > Key: BIT-1201 > URL: https://bro-tracker.atlassian.net/browse/BIT-1201 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Bernhard Amann > Assignee: Robin Sommer > Fix For: 2.3 > > > Please merge topic/bernhard/ssl-new-events. It adds two more SSL events that might be useful in the future and fixes repeated firings of ssl_established in case SSL::disable_analyzer_after_detection=F -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Sat Jun 7 00:00:17 2014 From: noreply at bro.org (Merge Tracker) Date: Sat, 7 Jun 2014 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406070700.s5770HIm010604@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From noreply at bro.org Sun Jun 8 00:00:14 2014 From: noreply at bro.org (Merge Tracker) Date: Sun, 8 Jun 2014 00:00:14 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406080700.s5870Ee9007605@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From noreply at bro.org Mon Jun 9 00:00:17 2014 From: noreply at bro.org (Merge Tracker) Date: Mon, 9 Jun 2014 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406090700.s5970HNT013065@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From noreply at bro.org Tue Jun 10 00:00:18 2014 From: noreply at bro.org (Merge Tracker) Date: Tue, 10 Jun 2014 00:00:18 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406100700.s5A70I2D031345@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Tue Jun 10 07:01:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Tue, 10 Jun 2014 09:01:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1202) Segfault with double redef of table[subnet] of subnet In-Reply-To: References: Message-ID: grigorescu created BIT-1202: ------------------------------- Summary: Segfault with double redef of table[subnet] of subnet Key: BIT-1202 URL: https://bro-tracker.atlassian.net/browse/BIT-1202 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: git/master Reporter: grigorescu Ran into this issue last night. The following code causes a segfault: {code} const my_table: table[subnet] of subnet &redef; redef my_table[3.0.0.0/8] = 1.0.0.0/8; redef my_table[3.0.0.0/8] = 2.0.0.0/8; event bro_init() { if ( 3.1.2.3 in my_table && 3.1.2.3 in my_table[3.0.0.0/8] ) print "Got it."; } {code} While it's a logic mistake to doubly redef this, I think there's a ref-tracking issue that should be fixed. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Tue Jun 10 11:51:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Tue, 10 Jun 2014 13:51:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1202) Segfault with double redef of table[subnet] of subnet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1202: --------------------------- Fix Version/s: 2.3 > Segfault with double redef of table[subnet] of subnet > ----------------------------------------------------- > > Key: BIT-1202 > URL: https://bro-tracker.atlassian.net/browse/BIT-1202 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: grigorescu > Fix For: 2.3 > > > Ran into this issue last night. The following code causes a segfault: > {code} > const my_table: table[subnet] of subnet &redef; > redef my_table[3.0.0.0/8] = 1.0.0.0/8; > redef my_table[3.0.0.0/8] = 2.0.0.0/8; > event bro_init() > { > if ( 3.1.2.3 in my_table && 3.1.2.3 in my_table[3.0.0.0/8] ) > print "Got it."; > } > {code} > While it's a logic mistake to doubly redef this, I think there's a ref-tracking issue that should be fixed. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Tue Jun 10 18:11:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 10 Jun 2014 20:11:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: Robin Sommer created BIT-1203: --------------------------------- Summary: Fixing SMTP state tracking in topic/robin/smtp-fix Key: BIT-1203 URL: https://bro-tracker.atlassian.net/browse/BIT-1203 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro Reporter: Robin Sommer Fix For: 2.3 This fixes the case that an SMTP session has multiple mails sent from the originator but we miss the server's response (e.g., because we don't see server side packets at all). topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Tue Jun 10 18:12:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 10 Jun 2014 20:12:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1203: ------------------------------ Status: Merge Request (was: Open) > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.3 > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Tue Jun 10 18:13:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Tue, 10 Jun 2014 20:13:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802#comment-16802 ] Robin Sommer commented on BIT-1203: ----------------------------------- I would like a double check on this fix. It introduces some small changes in output, see test suite; but they seem plausible. > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Fix For: 2.3 > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Wed Jun 11 00:00:13 2014 From: noreply at bro.org (Merge Tracker) Date: Wed, 11 Jun 2014 00:00:13 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406110700.s5B70DbW013520@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------ ---------- ---------- ------------- ---------- -------------------------------------------------- BIT-1203 [1] Bro Robin Sommer - 2014-06-10 2.3 Normal Fixing SMTP state tracking in topic/robin/smtp-fix Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- --------- ---------- ------------------------------------------------------------ e616554 [2] bro Jon Siwek 2014-06-10 Fix use-after-free in some cases of reassigning a table inde Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [3] bro Mraoul [4] 2014-05-19 New Logging Writers based on librabbitmq [5] [1] BIT-1203 https://bro-tracker.atlassian.net/browse/BIT-1203 [2] e616554 https://github.com/bro/bro/commit/e616554ab8a475d3b33463353ad0fa9a8645d0d9 [3] Pull Request #9 https://github.com/bro/bro/pull/9 [4] Mraoul https://github.com/Mraoul [5] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Wed Jun 11 10:59:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 11 Jun 2014 12:59:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1203: --------------------------- Assignee: Jon Siwek > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 11:55:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Wed, 11 Jun 2014 13:55:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1203: --------------------------- Attachment: signature.asc I think the changes make sense. > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > Attachments: signature.asc > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 12:41:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 11 Jun 2014 14:41:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804#comment-16804 ] Jon Siwek commented on BIT-1203: -------------------------------- Cool, they make sense to me as well. I was initially going to suggest something to deal w/ pipelining, but I'm becoming convinced that synchronizing/flushing the log upon seeing a new "MAIL FROM" (as it now does) is already enough. Will merge once I finish checking test baseline diffs. > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > Attachments: signature.asc > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 13:40:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 11 Jun 2014 15:40:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805#comment-16805 ] Robin Sommer commented on BIT-1203: ----------------------------------- Great, that's exactly the part I was left feeling unsure about: do we need more than that, or is this just fine? I'm thinking logs would probably look at bit different occasionally if we had full pipeline support, but it may just be parts that don't really matter much in the first (i.e., mostly with regards to control stuff between actual mails). Robin > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > Attachments: signature.asc > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 13:42:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 11 Jun 2014 15:42:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1203: --------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > Attachments: signature.asc > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 14:28:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 11 Jun 2014 16:28:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1202) Segfault with double redef of table[subnet] of subnet In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1202: ------------------------------ Resolution: Merged Status: Closed (was: Open) > Segfault with double redef of table[subnet] of subnet > ----------------------------------------------------- > > Key: BIT-1202 > URL: https://bro-tracker.atlassian.net/browse/BIT-1202 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: grigorescu > Fix For: 2.3 > > > Ran into this issue last night. The following code causes a segfault: > {code} > const my_table: table[subnet] of subnet &redef; > redef my_table[3.0.0.0/8] = 1.0.0.0/8; > redef my_table[3.0.0.0/8] = 2.0.0.0/8; > event bro_init() > { > if ( 3.1.2.3 in my_table && 3.1.2.3 in my_table[3.0.0.0/8] ) > print "Got it."; > } > {code} > While it's a logic mistake to doubly redef this, I think there's a ref-tracking issue that should be fixed. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 14:29:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Wed, 11 Jun 2014 16:29:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1195) SSL: subject overflow in issuer_subject In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1195: ------------------------------ Status: Closed (was: Reopened) > SSL: subject overflow in issuer_subject > --------------------------------------- > > Key: BIT-1195 > URL: https://bro-tracker.atlassian.net/browse/BIT-1195 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.2 > Environment: Tested on Debian and Security Onion > Reporter: Anthony Verez > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: 2.2_logs.tar.gz, capture.pcap, master_logs.tar.gz > > > Hi, > I found a string overflow of subject into issuer_subject that can be seen in both ssl.log (2.2 and master) and x509.log (master) > Steps to reproduce: > 1. Start capturing > 2. openssl s_client -connect 63.245.215.80:443 > 3. Stop capturing > 4. Load the pcap in Bro > Problem: > * cat -t master_logs/ssl.log -> "Orga^Inization" > * cat -t master_logs/x509.log -> "Orga^Inization" > * cat -t 2.2_logs/x509.log -> "Orga^Inization" > Whereas the openssl command above gives > subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=California/serialNumber=C2543436/street=650 Castro St Ste 300/postalCode=94041/C=US/ST=CA/L=Mountain View/O=Mozilla Foundation/CN=bugzilla.mozilla.org > issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1 > I have attached: > * the pcap > * logs in both 2.2 and master (bro -r capture.pcap) > Great job on beta 2.3 :-) -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From robin at icir.org Wed Jun 11 14:30:02 2014 From: robin at icir.org (Robin Sommer) Date: Wed, 11 Jun 2014 14:30:02 -0700 Subject: [Bro-Dev] 2.3 ready? Message-ID: <20140611213002.GE20261@icir.org> All tickets are closed. Anything left? I would propose to get the release out on Monday otherwise. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From jira at bro-tracker.atlassian.net Wed Jun 11 15:21:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 11 Jun 2014 17:21:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1203) Fixing SMTP state tracking in topic/robin/smtp-fix In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806#comment-16806 ] Jon Siwek commented on BIT-1203: -------------------------------- I think it seems fine now for what the scope of what the SMTP script current does: it's mostly concerned with tracking/logging the envelopes/header-fields created by the client, the server's last response is tracked/logged, but doesn't really factor in to any logic decisions, with the exception of any reply to '.' being a place to possibly flush/log the envelope/headers it's been tracking. Q: Can pipelining disrupt Bro's tracking of envelopes/header-fields? A: I don't think so because the protocol forces synchronization after DATA and Bro syncs up on either the next reply to '.' or the next MAIL signaling a new transaction. Doesn't seem like there's any place for enveloper/header info to get mixed anymore. Q: Can pipelining cause the logging of $last_reply field to wrong/different? A: Consider the two places bro syncs up the logging: (1) after a reply to '.', we know the protocol is already synchronized, so the next reply seen should be the correct/best one to log. (2) On seeing "MAIL FROM", but not having logged previous envelope/header info -- does seem like pipelining could cause the value of $last_reply to vary, but not sure that's different from the situation in which responses from the server may have been missed (though, maybe there's some distinguishing between the two situations that can be done). Hope that helps explain my reasoning. > Fixing SMTP state tracking in topic/robin/smtp-fix > -------------------------------------------------- > > Key: BIT-1203 > URL: https://bro-tracker.atlassian.net/browse/BIT-1203 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Robin Sommer > Assignee: Jon Siwek > Fix For: 2.3 > > Attachments: signature.asc > > > This fixes the case that an SMTP session has multiple mails sent from > the originator but we miss the server's response (e.g., because we > don't see server side packets at all). > topic/robin/smtp-fix in bro and bro-testing-private -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 17:14:07 2014 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Wed, 11 Jun 2014 19:14:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1204) broctl query|print timesout for really large tables In-Reply-To: References: Message-ID: Aashish Sharma created BIT-1204: ----------------------------------- Summary: broctl query|print timesout for really large tables Key: BIT-1204 URL: https://bro-tracker.atlassian.net/browse/BIT-1204 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.2, 2.3 Environment: Bro-2.x on FreeBSD-9.x Reporter: Aashish Sharma I've noticed that for really large tables (~10,000+) elements, "broctl print" command times out example: $ broctl print Drop::drop_info manager For few hundred elements or small enough table we get the desired results. Please let me know if you cannot reproduce the problem or need further clarifications. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 18:02:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Wed, 11 Jun 2014 20:02:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1204) broctl query|print timesout for really large tables In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16807#comment-16807 ] Jon Siwek commented on BIT-1204: -------------------------------- Does increasing the value of "CommTimeout" in broctl.cfg help (e.g. "CommTimeout = 300") ? The default is 10 seconds. > broctl query|print timesout for really large tables > --------------------------------------------------- > > Key: BIT-1204 > URL: https://bro-tracker.atlassian.net/browse/BIT-1204 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2, 2.3 > Environment: Bro-2.x on FreeBSD-9.x > Reporter: Aashish Sharma > Labels: broctl > > I've noticed that for really large tables (~10,000+) elements, "broctl print" command times out > example: > $ broctl print Drop::drop_info > manager > For few hundred elements or small enough table we get the desired results. > Please let me know if you cannot reproduce the problem or need further clarifications. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From seth at icir.org Wed Jun 11 18:40:44 2014 From: seth at icir.org (Seth Hall) Date: Wed, 11 Jun 2014 21:40:44 -0400 Subject: [Bro-Dev] 2.3 ready? In-Reply-To: <20140611213002.GE20261@icir.org> References: <20140611213002.GE20261@icir.org> Message-ID: <8A5B531A-BF8D-4F39-AB42-6699C533A4AF@icir.org> On Jun 11, 2014, at 5:30 PM, Robin Sommer wrote: > I would propose to get the release out on Monday otherwise. Sounds good to me! .Seth -- Seth Hall International Computer Science Institute (Bro) because everyone has a network http://www.bro.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140611/0711c20f/attachment.bin From bernhard at ICSI.Berkeley.EDU Wed Jun 11 19:42:38 2014 From: bernhard at ICSI.Berkeley.EDU (bernhard at ICSI.Berkeley.EDU) Date: Wed, 11 Jun 2014 19:42:38 -0700 Subject: [Bro-Dev] 2.3 ready? In-Reply-To: <8A5B531A-BF8D-4F39-AB42-6699C533A4AF@icir.org> References: <20140611213002.GE20261@icir.org> <8A5B531A-BF8D-4F39-AB42-6699C533A4AF@icir.org> Message-ID: <3D96F2E4-CDF0-48D7-B3DE-F8A62F2AF893@icsi.berkeley.edu> Me too. On 11 Jun 2014, at 18:40, Seth Hall wrote: > On Jun 11, 2014, at 5:30 PM, Robin Sommer wrote: > >> I would propose to get the release out on Monday otherwise. > > Sounds good to me! > > .Seth > > -- > Seth Hall > International Computer Science Institute > (Bro) because everyone has a network > http://www.bro.org/ > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From jira at bro-tracker.atlassian.net Wed Jun 11 22:38:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 12 Jun 2014 00:38:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1205) topic/dnthayer/doc-fixes-for-2.3 In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1205: ---------------------------------- Summary: topic/dnthayer/doc-fixes-for-2.3 Key: BIT-1205 URL: https://bro-tracker.atlassian.net/browse/BIT-1205 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Daniel Thayer Fix For: 2.3 This branch contains the last round of documentation fixes for Bro 2.3. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Wed Jun 11 22:39:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 12 Jun 2014 00:39:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1205) topic/dnthayer/doc-fixes-for-2.3 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1205: ------------------------------- Status: Merge Request (was: Open) > topic/dnthayer/doc-fixes-for-2.3 > -------------------------------- > > Key: BIT-1205 > URL: https://bro-tracker.atlassian.net/browse/BIT-1205 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Fix For: 2.3 > > > This branch contains the last round of documentation fixes for Bro 2.3. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Thu Jun 12 00:00:16 2014 From: noreply at bro.org (Merge Tracker) Date: Thu, 12 Jun 2014 00:00:16 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406120700.s5C70G47031972@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ---------- ---------- ------------- ---------- ------------------------------------ BIT-1205 [1] Bro Daniel Thayer - 2014-06-12 2.3 Normal topic/dnthayer/doc-fixes-for-2.3 [2] Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [3] bro Mraoul [4] 2014-05-19 New Logging Writers based on librabbitmq [5] [1] BIT-1205 https://bro-tracker.atlassian.net/browse/BIT-1205 [2] doc-fixes-for-2.3 https://github.com/bro/bro/tree/topic/dnthayer/doc-fixes-for-2.3 [3] Pull Request #9 https://github.com/bro/bro/pull/9 [4] Mraoul https://github.com/Mraoul [5] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Thu Jun 12 06:44:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 08:44:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1157) optional fields are missing from JSON logs In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1157: --------------------------- Resolution: Rejected Status: Closed (was: Open) I think the current behavior is correct. > optional fields are missing from JSON logs > ------------------------------------------ > > Key: BIT-1157 > URL: https://bro-tracker.atlassian.net/browse/BIT-1157 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Justin Azoff > Assignee: Seth Hall > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 06:58:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 08:58:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1154) Formatters restructed in: topic/seth/json-formatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1154: --------------------------- Affects Version/s: (was: 2.3) 2.4 > Formatters restructed in: topic/seth/json-formatter > --------------------------------------------------- > > Key: BIT-1154 > URL: https://bro-tracker.atlassian.net/browse/BIT-1154 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > > topic/seth/json-formatter has an abstraction for Formatters and I created a formatters directory under threading. There is also a new JSON formatter and support in the Ascii and ElasticSearch writers for the JSON formatter. > I went ahead and threw in per-filter configuration options for the Ascii writer for all of the options that were exposed globally too. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 06:59:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 08:59:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1154) Formatters restructed in: topic/seth/json-formatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809#comment-16809 ] Seth Hall commented on BIT-1154: -------------------------------- Robin's points are right and I'd like to do a bit more here so I bumped the ticket to 2.4. > Formatters restructed in: topic/seth/json-formatter > --------------------------------------------------- > > Key: BIT-1154 > URL: https://bro-tracker.atlassian.net/browse/BIT-1154 > Project: Bro Issue Tracker > Issue Type: New Feature > Components: Bro > Affects Versions: 2.4 > Reporter: Seth Hall > > topic/seth/json-formatter has an abstraction for Formatters and I created a formatters directory under threading. There is also a new JSON formatter and support in the Ascii and ElasticSearch writers for the JSON formatter. > I went ahead and threw in per-filter configuration options for the Ascii writer for all of the options that were exposed globally too. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:03:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 09:03:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-193) notice filter that does a subnet -> admin lookup In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-193: -------------------------- Resolution: Fixed Status: Closed (was: Open) This ticket is irrelevant (and mostly implemented in Bro now I think). > notice filter that does a subnet -> admin lookup > ------------------------------------------------ > > Key: BIT-193 > URL: https://bro-tracker.atlassian.net/browse/BIT-193 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 1.5.2 > Reporter: justin > Assignee: Vern Paxson > Priority: Low > Labels: email, notice > Attachments: admins.bro > > > attaching a script that defines a notice_email_subnet_admins and then shows how it could be used. > I'm not sure where the subnet_admins should be defined though. This seems to work, but there may be an even cleaner way of implementing it. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:05:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:05:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-864) tweaks/updates for http://www.bro-ids.org/research/index.html In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-864: --------------------------- Status: Reopened (was: Closed) > tweaks/updates for http://www.bro-ids.org/research/index.html > ------------------------------------------------------------- > > Key: BIT-864 > URL: https://bro-tracker.atlassian.net/browse/BIT-864 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Vern Paxson > Priority: Low > > The Chimera paper is now accessible via https://www.usenix.org/conference/usenixsecurity12/chimera-declarative-language-streaming-network-traffic-analysis . > There's also a glitch in that most of the papers listed have "Proc. Proc." in the proceedings names. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:08:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:08:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-864) tweaks/updates for http://www.bro-ids.org/research/index.html In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-864: --------------------------- Resolution: Fixed Status: Closed (was: Reopened) Fixing ticket: it was closed but marked as unresolved. > tweaks/updates for http://www.bro-ids.org/research/index.html > ------------------------------------------------------------- > > Key: BIT-864 > URL: https://bro-tracker.atlassian.net/browse/BIT-864 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Affects Versions: git/master > Reporter: Vern Paxson > Priority: Low > > The Chimera paper is now accessible via https://www.usenix.org/conference/usenixsecurity12/chimera-declarative-language-streaming-network-traffic-analysis . > There's also a glitch in that most of the papers listed have "Proc. Proc." in the proceedings names. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:09:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:09:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-459) Test Ticket In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-459: --------------------------- Status: Reopened (was: Closed) > Test Ticket > ----------- > > Key: BIT-459 > URL: https://bro-tracker.atlassian.net/browse/BIT-459 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:09:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:09:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-459) Test Ticket In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-459: --------------------------- Resolution: Fixed Status: Closed (was: Reopened) Fixing ticket: it was closed but marked as unresolved. > Test Ticket > ----------- > > Key: BIT-459 > URL: https://bro-tracker.atlassian.net/browse/BIT-459 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:09:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:09:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-933) Test ticket In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-933: --------------------------- Resolution: Fixed Status: Closed (was: Reopened) Fixing ticket: it was closed but marked as unresolved. > Test ticket > ----------- > > Key: BIT-933 > URL: https://bro-tracker.atlassian.net/browse/BIT-933 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.3 > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:09:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:09:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-933) Test ticket In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-933: --------------------------- Status: Reopened (was: Closed) > Test ticket > ----------- > > Key: BIT-933 > URL: https://bro-tracker.atlassian.net/browse/BIT-933 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master > Reporter: Robin Sommer > Fix For: 2.3 > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:10:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-682) Beta Documentation Pages Broken In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-682: --------------------------- Status: Reopened (was: Closed) > Beta Documentation Pages Broken > ------------------------------- > > Key: BIT-682 > URL: https://bro-tracker.atlassian.net/browse/BIT-682 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: maxfeldman > Labels: beta, documentation, > > http://bro-ids.org/documentation-beta/ seems to have various display errors, eg. " ERROR/3 (root/documentation-beta/+git+.index.bro.rst, line 6)" > It also seems that many of the specific links are not found, eg. http://bro-ids.org/documentation-beta/notice.bro.html -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:10:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 12 Jun 2014 09:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-682) Beta Documentation Pages Broken In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] grigorescu updated BIT-682: --------------------------- Resolution: Fixed Status: Closed (was: Reopened) Fixing ticket: it was closed but marked as unresolved. > Beta Documentation Pages Broken > ------------------------------- > > Key: BIT-682 > URL: https://bro-tracker.atlassian.net/browse/BIT-682 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Website > Reporter: maxfeldman > Labels: beta, documentation, > > http://bro-ids.org/documentation-beta/ seems to have various display errors, eg. " ERROR/3 (root/documentation-beta/+git+.index.bro.rst, line 6)" > It also seems that many of the specific links are not found, eg. http://bro-ids.org/documentation-beta/notice.bro.html -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:11:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 09:11:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1095) Meta ticker tracking patches for potential 2.2.1 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-1095: --------------------------- Resolution: Fixed Status: Closed (was: Open) We don't need this ticket anymore. > Meta ticker tracking patches for potential 2.2.1 > ------------------------------------------------ > > Key: BIT-1095 > URL: https://bro-tracker.atlassian.net/browse/BIT-1095 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2 > Reporter: Robin Sommer > > I'm creating this ticket to track commits that we would want to back port to 2.2 if ended up doing a bug fix release 2.2.1 -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:30:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 09:30:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-76) Low port trolling vs. backscatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816#comment-16816 ] Seth Hall commented on BIT-76: ------------------------------ First, to get one thing out of the way, scan.bro doesn't fire on this trace (and I don't think it should). But Vlad pointed out something interesting about this trace. It seems to cause the get_file_handle event to get generated quite a few times. That really doesn't make any sense to me. Something to look into at some point. > Low port trolling vs. backscatter > --------------------------------- > > Key: BIT-76 > URL: https://bro-tracker.atlassian.net/browse/BIT-76 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > Priority: Low > Labels: scan > Attachments: backscatter.trace > > > Running on the attached trace, mt.bro correctly diagnoses backscatter, but then goes on to later complain about low-port trolling. Seems this latter should be suppressed, as it's just a follow-on from the backscatter. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:44:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 09:44:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1036) add script based on BBN's Host Peering In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817#comment-16817 ] Seth Hall commented on BIT-1036: -------------------------------- This script won't work on clusters. This notion of histogram or historical time series analysis is something I've been wanting to add to SumStats but unfortunately it's not there yet. > add script based on BBN's Host Peering > -------------------------------------- > > Key: BIT-1036 > URL: https://bro-tracker.atlassian.net/browse/BIT-1036 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.4 > > Attachments: 0001-add-script-based-on-BBN-s-Host-Peering.patch > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:49:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 09:49:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1011) username/password authentication for SOCKS5 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall reassigned BIT-1011: ------------------------------ Assignee: Seth Hall > username/password authentication for SOCKS5 > ------------------------------------------- > > Key: BIT-1011 > URL: https://bro-tracker.atlassian.net/browse/BIT-1011 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: nicolas > Assignee: Seth Hall > Priority: Low > Fix For: 2.4 > > Attachments: 0001-SOCKS-authentication-patch.patch, output.pcap > > > Patch the bug explained below : > It appears using the username authentication with SOCKS 5. > After the client and the server have chosen the username authentication, > the client has to send the following packet : > Client request (RFC 1929) : > +----+------+----------+------+----------+ > |VER | ULEN | UNAME | PLEN | PASSWD | > +----+------+----------+------+----------+ > | 1 | 1 | 1 to 255 | 1 | 1 to 255 | > +----+------+----------+------+----------+ > Here the first byte must be 0x1, it specifies the version of the > authentication mechanisme, not the SOCKS version (0x5) like in all > others packets. > However in the socks-protocol.pac the type SOCKS_Version never parses > data if the first byte is 0x1, and it goes to an error. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 07:50:07 2014 From: jira at bro-tracker.atlassian.net (dmandelb (JIRA)) Date: Thu, 12 Jun 2014 09:50:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1036) add script based on BBN's Host Peering In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dmandelb updated BIT-1036: -------------------------- Attachment: signature.asc It's been a while, but I thought I tested this on clusters. Is there anything in particular that looks like it won't work? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ > add script based on BBN's Host Peering > -------------------------------------- > > Key: BIT-1036 > URL: https://bro-tracker.atlassian.net/browse/BIT-1036 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.4 > > Attachments: 0001-add-script-based-on-BBN-s-Host-Peering.patch, signature.asc > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 08:10:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 12 Jun 2014 10:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-76) Low port trolling vs. backscatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819#comment-16819 ] Jon Siwek commented on BIT-76: ------------------------------ {quote} But Vlad pointed out something interesting about this trace. It seems to cause the get_file_handle event to get generated quite a few times. That really doesn't make any sense to me. Something to look into at some point. {quote} I think that's mostly a result of some difficulty in hooking up the current HTTP_Analyzer w/ the FAF -- the protocol analyzer didn't have direct access to particular entities that are in-flight, so HTTP_Analyzer::Done() has a catch-all file_mgr->EndOfFile(). In this case, that means asking the script-layer to return a file handle for the current entity, but that ultimately just ends up saying "I haven't seen anything; there's nothing there". Agree that it's suboptimal. I think improving would require changes to HTTP analyzer (or maybe just waiting for the binpac++ version? :)). > Low port trolling vs. backscatter > --------------------------------- > > Key: BIT-76 > URL: https://bro-tracker.atlassian.net/browse/BIT-76 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > Priority: Low > Labels: scan > Attachments: backscatter.trace > > > Running on the attached trace, mt.bro correctly diagnoses backscatter, but then goes on to later complain about low-port trolling. Seems this latter should be suppressed, as it's just a follow-on from the backscatter. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 09:22:08 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 12 Jun 2014 11:22:08 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1205) topic/dnthayer/doc-fixes-for-2.3 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1205: --------------------------- Assignee: Jon Siwek > topic/dnthayer/doc-fixes-for-2.3 > -------------------------------- > > Key: BIT-1205 > URL: https://bro-tracker.atlassian.net/browse/BIT-1205 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Jon Siwek > Fix For: 2.3 > > > This branch contains the last round of documentation fixes for Bro 2.3. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 10:26:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 12:26:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-76) Low port trolling vs. backscatter In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Seth Hall updated BIT-76: ------------------------- Attachment: signature.asc Agreed on both points. No priority on it. I just wanted to document it since it was something I noticed. :) > Low port trolling vs. backscatter > --------------------------------- > > Key: BIT-76 > URL: https://bro-tracker.atlassian.net/browse/BIT-76 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Vern Paxson > Priority: Low > Labels: scan > Attachments: backscatter.trace, signature.asc > > > Running on the attached trace, mt.bro correctly diagnoses backscatter, but then goes on to later complain about low-port trolling. Seems this latter should be suppressed, as it's just a follow-on from the backscatter. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 10:35:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 12 Jun 2014 12:35:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1205) topic/dnthayer/doc-fixes-for-2.3 In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1205: --------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > topic/dnthayer/doc-fixes-for-2.3 > -------------------------------- > > Key: BIT-1205 > URL: https://bro-tracker.atlassian.net/browse/BIT-1205 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Daniel Thayer > Assignee: Jon Siwek > Fix For: 2.3 > > > This branch contains the last round of documentation fixes for Bro 2.3. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 10:35:07 2014 From: jira at bro-tracker.atlassian.net (Seth Hall (JIRA)) Date: Thu, 12 Jun 2014 12:35:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1036) add script based on BBN's Host Peering In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821#comment-16821 ] Seth Hall commented on BIT-1036: -------------------------------- Oh, sorry about that. I didn't see your cluster mechanism in there. What size cluster did you test this on? I'm just curious what it's performance characteristics are because it seems like it could cause a lot of inter-node traffic on clusters watching large networks. > add script based on BBN's Host Peering > -------------------------------------- > > Key: BIT-1036 > URL: https://bro-tracker.atlassian.net/browse/BIT-1036 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.4 > > Attachments: 0001-add-script-based-on-BBN-s-Host-Peering.patch, signature.asc > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 10:42:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Thu, 12 Jun 2014 12:42:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1206) Overuse of line numbers in doc/scripting/index.rst In-Reply-To: References: Message-ID: Jon Siwek created BIT-1206: ------------------------------ Summary: Overuse of line numbers in doc/scripting/index.rst Key: BIT-1206 URL: https://bro-tracker.atlassian.net/browse/BIT-1206 Project: Bro Issue Tracker Issue Type: Improvement Components: Bro Reporter: Jon Siwek Fix For: 2.4 This document uses a lot of hardcoded line numbers. Seems too fragile/unmaintainable (line numbers have changed and rendered the doc outdated at least a few times now), maybe something can be done to generally improve it. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 11:56:07 2014 From: jira at bro-tracker.atlassian.net (dmandelb (JIRA)) Date: Thu, 12 Jun 2014 13:56:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1036) add script based on BBN's Host Peering In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16822#comment-16822 ] dmandelb commented on BIT-1036: ------------------------------- I have an old config file that indicates I tested it on a cluster with one computer running the manager, one computer running 2 proxies, and 3 computers each running 2 workers. I don't remember the details of what I tested though. If anybody wants to test it on a big network, I'd recommend redefing track_peers_of to be one small subnet, and growing it step-by-step until performance starts to be an issue. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ > add script based on BBN's Host Peering > -------------------------------------- > > Key: BIT-1036 > URL: https://bro-tracker.atlassian.net/browse/BIT-1036 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: git/master > Reporter: dmandelb > Fix For: 2.4 > > Attachments: 0001-add-script-based-on-BBN-s-Host-Peering.patch, signature.asc > > -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 16:19:07 2014 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Thu, 12 Jun 2014 18:19:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1204) broctl query|print timesout for really large tables In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aashish Sharma updated BIT-1204: -------------------------------- Resolution: Fixed Status: Closed (was: Open) setting CommTimeout = 300 ( or higher number in seconds) fixes the issue. > broctl query|print timesout for really large tables > --------------------------------------------------- > > Key: BIT-1204 > URL: https://bro-tracker.atlassian.net/browse/BIT-1204 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2, 2.3 > Environment: Bro-2.x on FreeBSD-9.x > Reporter: Aashish Sharma > Labels: broctl > > I've noticed that for really large tables (~10,000+) elements, "broctl print" command times out > example: > $ broctl print Drop::drop_info > manager > For few hundred elements or small enough table we get the desired results. > Please let me know if you cannot reproduce the problem or need further clarifications. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Thu Jun 12 16:19:07 2014 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Thu, 12 Jun 2014 18:19:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1204) broctl query|print timesout for really large tables In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823#comment-16823 ] Aashish Sharma commented on BIT-1204: ------------------------------------- Yes ! increasing CommTimeout works well. ( Needless ticket - should have asked on mailing list, I guess ) > broctl query|print timesout for really large tables > --------------------------------------------------- > > Key: BIT-1204 > URL: https://bro-tracker.atlassian.net/browse/BIT-1204 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.2, 2.3 > Environment: Bro-2.x on FreeBSD-9.x > Reporter: Aashish Sharma > Labels: broctl > > I've noticed that for really large tables (~10,000+) elements, "broctl print" command times out > example: > $ broctl print Drop::drop_info > manager > For few hundred elements or small enough table we get the desired results. > Please let me know if you cannot reproduce the problem or need further clarifications. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Fri Jun 13 00:00:14 2014 From: noreply at bro.org (Merge Tracker) Date: Fri, 13 Jun 2014 00:00:14 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406130700.s5D70EwJ019371@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From robin at icir.org Fri Jun 13 07:49:35 2014 From: robin at icir.org (Robin Sommer) Date: Fri, 13 Jun 2014 07:49:35 -0700 Subject: [Bro-Dev] 2.3 ready? In-Reply-To: <20140611213002.GE20261@icir.org> References: <20140611213002.GE20261@icir.org> Message-ID: <20140613144935.GA10818@icir.org> On Wed, Jun 11, 2014 at 14:30 -0700, I wrote: > I would propose to get the release out on Monday otherwise. Alright, sounds like everybody's happy, so let's get it out. Jon is going to be our Release Master. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From jira at bro-tracker.atlassian.net Fri Jun 13 18:16:07 2014 From: jira at bro-tracker.atlassian.net (Aashish Sharma (JIRA)) Date: Fri, 13 Jun 2014 20:16:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1140) Bloomfilter hashing problem In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825#comment-16825 ] Aashish Sharma commented on BIT-1140: ------------------------------------- SO I have been running the code for last 5 days on DMZ box. I don't see any false +ve's. BloomFilter seems to be holding up quite well to store URL strings properly now. > Bloomfilter hashing problem > --------------------------- > > Key: BIT-1140 > URL: https://bro-tracker.atlassian.net/browse/BIT-1140 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Reporter: Robin Sommer > Assignee: Robin Sommer > Fix For: 2.3 > > Attachments: bloom-test2.bro, bloom-test-short.bro > > > It seems bloomfilter hashing isn't working correctly. Has that been confirmed? Is there a fix? -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From noreply at bro.org Sat Jun 14 00:00:19 2014 From: noreply at bro.org (Merge Tracker) Date: Sat, 14 Jun 2014 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406140700.s5E70JDG022493@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From noreply at bro.org Sun Jun 15 00:00:15 2014 From: noreply at bro.org (Merge Tracker) Date: Sun, 15 Jun 2014 00:00:15 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406150700.s5F70Fab027194@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From noreply at bro.org Mon Jun 16 00:00:18 2014 From: noreply at bro.org (Merge Tracker) Date: Mon, 16 Jun 2014 00:00:18 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406160700.s5G70IMR001142@bro-ids.icir.org> Open GitHub Pull Requests ========================= Issue Component User Updated Title ------- ----------- ---------- ---------- -------------------------------------------- #9 [1] bro Mraoul [2] 2014-05-19 New Logging Writers based on librabbitmq [3] [1] Pull Request #9 https://github.com/bro/bro/pull/9 [2] Mraoul https://github.com/Mraoul [3] Merge Pull Request #9 with git pull -no-ff --no-commit https://github.com/MITRECND/bro.git topic/rabbit_writers From jira at bro-tracker.atlassian.net Mon Jun 16 15:20:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 16 Jun 2014 17:20:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1207) Add test to catch changes breaking local.bro In-Reply-To: References: Message-ID: Robin Sommer created BIT-1207: --------------------------------- Summary: Add test to catch changes breaking local.bro Key: BIT-1207 URL: https://bro-tracker.atlassian.net/browse/BIT-1207 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Reporter: Robin Sommer Fix For: 2.4 We should get a better at tracking when a shipping local.bro breaks. We could add a test that runs the local.bro of the past release. Once something breaks, we'd update the test's copy of local.bro but then also take that as a trigger to document the change. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From robin at icir.org Thu Jun 19 11:41:32 2014 From: robin at icir.org (Robin Sommer) Date: Thu, 19 Jun 2014 11:41:32 -0700 Subject: [Bro-Dev] Looking on feedback on PACF/reaction framework Message-ID: <20140619184132.GA34742@icir.org> I have revised the proposed API a bit, see http://www.bro.org/development/projects/pacf.html I would be interested in feedback regarding if (1) the User API is generally expressed at a good level, and (2) if this covers the functionality that people have implemented, or plan to, for interfacing with their network gear. Any other thoughts are welcome too, of course. (The details for individual operations aren't cast in stone yet and could certainly be adjusted/extended). Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From vlad at grigorescu.org Thu Jun 19 12:21:42 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Thu, 19 Jun 2014 15:21:42 -0400 Subject: [Bro-Dev] Looking on feedback on PACF/reaction framework In-Reply-To: <20140619184132.GA34742@icir.org> References: <20140619184132.GA34742@icir.org> Message-ID: This lines up pretty well with the features that I'd want from this. I think the API is at a good level to be usable yet customizable. A few comments I had: - I believe Rule$target should be of type Target and not TargetType (which is undefined). - Some other options to consider for EntityType: * Subnet * MAC address * User? (I believe some devices allow filtering based on user, if they authenticate via VPN, 802.1X or something similar) - Should Rule have both orig and resp Entity fields? i.e. I could see a use case for filtering traffic from an IP, to it, or both. - More generally, should Rule have an optional BPF? Perhaps this is one of the use cases of arg_str. I've also been considering a feature that would allow a clean shutdown of a worker node. I'm not sure if this would be even remotely possible, or if it'd be a job for the PACF, but what I envision is Bro reaching out to the hardware frontend, removing one of the active output ports from the load balancing, and somehow transferring state on the in-progress connections to the other workers. The reverse would also be nice (adding a worker node), though there'd be more state to transfer. --Vlad On Thu, Jun 19, 2014 at 2:41 PM, Robin Sommer wrote: > > I have revised the proposed API a bit, see > > http://www.bro.org/development/projects/pacf.html > > I would be interested in feedback regarding if (1) the User API is > generally expressed at a good level, and (2) if this covers the > functionality that people have implemented, or plan to, for > interfacing with their network gear. > > Any other thoughts are welcome too, of course. > > (The details for individual operations aren't cast in stone yet and > could certainly be adjusted/extended). > > Robin > > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140619/26b76661/attachment.html From jira at bro-tracker.atlassian.net Thu Jun 19 12:49:07 2014 From: jira at bro-tracker.atlassian.net (grigorescu (JIRA)) Date: Thu, 19 Jun 2014 14:49:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1208) Unused Weirds In-Reply-To: References: Message-ID: grigorescu created BIT-1208: ------------------------------- Summary: Unused Weirds Key: BIT-1208 URL: https://bro-tracker.atlassian.net/browse/BIT-1208 Project: Bro Issue Tracker Issue Type: Task Components: Bro Affects Versions: 2.3 Reporter: grigorescu Priority: Low The following weirds are defined and assigned an action, but aren't being generated anywhere. We should figure out which ones we want to keep around and start generating them, and which ones we can remove: - DHCP_no_type_option - DHCP_wrong_msg_type - DHCP_wrong_op_type - HTTP_unknown_method (this seems to be a simple error, as http/main is generating unknown_HTTP_method) - corrupt_tcp_options - data_without_SYN_ACK - matching_undelivered_data - dns_changed_number_of_responses - dns_reply_seen_after_done - excessive_RPC_len - multiple_RPCs - partial_RPC_request - non_IPv4_packet -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Fri Jun 20 14:23:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 20 Jun 2014 16:23:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1206) Overuse of line numbers in doc/scripting/index.rst In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16826#comment-16826 ] Daniel Thayer commented on BIT-1206: ------------------------------------ Branch topic/dnthayer/ticket1206 contains a fix for this. > Overuse of line numbers in doc/scripting/index.rst > -------------------------------------------------- > > Key: BIT-1206 > URL: https://bro-tracker.atlassian.net/browse/BIT-1206 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Jon Siwek > Labels: documentation > Fix For: 2.4 > > > This document uses a lot of hardcoded line numbers. Seems too fragile/unmaintainable (line numbers have changed and rendered the doc outdated at least a few times now), maybe something can be done to generally improve it. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From jira at bro-tracker.atlassian.net Fri Jun 20 14:23:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Fri, 20 Jun 2014 16:23:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1206) Overuse of line numbers in doc/scripting/index.rst In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1206: ------------------------------- Status: Merge Request (was: Open) > Overuse of line numbers in doc/scripting/index.rst > -------------------------------------------------- > > Key: BIT-1206 > URL: https://bro-tracker.atlassian.net/browse/BIT-1206 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Jon Siwek > Labels: documentation > Fix For: 2.4 > > > This document uses a lot of hardcoded line numbers. Seems too fragile/unmaintainable (line numbers have changed and rendered the doc outdated at least a few times now), maybe something can be done to generally improve it. -- This message was sent by Atlassian JIRA (v6.3-OD-06-017#6327) From robin at icir.org Fri Jun 20 15:12:00 2014 From: robin at icir.org (Robin Sommer) Date: Fri, 20 Jun 2014 15:12:00 -0700 Subject: [Bro-Dev] Looking on feedback on PACF/reaction framework In-Reply-To: References: <20140619184132.GA34742@icir.org> Message-ID: <20140620221200.GT16910@icir.org> On Thu, Jun 19, 2014 at 15:21 -0400, you wrote: > - I believe Rule$target should be of type Target and not TargetType (which > is undefined). Ack. > - Some other options to consider for EntityType: > * Subnet > * MAC address > * User? (I believe some devices allow filtering based on user, if they > authenticate via VPN, 802.1X or something similar) Ack, as well. For subnets, we could even just use them generally instead of addresses, and specify addresses as /32. User is an interesting thought. One general question for the API is how much to standardize. A plugin can always just extend the RuleType if it has a specific cability no one else has. My hunch would be going with a small set initially that's likely supported by a majority of systems we're going to interface to. > - Should Rule have both orig and resp Entity fields? i.e. I could see a use > case for filtering traffic from an IP, to it, or both. Yes. Or alternatively, we could add ORIG and RESP to the EntityType instead? > - More generally, should Rule have an optional BPF? Perhaps this is one of > the use cases of arg_str. I'm reluctant to use BPF, for two reasons. One is that it's having some low-level problems, like VLANs etc. But more importantly, it's very generic and hence hard to map device capabilities. Basically it would only be supported by devices which indeed have full BPF capabilities; and other than host-based implementations filtering with libpcap that's probably not many (or, alternatively: Bro itself would need to do the filtering, which is kind of counterprodutive). I see the rules more as an (almost) lowest common denominator in terms of expressing filters that a range of devices can support efficiently. >From that perspective, I would rather aim to identify specific use cases ("drop IP") than provide a generic filter language. That said, I can see some hybrid in the future where we provide more complex filters than just simple entities, as long as they do map easily to a range of hardware. Asim has been looking at that for a bit already. For now we're going with the simple model for his work though. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From scampbell at lbl.gov Fri Jun 20 17:08:59 2014 From: scampbell at lbl.gov (Scott Campbell) Date: Fri, 20 Jun 2014 20:08:59 -0400 Subject: [Bro-Dev] Looking on feedback on PACF/reaction framework In-Reply-To: <20140619184132.GA34742@icir.org> References: <20140619184132.GA34742@icir.org> Message-ID: <53A4CD1B.4070701@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/19/14 2:41 PM, Robin Sommer wrote: > > I have revised the proposed API a bit, see > > http://www.bro.org/development/projects/pacf.html > > I would be interested in feedback regarding if (1) the User API is > generally expressed at a good level, and (2) if this covers the > functionality that people have implemented, or plan to, for > interfacing with their network gear. > > Any other thoughts are welcome too, of course. > > (The details for individual operations aren't cast in stone yet > and could certainly be adjusted/extended). > > Robin > > Besides all of Vlad's excellent points, I might add that OpenFlow related activity should be pointed at a controller rather than an individual switch. This might be one way to address the load balancing issues as well. The other question that I have is how you would identify the flow direction in the conn_id object in the instance where I want to shunt out one side of a connection? Might be nice to have a count() as well since many hardware devices have hard limits on what they can deal with. This also might make a nice example for an extension of the RuleType. Looks like you might have answered the flow question already via ORIG/RESP? thanks! scott -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOkzRsACgkQK2Plq8B7ZBy7SgCfUP8O4IprafnjoA0k5L9Z1WcK Pe8AoIzL57yQJFYAsGV7b3rr0t2DwiBb =xMhK -----END PGP SIGNATURE----- From noreply at bro.org Sat Jun 21 00:00:22 2014 From: noreply at bro.org (Merge Tracker) Date: Sat, 21 Jun 2014 00:00:22 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406210700.s5L70MMl031272@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------- BIT-1206 [1] Bro Jon Siwek - 2014-06-20 2.4 Normal Overuse of line numbers in doc/scripting/index.rst [1] BIT-1206 https://bro-tracker.atlassian.net/browse/BIT-1206 From robin at icir.org Sat Jun 21 10:08:03 2014 From: robin at icir.org (Robin Sommer) Date: Sat, 21 Jun 2014 10:08:03 -0700 Subject: [Bro-Dev] Looking on feedback on PACF/reaction framework In-Reply-To: <53A4CD1B.4070701@lbl.gov> References: <20140619184132.GA34742@icir.org> <53A4CD1B.4070701@lbl.gov> Message-ID: <20140621170803.GF34080@icir.org> On Fri, Jun 20, 2014 at 20:08 -0400, you wrote: > Besides all of Vlad's excellent points, I might add that OpenFlow > related activity should be pointed at a controller rather than an > individual switch. Yeah, the OpenFlow-related code in there is just some dummy code. Once we start writing an actual OpenFlow plugin, we can see how to structure that internally. I guess we may even end up having several ones if we want to interface to different controllers. > The other question that I have is how you would identify the flow > direction in the conn_id object in the instance where I want to shunt > out one side of a connection? You would specify EntityType::FLOW and then, by definition, conn_id$orig would be the source side and conn_i$resp the destination. I admit that might be a bit confusing, so we could also extend Entity with a separate flow_id item so that things don't get mixed up with standard connection semantics for conn_id. > Might be nice to have a count() as well since many hardware devices > have hard limits on what they can deal with. What would it count? Number of rules put in so far? At the level of the API (i.e., number of add() calls), or at the hardware level? (one add() could translate into multiple hardware filters I suppose). Thanks, Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From noreply at bro.org Sun Jun 22 00:00:17 2014 From: noreply at bro.org (Merge Tracker) Date: Sun, 22 Jun 2014 00:00:17 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406220700.s5M70HUu004666@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------- BIT-1206 [1] Bro Jon Siwek - 2014-06-20 2.4 Normal Overuse of line numbers in doc/scripting/index.rst [1] BIT-1206 https://bro-tracker.atlassian.net/browse/BIT-1206 From noreply at bro.org Mon Jun 23 00:00:21 2014 From: noreply at bro.org (Merge Tracker) Date: Mon, 23 Jun 2014 00:00:21 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406230700.s5N70Lsd010732@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------------- BIT-1206 [1] Bro Jon Siwek - 2014-06-20 2.4 Normal Overuse of line numbers in doc/scripting/index.rst [1] BIT-1206 https://bro-tracker.atlassian.net/browse/BIT-1206 From jira at bro-tracker.atlassian.net Mon Jun 23 08:13:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Mon, 23 Jun 2014 10:13:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1209) bro-cut needs tests In-Reply-To: References: Message-ID: Daniel Thayer created BIT-1209: ---------------------------------- Summary: bro-cut needs tests Key: BIT-1209 URL: https://bro-tracker.atlassian.net/browse/BIT-1209 Project: Bro Issue Tracker Issue Type: Improvement Components: bro-aux Reporter: Daniel Thayer Fix For: 2.4 It would be useful to have a set of tests for bro-cut. The tests should include tests of all command-line options, tests with and without BRO_CUT_TIMEFMT, and tests that specify various combinations of column names (including tests which swap the order of columns). -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From robin at icir.org Mon Jun 23 08:43:59 2014 From: robin at icir.org (Robin Sommer) Date: Mon, 23 Jun 2014 08:43:59 -0700 Subject: [Bro-Dev] Time for C++11? Message-ID: <20140623154359.GH2584@icir.org> I'm guessing (and hearing :-) that most of us would like to start using C++11 in Bro's code base. With compiler support now apparently broad and robust, and our 2.4 dev cycle starting, I'm thinking it may be a good time now to make the move. What I propose is: - We decide which minimum versions of GCC and clang (and their stdlibs) we need to require. - As a double-check, we survey the main OS distributions and make sure they offer that by now. - We put cmake magic in place to check for these versions. [1] - We switch to compiling all C++ code with -std=c++11. - We allow use of C++11 features in new code. - Over time, we modernize old code as appropiate. Probably just ad-hoc for the most part, as we touch it; but maybe we can also put some time towards systematic changes, like with some of clang's transition tools. Opinions? Robin [1] While we are at that, I suggest we also (re-)up the cmake version. Probably hard to find a C++11 tool chain with a many-years-old cmake. -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From vallentin at icir.org Mon Jun 23 11:13:07 2014 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 23 Jun 2014 11:13:07 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623154359.GH2584@icir.org> References: <20140623154359.GH2584@icir.org> Message-ID: <20140623181307.GQ1273@icir.org> > I'm guessing (and hearing :-) that most of us would like to start > using C++11 in Bro's code base. With compiler support now apparently > broad and robust, and our 2.4 dev cycle starting, I'm thinking it may > be a good time now to make the move. I would go one step further: let's aim for C++14. In many ways C++11 was just a half-hearted attempt to modernize the language. For example, automatic return type deduction and lambdas are just incomplete in C++11. > - We decide which minimum versions of GCC and clang (and their > stdlibs) we need to require. To be useful, we'd need gcc 4.9 anyway (because everything below has a broken implementation of std::regex) and 4.9 also supports the most important C++14 features (except for variable templates, which I think we can live without for a while). We'd get a way with Clang 3.3 but Clang 3.4 already has full C++14 support. Therefore, I suggest we require GCC 4.9 and Clang 3.4. > - As a double-check, we survey the main OS distributions and make > sure they offer that by now. Your install-clang script should give us some mileage when we use Clang, GCC is often more tightly integrated into the distribution package managers. > - We put cmake magic in place to check for these versions. [1] Since version 3.0 CMake supports explicit feature enumeration of available C++ features [1]. This may obviate the need of a specific compiler version, albeit a bit of fiddling. > - We switch to compiling all C++ code with -std=c++11. Or -std=c++1y :-). > - We allow use of C++11 features in new code. Further, I'm sure we could replace many existing hacks and workarounds in the existing code base. > - Over time, we modernize old code as appropiate. Probably just > ad-hoc for the most part, as we touch it; but maybe we can also > put some time towards systematic changes, like with some of > clang's transition tools. Tools sound interesting for existing code. Looking forward, it would also be useful to come up with a few guidelines, such as avoiding owning naked pointers, preferring value semantics where possible, etc. Matthias [1] http://stackoverflow.com/a/20165220/1170277 From vlad at grigorescu.org Mon Jun 23 11:17:07 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 23 Jun 2014 14:17:07 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623154359.GH2584@icir.org> References: <20140623154359.GH2584@icir.org> Message-ID: On Mon, Jun 23, 2014 at 11:43 AM, Robin Sommer wrote: > > - We decide which minimum versions of GCC and clang (and their > stdlibs) we need to require. > If the OpenSuSE build service idea moves forward, does that mean we can be stricter with the requirements? Hopefully, people should be able to install a package except if they want to try master or try a certain branch. --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140623/0c319865/attachment.html From robin at icir.org Mon Jun 23 11:35:36 2014 From: robin at icir.org (Robin Sommer) Date: Mon, 23 Jun 2014 11:35:36 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623181307.GQ1273@icir.org> References: <20140623154359.GH2584@icir.org> <20140623181307.GQ1273@icir.org> Message-ID: <20140623183536.GH5597@icir.org> On Mon, Jun 23, 2014 at 11:13 -0700, you wrote: > I would go one step further: let's aim for C++14. I was expecting you to propose that. :-) I'm very reluctant to rely on a cutting-edge compiler for compiling Bro. There's really not much worse for an open-source tool than downloading the code and then realizing that your system's compiler is too old to handle it. I think we need to ensure that most people will be able to directly download and compile Bro, without having to worry about much else. My hope is that we are that point now for C++11 (potentially by skipping use of some specific features), but clang 3.4 and gcc 4.9 sound like a stretch to me ... We should probably reverse the order of my list: survey OSs first what they ship these days, then decide what we are fine requiring. This looks like a nice C++11 summary for gcc 4.8 and clang 3.3: http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From robin at icir.org Mon Jun 23 11:37:20 2014 From: robin at icir.org (Robin Sommer) Date: Mon, 23 Jun 2014 11:37:20 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> Message-ID: <20140623183720.GI5597@icir.org> On Mon, Jun 23, 2014 at 14:17 -0400, you wrote: > If the OpenSuSE build service idea moves forward, does that mean we can be > stricter with the requirements? Hopefully, people should be able to install > a package except if they want to try master or try a certain branch. For many people that might remain a matter of taste. Personally, for example, I usually go for the source even if a project offers RPMs. So I'm not sure I would relax requirements just because we have more/better binaries. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From vlad at grigorescu.org Mon Jun 23 11:58:05 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 23 Jun 2014 14:58:05 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623183720.GI5597@icir.org> References: <20140623154359.GH2584@icir.org> <20140623183720.GI5597@icir.org> Message-ID: Fair enough. For surveying the environment, you can use DistroWatch. For example, to see which distros have gcc 4.9: http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9.0#pkgsearch The main stragglers seem to be RHEL and Ubuntu LTS. Ubuntu 12.04 has 4.6.3 and RHEL 6.5 has 4.4.7. I believe RHEL users can install a devtoolset, which has a more recent version installed under /opt, but we'll have to make sure CMake checks there. --Vlad On Mon, Jun 23, 2014 at 2:37 PM, Robin Sommer wrote: > > > On Mon, Jun 23, 2014 at 14:17 -0400, you wrote: > > > If the OpenSuSE build service idea moves forward, does that mean we can > be > > stricter with the requirements? Hopefully, people should be able to > install > > a package except if they want to try master or try a certain branch. > > For many people that might remain a matter of taste. Personally, for > example, I usually go for the source even if a project offers RPMs. So > I'm not sure I would relax requirements just because we have > more/better binaries. > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140623/21c2f7ba/attachment-0001.html From dnthayer at illinois.edu Mon Jun 23 12:01:37 2014 From: dnthayer at illinois.edu (Daniel Thayer) Date: Mon, 23 Jun 2014 14:01:37 -0500 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> <20140623183720.GI5597@icir.org> Message-ID: <53A87991.1010502@illinois.edu> According to distrowatch: RHEL 7 gcc 4.8.2 RHEL 6.5 gcc 4.4.7 debian 7 gcc 4.7.2 ubuntu 14.04 LTS gcc 4.8.2 ubuntu 12.04 LTS gcc 4.6.3 FreeBSD 10 gcc 4.7.3 FreeBSD 9.2 gcc 4.6.4 On 06/23/2014 01:58 PM, Vlad Grigorescu wrote: > Fair enough. > > For surveying the environment, you can use DistroWatch. For example, to > see which distros have gcc 4.9: > http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9.0#pkgsearch > > The main stragglers seem to be RHEL and Ubuntu LTS. Ubuntu 12.04 has > 4.6.3 and RHEL 6.5 has 4.4.7. > > I believe RHEL users can install a devtoolset, which has a more recent > version installed under /opt, but we'll have to make sure CMake checks > there. > > --Vlad > > > On Mon, Jun 23, 2014 at 2:37 PM, Robin Sommer > wrote: > > > > On Mon, Jun 23, 2014 at 14:17 -0400, you wrote: > > > If the OpenSuSE build service idea moves forward, does that mean > we can be > > stricter with the requirements? Hopefully, people should be able > to install > > a package except if they want to try master or try a certain branch. > > For many people that might remain a matter of taste. Personally, for > example, I usually go for the source even if a project offers RPMs. So > I'm not sure I would relax requirements just because we have > more/better binaries. > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 > * robin at icir.org > > ICSI/LBNL * Fax +1 (510) 666-2956 > * www.icir.org/robin > > > > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From vallentin at icir.org Mon Jun 23 12:16:46 2014 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 23 Jun 2014 12:16:46 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623183536.GH5597@icir.org> References: <20140623154359.GH2584@icir.org> <20140623181307.GQ1273@icir.org> <20140623183536.GH5597@icir.org> Message-ID: <20140623191646.GR1273@icir.org> > > I would go one step further: let's aim for C++14. > > I was expecting you to propose that. :-) And I knew your answer beforehand :-). > I'm very reluctant to rely on a cutting-edge compiler for compiling > Bro. There's really not much worse for an open-source tool than > downloading the code and then realizing that your system's compiler is > too old to handle it. I fully understand the concerns regarding our users: it's unreasonable to request manual bootstrapping of compilers or devoting extensive time just to install Bro. My main point was from a developer pointer of view: why drive with the handbrake on if it's not necessary. That said, if we're well aware of the limitations of C++11, I don't see an issue with this "compromise." > We should probably reverse the order of my list: survey OSs first what > they ship these days, then decide what we are fine requiring. Agreed. GCC 4.8 and Clang 3.3 are hopefully well-supported by most distributions by the end of the year. Matthias From bernhard at ICSI.Berkeley.EDU Mon Jun 23 12:50:23 2014 From: bernhard at ICSI.Berkeley.EDU (bernhard at ICSI.Berkeley.EDU) Date: Mon, 23 Jun 2014 12:50:23 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <53A87991.1010502@illinois.edu> References: <20140623154359.GH2584@icir.org> <20140623183720.GI5597@icir.org> <53A87991.1010502@illinois.edu> Message-ID: At least for FreeBSD 10 this is wrong. By default, it ships with clang3.3 and has no gcc installed in the base system. On 23 Jun 2014, at 12:01, Daniel Thayer wrote: > According to distrowatch: > > RHEL 7 gcc 4.8.2 > RHEL 6.5 gcc 4.4.7 > debian 7 gcc 4.7.2 > ubuntu 14.04 LTS gcc 4.8.2 > ubuntu 12.04 LTS gcc 4.6.3 > FreeBSD 10 gcc 4.7.3 > FreeBSD 9.2 gcc 4.6.4 > > > > On 06/23/2014 01:58 PM, Vlad Grigorescu wrote: >> Fair enough. >> >> For surveying the environment, you can use DistroWatch. For example, >> to >> see which distros have gcc 4.9: >> http://distrowatch.com/search.php?pkg=gcc&pkgver=4.9.0#pkgsearch >> >> The main stragglers seem to be RHEL and Ubuntu LTS. Ubuntu 12.04 has >> 4.6.3 and RHEL 6.5 has 4.4.7. >> >> I believe RHEL users can install a devtoolset, which has a more >> recent >> version installed under /opt, but we'll have to make sure CMake >> checks >> there. >> >> --Vlad >> >> >> On Mon, Jun 23, 2014 at 2:37 PM, Robin Sommer > > wrote: >> >> >> >> On Mon, Jun 23, 2014 at 14:17 -0400, you wrote: >> >> > If the OpenSuSE build service idea moves forward, does that mean >> we can be >> > stricter with the requirements? Hopefully, people should be able >> to install >> > a package except if they want to try master or try a certain >> branch. >> >> For many people that might remain a matter of taste. Personally, for >> example, I usually go for the source even if a project offers RPMs. >> So >> I'm not sure I would relax requirements just because we have >> more/better binaries. >> >> Robin >> >> -- >> Robin Sommer * Phone +1 (510) 722-6541 >> * robin at icir.org >> >> ICSI/LBNL * Fax +1 (510) 666-2956 >> * www.icir.org/robin >> >> >> >> >> >> _______________________________________________ >> bro-dev mailing list >> bro-dev at bro.org >> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev >> > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From bernhard at ICSI.Berkeley.EDU Mon Jun 23 12:59:26 2014 From: bernhard at ICSI.Berkeley.EDU (bernhard at ICSI.Berkeley.EDU) Date: Mon, 23 Jun 2014 12:59:26 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140623154359.GH2584@icir.org> References: <20140623154359.GH2584@icir.org> Message-ID: I am generally all in favor for that. The only problem I see with this is, that a number of people still seem to be using RHEL 6 or similar to run Bro - at least I think I remember a few people in the last few months mentioning that on IRC. However, if we offer binary packages for these old systems (as Vlad mentioned in his email) that might be ok. You still can install it without fidgeting on older systems that you might have to use in production and we still get to use the new features. On 23 Jun 2014, at 8:43, Robin Sommer wrote: > I'm guessing (and hearing :-) that most of us would like to start > using C++11 in Bro's code base. With compiler support now apparently > broad and robust, and our 2.4 dev cycle starting, I'm thinking it may > be a good time now to make the move. > > What I propose is: > > - We decide which minimum versions of GCC and clang (and their > stdlibs) we need to require. > > - As a double-check, we survey the main OS distributions and make > sure they offer that by now. > > - We put cmake magic in place to check for these versions. [1] > > - We switch to compiling all C++ code with -std=c++11. > > - We allow use of C++11 features in new code. > > - Over time, we modernize old code as appropiate. Probably just > ad-hoc for the most part, as we touch it; but maybe we can also > put some time towards systematic changes, like with some of > clang's transition tools. > > Opinions? > > Robin > > [1] While we are at that, I suggest we also (re-)up the cmake version. > Probably hard to find a C++11 tool chain with a many-years-old cmake. > > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From vlad at grigorescu.org Mon Jun 23 13:27:15 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 23 Jun 2014 16:27:15 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> Message-ID: Is it worth conducting a survey on the mailing list of what distros people are using? If we spin it the correct way (maybe something like "We're reevaluating what distros we test and fully support") and make it anonymous, even the corporate users might chime in. I figure that between this discussion, and the one on revisiting our packages, having some more information would be useful. --Vlad On Mon, Jun 23, 2014 at 3:59 PM, wrote: > I am generally all in favor for that. The only problem I see with this > is, that a number of people still seem to be using RHEL 6 or similar to > run Bro - at least I think I remember a few people in the last few > months mentioning that on IRC. > > However, if we offer binary packages for these old systems (as Vlad > mentioned in his email) that might be ok. You still can install it > without fidgeting on older systems that you might have to use in > production and we still get to use the new features. > > On 23 Jun 2014, at 8:43, Robin Sommer wrote: > > > I'm guessing (and hearing :-) that most of us would like to start > > using C++11 in Bro's code base. With compiler support now apparently > > broad and robust, and our 2.4 dev cycle starting, I'm thinking it may > > be a good time now to make the move. > > > > What I propose is: > > > > - We decide which minimum versions of GCC and clang (and their > > stdlibs) we need to require. > > > > - As a double-check, we survey the main OS distributions and make > > sure they offer that by now. > > > > - We put cmake magic in place to check for these versions. [1] > > > > - We switch to compiling all C++ code with -std=c++11. > > > > - We allow use of C++11 features in new code. > > > > - Over time, we modernize old code as appropiate. Probably just > > ad-hoc for the most part, as we touch it; but maybe we can also > > put some time towards systematic changes, like with some of > > clang's transition tools. > > > > Opinions? > > > > Robin > > > > [1] While we are at that, I suggest we also (re-)up the cmake version. > > Probably hard to find a C++11 tool chain with a many-years-old cmake. > > > > > > -- > > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > > _______________________________________________ > > bro-dev mailing list > > bro-dev at bro.org > > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140623/8281dad8/attachment.html From jira at bro-tracker.atlassian.net Mon Jun 23 14:33:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 23 Jun 2014 16:33:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1206) Overuse of line numbers in doc/scripting/index.rst In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1206: --------------------------- Assignee: Jon Siwek > Overuse of line numbers in doc/scripting/index.rst > -------------------------------------------------- > > Key: BIT-1206 > URL: https://bro-tracker.atlassian.net/browse/BIT-1206 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Jon Siwek > Assignee: Jon Siwek > Labels: documentation > Fix For: 2.4 > > > This document uses a lot of hardcoded line numbers. Seems too fragile/unmaintainable (line numbers have changed and rendered the doc outdated at least a few times now), maybe something can be done to generally improve it. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 23 14:58:07 2014 From: jira at bro-tracker.atlassian.net (Jon Siwek (JIRA)) Date: Mon, 23 Jun 2014 16:58:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1206) Overuse of line numbers in doc/scripting/index.rst In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Siwek updated BIT-1206: --------------------------- Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > Overuse of line numbers in doc/scripting/index.rst > -------------------------------------------------- > > Key: BIT-1206 > URL: https://bro-tracker.atlassian.net/browse/BIT-1206 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Reporter: Jon Siwek > Assignee: Jon Siwek > Labels: documentation > Fix For: 2.4 > > > This document uses a lot of hardcoded line numbers. Seems too fragile/unmaintainable (line numbers have changed and rendered the doc outdated at least a few times now), maybe something can be done to generally improve it. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From robin at icir.org Mon Jun 23 17:13:40 2014 From: robin at icir.org (Robin Sommer) Date: Mon, 23 Jun 2014 17:13:40 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> Message-ID: <20140624001340.GR5597@icir.org> On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: > Is it worth conducting a survey on the mailing list of what distros people > are using? Yeah, that's a good idea. Is anybody up for creating a SurveyMonkey or Google Form that lists the most common OS/distros so that we can send a link to the list? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From vlad at grigorescu.org Mon Jun 23 17:34:42 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 23 Jun 2014 20:34:42 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <20140624001340.GR5597@icir.org> References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> Message-ID: I got it. On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer wrote: > > > On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: > > > Is it worth conducting a survey on the mailing list of what distros > people > > are using? > > Yeah, that's a good idea. Is anybody up for creating a SurveyMonkey or > Google Form that lists the most common OS/distros so that we can send > a link to the list? > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140623/46a12469/attachment.html From vlad at grigorescu.org Mon Jun 23 19:15:27 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Mon, 23 Jun 2014 22:15:27 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> Message-ID: The SurveyMonkey logic is quite limited, but here's a first stab: https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5 Any major distros that I forgot? Or that I can remove? Do we know what architectures Bro currently supports? Apart from the obvious x86 and x86-64, does it support PowerPC? Is it worth asking if there's another architecture they'd like to see supported (maybe ARM)? --Vlad On Mon, Jun 23, 2014 at 8:34 PM, Vlad Grigorescu wrote: > I got it. > > > On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer wrote: > >> >> >> On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: >> >> > Is it worth conducting a survey on the mailing list of what distros >> people >> > are using? >> >> Yeah, that's a good idea. Is anybody up for creating a SurveyMonkey or >> Google Form that lists the most common OS/distros so that we can send >> a link to the list? >> >> Robin >> >> -- >> Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org >> ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140623/826456ff/attachment.html From dnthayer at illinois.edu Mon Jun 23 20:59:44 2014 From: dnthayer at illinois.edu (Daniel Thayer) Date: Mon, 23 Jun 2014 22:59:44 -0500 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> Message-ID: <53A8F7B0.4090609@illinois.edu> You left out Scientific Linux, and FreeBSD 8.4 On 06/23/2014 09:15 PM, Vlad Grigorescu wrote: > The SurveyMonkey logic is quite limited, but here's a first stab: > > https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5 > > Any major distros that I forgot? Or that I can remove? > > Do we know what architectures Bro currently supports? Apart from the > obvious x86 and x86-64, does it support PowerPC? Is it worth asking if > there's another architecture they'd like to see supported (maybe ARM)? > > --Vlad > > > On Mon, Jun 23, 2014 at 8:34 PM, Vlad Grigorescu > wrote: > > I got it. > > > On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer > wrote: > > > > On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: > > > Is it worth conducting a survey on the mailing list of what > distros people > > are using? > > Yeah, that's a good idea. Is anybody up for creating a > SurveyMonkey or > Google Form that lists the most common OS/distros so that we can > send > a link to the list? > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 > * robin at icir.org > > ICSI/LBNL * Fax +1 (510) 666-2956 > * www.icir.org/robin > > > > > > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev > From noreply at bro.org Tue Jun 24 00:00:20 2014 From: noreply at bro.org (Merge Tracker) Date: Tue, 24 Jun 2014 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406240700.s5O70KeH012785@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------------- fa6dd0f [1] bro-aux Daniel Thayer 2014-06-23 Change utc options to not always override local time [1] fa6dd0f https://github.com/bro/bro-aux/commit/fa6dd0f99d51cf28cba64a9db3724416cb842456 From gc355804 at ohio.edu Tue Jun 24 00:02:35 2014 From: gc355804 at ohio.edu (Gilbert Clark) Date: Tue, 24 Jun 2014 03:02:35 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> Message-ID: <53A9228B.7050705@ohio.edu> +1 for ARM -Gilbert On 6/23/14, 10:15 PM, Vlad Grigorescu wrote: > The SurveyMonkey logic is quite limited, but here's a first stab: > > https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5 > > Any major distros that I forgot? Or that I can remove? > > Do we know what architectures Bro currently supports? Apart from the > obvious x86 and x86-64, does it support PowerPC? Is it worth asking if > there's another architecture they'd like to see supported (maybe ARM)? > > --Vlad > > > On Mon, Jun 23, 2014 at 8:34 PM, Vlad Grigorescu > wrote: > > I got it. > > > On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer > wrote: > > > > On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: > > > Is it worth conducting a survey on the mailing list of what > distros people > > are using? > > Yeah, that's a good idea. Is anybody up for creating a > SurveyMonkey or > Google Form that lists the most common OS/distros so that we > can send > a link to the list? > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 > * robin at icir.org > > ICSI/LBNL * Fax +1 (510) 666-2956 > * www.icir.org/robin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140624/1d03f114/attachment-0001.html From vlad at grigorescu.org Tue Jun 24 03:49:12 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Tue, 24 Jun 2014 06:49:12 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <53A8F7B0.4090609@illinois.edu> References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> <53A8F7B0.4090609@illinois.edu> Message-ID: On Mon, Jun 23, 2014 at 11:59 PM, Daniel Thayer wrote: > You left out Scientific Linux, Well, I have this comment under "What Linux distro do you run Bro on?": Note: Please select the "parent" distro if yours isn't listed (e.g. if you're running Scientific Linux, select RHEL) Is there any functional difference between Scientific and RHEL, in terms of package versions? Since their stated goal is "as close to the commercial enterprise distribution as we can get it," I figured it was a safe bet leaving it off. I can certainly add it, though. and FreeBSD 8.4 Ah, good catch. That's what I get for relying on the DistroWatch page... Added a few more FreeBSD versions. --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140624/e1b0bd3f/attachment.html From dnthayer at illinois.edu Tue Jun 24 05:45:26 2014 From: dnthayer at illinois.edu (Daniel Thayer) Date: Tue, 24 Jun 2014 07:45:26 -0500 Subject: [Bro-Dev] Time for C++11? In-Reply-To: References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> <53A8F7B0.4090609@illinois.edu> Message-ID: <53A972E6.9030203@illinois.edu> On 06/24/2014 05:49 AM, Vlad Grigorescu wrote: > On Mon, Jun 23, 2014 at 11:59 PM, Daniel Thayer > wrote: > > You left out Scientific Linux, > > > Well, I have this comment under "What Linux distro do you run Bro on?": > Note: Please select the "parent" distro if yours isn't listed (e.g. if > you're running Scientific Linux, select RHEL) > > Is there any functional difference between Scientific and RHEL, in terms > of package versions? Since their stated goal is "as close to the > commercial enterprise distribution as we can get it," I figured it was a > safe bet leaving it off. I can certainly add it, though. Maybe you should just combine RHEL and CentOS into one entry, like this: RHEL/CentOS/Scientific Linux From vlad at grigorescu.org Tue Jun 24 06:20:52 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Tue, 24 Jun 2014 09:20:52 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <53A972E6.9030203@illinois.edu> References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> <53A8F7B0.4090609@illinois.edu> <53A972E6.9030203@illinois.edu> Message-ID: Good idea, thanks. Updated. On Tue, Jun 24, 2014 at 8:45 AM, Daniel Thayer wrote: > On 06/24/2014 05:49 AM, Vlad Grigorescu wrote: > >> On Mon, Jun 23, 2014 at 11:59 PM, Daniel Thayer > > wrote: >> >> You left out Scientific Linux, >> >> >> Well, I have this comment under "What Linux distro do you run Bro on?": >> Note: Please select the "parent" distro if yours isn't listed (e.g. if >> you're running Scientific Linux, select RHEL) >> >> Is there any functional difference between Scientific and RHEL, in terms >> of package versions? Since their stated goal is "as close to the >> commercial enterprise distribution as we can get it," I figured it was a >> safe bet leaving it off. I can certainly add it, though. >> > > > Maybe you should just combine RHEL and CentOS into one entry, like this: > > RHEL/CentOS/Scientific Linux > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140624/433a6156/attachment.html From bernhard at ICSI.Berkeley.EDU Tue Jun 24 07:46:05 2014 From: bernhard at ICSI.Berkeley.EDU (bernhard at ICSI.Berkeley.EDU) Date: Tue, 24 Jun 2014 07:46:05 -0700 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <53A9228B.7050705@ohio.edu> References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> <53A9228B.7050705@ohio.edu> Message-ID: <0A071AA6-6637-48C5-B0A9-F822CAF2031A@icsi.berkeley.edu> The last time I tried (a few months ago), Bro worked fine on arm. On the opens use build service, one of the arm builds also went through. From time to time we get people on IRC compiling it on their raspberry pi's - but those are kind of too slow to actually use it. On 24 Jun 2014, at 0:02, Gilbert Clark wrote: > +1 for ARM > > -Gilbert > > On 6/23/14, 10:15 PM, Vlad Grigorescu wrote: >> The SurveyMonkey logic is quite limited, but here's a first stab: >> >> https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5 >> >> Any major distros that I forgot? Or that I can remove? >> >> Do we know what architectures Bro currently supports? Apart from the >> obvious x86 and x86-64, does it support PowerPC? Is it worth asking >> if there's another architecture they'd like to see supported (maybe >> ARM)? >> >> --Vlad >> >> >> On Mon, Jun 23, 2014 at 8:34 PM, Vlad Grigorescu > > wrote: >> >> I got it. >> >> >> On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer > > wrote: >> >> >> >> On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: >> >> > Is it worth conducting a survey on the mailing list of what >> distros people >> > are using? >> >> Yeah, that's a good idea. Is anybody up for creating a >> SurveyMonkey or >> Google Form that lists the most common OS/distros so that we >> can send >> a link to the list? >> >> Robin >> >> -- >> Robin Sommer * Phone +1 (510) 722-6541 >> * robin at icir.org >> >> ICSI/LBNL * Fax +1 (510) 666-2956 >> * www.icir.org/robin >> >> >> >> > > _______________________________________________ > bro-dev mailing list > bro-dev at bro.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From gc355804 at ohio.edu Tue Jun 24 13:05:58 2014 From: gc355804 at ohio.edu (Gilbert Clark) Date: Tue, 24 Jun 2014 16:05:58 -0400 Subject: [Bro-Dev] Time for C++11? In-Reply-To: <0A071AA6-6637-48C5-B0A9-F822CAF2031A@icsi.berkeley.edu> References: <20140623154359.GH2584@icir.org> <20140624001340.GR5597@icir.org> <53A9228B.7050705@ohio.edu> <0A071AA6-6637-48C5-B0A9-F822CAF2031A@icsi.berkeley.edu> Message-ID: <53A9DA26.1010806@ohio.edu> +1 that it works on a raspberry pi (have it running on one here, too :) ), but also +1 that seems too slow to really be practically useful. Never spent much time trying to tune it, though, so maybe there could be a way to speed things up. -Gilbert On 6/24/14, 10:46 AM, bernhard at ICSI.Berkeley.EDU wrote: > The last time I tried (a few months ago), Bro worked fine on arm. On the > opens use build service, one of the arm builds also went through. From > time to time we get people on IRC compiling it on their raspberry pi's - > but those are kind of too slow to actually use it. > > On 24 Jun 2014, at 0:02, Gilbert Clark wrote: > >> +1 for ARM >> >> -Gilbert >> >> On 6/23/14, 10:15 PM, Vlad Grigorescu wrote: >>> The SurveyMonkey logic is quite limited, but here's a first stab: >>> >>> https://www.surveymonkey.com/create/survey/preview?sm=sMxABvZfS7kFp1nczfE1LmaagTQleFF7GNi5q6aW_2Fnz7aihojblvATta4i5un_2FS5 >>> >>> Any major distros that I forgot? Or that I can remove? >>> >>> Do we know what architectures Bro currently supports? Apart from the >>> obvious x86 and x86-64, does it support PowerPC? Is it worth asking >>> if there's another architecture they'd like to see supported (maybe >>> ARM)? >>> >>> --Vlad >>> >>> >>> On Mon, Jun 23, 2014 at 8:34 PM, Vlad Grigorescu >> > wrote: >>> >>> I got it. >>> >>> >>> On Mon, Jun 23, 2014 at 8:13 PM, Robin Sommer >> > wrote: >>> >>> >>> >>> On Mon, Jun 23, 2014 at 16:27 -0400, you wrote: >>> >>> > Is it worth conducting a survey on the mailing list of what >>> distros people >>> > are using? >>> >>> Yeah, that's a good idea. Is anybody up for creating a >>> SurveyMonkey or >>> Google Form that lists the most common OS/distros so that we >>> can send >>> a link to the list? >>> >>> Robin >>> >>> -- >>> Robin Sommer * Phone +1 (510) 722-6541 >>> * robin at icir.org >>> >>> ICSI/LBNL * Fax +1 (510) 666-2956 >>> * www.icir.org/robin >>> >>> >>> >>> >> _______________________________________________ >> bro-dev mailing list >> bro-dev at bro.org >> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev From noreply at bro.org Wed Jun 25 00:00:19 2014 From: noreply at bro.org (Merge Tracker) Date: Wed, 25 Jun 2014 00:00:19 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406250700.s5P70J62011093@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------------- fa6dd0f [1] bro-aux Daniel Thayer 2014-06-23 Change utc options to not always override local time [1] fa6dd0f https://github.com/bro/bro-aux/commit/fa6dd0f99d51cf28cba64a9db3724416cb842456 From jira at bro-tracker.atlassian.net Wed Jun 25 09:45:07 2014 From: jira at bro-tracker.atlassian.net (Nicholas Weaver (JIRA)) Date: Wed, 25 Jun 2014 11:45:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1210) Safe "Exec" python subprocess.Popen style In-Reply-To: References: Message-ID: Nicholas Weaver created BIT-1210: ------------------------------------ Summary: Safe "Exec" python subprocess.Popen style Key: BIT-1210 URL: https://bro-tracker.atlassian.net/browse/BIT-1210 Project: Bro Issue Tracker Issue Type: New Feature Components: Bro Affects Versions: git/master Reporter: Nicholas Weaver Priority: Low The system() and exec::command routines/types take a string which is passed to the shell for execution. This both has efficiency issues (needlessly invoking a shell) and security issues if str_shell_escape is forgotten/incorrect. A better alternative (This would probably require a separate bif for backwards compatibility) would be in the style of Python's subprocess.Popen, which instead of taking a string takes a vector of strings, does not invoke a shell by default, and instead directly fork() and execvp's the new process, with the first argument being the target executable and the subsequent arguments forming the rest of the target's argv. This has a substantial advantage as "Unlike some other popen functions, this implementation will never call a system shell implicitly. This means that all characters, including shell metacharacters, can safely be passed to child processes." -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From noreply at bro.org Thu Jun 26 00:00:26 2014 From: noreply at bro.org (Merge Tracker) Date: Thu, 26 Jun 2014 00:00:26 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406260700.s5Q70QqC015208@bro-ids.icir.org> Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------------- fa6dd0f [1] bro-aux Daniel Thayer 2014-06-23 Change utc options to not always override local time bfaa082 [2] bro Jon Siwek 2014-06-25 Fix a reference counting bug in ListVal ctor. [1] fa6dd0f https://github.com/bro/bro-aux/commit/fa6dd0f99d51cf28cba64a9db3724416cb842456 [2] bfaa082 https://github.com/bro/bro/commit/bfaa082aeeb1b5e4ffc51a912008ac9cc6409d72 From jira at bro-tracker.atlassian.net Thu Jun 26 13:00:07 2014 From: jira at bro-tracker.atlassian.net (Michel (JIRA)) Date: Thu, 26 Jun 2014 15:00:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1211) Bro fails to compile with DataSeries support In-Reply-To: References: Message-ID: Michel created BIT-1211: --------------------------- Summary: Bro fails to compile with DataSeries support Key: BIT-1211 URL: https://bro-tracker.atlassian.net/browse/BIT-1211 Project: Bro Issue Tracker Issue Type: Patch Components: Bro Affects Versions: 2.3 Environment: CentOS 6.5 x86_64 Reporter: Michel Attachments: 0001-DataSeries-compilation-issue-fixed.patch Bro fails to compile with DataSeries support. Dataseries has been compiled from source (retrieved from github). Patch replaces references to 'compress_X' with 'compress_mode_X' for the different compression algorithms and replaces all occurrences of 'gz' with 'zlib' as gz seems to have been removed -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Thu Jun 26 13:45:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 26 Jun 2014 15:45:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1209) bro-cut needs tests In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Thayer updated BIT-1209: ------------------------------- Status: Merge Request (was: Open) > bro-cut needs tests > ------------------- > > Key: BIT-1209 > URL: https://bro-tracker.atlassian.net/browse/BIT-1209 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: bro-aux > Reporter: Daniel Thayer > Fix For: 2.4 > > > It would be useful to have a set of tests for bro-cut. The tests should include tests of all command-line options, tests with and without BRO_CUT_TIMEFMT, and tests that specify various combinations > of column names (including tests which swap the order of columns). -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Thu Jun 26 13:45:07 2014 From: jira at bro-tracker.atlassian.net (Daniel Thayer (JIRA)) Date: Thu, 26 Jun 2014 15:45:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1209) bro-cut needs tests In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900#comment-16900 ] Daniel Thayer commented on BIT-1209: ------------------------------------ Branch topic/dnthayer/ticket1209 contains a set of tests for bro-cut. > bro-cut needs tests > ------------------- > > Key: BIT-1209 > URL: https://bro-tracker.atlassian.net/browse/BIT-1209 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: bro-aux > Reporter: Daniel Thayer > Fix For: 2.4 > > > It would be useful to have a set of tests for bro-cut. The tests should include tests of all command-line options, tests with and without BRO_CUT_TIMEFMT, and tests that specify various combinations > of column names (including tests which swap the order of columns). -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Thu Jun 26 14:14:07 2014 From: jira at bro-tracker.atlassian.net (Michel (JIRA)) Date: Thu, 26 Jun 2014 16:14:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1211) Bro fails to compile with DataSeries support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michel updated BIT-1211: ------------------------ Status: Merge Request (was: Open) > Bro fails to compile with DataSeries support > -------------------------------------------- > > Key: BIT-1211 > URL: https://bro-tracker.atlassian.net/browse/BIT-1211 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 6.5 x86_64 > Reporter: Michel > Labels: logging > Attachments: 0001-DataSeries-compilation-issue-fixed.patch > > > Bro fails to compile with DataSeries support. > Dataseries has been compiled from source (retrieved from github). > Patch replaces references to 'compress_X' with 'compress_mode_X' for the different compression algorithms and replaces all occurrences of 'gz' with 'zlib' as gz seems to have been removed -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Thu Jun 26 17:29:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 26 Jun 2014 19:29:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1211) Bro fails to compile with DataSeries support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901#comment-16901 ] Robin Sommer commented on BIT-1211: ----------------------------------- At first I thought we'd need ifdef's to support old and new DS versions simultaneously , however after applying the patch Bro actually still compiles fine for me with my older DS installation, so I assume not differentiating further is ok. Merging, thanks! > Bro fails to compile with DataSeries support > -------------------------------------------- > > Key: BIT-1211 > URL: https://bro-tracker.atlassian.net/browse/BIT-1211 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 6.5 x86_64 > Reporter: Michel > Labels: logging > Attachments: 0001-DataSeries-compilation-issue-fixed.patch > > > Bro fails to compile with DataSeries support. > Dataseries has been compiled from source (retrieved from github). > Patch replaces references to 'compress_X' with 'compress_mode_X' for the different compression algorithms and replaces all occurrences of 'gz' with 'zlib' as gz seems to have been removed -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Thu Jun 26 17:32:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Thu, 26 Jun 2014 19:32:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1209) bro-cut needs tests In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer reassigned BIT-1209: --------------------------------- Assignee: Robin Sommer > bro-cut needs tests > ------------------- > > Key: BIT-1209 > URL: https://bro-tracker.atlassian.net/browse/BIT-1209 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: bro-aux > Reporter: Daniel Thayer > Assignee: Robin Sommer > Fix For: 2.4 > > > It would be useful to have a set of tests for bro-cut. The tests should include tests of all command-line options, tests with and without BRO_CUT_TIMEFMT, and tests that specify various combinations > of column names (including tests which swap the order of columns). -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From noreply at bro.org Fri Jun 27 00:00:20 2014 From: noreply at bro.org (Merge Tracker) Date: Fri, 27 Jun 2014 00:00:20 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406270700.s5R70Ks3002607@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ------------- ------------ ---------- ------------- ---------- -------------------------------------------- BIT-1211 [1] Bro Michel - 2014-06-26 - Normal Bro fails to compile with DataSeries support BIT-1209 [2] bro-aux Daniel Thayer Robin Sommer 2014-06-26 2.4 Normal bro-cut needs tests Open Fastpath Commits ====================== Commit Component Author Date Summary ----------- ----------- ------------- ---------- ---------------------------------------------------- fa6dd0f [3] bro-aux Daniel Thayer 2014-06-23 Change utc options to not always override local time bfaa082 [4] bro Jon Siwek 2014-06-25 Fix a reference counting bug in ListVal ctor. [1] BIT-1211 https://bro-tracker.atlassian.net/browse/BIT-1211 [2] BIT-1209 https://bro-tracker.atlassian.net/browse/BIT-1209 [3] fa6dd0f https://github.com/bro/bro-aux/commit/fa6dd0f99d51cf28cba64a9db3724416cb842456 [4] bfaa082 https://github.com/bro/bro/commit/bfaa082aeeb1b5e4ffc51a912008ac9cc6409d72 From jira at bro-tracker.atlassian.net Fri Jun 27 07:10:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Fri, 27 Jun 2014 09:10:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1209) bro-cut needs tests In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1209: ------------------------------ Resolution: Merged (was: Fixed) Status: Closed (was: Merge Request) > bro-cut needs tests > ------------------- > > Key: BIT-1209 > URL: https://bro-tracker.atlassian.net/browse/BIT-1209 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: bro-aux > Reporter: Daniel Thayer > Assignee: Robin Sommer > Fix For: 2.4 > > > It would be useful to have a set of tests for bro-cut. The tests should include tests of all command-line options, tests with and without BRO_CUT_TIMEFMT, and tests that specify various combinations > of column names (including tests which swap the order of columns). -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From vlad at grigorescu.org Fri Jun 27 13:35:24 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Fri, 27 Jun 2014 16:35:24 -0400 Subject: [Bro-Dev] Documenting Weirds Message-ID: It seems like one area where our documentation is sorely lacking is the weirds. Apart from comments in the code, I believe the only documentation is the name of the weird itself. Is there a mechanism in Broxygen to document weirds? If not, has anyone thought about what such a mechanism might look like? --Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140627/d6391745/attachment.html From jsiwek at illinois.edu Fri Jun 27 14:41:45 2014 From: jsiwek at illinois.edu (Siwek, Jon) Date: Fri, 27 Jun 2014 21:41:45 +0000 Subject: [Bro-Dev] Documenting Weirds In-Reply-To: References: Message-ID: On Jun 27, 2014, at 3:35 PM, Vlad Grigorescu wrote: > Is there a mechanism in Broxygen to document weirds? If not, has anyone thought about what such a mechanism might look like? There?s not currently a mechanism. Things that Broxygen can easily aid in documenting are tied to a script-layer name/symbol/identifier. Weirds differ since they?re string values. A suggestion would be to change weirds to use an enum instead of a string value. That would then provide an identifier to hang documentation off of and also maybe help keep the core-analyzers in sync w/ scripts (e.g. there?s currently not a robust way to signify to a user that a weird was removed/changed and thus their scripts may become stale or possibly broken in the case of a rename). - Jon From robin at icir.org Fri Jun 27 14:54:10 2014 From: robin at icir.org (Robin Sommer) Date: Fri, 27 Jun 2014 14:54:10 -0700 Subject: [Bro-Dev] Documenting Weirds In-Reply-To: References: Message-ID: <20140627215410.GL9039@icir.org> On Fri, Jun 27, 2014 at 21:41 +0000, you wrote: > A suggestion would be to change weirds to use an enum instead of a > string value. Yeah, either that, or introducing a structured ID namespace (e.g., "http.client.unexpected_data"), potentially with some static analysis to find IDs that aren't linked to docs. In either case it would be nice if the scheme unified reporting weirds from core and script land. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin From noreply at bro.org Sat Jun 28 00:00:16 2014 From: noreply at bro.org (Merge Tracker) Date: Sat, 28 Jun 2014 00:00:16 -0700 Subject: [Bro-Dev] [Auto] Merge Status Message-ID: <201406280700.s5S70G5h024354@bro-ids.icir.org> Open Merge Requests =================== ID Component Reporter Assignee Updated For Version Priority Summary ------------ ----------- ---------- ---------- ---------- ------------- ---------- -------------------------------------------- BIT-1211 [1] Bro Michel - 2014-06-26 - Normal Bro fails to compile with DataSeries support [1] BIT-1211 https://bro-tracker.atlassian.net/browse/BIT-1211 From vlad at grigorescu.org Sat Jun 28 08:46:08 2014 From: vlad at grigorescu.org (Vlad Grigorescu) Date: Sat, 28 Jun 2014 11:46:08 -0400 Subject: [Bro-Dev] Documenting Weirds In-Reply-To: <20140627215410.GL9039@icir.org> References: <20140627215410.GL9039@icir.org> Message-ID: I was thinking of just a simple Weird::Type enum with comments, much like how the Notice documentation is generated. I do also like the thought of the structured namespace. Maybe more generally, we should to make a Weird closer to a Notice. For example, if a file analyzer generates a weird, there are no fields in the weird.log to map it back to the offending file. I realize that that's trickier, since Weirds can be generated from either the core or script-land. --Vlad On Fri, Jun 27, 2014 at 5:54 PM, Robin Sommer wrote: > > > On Fri, Jun 27, 2014 at 21:41 +0000, you wrote: > > > A suggestion would be to change weirds to use an enum instead of a > > string value. > > Yeah, either that, or introducing a structured ID namespace (e.g., > "http.client.unexpected_data"), potentially with some static analysis > to find IDs that aren't linked to docs. > > In either case it would be nice if the scheme unified reporting weirds > from core and script land. > > Robin > > -- > Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org/robin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140628/340cd375/attachment.html From jira at bro-tracker.atlassian.net Sat Jun 28 10:22:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Sat, 28 Jun 2014 12:22:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1211) Bro fails to compile with DataSeries support In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1211: ------------------------------ Status: Closed (was: Merge Request) > Bro fails to compile with DataSeries support > -------------------------------------------- > > Key: BIT-1211 > URL: https://bro-tracker.atlassian.net/browse/BIT-1211 > Project: Bro Issue Tracker > Issue Type: Patch > Components: Bro > Affects Versions: 2.3 > Environment: CentOS 6.5 x86_64 > Reporter: Michel > Labels: logging > Attachments: 0001-DataSeries-compilation-issue-fixed.patch > > > Bro fails to compile with DataSeries support. > Dataseries has been compiled from source (retrieved from github). > Patch replaces references to 'compress_X' with 'compress_mode_X' for the different compression algorithms and replaces all occurrences of 'gz' with 'zlib' as gz seems to have been removed -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 06:26:08 2014 From: jira at bro-tracker.atlassian.net (Marek Balint (JIRA)) Date: Mon, 30 Jun 2014 08:26:08 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: Marek Balint created BIT-1212: --------------------------------- Summary: Segfault in X509 file analyzer Key: BIT-1212 URL: https://bro-tracker.atlassian.net/browse/BIT-1212 Project: Bro Issue Tracker Issue Type: Problem Components: Bro Affects Versions: 2.3 Reporter: Marek Balint Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 06:29:07 2014 From: jira at bro-tracker.atlassian.net (Marek Balint (JIRA)) Date: Mon, 30 Jun 2014 08:29:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000#comment-17000 ] Marek Balint commented on BIT-1212: ----------------------------------- That should be "basic->certs" (not "base->certs" - typo in Description) in call to sk_X509_push. > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 06:50:07 2014 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 30 Jun 2014 08:50:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johanna Amann reassigned BIT-1212: ---------------------------------- Assignee: Johanna Amann > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 06:56:07 2014 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 30 Jun 2014 08:56:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001#comment-17001 ] Johanna Amann commented on BIT-1212: ------------------------------------ Hi. May I ask which version of Bro you are using? This seems to have been fixed before the 2.3 release (I think it was fixed inbetween the beta and the final release). > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 07:50:07 2014 From: jira at bro-tracker.atlassian.net (Marek Balint (JIRA)) Date: Mon, 30 Jun 2014 09:50:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17002#comment-17002 ] Marek Balint commented on BIT-1212: ----------------------------------- It is released 2.3 (not beta). The file in question is on ff00c0786af01bddc8aa5b455edbb214ff06c4e7. > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 08:08:07 2014 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 30 Jun 2014 10:08:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003#comment-17003 ] Johanna Amann commented on BIT-1212: ------------------------------------ Ah, sorry, you are right. That apparently is another special case I did not come accross (or think of) during my tests. :/ > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 08:09:07 2014 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 30 Jun 2014 10:09:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004#comment-17004 ] Johanna Amann commented on BIT-1212: ------------------------------------ May I ask which server you encountered this bug with? That might make writing a testcase a bit easier... > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 08:34:07 2014 From: jira at bro-tracker.atlassian.net (Marek Balint (JIRA)) Date: Mon, 30 Jun 2014 10:34:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005#comment-17005 ] Marek Balint commented on BIT-1212: ----------------------------------- Hi, the server is ocsp.digicert.com. > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 11:07:07 2014 From: jira at bro-tracker.atlassian.net (Johanna Amann (JIRA)) Date: Mon, 30 Jun 2014 13:07:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1212) Segfault in X509 file analyzer In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006#comment-17006 ] Johanna Amann commented on BIT-1212: ------------------------------------ Hello Marek, would it perhaps be possible to create a test pcap that produces the crash? When I connect to ocsp.digicert.com:443 and request ocsp stapling, everything seems to work as expected (example trace at http://www.icir.org/johanna/traces/ocsp-stapling-digicert.pcap). > Segfault in X509 file analyzer > ------------------------------ > > Key: BIT-1212 > URL: https://bro-tracker.atlassian.net/browse/BIT-1212 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: 2.3 > Reporter: Marek Balint > Assignee: Johanna Amann > > Bro segfaults in src/file_analysis/x509/functions.bif:256, due to base->certs being NULL. -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 15:51:07 2014 From: jira at bro-tracker.atlassian.net (Nicholas Weaver (JIRA)) Date: Mon, 30 Jun 2014 17:51:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1213) broccoli/bindings/broccoli-python not building correctly In-Reply-To: References: Message-ID: Nicholas Weaver created BIT-1213: ------------------------------------ Summary: broccoli/bindings/broccoli-python not building correctly Key: BIT-1213 URL: https://bro-tracker.atlassian.net/browse/BIT-1213 Project: Bro Issue Tracker Issue Type: Problem Components: broccoli-python Affects Versions: 2.3 Environment: OS-X 10.9.3 Reporter: Nicholas Weaver The setup.py routine fails due to path changes in 2.3, namely that the broccoli.h file is now in ../../build/src, as is the resulting library. This patch appears to work: diff --git a/setup.py b/setup.py index 8a017f1..9cd19ae 100755 --- a/setup.py +++ b/setup.py @@ -12,8 +12,8 @@ setup(name="broccoli-python", py_modules=['broccoli'], ext_modules = [ Extension("_broccoli_intern", ["broccoli_intern_wrap.c"], - include_dirs=["../../src"], - library_dirs=["../../src/.libs"], + include_dirs=["../../build/src"], + library_dirs=["../../build/src"], libraries=["broccoli"])] ) -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327) From jira at bro-tracker.atlassian.net Mon Jun 30 17:34:07 2014 From: jira at bro-tracker.atlassian.net (Robin Sommer (JIRA)) Date: Mon, 30 Jun 2014 19:34:07 -0500 (CDT) Subject: [Bro-Dev] [JIRA] (BIT-1213) broccoli/bindings/broccoli-python not building correctly In-Reply-To: References: Message-ID: [ https://bro-tracker.atlassian.net/browse/BIT-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Sommer updated BIT-1213: ------------------------------ Status: Merge Request (was: Open) > broccoli/bindings/broccoli-python not building correctly > -------------------------------------------------------- > > Key: BIT-1213 > URL: https://bro-tracker.atlassian.net/browse/BIT-1213 > Project: Bro Issue Tracker > Issue Type: Problem > Components: broccoli-python > Affects Versions: 2.3 > Environment: OS-X 10.9.3 > Reporter: Nicholas Weaver > > The setup.py routine fails due to path changes in 2.3, namely that the broccoli.h file is now in ../../build/src, as is the resulting library. > This patch appears to work: > diff --git a/setup.py b/setup.py > index 8a017f1..9cd19ae 100755 > --- a/setup.py > +++ b/setup.py > @@ -12,8 +12,8 @@ setup(name="broccoli-python", > py_modules=['broccoli'], > ext_modules = [ > Extension("_broccoli_intern", ["broccoli_intern_wrap.c"], > - include_dirs=["../../src"], > - library_dirs=["../../src/.libs"], > + include_dirs=["../../build/src"], > + library_dirs=["../../build/src"], > libraries=["broccoli"])] > ) -- This message was sent by Atlassian JIRA (v6.3-OD-07-013#6327)