or download a pre-built binary, see
the `README`. There's also some more information on possible ways to
integrate it with mutt through `mailcap` and a macro. This is all a bit
in-progress still too, so feel free to send suggestions or even patches.
Best,
Robin
--
Robin Sommer * ICSI * ro
OS 11.1, if that helps
Same here.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
On Fri, Jan 22, 2021 at 13:48 +, I wrote:
> so things must have reverted. But it's all still working fine
I take that back: the problem persists when linking against MacPorts'
libsasl2. Linking against the system's library lets SMTP work for me.
Robin
--
Robin Sommer * ICSI/LBNL *
means that it was libsasl2
version thing somehow that's been corrected by now.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
xactly happens.
>
> Johanna
>
> On 10 Dec 2020, at 18:06, Robin Sommer wrote:
>
> > It's interesting how different people have different intuitions on
> > semantics here. I also see it as consistent with function arguments,
> > that's why I'd be fine it. That said,
ng. (And maybe no warning if the body doesn’t use any of the outer
> variables, since that form will continue to work.)
>
> — Vern
> ___
> zeek-dev mailing list -- zeek-dev@lists.zeek.org
> To unsubscribe send an email to zeek-d
hen new macOS release come out (but not the Xcode image).
> https://github.com/zeek/zeek/pull/1268
Excellent. Look like we're all good with our new policy. Thanks for
driving this forward, Christian!
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelig
ther way:
https://github.com/cirruslabs/cirrus-ci-docs/issues/218
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list -- zeek-dev@lists.zeek.org
To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
in that page:
>
> https://github.com/zeek/zeek/wiki/Platform-Support-Policy
>
> Let me know your thoughts...
>
> Thanks,
> Christian
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing li
t behind it?
One more OS to add is macOS. While nobody knows the deadlines there,
we should record how far back we go in supporting previous versions,
and what package management we're assuming for dependencies (Homebrew
I suppose).
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.c
e'll need to do is define
the per distribution policies. You could add a 1st stab at that to the
calendar as well, or we can do it afterwards.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list --
lly catch up to new C++ features eventually (which is
> the main motivation), but we can also steadily modernize our CMake
> scaffold, Python scripts, and so on.
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
ze
chieves
all that already, but it has indeed been designed as an incremental
path forward rather than a lets-redo-it-from-scratch approach. Happy
to discuss if that's the right trade-off.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
Python API.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list -- zeek-dev@lists.zeek.org
To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
To summarize this a bit, below is what I think what I heard so far.
Feel free to respond further, I'll move this over into the ticket
later once we have consensus.
Robin
- General preference to keep packages in individual repositories
hosted inside a new GitHub organization "zeek-packages".
On Mon, Aug 24, 2020 at 14:15 -0700, Jon Siwek wrote:
> * What's the LTS policy for packages?
Good question. I think would tie it to the Zeek LTS policy, with a
"blessed" version of the meta-package that we recommend (and maintain)
for each currently maintained Zeek version.
Rob
uard against.
> It would be neat to have a place that contains the combined
> documentation of these scripts.
Agree, and I'd extend that to packages in general, you be a job for an
extended packages.zeek.org to provide autogen'ed documentation.
Robin
--
Robin Sommer * Corelight, Inc. *
an manage
dependencies already. So the "collection" I mentioned could be a
meta-package that depends on all the ones we want. We might need to
make that a bit more explicit for this use case (like you say for
example in the output of "list"), but the basic functionality is
there.
Robin
ple to install a set of default packages now that these won't come
with Zeek itself anymore. Some of the schemes above make that easier
than others.
Thoughts/opinions/more ideas?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
_
ult is.
>
> Anyone who has additional heuristics of goodness to add, also chime in with
> them. We'll probably, after consensus, enact change by sending some PRs to a
> few packages to unify them more. I did a sort of census last evening. Of 273
> tags used, I would bani
atured, thread-safe logging
framework is a trade-off against complexity and maintainance costs.
Not saying it's impossible, but I'd like to hear more people thinking
this is a good idea before committing to such a route.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelig
afterwards?)
And just to be clear why I'm making all these comments: I'm worried
about the difficulty of using this API, on both ends. The more complex
we make the things being passed around, the more difficult it gets to
implement the logic correctly and efficiently.
Robin
--
Robin Somm
more detail about write failures, including suggestions
> about
>possible ways to recover.
Similar question here: how would these "suggestions" look like?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
de executed before
> LockedDebugMsg.
>
> For what I was doing, though, that proved to be good enough. :-)
>
> I’d be very interested in ideas about how to improve that, especially if
> they’re simple. I can think of a way to improve it, but it would be
> substantially more c
or the log file we are just opening (if we did it at
open() time). But yeah, won't work when the cleanup happens already
before the new open.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Ze
the cluster
coordinator), but it's different from a world where the client can
execute higher-level operations on its own.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@z
case: If for some reason one wants to restart the
supervisor itself, "terminate" would kill it and the service
manager would then restart it.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
at one can incorporate that into the name of the
rotated file (assuming we want to retain that capability). Unless we
parsed that out of the X.log itself ...
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
s?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
and it'll we easier to collect
requirements for administration/management of multi-system setups once
we got some experience with single-system setups.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
"exec" will likely not be supported. We *could* support it, no
technical reason for not doing that over Broker. It just s seems like
another things that's better handled with different tools.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
Zeek repo.
Makes sense to me as well.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
bin
(I'll keep this on zeek-dev for now; will post more broadly as well
once the timeline stabilizes).
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek-Dev@zeek.org
http://mailman.icsi.berkeley.e
to see if it mentions
everything we should point us. I'm also planing to take that as the
starting point for a blog posting announcing 3.1.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
Zeek-Dev mailing list
Zeek
nly be
a plus. On the other hand, this might be a case of "if it's not
broken, don't fix it". pysubnettree hasn't required a lot of work
recently, and users would need to install a new dependency if we
switched.
I don't know what constraints LGPL imposes when applied to Python
modules.
Rob
ahead with your scheme for 3.0.0, that should work well.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
Could essentially consider any given commit in "master" to be a "test
> release" -- and if we decide to be more formal/vocal about providing
> builds of "master" (e.g. the OBS nightlies), then "alpha" may describe
> exactly what you thin
one else tinkered with this? - I would be happy to elaborate, and
> discuss with others.
>
> Jim
> ___
> zeek-dev mailing list
> zeek-dev@zeek.org
> http://mailman.icsi.berkeley.edu/mailman/l
the ticket to yourself. It's best
to start with a short proposal on what you plan to do. You can also
use the ticket discussion for any further clarification you might
need.
Thanks!
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
rg
> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
-layer analyzers from that would feel like a
gap to me. That said, we definitely need to benchmark performance to
make sure it's feasible. My hunch is that a lookup table should be
good enough, but we'll see.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelig
t need
> their own PIA to support the analysis of known protocols like HTTP
> etc.
Yeah, or a more generic PIA that provides its own hook for plugins.
The main difference between TCP/UDP PIAs is packet vs stream
semantics, iirc. That might generalize sufficiently, but not sure.
Ro
d both and can understand what's going on.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
event my_event(b: string)
Now I need to know if the language goes by order of parameters or by
parameter name.
I do see the appeal of making things just work when event handlers
change, but is there really no different way to support that?
(I don't have an opinion on the event overloading discussion yet
s form, because it *looks* like an error to not have matching
argument lists. Is there some syntax that would make it more clear
what's going on?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mail
it be worth aiming to do that update with the next 2.6.x patch
release? Would be nice to get the modern look for the release version,
too.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
zeek-dev mailing list
zee
CAF port? If it's recent, Bro should be able
to link against that.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
f an error happens at that
> time, I'd say it's fine to completely abort -- it's unlikely or hard
> to say whether Bro would operate well if it proceeded after an error
> that early in initialization.
Yeah, that makes sense.
Robin
--
Robin Sommer * Corelight, Inc.
, as it will impact custom log files that people
create in their own scripts.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
> _______
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ike the ones listed above.
Sounds good to me.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ink there's a way just redirect a git client, but maybe we could get
some error message into the output or something? Not sure.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
h
On Fri, Sep 14, 2018 at 11:36 -0500, Jonathan Siwek wrote:
> I did some label tweaking and reduced some prefix names: "Component"
> -> "Area" and "Difficulty" -> "Pain".
Ok, thanks, makes sense.
Robin
--
Robin Sommer * Corel
ght? Doing it all at the same time could
avoid confusion ("everything is on github now" is an easier
statement), but would also make the process more complex. Maybe the
real question here is if we want to switch repositories before or
after 2.6?
Robin
--
Robin Sommer * Corelight, Inc. *
= 0; i < num; ++i) {
+auto ev = broker::bro::Event(std::string("event_1"),
+ std::vector{42, "test"});
+out.push(std::make_pair(topic_str, std::move(ev)));
+ }
global_count += num;
},
[=](c
alization that's the bottle-neck, then we'll need to come up with
something else indeed.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
ntly be used if one writes a Bro
> script that publishes plain events (message type 1 in bro.hh)?
Yes to that. Non-Bros can exchange events (assuming they know the
schema), but not logs.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * ww
and still needs to be addressed. As part of upgrading that, I think it
can make sense to think about documenting the format we end up
chosing.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-de
ly, so that it's easier
to synchronize with an ongoing stream.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
e diverse so that self-description doesn't really seem
feasible/useful. Republishing a relevant subset certainly sounds
better for that; or, if it's really a bulk feed that's desired, some
out-of-band mechanism to convey the schema information somehow.
Robin
--
Robin Sommer * Corelight,
ght? Logs have a
different wire format and they actually come with meta data describing
their columns.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.ber
Quick reminder: Please keep in mind that mails to the Bro mailing
lists are archived publically. We had a couple of cases recently where
internal information went to a list, ending up in the archive, where
it's difficult to remove from. Thanks,
Robin
--
Robin Sommer * Corelight, Inc. * ro
t's in fact also
an argument against my original thinking how this could help unify
scripts --- well, unless we'd go with Jan's thought of subtopics
(e.g., subscribe("bro/cluster/worker/intel", local_raise=T).
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.c
ing "real" routing in Broker
> right from the start.
In an ideal world, yes, that would certainly be nice to have. But it's
a larger task that I don't think we would be able to finish for 2.6
anymore. So, I'd put that on the list for later.
Robin
--
Robin Sommer * Corelight, Inc.
manually
> handle+forward the event on proxies.
Ok, let's make that change then, I think removing relay() will help
for sure making the API easier.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
/cluster/worker if both go to all workers? Or is it so that some
workers can decide not to receive the intel events?
(And technically, subscriptions are prefixed based, so anybody
subscribing to bro/cluster/worker automatically gets
bro/cluster/worker/intel as well; not sure if that helps
cing in the case of there being more than one
> route to a subscriber.
Yeah, I'm becoming more and more convinced that in the end we won't
get around adding a "real" routing layer that takes of such things
under the hood.
Robin
--
Robin Sommer *
hat would also make later changes easier &
centralized to how topics and connections are set up.
For other use cases, it should still be possible to configure things
independently, too, though (say, for talking to external Broker
applications).
Robin
--
Robin Sommer *
tandalone to raise the event
> directly if not being ran in a cluster.
Or we generally raise published events locally as well if the node is
subscribed to the destination topic. There are pros and cons for that
I think.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.co
f time and so there's
> inconsistencies to be expected) ? Or due to being a mishmash of both
> old and new?
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.b
at doesn't make it nice. ;-) It
makes it very hard to follow the logic; when reading through the
scripts I got lost multiple times because some "@if I-am-a-manager"
was somewhere half a page earlier, disabling the code I was currently
looking at for most nodes. We probably can't totally avo
ch consistency right now in how scripts
structure their communication. That's not surprising, given that we're
just starting to use all this, but it suggests that we have room for
improvement in our abstractions. :)
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.co
use
cases.)
I have another question about this specific case: we use relay_rr()
only for sending Intel::insert_indicator. Intel::remove_indicator gets
published normally through auto_publish(). Why the difference?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.
relay(), and that's the one above.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
On Mon, Jul 30, 2018 at 13:30 -0500, Jonathan Siwek wrote:
> Seems clunky and could get dicey
Agreed. :) It'd just be a heuristic to catch some obvious errors. I
don't think there's more we can do, we can't really catch loops
statically by looking at the code.
Robin
--
Robin Som
ode send a message to all
subscribed topics, and watch for TTL violations?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
function around that
> if they find it too verbose and always want to use certain defaults?
They could, but my general point is that it'd be nice to have a simple
API that covers the most common uses cases directly and intuitively.
Then let people change defaults if they have to and know what they are
ther to raise events
received on a given topic locally, or just forward). I think I can see
that either way.
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
time plus another atomic<> counter
tracking if there are any pending message. And go into the locked case
only if the latter is non-zero?
> General changes/improvements in CAF itself may be warranted here
Yeah, sounds like it.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org *
ything.
I then ran it through oprofile. Output is attached. There's indeed
some locking showing up high in there, but I can't tell if that's just
expected idling in CAF. I am bit surprised to see a number of
std::chrono() methods showing rather prominently that I would expect
to be cheap.
Robin
--
gt; There's some mutex locking going on there, but w/o data stores
> involved there shouldn't be anyone competing for them.
>
> - Jon
>
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http:
's the trade-off between
performance and consistency. Where's the code that's doing this
blocking? Would it be possible to not block right away, but sync up
with Broker when events are flushed the next time? (Like we had
discussed before as a general mechanism for making async operations
consistent)
Robin
)
; Current master
# zcat 2009-M57-day11-18.trace.gz | time bro -r - tests/m57-long.bro
2191.59user 1606.69system 12:39.92elapsed 499%CPU (0avgtext+0avgdata
228400maxresident)
Bro must still be blocking somewhere when reading from trace files.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org
for folks. If things seem to
work, we should definitely also announce the merge more broadly.
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
d and
resolved. We'll see. :)
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
ndard scripts
(and if not, please let us know!)
Many thanks to Jon Siwek for the recent integration work tying up all
the loose ends and getting Broker mergeable. Also thanks to those who
have tested it already from the actor-system branch.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.i
A tickets into GitHub. What do others think?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
we'd want a PR to be created
> against each individual repo?
Good point. Creating just one root PR that mentions the others sounds
good to me for such cases.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
d ones), they will just come
with a little bit of a delay (within 10-15 minutes should be
reasonable). And if we want we can trigger that through webbhooks,
too, for immediate notification, would just need a bit of work to get
it set up.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
n way would be instead creating one event per
type of payload and then raising the corresponding event as you parse
packets and find out what's in there.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing lis
e kind of our version of methods). Same for Ruby. I
looked around for a few more minutes for other languages, but didn't
immediately find any that even have any set operators at all (only
methods/functions for union/intersection/etc.).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.i
t, but at least it's explicit and we couldn't
come up with anything better if we want to have such operations as
operators. Might work for some other types as well.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-d
d IMO, unless it does actually prevent us from building
binary packages for RH, that would be a problem.
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
ghts on the best way to proceed.
> >>
> >
> > Maybe delete the branch from the official git repo and push it to your own
> > github fork.
> >
> > - Jon
> >
> _______
> bro-dev mailing list
t a feasible compromise to allow cmake 2.8 if we don't need to
build CAF? So either people have cmake 3.0 or they need to build CAF
themselves and say --with-caf=...?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mail
ot; doesn't sound great to me :-). Is it just me feeling
that way?
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
efined
This one I'm unsure about. The point about the order being undefined
seems odd. If I don't care about order, wouldn't I stay with a set?
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
).
This has interesting implication for BIT-1431: if overloading worked
work, that could take the place of the attribute suggested
there.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing l
ts to insert the key
> with a sane default value (e.g. zero/empty) in those cases, otherwise,
> it's awkward/race-prone to require they do it themselves.
Agree with this as well, has always felt a bit awkward to me too.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
ich initialization that refers too,
may not be feasible.
Are there other differences with stores between online and offline
operation?
Robin
--
Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com
___
bro-dev mailing list
bro-dev@b
1 - 100 of 1082 matches
Mail list logo
