[Zeek-Dev] Re: Moving policy scripts into packages
On 8/25/20 1:27 AM, Jan Grashöfer wrote: I think the underlying issue extends to the pcaps as well. If I am not mistaken, a significant number of test cases make use of the same pcaps. Having multiple copies of them scattered across different repositories doesn't feel right. Good point, yeah. I took a look at this. The btests in the Zeek distribution use 352 different pcaps. The tests for the policy folder use 30; 18 of them are also used by other tests. That set is small, less than 1MB. Use of the same pcap across the policy tests is pretty limited and would likely occur only within one new package. So it's not too bad -- if those tests migrate into new Zeek packages, we would duplicate those 18 pcaps, but mostly just once. Other Zeek packages seem pretty unlikely to need a pcap from the Zeek distribution, but I'd argue they probably benefit from a standard random.seed and some of the canonicalizers. An alternative would be to install the full set of pcaps (that's 23MB), probably optionally, and make the availability of the pcap a test requirement. What do you think? I personally could live with duplicating those pcaps. Best, Christian ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On Tue, Aug 25, 2020 at 3:27 AM Jan Grashöfer
wrote:
>
> I like that idea! It would be great to have a standard process for
> generating docs for each package.
>
I've been working[1] on a template for Zeek packages that consist only of
scripts. It's based heavily on the plugin-support[2] in zeek-aux, but it
goes a few steps further by running the tests via GitHub Actions with the
current {zeek, zeek-lts, zeek-nightly} packages. It also integrates with
GitHub Pages to auto-generate the Sphinx documentation. You can see an
example here: https://grigorescu.github.io/external_dns/. (Note: This is my
"working" package, and deviates from the upstream cookiecutter as I play
around with new things).
It tries to combine the user-provided README, with autogenerated
documentation, and some useful things that I bundled into the docs (for
example, explaining how plugins get loaded). One neat feature is using
intersphinx to link to the official Zeek docs, so that all the references
to types, enums, base scripts will still be clickable links.
There are a couple of open questions with this. For instance, Zeekygen does
not generate documentation for redefs within the script that's doing the
redefs. So this[3] will tell you that your script is adding some new notice
types, but the documentation is missing. Also, I don't have a good way to
generate documentation for all your packages into a single page, which
would be nice. I also made some changes to the Sphinx scripts in zeek-docs
that I should probably figure out how to upstream. We might want to just
publish the Sphinx module separately, so that people can just use it.
--Vlad
[1] -
[2] -
[3] - <
https://grigorescu.github.io/external_dns/scripts/NCSA/external_dns/main.zeek.html#redefinitions
>
___
zeek-dev mailing list -- zeek-dev@lists.zeek.org
To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On 25/08/2020 09:46, Robin Sommer wrote: 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. I like that idea! It would be great to have a standard process for generating docs for each package. On 24/08/2020 23:09, Christian Kreibich wrote: On a related note, I think it would be quite helpful if the Zeek install tree would include some of the standard btest helpers, such as random.seed and the various canonification scripts. I think the underlying issue extends to the pcaps as well. If I am not mistaken, a significant number of test cases make use of the same pcaps. Having multiple copies of them scattered across different repositories doesn't feel right. Jan ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into 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. 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
[Zeek-Dev] Re: Moving policy scripts into packages
On Mon, Aug 24, 2020 at 11:49 -0700, Johanna Amann wrote: > This, from my point of view, it would be neat to have a way to still > easily install a rather large set of packages (potentially nearly > everything that is in policy at the moment) and run test on them. While I agree that integration testing is useful, too, ideally the new packages would primarily rely on tests that are standalone. Do you see a problem with that for, e.g., the SSL functionality? > that change a lot of the test baselines - especially when we touch > something that affects connection-ID hashing, or the order of elements > in hashmaps. Agree with Jon here: This might be an opportunity to make the tests less fragile, more like what we'd recommend for external packages anyways. > It would be nice if, afterwards, it would still be possible to install a > working set of a script for the running version of Zeek. Yeah, if we worked with a meta-package, we could "bless" a specific version of that for a given Zeek release. People could update further, but with less of a guarantee, though we'd try hard to ensure they work with different versions, can even CI them against a bunch of recent releases. Overall, our current policy/ scripts haven't required version-specific changes very often, so I'm not too worried here. The most common use case it probably some script starting to use a newly introduced feature, and that's pretty easy to catch / guard 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. * 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
