[Bro-Dev] attributes & named types
jsiwek at corelight.com
Wed Nov 7 08:23:29 PST 2018
On Tue, Nov 6, 2018 at 3:00 PM Vern Paxson <vern at corelight.com> wrote:
> I think what we need to do is rethink the basic architecture/structure of
> attributes. In particular, types in general (not just named types) should
> be able to have attributes associated with them. The attributes associated
> with an identifier are those associated with its type plus those directly
> associated with the identifier (like &redef).
Sounds worth pursuing. I think this was also one of the routes
originally offered, but not sure if it actually got attempted or there
were other complications. Hard to remember all the twists this issue
has taken, but you probably have the freshest view of things at the
moment to decide which way to try going.
> While doing this, we can also think about mechanisms for removing attributes.
> I don't think the "&attr=F" approach mentioned earlier on this thread will do
> the trick, since it's syntactically/semantically quite weird for attributes
> that already take expressions as values, such as &default or &read_expire.
Yeah, attr removal seems to warrant its own unique syntax. But might
help to just review which attrs one may actually want to remove (or
even make sense to remove) -- seems like it's only &log in the first
place so maybe doesn't warrant a generalized mechanism ?
A related idea I haven't thought through: how about providing a BIF
that does attr removal/modification? Actually seems more powerful to
be able to change attributes at runtime rather than just parse-time.
Another thought/worry that may or may not be valid for generalized
attr remove/modification: seems there may be opportunity to create
non-sensical states. e.g. the sequence of (1) create a value of the
type "foo" which initially has attr &bar, (2) later remove &bar from
type foo, (3) are the existing values of type foo still coherent now
that they lack &bar ? Obviously made up the type/attr, but probably
have to think that sequence through for each existing attribute to
make sure behavior is well-defined for each.
More information about the bro-dev