Documentation #7890
closeddetect: tls.cert_subject incorrectly claims to support multi-buffer
Description
See commit 5379b52af2df9eb2911fc4655d5db5defcecb863
Some rules expected this keyword to be a multi-buffer (and thus will never match)
So, we need to document in upgrade notes that a new warning gets printed for misusage of this keyword...
Updated by Philippe Antoine 7 days ago
- Status changed from New to In Review
Updated by Philippe Antoine 5 days ago
Jason Ish wrote in #note-2:
it was allowed as a multi buffer keyword before but is not.
It was not really "allowed" as a multi-buffer : it was not implemented as a multi-buffer, even if it was documented as such.
It was just rules using the multi-buffer syntax did not warn even if they should have
Updated by Jason Ish 4 days ago
Philippe Antoine wrote in #note-3:
Jason Ish wrote in #note-2:
it was allowed as a multi buffer keyword before but is not.
It was not really "allowed" as a multi-buffer : it was not implemented as a multi-buffer, even if it was documented as such.
It was just rules using the multi-buffer syntax did not warn even if they should have
Yeah, I think that is captured in #7867. We need a ticket for the bug fix though, being that we now warn on this condition instead of silently allowing as its a visible user facing change.
Updated by Philippe Antoine 4 days ago
But, please feel free to modify the ticket as you wish :-)
Updated by Victor Julien 2 days ago
- Assignee changed from OISF Dev to Philippe Antoine
Updated by Philippe Antoine 1 day ago
- Status changed from In Review to Closed
Updated by Victor Julien about 16 hours ago
- Subject changed from detect: tls.cert_subject has never been a multi-buffer yet to detect: tls.cert_subject incorrectly claims to support mult-buffer
Updated by Victor Julien about 16 hours ago
- Subject changed from detect: tls.cert_subject incorrectly claims to support mult-buffer to detect: tls.cert_subject incorrectly claims to support multi-buffer