258 karma · joined November 5, 2015
Broad view betweeen BSD ecosystem offers that this wasn’t a good way. I still want to see a good alternative from that point of view…
The solution has been evolving along these years and currently the las IETF draft is https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account...
The new proposal brings the dns-account-01 challenge, incorporating the ACME account URL into the DNS validation record name.
The scenario is like the cgroup v1 and v2 change.
The early history of data networks https://archive.org/details/earlyhistoryofda0000holz
https://en.m.wikipedia.org/wiki/Abraham_Niclas_Edelcrantz
Also UK used a system close to that. And a lot of countries along Europe developed their networks with different signaling devices.
For example, EV carts had the green bar that was a soft way to promote their presence/use over the normal ones. That bar, started as a strong evidence on the url box and lost that look with the time.
Something like that let the owner to decide and, maybe, the user push their use because it feels more secure, not directly the CA.
It's a miracle how simple NetBSD still is, a few foo=NO in /etc/rc.conf and a check with ps auxc after rebooting, that's all.
https://web.archive.org/web/20061103174315/http://www.kleinj...
> Finally, if sshd cannot be updated or recompiled, this signal handler race condition can be fixed by simply setting LoginGraceTime to 0 in the configuration file. This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from the remote code execution presented in this advisory.
Setting 'LoginGraceTime 0' in sshd_config file seems to mitigate the issue.