ules, how are deleted/unavailable packages
> > detected/removed?
>
> At the moment, they’d have to be removed manually whenever someone notices or
> reports it.
>
> If we switch to automated metadata aggregation, removal of nonexistent
> packages could naturally be a part of that.
>
> - Jon
>
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
I'm not quite sure about the reasons for the
current structure, I'm mostly thinking from the perspective of
information about the package I'd like to have access to easily, and
where it's coming from.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
end up using the package manager, but for now
I don't see a need change anything. I doubt that the current model is
what would prevent people from creating packages.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev
nd of
testing anyways with the SMB updates, so the TLS code will see some
more exercising (for regressions at least) then as well. Unless I hear
objections, I'll go ahead and merge.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
(given that core tests seem to be failing, which shouldn't have a
Python dependency otherwise?)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
rsmmr added a comment.
Well, last time I counted it was more like 100 contributors---Bro existed
before GitHub (and before git). The style-guide is lacking, yes ... what can I
say.
I don't really want to argue about importance of the project. We would like to
use clang-format here and elsewher
rsmmr added a comment.
Sure, I'm aiming to use clang-format on a couple of open-source code bases
using this style, with the main one being the Bro network security monitor, see
www.bro.org and github.com/bro/bro (note the stars and forks :-) Bro is also
featured on GitHub's list of security sh
rsmmr added a comment.
Cool, thanks Steve. What's the next step for me to get it committed?
https://reviews.llvm.org/D25171
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
rsmmr created this revision.
rsmmr added reviewers: djasper, lodato.
rsmmr added a subscriber: cfe-commits.
Herald added a subscriber: klimek.
This patch adds two new options, feedback welcome.
SpacesAroundConditions (bool)
If true, spaces will be inserted around if/for/while conditions.
Spac
On Thu, Sep 29, 2016 at 20:49 +, you wrote:
> ‘bundle’ and ‘unbundle’ commands are now available in bro-pkg 0.7 and
> should work as described earlier in the thread.
Great, many thanks! I'll give it a try soon.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.ici
On Fri, Sep 23, 2016 at 07:47 +0200, Heinz Diehl wrote:
> > It adds a new option 'mark_read' that marks all messages as read when
> > exiting a mailbox.
>
> As long as this is configurable and not the default behaviour, it
> should be ok.
Yep, it's off
ach
> individual package if it’s ok to overwrite it?
Just a single "yes" sounds good to me, I would see it more as
double-check to confirm the bundle is right. If it's not, one can (and
should I argue) always rebuild the bundle with different packages.
Robin
ed operations to
> inspect & retrieve the content of a bundle, such as iterating over
> the packages inside a bundle and iterating over the files inside a
> package. That way one could easily build target-side scripts that
> process and validate bundles before going ahead an
urrently for that use-case, I’d say “just don’t run autoconfig, the
> default paths are sufficient”.
What are the default paths? In other words, where do the downloaded
packages get put if I don't set anything further up?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org
n?
I was thinking that it needs bro-config. Is that only for "autoconfig"
to set up the right paths? If so, then maybe we can add an option to
"autoconfig" to setup (and create) local paths for this
working-without-a-Bro mode?
Robin
--
server"
setting), but that sounds like an orthogonal feature (and more complex
to add to the package manager).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
tory, to avoid configuration
mistakes; or even just logging what gets pushed out).
What do you guys think about this?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.ics
combination of macros but that gets cumbersome
when enabling it selectively only for a subset of folders, so I
finally turned it into an option.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
diff -ur mutt-1.7.0/PATCHES mutt-1.7.0-patched/PATCHES
--- mutt-1.7.0/PATCHES 2016
**SpacesAroundConditions** (``bool``)
If ``true``, spaces will be inserted around if/for/while conditions.
**SpacesAfterNot** (``bool``)
If ``true``, spaces will be inserted after ``!``.
---
docs/ClangFormatStyleOptions.rst | 6 ++
include/clang/Format/Format.h| 8
lib/Form
On Thu, Sep 15, 2016 at 19:25 -0500, you wrote:
> Bropkg is easier to type indeed. And then let's change the brocut.
No strong preference either way on my end, but let's not touch bro-cut
please, that's used in too many scripts.
Robin
--
Robin Sommer * ICSI/LBN
On Thu, Sep 15, 2016 at 12:56 -0400, you wrote:
> Is it just me or are recursive clones of the GitHub repo failing when
> trying to clone aux/binpac?
Just tried and it worked fine for me. If you still see the problem,
what's the error you're getting?
Robin
--
Robin Sommer
until we're ready to announce it. A blog posting would be
good once we believe we have the process down. Before we do that,
maybe we can get a couple people here on this list to give publishing
some of their scripts a try? If that goes well, we start over once
more and announce.
Robin
--
Ro
ocs are
actually the right place for that then, should that go into the
community section on bro.org?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mail
there were `bro —config site_dir` and `bro —config plugin_dir`
Good thought, though why not keep it out of Bro: we can add a script
"bro-config" to Bro that cmake populates with the right data. That
would actually be helpful for other stuff as well. That's something we
Thanks, integrated!
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
e busy at the moment it will take some more time.
>
> Best regards,
> Jan
> _______
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
--
Robin Sommer * ICSI/LBNL * ro...@i
in.bro,
line 49: Can't document redef of DPD::ignore_violations, identifier lookup
failed
===
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
nges.
Any takers for these?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
to Broker that clearly
says what's is needed if it cannot find the right CAF version? People
have run into this a few times now both ways (Broker wants newer/older
CAF version). That seems something worth adding for 2.5 still.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org *
ovided
more than one specific piece of functionality.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
make that clear.
> Tried to do this in the Overview/README’s “Installation” section. I
> think reorganizing that in smaller sections with bullet points to
> follow and re-labeling it as “quick-start guide” may help.
Ack.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.o
ld
merge soon; if not, postpone until that's out the door. Given how far
you are already, I vote for making it part of 2.5. We could declare it
experimental still for 2.5 to get some more time to iron out the
workflow before we tell people it's ok to start relying on it.
Again, all very nice work!
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
mbiguous and tell the
> user to clarify between either “bob/bro-test-package” or
> “jsiwek/bro-test-package”.
Ah, I see. Would it be better to generally use the full path as the
name, and not search for submatches, to make it consistent/unambiguous
what a name refers to?
Robin
--
Robin
csi.berkeley.edu/mailman/listinfo/bro-dev
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Fri, Jul 08, 2016 at 16:59 -0700, you wrote:
> Something similar to __load__.bro model
@DIR gives you the path to the directory the current script is located
in. Does that help?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/ro
On Tue, Jun 28, 2016 at 12:27 -0700, you wrote:
> Personally, I think use exactly-once delivery semantics
> would be most intuitive.
Yeah, seems most intuitive to me too.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
ook at that for a bit to see if
I can remember my reasoning from many years ago (which might very well
have been flawed!). Please file a ticket with your thoughts and assign
it to me. Thanks,
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
__
lem, we should still take a look, but more
generally: yeah Broker will take that over as soon as things are in
sufficient shape.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-de
I was thinking about that too. I'd still be curious if the
overhead of re-evaluating the constant overhead becomes noticable. If
you're game, you could try a little benchmark just manipulating a
table plenty times and measure if that changes execution time much.
Robin
--
Robin Somme
evaluated every time. My
main concern there would be performance, although I'm not sure if that
would actually cause much overhead in the still most common case of a
constant (i.e., for existing scripts).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
__
Sounds good.
On Wed, Jun 08, 2016 at 19:13 +, you wrote:
> git repo name: bro-pkg
Do we maybe need need two repositories, one for the client and for the
packages?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
On Tue, Jun 07, 2016 at 10:45 -0400, you wrote:
> Is there some reason why "new Val(%s, TYPE_BOOL)" is correct for the
> TYPE_INT constructor here?
Sure looks like a typo, I just fixed it in master. Thanks!
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * ww
expliclty).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Tue, Jun 07, 2016 at 04:52 +, you wrote:
> Only difference is I don’t think the client needs the plural.
Yep, I meant bro-pkg, the plural was just a typo.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-
bout how/whether
> to change that.
Ok, then let's rename "package" in the current docs. I propose
"module" as the replacement: it's not quite right regarding the
language's module concept but close enough I would say.
> naming the project/client/containe
ks for me as well, as
I think "container" does (though Matthias has a point there about
meanings uses of "container"). I just don't like "plugin". :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
n's installation directory. (And
we'd need to add mechanism to Bro to actually do that.)
> Or are we still planning to default to /lib/bro/plugins/ ?
That default location will stay, we just add the new ones to the
internal search path as well.
Robin
--
Robin Sommer * ICSI/LBNL
make test
/configure
/src/*
/tests/*
(The skeleton that init-plugin creates works for this directly
already, except for the meta information.)
5. A binary plugin with different build command and location:
/META
name=foo
version=1
a plugin for
> the Bro application.
Yeah, but Bro *is* the language as well. Anyways, I don't think we'll
agree on this, but that's ok. :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
pts or
> a combination of both”.
Sure, but it's still confusing to tell people you need to write a
plugin to add your new vulnerability detector; whereas so far they
simply wrote a script. Look at the mailing list for how people have
used the term "plugin" so far: I'm pretty sur
s"
My second choice would be using "bundle" instead of "package", and
then I guess "bro-bundle" "Bro Bundle Manager". We're introducing
something new here, so it would make sense to use a new term, "bundle".
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ck immediately. We could have a shopping
> "cart" as well, to represent a collection of bags. The grocery store
> theme works really well, in my opinion.
>
> Matthias
> ___
> bro-dev mailing list
> bro-dev@bro.org
> htt
CBAN;
it will point to 1.0. Then Seth updates to 1.1 on his end. CBAN would
still point to 1.0, but clients would just move their local clones to
1.1, ignoring the parent repository's state. Is that what you have in
mind?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robi
log writer, packet source) etc. and
that's also how the documentation uses that term currently.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
mespace reserved.
> "extension" comes to mind, or maybe "bundle."
I like "bundle".
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
g. Would be good to keep this all open and
transparent.
- I'm offended that my plugin is just "nice", but Seth's is *cool*!
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
gs like this. If one
could express such analyses easily with a few lines of script code,
that would be quite powerful for doing script inspection that's also
easy to customize.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
versal machinery. That infrastructure is used in a few places now,
and I'm not planing on touching that. Just removing this specific use
of finding NOTICEs, which doesn't seem anybody has been using in a
long time.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@ici
intain this information outside of git in a
state file that clients download? Otherwise the repository will
clutter up quite a bit over time with tons of automatic commits.
Overall, I agree that we can always add more restrictions later if it
turns out necessary. It's not that we'll hav
that's good information we can
provide to users about the state of something. And that state could be
"totally broken". :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
to
> experience in the first place.
Yeah, that's exactly what I'm advocating: making it easy should really
be priority number one, with everything else coming second. If you see
ways to adapt the design to target that specifically, I'm all for it.
Robin
--
Rob
Found NOTICE: Signatures::Multiple_Signatures
This looks very specific for hard-coded event-engine functionality. I
propose to remove unless somebody still sees a use for this?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro
I went through the pending Converity alerts, fixed a few with my
commits this morning, and marked the others as minor. I didn't see
anything severe in there, most were expected.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/
d
more languages later. Is that worth the benefit of switching?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
nd quality
> control we can provide.
Yes, indeed, I like this. With things already merged in, we can in
parallel, in the background, build up a toolbox of things to check for
and mark a module accordingly.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
block it if something fails, just mark it (say,
with a banner saying "tests pass", "tests fail", "no tests").
Thoughts?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
Assign further tickets to 2.5 that should go in but aren't
marked so yet.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
espace) and
> also reduce ambiguity (we can now use bro::broker as a class name).
I don't think the first one is a problem, and the latter is a
self-made one: I think the better solution would be finding a
different name for those things now called "broker", rather than
until we call a feature freeze. I'll let Seth comment on
content but generally merging your changes in for 2.5 certainly sounds
good to me.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
easible, doing just
the standard DPD confirmation for a protocol should usually be pretty
straight-forward.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/m
to address, now would be a good time to point them out.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ot the type working from a plugin. Would be even
nicer if Bro actually showed the new type in the output of "-NN" but
we don't have the support in place yet for a plugin to register it
accordingly.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
diff --git a
on of development
topics; no more automated postings here.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
whose uniqueness cannot be guaranteed for a plugin,
> right?
Yeah, good point, there's no mechanism for that.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
rks/files/entropy-test-all-files.bro
@@ -11,10 +11,10 @@ export {
event file_new(f: fa_file)
{
- Files::add_analyzer(f, Files::ANALYZER_ENTROPY);
+ # Files::add_analyzer(f, Files::ANALYZER_ENTROPY);
}
--
Robin Sommer * ICSI/LBNL *
[
https://bro-tracker.atlassian.net/browse/BIT-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1572:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Please merge to
[
https://bro-tracker.atlassian.net/browse/BIT-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1574:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Please merge to
[
https://bro-tracker.atlassian.net/browse/BIT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1449:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Wrap Broker Bifs i
On Thu, Apr 28, 2016 at 20:18 +0200, you wrote:
> Is it possible to create a new opaque type for Bro using a dynamic
> plugin without touching Bro sources?
Yes, it should. I believe if you implement the logic in your plugin's
InitPreScript() method, it should work.
Robin
--
R
[
https://bro-tracker.atlassian.net/browse/BIT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26003#comment-26003
]
Robin Sommer commented on BIT-1449:
---
Nice, thanks!
> Wrap Broker Bifs into scrip
[
https://bro-tracker.atlassian.net/browse/BIT-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1449:
-
Assignee: Robin Sommer
> Wrap Broker Bifs into script-level functi
[
https://bro-tracker.atlassian.net/browse/BIT-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1574:
-
Assignee: Robin Sommer
> Please merge topic/johanna/imap-start
[
https://bro-tracker.atlassian.net/browse/BIT-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1567:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Please merge to
[
https://bro-tracker.atlassian.net/browse/BIT-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1567:
-
Assignee: Robin Sommer
> Please merge topic/johanna/intel-cert-h
On Wed, Apr 20, 2016 at 10:21 -0400, you wrote:
> Did you ever happen to figure out what was going on with this?
No, but I also didn't look further. Could it be the new file
identifications (i.e., the regexps)?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.o
ailed (+39.8%)
[ 85%] tests.m57-long ... failed (+9.8%)
The short tests are prone to fluctuate in timing, but the increases
for ipv6 and m57-long are sticking out. Any ideas what could be
causing this?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/
Huh, what's up with that all that Jenkins output?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[
https://bro-tracker.atlassian.net/browse/BIT-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1557:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> broccoli code examp
[
https://bro-tracker.atlassian.net/browse/BIT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1528:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> SNMP and SIP sc
at are currently using Broker. I think it's still ok to do
such breaking changes for Broker now, but before going ahead and
merge, I wanted to ask if anybody believes that's not a good idea?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * ww
[
https://bro-tracker.atlassian.net/browse/BIT-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1528:
-
Assignee: Robin Sommer
> SNMP and SIP scans show up in known servi
[
https://bro-tracker.atlassian.net/browse/BIT-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1557:
-
Assignee: Robin Sommer
> broccoli code examples don't
1w, 1m)? Then you
could work with a set of tables with corresponding expiration
intervals.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[
https://bro-tracker.atlassian.net/browse/BIT-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1553:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> Please merge to
[
https://bro-tracker.atlassian.net/browse/BIT-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer updated BIT-1533:
--
Resolution: Merged (was: Fixed)
Status: Closed (was: Merge Request)
> mysql analyzer d
e as possible
(I realize that the integration already has quite a bit in there ...)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
[
https://bro-tracker.atlassian.net/browse/BIT-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1533:
-
Assignee: Robin Sommer
> mysql analyzer does not set service to my
[
https://bro-tracker.atlassian.net/browse/BIT-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robin Sommer reassigned BIT-1553:
-
Assignee: Robin Sommer
> Please merge topic/johanna/filter_subnet_ta
On Mon, Mar 21, 2016 at 10:36 -0700, you wrote:
> That's fine in my thinking, because anyone developing and compiling a
> Broker application must have CAF installed anyway.
Yeah, I agree, sounds like the right strategy at this point.
Robin
--
Robin Sommer * ICSI/LBNL * ro.
-format
> [3] http://reviews.llvm.org/D6833
> [4] https://github.com/agis-/git-style-guide#messages
> ___
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
--
Robin Sommer * ICSI/L
201 - 300 of 1475 matches
Mail list logo
