more concise phrasing for kex-strict-s-v00@openssh.com [info]

[perkelix]

What we currently have:

(kex) kex-strict-s-v00@openssh.com        -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

What I recommend instead:

(kex) kex-strict-s-v00@openssh.com        -- [info] supports strict key exchange to mitigate the Terrapin attack (CVE-2023-48795)

[jtesta]

I think this comes down to personal preference. My own preference is to leave it as-is, but perhaps we can let the community vote on this.

If anyone would like this change made, put a thumbs-up emoji on this comment. Otherwise, if you'd like the output to remain as-is, put a thumbs-down emoji on this comment. Voting will remain open until Oct. 1 (for approximately 3 months). After that time, I'll follow whatever the community prefers.

[egberts]

I think an inline comment line having a CVE number is a very helpful CyberSec tip in which one can investigate further with regard to ANY specialized "@vendor-notation" response to its algorithm as having been denoted by its (new/updated) version number.

This above suggested comment inclusion of a CVE notation is way better than nothing for assisting CyberSec community than saying "branch of " or worse an attempt to qualify/quantify "a responded fix to original ".

But, but ... BUT perhaps a comment like "in response to CVE-####" is the better and more neutral choice of wording IF and only IF introducing another SSH algorithm neogitation string in form an annotated/new algorithm versioning substring having been tacked on.

[perkelix]

To me, the key point is to keep the explanation as concise as possible. Headlines rather than long sentences. Mentioning that a feature exists as mitigation against a CVE remains concise. Writing a novel about doesn't.