docs: add security notice 17 (Check Publication date before publishing)

[npepinpe]

• NOTE: Have you checked and updated the Publication date in this PR before publishing?

Description

Adds a security notice for the following vulnerability: GHSA-735f-pc8j-v9w8

We've opted to release only on the next patch cycle, because:

1. The CVE will only crash the gateway if the attacker is sending hammering the gateway with requests; this is because Netty will correctly handle the StackOverflowException generated by the message without crashing. However, it has some performance impact on other requests, so sending lots of requests will bog down the gateway.
2. This is actually something we don't handle well right now in general, even ignoring malicious messages, and something customers can work around by throttling clients spamming their servers.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the DevEx team. (create draft PR and/or add hold label)
• [] This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• My changes are for an upcoming minor release and:
  • are in the /docs directory (version 8.8).
  • are in the /versioned_docs/version-8.7/ directory (version 8.7).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[npepinpe]

This should be released only with the next 8.6.x patch, whenever that is (at the latest first week of April).

[github-actions]

👋 🤖 ✅ Looks like the changes were ported across versions, nice job! 🎉

You can read more about the versioning within our docs in our documentation guidelines.

[npepinpe]

There are failures which I'm confused by, like the format is because some utility is missing? 🤔

[akeller]

@npepinpe, I ran npm run format on your branch locally just to make sure there wasn't anything weird going on. Let me rerun the job and see if that clears this up.

[akeller]

@pepopowitz can you have a look at check-format?

Running vale... /home/runner/vale --output=/home/runner/work/_actions/errata-ai/vale-action/reviewdog/lib/rdjsonl.tmpl . E100 [lintMDX] Runtime error mdx2vast not found Execution stopped with code 1. Error: Vale and reviewdog exited with status code: 2

[Langleu]

@akeller @pepopowitz that is because of the latest vale relase (3.10.0). Just ran into the same issue on a different PR and started looking whether anyone encountered / fixing it already.

Fix is as easy as npm install -g mdx2vast as part of the check-format workflow. Ideally it's fixed upstream eventually in the action that you're using for vale. There's probably other ways to approach it as well, was just the quickest one to do.

[mesellings]

@npepinpe I've reviewed and made some commits directly to the branch for readability, rewording etc. I just have a lingering question about some of the text which originally said:

it could lead to DoS issues both on the server side

I removed "both on", but wasn't sure if this was meant to be "both on the server and client side" perhaps?

Also, we don't have a ny solution/resolution/how to tell if affected info, not sure if that is by design?

Approved, with just these two questions that may or may not affect whether it is ready to publish (I don't think they are blocking). 🚀

[npepinpe]

No, that was not by design, sorry 🙈

[mesellings]

Also, do we have a schedule for when this should be published, or a way of keeping in sync with the relevant 8.6.x patch? I.e., making sure we publish it at the right time.

[npepinpe]

I was hoping you had a way to do that. So we release every month on the fist week a patch, but we might be releasing before that (since anyone from the monorepo can trigger a release). I'm not aware of anything, but I could imagine a step in our release process should handle that hopefully...

[mesellings]

I guess without some kind of automated notification, we'll have to rely on communication for now - to make sure we can publish the security notice in time - who would be best placed in the team for making sure we know perhaps 1 day ahead that the release will be going out please?

Also, is this CVE fixed with the patch release - if so, shouldn't we mention it in this notice in a Solution section?

[npepinpe]

Sorry, this is what happens from doing too many different things at once :(

[akeller]

@npepinpe does this date need to be adjusted?

[npepinpe]

Yeah, I guess. What's the process if I don't know it? 😄

[npepinpe]

I just leave it blank and wait until the release?

[mesellings]

If we know in advance the date, we can set it to that - my suggestion would be to change it to the date in the first week of the month (April) that this is planned for - is it on a Tuesday for example? If the date is simply really fluid/unpredictable, we're just going to have to rely on clear communication - I'll add something in the title/description to make sure this isn't missed.