output: allow arbitrary keys in metadata

[regit]

Metadata keyword in signatures can have any key defined so we should allow them.

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• [x] I have read the contributing guide lines at https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Contributing
• [x] I have signed the Open Information Security Foundation contribution agreement at https://suricata.io/about/contribution-agreement/
• [x] I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable)

Link to redmine ticket:

Describe changes:

• update schema.json

[victorjulien]

Interesting issue. I feel this should be restrictive in our CI, but I see that outside of our CI it should not be.

[codecov[bot]]

Codecov Report

Merging #7792 (72c110e) into master (1bff888) will decrease coverage by 0.00%. The diff coverage is n/a.

:exclamation: Current head 72c110e differs from pull request most recent head 90c7205. Consider uploading reports for the commit 90c7205 to get more accurate results

@@            Coverage Diff             @@
##           master    #7792      +/-   ##
==========================================
- Coverage   76.05%   76.05%   -0.01%     
==========================================
  Files         663      663              
  Lines      185874   185872       -2     
==========================================
- Hits       141375   141373       -2     
  Misses      44499    44499              

Flag	Coverage Δ
fuzzcorpus	61.01% <ø> (+0.01%)	:arrow_up:
suricata-verify	52.48% <ø> (-0.04%)	:arrow_down:
unittests	60.71% <ø> (ø)

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

[regit]

Just for information: I've added a commit to the MR as it is on the same subject.

[regit]

Interesting issue. I feel this should be restrictive in our CI, but I see that outside of our CI it should not be.

Should it be the suricata-verify test that are restrictive and not the schema check ?

[victorjulien]

Interesting issue. I feel this should be restrictive in our CI, but I see that outside of our CI it should not be.

Should it be the suricata-verify test that are restrictive and not the schema check ?

New SV tests or SV tests exposing new EVE fields trigger schema error if fields are not part of the schema. This has been a major driver of schema updates.

[catenacyber]

I stumbled on the metadata schema.json problem with https://github.com/OISF/suricata/pull/8320 ;-)

[catenacyber]

Eric, do you have S-V tests for the port field ?

[jasonish]

Replaced by https://github.com/OISF/suricata/pull/8824.