Re: [Zeek-Dev] support for event handlers using a subset of parameters

[Jon Siwek]

On Wed, Feb 6, 2019 at 1:30 PM Vlad Grigorescu  wrote:

> I _think_ I like Seth's idea of records, but I'm still thinking it through. 
> It would formalize a growing trend towards moving more parameters into 
> records anyway. If we're worried about backwards compatibility, then maybe we 
> have a built in version number in each record. Whenever fields are 
> added/removed, or there are more subtle contextual changes, the version 
> number could increase.

Explicit versioning is a neat idea to maybe try expanding on.  I'm not
quite sure how it would look for the user to, when they write their
code, make it explicit that they expect the semantics of the record to
match version XYZ.  But yeah, on our end, we could ensure that if we
see someone wanted XYZ, we send them that version of the record, which
matches their semantic expectations.

> As a concrete example, the is_server parameter of the ssh_capabilities event 
> was being set backwards (effectively as "is_client.")

In this particular example, the way I would have wanted to solve it
with my proposed patch would be: deprecate "is_server", document it as
actually meaning "is client" (don't change semantics of that parameter
to avoid breaking user code that is already doing the inversion), but
do introduce a new "is_client" which actually means "is client", then
later remove "is_server".

- Jon

___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev

Re: [Zeek-Dev] support for event handlers using a subset of parameters

[Jon Siwek]

On Wed, Feb 6, 2019 at 10:51 AM Seth Hall  wrote:

> One thing I've been thinking about a little bit is how much we're
> concerning ourselves with maintaining perfect backward compatibility and
> if there is some benefit to breaking a bit of backward compatibility for
> something truly nicer?

Sure, I wouldn't argue against taking that approach if there's a good
suggestion.

>  Like, should we have some specialized syntax for
> specifying named parameter use?  Should we have something like anonymous
> records where you specify a variant of record syntax for named
> parameters?

I think a user would prefer to always do whatever is most robust and
won't break in the face of upstream changes.  If I'm going to use the
alternative syntax everywhere because it's better, why have an
alternative in the first place.

- Jon
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev

Re: [Zeek-Dev] support for event handlers using a subset of parameters

[Vlad Grigorescu]

I think compatibility is a growing issue with scripts being released as
plugins. I'm already seeing some code shift to:

> @if (Version ...)
> new event
> @else
> old event

I _think_ I like Seth's idea of records, but I'm still thinking it through.
It would formalize a growing trend towards moving more parameters into
records anyway. If we're worried about backwards compatibility, then maybe
we have a built in version number in each record. Whenever fields are
added/removed, or there are more subtle contextual changes, the version
number could increase.

As a concrete example, the is_server parameter of the ssh_capabilities
event was being set backwards (effectively as "is_client.") I introduced a
change[1] where the is_server parameter was corrected, but now how to
interpret the value depended on the Bro version. This is a very subtle
case, where no field was added or deleted, but users were still expected to
change their code.

  --Vlad

[1] - 

On Wed, Feb 6, 2019 at 5:10 PM Seth Hall  wrote:

>
>
> On 6 Feb 2019, at 10:48, Jon Siwek wrote:
>
> > We can't magically change that user's code.  We have to, somehow, let
> > that work as it is, without user intervention.
>
> Yeah, I think that's right.  I was trying to come up with some proposed
> model for indicating that you're specifying named parameters but that
> would still force existing code to be updated so that it could keep
> using the existing model.
>
> One thing I've been thinking about a little bit is how much we're
> concerning ourselves with maintaining perfect backward compatibility and
> if there is some benefit to breaking a bit of backward compatibility for
> something truly nicer?  Like, should we have some specialized syntax for
> specifying named parameter use?  Should we have something like anonymous
> records where you specify a variant of record syntax for named
> parameters?  (ruby comes to mind for this, but I've seen people do
> similar things in c too)
>
> I'm just wondering if we should do a one-time source compatibility break
> to could get some tangible benefit in usability or understanding.  I
> think Robin's concern is about backing us into a corner with a syntax
> that makes code confusing.  Is that correct Robin?
>
>.Seth
>
> --
> Seth Hall * Corelight, Inc * www.corelight.com
> ___
> zeek-dev mailing list
> zeek-dev@zeek.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
>
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev

Re: [Zeek-Dev] support for event handlers using a subset of parameters

[Seth Hall]

On 6 Feb 2019, at 10:48, Jon Siwek wrote:

> We can't magically change that user's code.  We have to, somehow, let
> that work as it is, without user intervention.

Yeah, I think that's right.  I was trying to come up with some proposed 
model for indicating that you're specifying named parameters but that 
would still force existing code to be updated so that it could keep 
using the existing model.

One thing I've been thinking about a little bit is how much we're 
concerning ourselves with maintaining perfect backward compatibility and 
if there is some benefit to breaking a bit of backward compatibility for 
something truly nicer?  Like, should we have some specialized syntax for 
specifying named parameter use?  Should we have something like anonymous 
records where you specify a variant of record syntax for named 
parameters?  (ruby comes to mind for this, but I've seen people do 
similar things in c too)

I'm just wondering if we should do a one-time source compatibility break 
to could get some tangible benefit in usability or understanding.  I 
think Robin's concern is about backing us into a corner with a syntax 
that makes code confusing.  Is that correct Robin?

   .Seth

--
Seth Hall * Corelight, Inc * www.corelight.com
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev

Re: [Zeek-Dev] support for event handlers using a subset of parameters

[Jon Siwek]

On Tue, Feb 5, 2019 at 7:40 PM Robin Sommer  wrote:

> The following would be even worst in terms of confusion:
>
> global my_event: event(a: string, b: string);
> event my_event(b: string)
>
> Now I need to know if the language goes by order of parameters or by
> parameter name.

The issue may be exaggerated because we're using contrived parameter
names.  If we make it a bit more real (still "shortened" for sake of
example):

http_request: event(method: string, version: string);
event http_request(version: string) { ... }

The "parameter order vs. name" issue doesn't even cross my mind here
because the intent is clear -- I understand the meaning of the
handler's parameter because the original author of the event chose a
meaningful and useful name for it (which will be the common case).
That's all the reader cares about -- understanding the meaning of any
given parameter.

> I do see the appeal of making things just work when event handlers
> change, but is there really no different way to support that?

If the goal is to avoid breaking user-code, I don't think we're in a
position to do anything else.  For example, we have:

global my_event: event(a: string);

And we want to add a parameter:

global my_event: event(a: string, b: string);

The user has already written their handler as:

event my_event(a: string) { ... }

We can't magically change that user's code.  We have to, somehow, let
that work as it is, without user intervention.

- Jon
___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev

[Zeek-Dev] Hi + LL Analyzer

[Elbez, Ghada (IAI)]

Hi everyone,

I am researcher in KIT where I’m also doing my PhD. I had the chance to meet 
some of you in the last (well first) Bro Europe workshop.

My research work is focused on the cyber-physical security of communication 
networks of substations based on IEC 61850. Thus, I was wondering if I could 
use Zeek for network monitoring of some layer 2 protocols (GOOSE and SV).

I already quickly discussed the topic with Jan. However, I still would like to 
know more details what has been already done and what the current state is. To 
start also gathering some ideas about the topic.

Best,
Ghada


Karlsruhe Institute of Technology (KIT)
Institute for Automation and Applied Informatics (IAI)

M.Sc. Ghada Elbez
PhD Student

Hermann-von-Helmholtz-Platz 1
Building 445, Room 218
76344 Eggenstein-Leopoldshafen, Germany

Phone: +49 721 608-2 8429
E-mail: ghada.elbez∂kit.edu

___
zeek-dev mailing list
zeek-dev@zeek.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev