e if there's a middle-ground
that would give us the best of both worlds: easy of installation for
Bro users, while remaining flexible for external Broker/CAF usages.
But agree that this needs more thought before moving ahead with
anything. Thanks for bringing that up, Dominik.
Robin
--
Robin Sommer
uld be a problem
for some use cases, we might need to add way to recognizes duplicates.
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
s; #=originator;
superlinear/policy//worm.bro:=0 _expire = 2
days _func=expi; # =originator;
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
On Tue, Feb 13, 2018 at 11:02 -0600, you wrote:
> On Tue, Feb 13, 2018 at 9:44 AM, Robin Sommer <ro...@icir.org>
think consumer-side is important? We already can not prevent a peer
from sending too much data during normal operation either.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.or
ill needs some thinking. I'm
getting the sense though that we'll need it for some applications,
osquery being the main one on my mind.
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
% sure if that's straight-forward to do, but I
hope so ...
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 integrate that. For outgoing
messages, we could add it to the transparent reconnect. However, for
incoming connections, where the local endpoint doesn't have a notion
of "that peer should be coming back", it might not be as straight
forward?
Robin
--
Robin Sommer * ICSI/LBNL * ro..
perspective all they deal
with is Broker: if they link against it, they get everything they
need.
Would that make sense?
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http
t more
brainstorming and then implementation, obviously), or if we want to
get async in in the current state and then put that on the TODO list?
I can see arguments either way, curious what others think.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
based subsets were the main use case
anways. Actually I'm not even sure anymore if there might have been a
custom execute-my-own-function scope as well, I'll see if I can find
the old code somewhere.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
ff in flight.
On the other hand, I don't think this can be avoided though: either we
want dependencies or we don't. You can't have the cake and it eat it
too I guess. :)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mail
ope" is the scheduling
granularity, e.g., "by connection". "context" is the current
instantiation of that scope (e.g., "1.2.3.4:1234,2.3.4.5:80" for
connection scope).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
tion suspends, halt all handlers that
depend on the same context (e.g., same connection). More on that idea
in this paper: http://www.icir.org/robin/papers/ccs14-concurrency.pdf
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
a big deal for anything,
as the cases where the new behaviour may actually lead to significant
differences should be rare.
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
could use that infrastructure
for a yield keyword.
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
where we want to get to).
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
ss IdentifierUpdate : public Message {
> public:
>IdentifierUpdate(std::string id_name, data id_value)
> -: Message(Message::Type::IdentifierUpdate, {id_name, id_value}) {
> +: Message(Message::Type::IdentifierUpdate, {std::move(id_name),
> +
On Fri, Dec 01, 2017 at 15:22 +, you wrote:
> Now I'm glad I never got it to work right :-)
Me too. :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
h
d it also won't work for atomic values, at least not since
https://github.com/bro/bro/commit/5b889360705120c9061390214881ea376819c669
went in. :)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro
>
> - 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
On Mon, Nov 06, 2017 at 09:16 -0500, you wrote:
> versions of awk and they all support scientific notation
I'm wondering if that's true for other log parsers as well. The main
thing I'd want to avoid is breaking people's existing scripts. We
could make it an option?
Robin
--
Robin Som
broker
> endpoints originally being able to self-identify with the friendly
> names, so these new hello/bye events wouldn’t have been needed, but it
> didn’t seem like that functionality was around anymore.
I actually don't remember. If we had it, not sure what happened to it.
Robin
--
This is coming together quite nicely. Not sure if it's stable yet, but
I'll just go ahead with some feedback I noticed looking over the new
cluster API:
- One thing I can't quite tell is if this is still aiming to
maintain compatibility with the old communication system, like
by
et the redef approach. I was more
thinking about consistency with other script APIs. We use redef for
simple tuning (single-value options, timeouts, etc), but less these
days for more complex setups (see logging and input frameworks). I'd
be interested to hear what other people prefer.
Robin
--
efault_store_dir = "/home/jon/stores";
Can the default_store_dir be set to some standard location through
BroControl? Would be neat if this all just worked in the standard case
without any custom configuration at all.
> BroControl Example Usage
>
I'
For those tracking the new Broker version in the topic/actor-system
branch: A new CAF release 0.15.4 is out now that's incorporating
everything that code requires, so no need to use the CAF "develop"
branch anymore.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir
warranted over re-using
> ‘const’ for configuration values as the semantics are now blatantly different
> than what ‘const’ is expected to mean. i.e. config values are meant to
> change at run-time, but only via a restricted API and ‘const’ is still
> intended to never change at run-tim
nd we'd have Broxygen pick up on it too.
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
oesn't, I don't know, that's part of why I keep looking for feedback.
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;async" works? (If you
can honestly answer "yes" in under 15 minutes, I buy you a beer. ;-)
Robin
PS: See the TODOs in that commit for the current state of the code.)
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
e. The downside for you might be a bit of wasted time
if discussion afterwards leads to a different approach. So feel free
to also ask for feedback upfront, whatever seems best. Either way,
getting it to work by applying the most straightforward approach is
definitely the right rule of thumb.
Robin
-
can even reuse that implementation later by making it more
generic.
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
use for any given one.
> That's not possible because there's infinite ways you can create
> composite types (tables, sets, vectors, etc).
--
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 Sat, May 13, 2017 at 00:28 -0500, you wrote:
> We'll look at upgrading our test cluster (and UIUC's test cluster) to
> master.
Sounds good, let us know how that is going.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
Using
## the same value here will make the hashes compatible between independent
Bro
q## instances. If left unset, Bro will use a temporary local seed.
const global_hash_seed: string = ""
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * ww
s or if I am
> doing something not quite right.
Bloom filters should work over communication. What's the code for the
two sides? The error messages sound like these are filters of
different types.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www
don’t
> require/support poll-ability should also be possible to integrate.
I need to think about that argument ... Did you try reading from files
while also doing communication (that would be pseudo-realtime mode),
or was the pcap the only source of input?
Robin
--
Robin Sommer * ICSI/LBNL * ro
en before we'd
consider moving to a CAF-based loop?
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
and FreeBSD for, say, the two most
recent major releases of each and also consider common alternative
capturing solutions (pfring, netmap, afnet?), I'd be pretty
comfortable switching.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
mption is that dynamic plugins are compiled
separately. It would indeed be nice to have the Bro CMake
configuration pick up further dynamic plugins to compile along.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
b
ce).
Yeah, that makes sense. We can switch back once we have something
better.
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
ither way, a better
Bro-side UI for Broker is coming, we just need to get the various
pieces in place first that people are working on currently before we
can move forward.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-d
-plugins-2.3
topic/robin/pktsrc
topic/robin/plugin-updates
topic/robin/reader-writer-plugins
topic/vladg/homebrew-openssl
%% bro/master/src/3rdparty
topic/jsiwek/file-signatures
topic/jsiwek/libmagic-integration
topic/jsiwek/new-libmagic
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.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/mailman/listinfo/bro-dev
could add some automatic way instead, like calling the
files __bare__.bro and have Bro find them automatically (but to
Johanna's point, not sure if that would cause load-order problems).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
g some code needing to be
thread-safe, while other parts break every rule in the book in that
regard, is also confusing; we have that challenge already with the
logging and input frameworks.))
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org
of platforms and OS versions. Whatever
we do, it'll be important to do quite a bit of test-driving and
benchmarking. Let's try to structure the work so that we can get
to a prototype quickly that allows for some initial performance
validation of the approach taken.
Robin
--
Robin
s best I think. Onw
the receiving side, the entries don't "really" enter the flu logging
framework, they just take a fast path directly into the writers. One
thing I'm doing is renaming methods to make that bit clearer; the two
Write() methods are clearly misleading.
Robin
--
Robin Sommer
there. If we need more, we can add that later. The
less semantic differences we have between old and new communication,
the easier the switch will be.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing lis
l look into 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
ding on use case. In
any case, it's a change in semantics compacted to the old
communication system, and I'm not sure we want that.
I'm wondering if there's a reason that in the Broker case things
*have* to be this way. Is there something that prevents the Broker
manager from doing the same as the Remote
On Wed, Jan 25, 2017 at 02:23 +, you wrote:
> * package unit testing [1]
> * package dependencies [2]
Great job, Jon!
One of the next steps now is moving our bro-plugins into packages,
I'll talk to the maintainers to get that started.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@ic
On Wed, Jan 25, 2017 at 05:07 -0600, jenk...@brotestbed.ncsa.illinois.edu wrote:
> tests.progress ... failed
This new test is failing on some Jenkins nodes, but I cannot reproduce
it locally (tried on Linux and Mac). Is anybody else seeing this?
Robin
--
Robin Sommer * ICSI/LBNL *
re a first line
of defense against making sure nothing fundamentally broken. Said
differently, the tests generally cannot answer the question "will this
bro-pkg operation break my setup"; what they answer is "is this
package ok?".
Robin
--
Robin Sommer * ICSI/LBNL *
le to get the name of the
thread through 'this->reader->name' (haven't tried that, just took a
quick look at the code).
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.ic
RO to stop packets processing ?
It shouldn't deadlock. What I can see happening, depending on load and
these parameters, is Bro spending most of its time going through the
table to expire entries and only getting to few packets in between (so
not complete stop of processing, but not getting much done either)
>
> _______
> 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
it belongs to, as it depends
on how thing got queued and processed internally. That can make it
hard to react to something more specifically. But that's something we
can't avoid with the asynchronous processing.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
but it would still be good to have some
default classification for cases that one doesn't handle directly (and
if it's only for then logging as error/warning/info). One could then
also compare the level directly with the status object: "if ( status
== ERROR ) ..."
Robin
--
Robin S
On Mon, Jan 09, 2017 at 11:34 -0800, you wrote:
> To distinguish between the two status, I use operator bool.
I don't see that in the "status and error handling" section. Would I
do "if (! status) { }"? That doesn't seem quite
intuitive. I think a method with a descriptive name would be
y through but at least 2.3 isn't complaining about the
extensionss (it just needs the expected shift/reduce conflicts
adapted).
So not sure what the right solution is but for now: either upgrade
bison, or remove the line and keep an eye on if things work correctly.
Robin
--
Robin Sommer * ICSI/
dl;
> if (*e == error::type_clash)
> // dispatch concrete error
> } else if (auto s = msg.status()) {
> cout << "status: " << to_string(*s) << endl;
> if (*s == status::peer_added)
> // dispatch concrete status
> } else {
sg = ep.receive();
if (msg)
return f(*msg); // unbox contained message
if (msg.failed())
cout << "Trouble: " << to_string(msg.status()) << endl;
else
cout << "Status change: " << to_string(msg.status()) << endl;
I
not
rocket science, it just needs somebody to take it on as a separate
project I 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
or now and switch over to
tuples later if/when we get them ...
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
s most recent state.
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
ted a first implementation of the type-based switch that uses
this syntax instead:
case type string:
case type count as c:
What do you think of that? The additional "type" makes it visually
clear what's it's about, and also helps the parser figure it
6 -0800, I wrote:
> if ( status(v) == Broker::SUCCESS )
Thinking more about this, I kind of like this version actually, and
have for now included that into the proposal. Curious to hear what
others think about this. It would be an easy solution actually.
Robin
--
Robin Sommer * I
ownside is that "result", and "value" would need to
be declared first, making it less concise.
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 question what namespace to use.
"Broker::Success" would certainly be nicer.
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
ever
even remember how exactly it works. So not sure if that's a good thing
to rely on here? On the other hand, given that it's there and can
solve the problem, we might as well use it ... I'm torn. :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.
define internally
what they convert to, and how.
Seth, a question: do you have more in mind by "nicely generalized
error handling" than this? Do you see a way to generalize this to
purely script-level logic (i.e., no opaques, just normal Bro types
being passed around)?
Robin
--
Robin Somm
ate to the
error flag. If you wanted to get the actual value out of it, you'd
cast it accordingly with the new cast operator; and that includes
casting to "bool".
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
br
can
differentiate what happened. I need to think about it, but that could
eliminate the need for simply aborting the event handler on timeout
(which in turn would help with the problem that Bro isn't good at
aborting code)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
_
link in the ticket, it's now at
https://www.bro.org/development/projects/violation-confirmation.html
Given the long time that has passed, I'm sure this would need another
round of discussion to see if it still sounds like the right thing to
do.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@
766
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
icket once fixed in master to avoid confusion.)
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 Mon, Dec 05, 2016 at 00:50 +0100, you wrote:
> That was just another example for a situation in which "hidden"
> asynchronous execution could easily lead to unintended behavior.
Ah, got it, I had misread what you meant. Thanks,
Robin
--
Robin Sommer * ICSI/LBNL
The first thing I thought of was the get_current_packet() or the
> get_current_packet_header() function.
Can you elaborate? These functions aren't asynchronous currently.
Would you change them to being so; and if so, what would that do?
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
f operations would be nice, but that's a
> separate issue :-)
Good thought, those three lookups above could all proceed in parallel,
and then one would wait for them all to finish before continuing.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org
://www.bro.org/development/projects/broker-lang-ext.html
Feedback welcome, this is just a first draft.
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
Thanks, that and the new text help, I think I got it now. That all
makes sense. Maybe add to the text that tags are not pushed by default
by git, so one shouldn't forget "git push --tags".
Robin
On Mon, Nov 21, 2016 at 18:24 +, you wrote:
>
> > On Nov 21, 2016, at 10:
all sources then add an optional
> "—source ” flag for those that just want to operate on a
> single one.
Makes sense.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
http://mai
most recent version (i.e., the commit that that
version tag refers to). That way people could control a bit better
when meta data gets updated (it's when they set a new version). It
would still fallback to master if no version tag is set.
Robin
--
Robin Sommer * ICSI/LBNL
commit/b28801ce9508250594a8e3c6483f3176483d790c
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 Sat, Oct 29, 2016 at 11:28 -0700, I wrote:
> (if a source operator can do hooks that will avoid any delays at all).
Ah, that's not true of course, it only applies to initial setup of a
package.
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/ro
bmodules, 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 par
ng 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
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 mailing list
b
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
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
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.
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.icir.org
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
--
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 and installing them
> (e.g., imposing custom restrictions on w
ls on 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
void 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.icsi.berkeley
**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
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/LBNL * ro...@icir.
101 - 200 of 1082 matches
Mail list logo
