LWN: Comments on "OpenSSH 9.2 released" https://lwn.net/Articles/922006/ This is a special feed containing comments posted to the individual LWN article titled "OpenSSH 9.2 released". en-us Mon, 27 Oct 2025 10:27:21 +0000 Mon, 27 Oct 2025 10:27:21 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net OpenSSH 9.2 released https://lwn.net/Articles/923546/ https://lwn.net/Articles/923546/ mrugiero <div class="FormattedComment"> From the mention to `goto` I infer OP means not using the `return` keyword directly but jumping to a label at the end of the function that does cleanup and then returns, rather than not exiting the function early on errors. It's a common pattern, I've seen it called "goto exit" and "goto cleanup".<br> </div> Thu, 16 Feb 2023 17:18:33 +0000 OpenSSH 9.2 released https://lwn.net/Articles/923086/ https://lwn.net/Articles/923086/ nix <div class="FormattedComment"> Ban use of early return, thus making early error checks much less readable, discouraging them, for the sake of edge cases like portability to weird embedded C compilers?<br> <p> Aren't you optimizing for entirely the wrong thing here?<br> </div> Sun, 12 Feb 2023 12:07:40 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922448/ https://lwn.net/Articles/922448/ smoogen <div class="FormattedComment"> Most likely because that is how they have written code for 30 to 40 years and so 'know' it better than some other style. That means it has become the dialect they are most familiar with and able to usually catch various errors better in it than others. Changing the code dialect usually requires a lot of retraining and usually adds a lot of errors. Those errors can end up being exploitable which then re-enforces not changing the style. <br> <p> Changes in coding dialect usually require an outside force to bring in the changes and show how they work. <br> </div> Tue, 07 Feb 2023 13:27:39 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922437/ https://lwn.net/Articles/922437/ paulj <div class="FormattedComment"> For this reason, I like to have modules in C code of mine that allocate objects, have a foo_free(foo **obj) function. The foo module's free function can then NULL the pointer in the caller.<br> <p> Far from perfect, the caller or other code may have stashed other pointers, but at least it ensures 'ownership' at the call site is cleanly transferred and destroyed.<br> <p> More complete solutions would involve providing functions to handle transfer of assignment, rather than using C =, and/or weak pointer/reference abstraction. Whether that's worth it depends on the complexity of the lifetime management of whatever objects you're dealing with. (And many will say "Why not Rust these days instead?").<br> </div> Tue, 07 Feb 2023 09:58:03 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922147/ https://lwn.net/Articles/922147/ ibukanov <div class="FormattedComment"> Personally I do not like auto ptr and similar macros for C. I rather prefer explicit free at the end of a function with a static checker to make sure that it is always called. At least it makes porting code to weird embedded C compiler much less problematic.<br> <p> As for rarely used cleanup paths a rather effective strategy IMO is to ban use of early return in C and always use goto instead to jump to the common cleanup code shared between success and error paths.<br> <br> </div> Fri, 03 Feb 2023 18:11:46 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922142/ https://lwn.net/Articles/922142/ mss <q>free() and similar destructor-type functions in the middle of the function with no comments and no assignments of the pointer to NULL after that.</q><br> <br> +1 for that, there's no reason <b>not</b> to set the object pointer to NULL after freeing the pointed-to object.<br> This turns a possible re-use into a NULL pointer dereference, which is almost always "just" a DoS risk.<br> <br> For example, Glib has a nice <a href="https://docs.gtk.org/glib/func.clear_pointer.html"><code>g_clear_pointer ()</code></a> macro for doing exactly that, which makes it easy to audit the code that it does this clearing everywhere - just by searching for freestanding <code>free ()</code> calls.<br> <br> However, this does <b>not</b> replace clear object ownership rules and annotations.<br> <br> For function-local objects or for holding a temporary object reference in a code block RAII-like self-freeing constructs as Glib's <a href="https://developer-old.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#g-autoptr"><code>g_autoptr(TypeName)</code></a> are very useful.<br> These especially make error cleanups much simpler (and these paths are often not well tested and bit-rot quickly).<br> <br> AFAIK, Linux kernel would benefit from these constructs, too. Fri, 03 Feb 2023 17:39:48 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922071/ https://lwn.net/Articles/922071/ ibukanov <div class="FormattedComment"> My complain is not about tabs or other cosmetics. It is about:<br> <p> Cryptic names of variables<br> Unclear ownership of memory not reflected in comments.<br> free() and similar destructor-type functions in the middle of the function with no comments and no assignments of the pointer to NULL after that. <br> Reuse of pointers to point to different memory-allocated things instead of introducing a new name for the new pointer.<br> Attempts to save vertical space via combing memory-allocating assignments and the if check.<br> <p> And the rules are violated in a single function in new code written in C in a system-critical service... <br> </div> Fri, 03 Feb 2023 01:17:11 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922067/ https://lwn.net/Articles/922067/ wahern <div class="FormattedComment"> The code *style* is traditional BSD KNF (Kernel Normal Form). Like most older styles in the Unix world it uses hard tabs. And unlike more recent derivatives it still uses tabs for alignment (not just indentation), including columnar alignment of types and type names. So the code itself will look messier unless your tab stop is set to 8.<br> <p> But if the *architecture* of OpenSSH seems messy, that's because it is messy. It's a fork of the *original* SSH implementation by Tatu Ylönen, and like any such original piece of software which coevolved with the functional concepts, the awkwardness is evident (and challenging). The codebase has seen tremendous changes, but the basic program layout and processing architecture, including the peculiar event loop, data model, etc, remain. That fundamental flavor of the codebase could never really be extirpated without effectively doing a complete rewrite. Newer components, which I think account for the majority of SLoC, still necessarily reflect the design (such as it is) of the original codebase.<br> <p> Sudo has similar problems for similar reasons--original software that created its niche--though sudo is 10-15 years older and corporate demands and funding resulted in sudo growing much more complex than was probably reasonable. That's why OpenBSD switched to doas, with the blessing and assistance of the long-time sudo maintainer.<br> </div> Fri, 03 Feb 2023 00:27:38 +0000 OpenSSH 9.2 released https://lwn.net/Articles/922062/ https://lwn.net/Articles/922062/ ibukanov <div class="FormattedComment"> The relevant code is dense and cryptic. I understand why OpenSSH will continue to use the standard C, not a memory safe language or at least a safe subset of C with safety enforced via tooling. But how do the authors justify to write in such code style on top of plain C? <br> </div> Thu, 02 Feb 2023 23:09:06 +0000