Among other changes 10.4 adds post-quantum keys (composite ML-DSA 44 and Ed25519), not enabled by default.
When pq key agreement was added in 2019, it took almost 3 years for it to become enabled by default. This isn't criticism, just an observation. I don't have a pressing need for pq sigs. Always happy for new OpenSSH releases though!
I recently added ml-dsa-44 to solokeys, both piv and fido2. To my understanding ssh+fido2 doesn’t support pq yet, but if anybody’s reading and knows how to make it happen, I’d be really interested.
<!--
DO NOT EDIT MANUALLY! This is generated from:
www/build/openssh/releasenotes.html.head
www/build/openssh/releasenotes.html.tail
See comments in www/build/openssh/Makefile for details.
-->
My experience is that minor improvements tend to get accepted if they come with a solid technical motivation and fits into the overall OpenBSD mindset and ecosystem. If the change is simply justified by "best practices" and is rather large, then the conservative choice of just leaving things as they are usually prevail.
For example, I think I have seen two proposals for major overhauls of the OpenBSD.org homepage by "outsiders" over the last three years or so and they were both rejected. However, as you can see by the commit log, minor improvements (including presentation ones) happen all the time.
It's not supposed to wrap or be responsive.. It's a tradition of making text legible on vintage terminals. I use `fill-paragragh` in emacs to format my commit messages like this 'cause I'm a dork hehe
Narrower windows will adjust the layout of the page to be more easily accessible for narrower devices like phones. This is a css feature and does not require JavaScript or similar.
In the context of the linked site which manually uses line breaks this won’t work well aside from fixing the scroll overflow, the text is small on my iPhone when zoomed out to show the full line width. A fix is better than nothing but does not perfectly fix the issue.
Requiring thousands of node packages to malformat text for people who can't be bothered to not use a phone to read a webpage seems to be the common definition of responsive these days.
OpenSSH thankfully cares little for corporate security theathre
But I can sympathise, our stuff got flagged in audit because we foolishly assumed that some requirement was checked by just having OpenSSH "new enough",but it turned out that RedHat for that RHEL version patched back some old considered insecure primitives to keep their customers happy...
It would be nice to have defaults that are following regulations because it sucks to have and maintain explicit list.
If it would be a simple toggle - secureciphersonly=yes sure, but listing them is just creating tech debt.
Among other changes 10.4 adds post-quantum keys (composite ML-DSA 44 and Ed25519), not enabled by default.
When pq key agreement was added in 2019, it took almost 3 years for it to become enabled by default. This isn't criticism, just an observation. I don't have a pressing need for pq sigs. Always happy for new OpenSSH releases though!
> Among other changes 10.4 adds post-quantum keys (composite ML-DSA 44 and Ed25519), not enabled by default.
The draft was only published a few months ago:
* https://datatracker.ietf.org/doc/draft-miller-sshm-mldsa44-e...
The draft is a 'personal document', so not associated with the IETF/WG.
I recently added ml-dsa-44 to solokeys, both piv and fido2. To my understanding ssh+fido2 doesn’t support pq yet, but if anybody’s reading and knows how to make it happen, I’d be really interested.
HTML version of release notes:
* https://www.openssh.org/releasenotes.html#10.4
Still looks like ascii, doesn’t automatically wrap, nor is it responsive.
Anyone know if these projects accept PRs to improve these kinds of things, like legibility? Or is it a point of pride?
https://www.openssh.org/releasenotes.html#10.4
Well, you can have a look at the commit history to see what changes have been accepted in the past:
https://github.com/openbsd/www/commits/master
My experience is that minor improvements tend to get accepted if they come with a solid technical motivation and fits into the overall OpenBSD mindset and ecosystem. If the change is simply justified by "best practices" and is rather large, then the conservative choice of just leaving things as they are usually prevail.
For example, I think I have seen two proposals for major overhauls of the OpenBSD.org homepage by "outsiders" over the last three years or so and they were both rejected. However, as you can see by the commit log, minor improvements (including presentation ones) happen all the time.
It is vintage style. I actually love it a lot.
It's not supposed to wrap or be responsive.. It's a tradition of making text legible on vintage terminals. I use `fill-paragragh` in emacs to format my commit messages like this 'cause I'm a dork hehe
What “responsive” mean here?
Narrower windows will adjust the layout of the page to be more easily accessible for narrower devices like phones. This is a css feature and does not require JavaScript or similar.
In the context of the linked site which manually uses line breaks this won’t work well aside from fixing the scroll overflow, the text is small on my iPhone when zoomed out to show the full line width. A fix is better than nothing but does not perfectly fix the issue.
doesn't even need specific CSS rules, just the default. every item needs to be wrapped or even just prefixed with a <p> or <li> element
[flagged]
Requiring thousands of node packages to malformat text for people who can't be bothered to not use a phone to read a webpage seems to be the common definition of responsive these days.
I can almost guarantee it would not be an improvement.
To make it worse ? I hope they don't!
Honestly this just looks like RST markup to me. If you really wanted to format it, I feel like using a previewer for that would basically do the job
Is hmac-sha1 and umac-64 still enabled by default?
Yes:
* https://man.openbsd.org/ssh_config.5#MACs
* https://man.openbsd.org/sshd_config.5#MACs
ETM, encrypt-than-mac, variants are at the front of the preference list.
* https://en.wikipedia.org/wiki/UMAC_(cryptography)
That sucks, that means they will still appear in audits, they should remove them from the default.
OpenSSH thankfully cares little for corporate security theathre
But I can sympathise, our stuff got flagged in audit because we foolishly assumed that some requirement was checked by just having OpenSSH "new enough",but it turned out that RedHat for that RHEL version patched back some old considered insecure primitives to keep their customers happy...
It would be nice to have defaults that are following regulations because it sucks to have and maintain explicit list. If it would be a simple toggle - secureciphersonly=yes sure, but listing them is just creating tech debt.
aka FIPS.