Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eve-filetypes: separate from plugins, as eve filetypes are not plugins: plugins can register eve filetypes - v1 #10591

Closed
wants to merge 3 commits into from

Conversation

jasonish
Copy link
Member

@jasonish jasonish commented Mar 7, 2024

EVE filetypes and plugins were conflated in naming and discussion when they are really different things which is clear by examples in code such as the nullsink and syslog eve filetypes, which are very much not plugins.

To make this more clear, rename and refactor such that these registered EVE filetypes are referred to as filetypes, not plugins.

Plugins can register these filetypes, but so can internal code as well as library users.

Includes some header cleanup due to removing "suricata-plugin.h" from places that shouldn't need any knowledge of plugins, but somehow become the way some files were getting the "conf.h" header.

Pushing for review, but as I'm reviewing myself right now, I want to fill out more of the in-code documentation.

Ticket: https://redmine.openinfosecfoundation.org/issues/6838

Remove EVE filetypes from plugin context as they are not only used
from plugins. Plugins allow user code to register filetypes, but we
also have internal file types that use this api including the null
output and syslog.  Additionally library users can use this API to
register filetypes, and they are not plugins.

Ideally this code would go in "output-json.[ch]" as the "primary" eve
API, however there are currently some include circular include issues
there, so start new cleaned up EVE API in "output-eve.[ch]" which is
"clean" with respect to includes, and as we cleanup existing EVE API for
"public" use, it can be moved here.

Ticket: OISF#6838
Remove "conf.h" from suricata-plugin.h as its not needed by that
header. However, some other files became transitively dependent on
through other includes, so fix those up.
EVE filetypes are not always plugins, for example, null and syslog
that are built-in filetypes.
@jasonish jasonish requested review from victorjulien and a team as code owners March 7, 2024 23:46
Copy link

codecov bot commented Mar 8, 2024

Codecov Report

Attention: Patch coverage is 45.09804% with 28 lines in your changes are missing coverage. Please review.

Project coverage is 82.70%. Comparing base (4afaadc) to head (a5b2c61).

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #10591      +/-   ##
==========================================
- Coverage   82.74%   82.70%   -0.05%     
==========================================
  Files         924      925       +1     
  Lines      247401   247401              
==========================================
- Hits       204719   204619     -100     
- Misses      42682    42782     +100     
Flag Coverage Δ
fuzzcorpus 64.08% <39.21%> (-0.03%) ⬇️
suricata-verify 61.89% <45.09%> (+<0.01%) ⬆️
unittests 62.19% <37.25%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

@suricata-qa
Copy link

Information: QA ran without warnings.

Pipeline 19064

* include issues are figured out.
*/

#ifndef __SURICATA_OUTPUT_EVE_H__
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why SURICATA part of the define here? We normally only base on the file name

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an include that is part of the library, it should be name spaced as well. __OUTPUT_EVE_H__ is probably not that generic, but something simpler like __OUTPUT_H__ is more generic with a higher chance of conflicting with a user header.

LibHTP, libcurl, etc. all do this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this type of change go into the whole codebase? Perhaps as a separate change/commit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm somewhat indifferent here as its not an introducer of merge conflicts like some other changes we have discussed would be. But would be nice I guess, should we also remove the leading double underscores (and trailing) as they are in reserved namespace?

/**
* Structure used to define an Eve output file type plugin.
*/
typedef struct SCEveFileType_ {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice to tighten the function signatures a bit, esp with adding const where appropriate

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DIdn't want to change or break the API with this PR, I have some breaking changes coming for 8.0 that hopefully make it easier, that would be where to change the signatures.

@@ -20,6 +20,7 @@

#include <stdint.h>
#include <stdbool.h>
#include <queue.h>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this meant to "queue.h"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, oops.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we combine the SCPlugin and SCCapturePlugin types?

I think that SCPlugin would suffice for both (maybe all?) plugin types and then a backing type for the capture plugins can be created in a similar way that SCEveFileType is a backing type for SCPlugin.

Thoughts?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only catch here is that the filetypes don't require anything from the engine, but the captures do, at least now -- the "slot" they fit into. So capture plugins need that extra hook from the engine that file types do not.

Copy link
Contributor

@jlucovsky jlucovsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this. Can the logic from #10159 be incorporated?

@jasonish
Copy link
Member Author

jasonish commented Mar 9, 2024

I like this. Can the logic from #10159 be incorporated?

This PR tried to be simple with no behaviour changes. However, it would make sense to integrate that with what I want to do next, simplify the filetypes for threaded and non-threaded modes.

@jasonish
Copy link
Member Author

Taking this all the way with breaking cleanups: #10621

@jasonish jasonish closed this Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants