Technically they're correct though, in a way. If every account has a password, the system isn't vulnerable.
You're also not vulnerable if you use two factor auth, because all 2FA modules require PAM, whereas this vulnerability only exists when PAM is disabled or not installed.
Not just rootless and read-only, but distroless/chiseled too. There's no reason to have unneeded parts of an OS in your Docker containers. It should just be one app along with any libraries it needs (or just statically compile the app)
"passwordless" here means that the account doesn't have a password. What the person you're replying to means is that password authentication should be completely disabled in the SSH config, as that's the only way to exploit this issue.
Wireguard and apps based on it (like Tailscale) don't respond at all unless the data is signed with the key of a configured peer (or with Tailscale, a system on your tailnet that passes the ACL). It's literally impossible for an outsider/attacker to detect with a port scan since it just ignores unauthenticated packets.
The Wireguard codebase is also extremely small. The core Wireguard implementation (the version in the Linux kernel) is around 5,000 lines long, so an experienced developer can read through all the code if they dedicate a day or two to it, and understand how it works.
For comparison, OpenVPN is around 70,000 lines of code and OpenSSH is around 150,000 lines of code. There's a huge number of features in SSH!
I forgot to mention that PDF added new features on top of PostScript, including 3D models.
Strangely, this kinda makes sense. PDF is based on PostScript, which is a file type (also by Adobe) that gets sent to printers. It's just skipping the final "send to printer" part and sends it to a file instead.
A fascinating thing (in a scary way) is that PostScript is technically a full programming language with loops, functions, logic, and a built-in font rendering and 2D graphics engine. When a document is printed using PostScript, your computer generates a script to lay out the page, that the printer runs in order to produce the document!
PDF is essentially "the safe parts" of PostScript - the same 2D graphics engine but with all the dynamic parts removed. PDFs are statically laid out when they're created, rather than having to run arbitrary code to lay them out like PostScript does.
PDF does support JavaScript code, but it's rarely used and needs to be granted permission to run. It's not a core part of the format.
For printing, PCL has somewhat taken over and it's less scary - it just has preset commands rather than allowing arbitrary code in a full programming language. PostScript is still used today for higher-end printers and print jobs though.
Gzip is old-school. The majority of modern sites use Brotli now. It's slower to compress, but that's not normally an issue for static resources (CSS, JS, etc) because they can be pre-compressed during the build and the web server serves the pre-compressed files instead of dynamically compressing them.
Some sites and apps have custom scrollbars. I don't like it, but they do exist.
Websites can change the colour of the scrollbars, in which case they're no longer system-rendered ones.
The recommended ESLint rules catch most of the bad stuff, and these days this is all you need in your ESLint config to enable them:
import {defineConfig} from 'eslint/config';
import js from '@eslint/js'
export default defineConfig([
js.configs.recommended,
];
There's one use case where == is still commonly used: == null matches both null and undefined. Lint rules that block == usually allows the null case as an exception.
I think a lot of "modern" scrollbars are just there as an affordance so you know that the content is scrollable and how far you've scrolled down, not to actually click and drag. Not entirely sure about the UX research for this but my guess is that it's because most people either physically drag (like with a touchpad or touch screen) or use a mousewheel to scroll down.
Some websites / web apps have the opposite problem: too many scrollbars.
MacOS has a setting to hide scrollbars when a mouse isn't plugged in (i.e. when just using the trackpad on a laptop), and it's enabled by default. Even if you force a scrollbar to appear using CSS (overflow: scroll), it won't appear.
I've seen sites where some boxes had two or three sets of scrollbars, because the developer didn't test on desktop OSes other that MacOS (or on MacOS with a mouse plugged in) and didn't realise that their CSS was adding scrollbars to too many elements.
In any case, your design should have an affordance to show that there's more content that can be scrolled to. A common way to do it is fading out or having a shadow on the scrollable edge. This technique is close to 15 years old but I still see it used today: https://css-tricks.com/books/greatest-css-tricks/scroll-shadows/. The Chrome dev site has some brief notes on some more modern techniques: https://developer.chrome.com/docs/modern-web-guidance/guides/ui-atoms/scrollability-affordance-hints
There's Dropbear SSH, which is the most common choice for a minimal SSH server and client, but even that is around 50,000 lines of code.