Documentation #7890
closed
detect: tls.cert_subject incorrectly claims to support multi-buffer
Added by Philippe Antoine 7 days ago.
Updated about 16 hours ago.
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...
- Status changed from New to In Review
This involved a code change. Should it be a bug as it was allowed as a multi buffer keyword before but is not. I think that’s the issue we’re trying to capture in a ticket.
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
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.
But, please feel free to modify the ticket as you wish :-)
- Assignee changed from OISF Dev to Philippe Antoine
- Status changed from In Review to Closed
- 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
- Subject changed from detect: tls.cert_subject incorrectly claims to support mult-buffer to detect: tls.cert_subject incorrectly claims to support multi-buffer
Also available in: Atom
PDF