Posts by sward 10 publicly visible posts • joined 20 Feb 2013
I’m all for credit where credit is due and I also advocate referring to GNU when generically referring to families of operating systems based around GNU core user land software. However, there exist systems that use the Linux kernel and a user land without GNU software, such as Chimera Linux. These are not GNU systems, and just because some software requires GNU tools to build does not suddenly mean it becomes GNU software.
Depending on who you ask, “operating system” means different things, and is further blurred by distributions, both GNU and non‐GNU. Arguably the whole distribution is in scope, since the distribution maintainers curate and integrate the software that goes into their package repositories, such that they can be seen as part of the whole system. Some may choose draw the line at, as seems to be your preference, Linux plus the core system utilities, although this still omits the fact that in many cases much other system software is not GNU—take many of the major distributions that now use systemd, which is just as fundamental to the system as the GNU utilities, if not more. If we instead draw the line at the software that works “behind the scenes” to provide an environment for applications software, one of the more common definitions of an operating system, then we have a variety of system services, the X display server and window manager, or Wayland compositor, session manager, graphical shell and its core components—all typically considered part of the operating system in the Windows world, so why not on GNU systems too?
It’s much better to stay out of these murky waters and instead refer to each distribution rather than generically referring to them as GNU/Linux or GNU then getting stuck when something doesn’t neatly fit into that highly general but at the same time so specific category.
There is an implementation of OpenPGP on the other platforms: GnuPG. The decision includes having hard dependencies on Sequoia-PGP. The specific OpenPGP implementation isn't the only dependency though, going by the text quoted from Klode in the article, it suggests parts of APT will be implemented in Rust.
All correct, although Cyber Essentials does require that user accounts with password-based authentication are protected against brute-force guessing by implementing at least one of: multi-factor authentication; throttling (rate limiting); or locking after a number of fails. The article states “The Information Commissioner's Office (ICO) says a third-party consultancy determined that the criminal used brute-force tactics to gain entry to an infrequently used administrator's account that lacked multi-factor authentication.”
What happened to Distributed Weakness Filing (DWF)? The project was started in 2016, and El Reg reported on it[1], but it seems to have died. It tried to address some issues with CVE, foremost being getting an identifier in the first place. It was resurrected in 2021 according to LWN[2], but seems to have died again.
Incidentally, while trying to find DWF (I couldn’t remember the name), all searches seemed to point at gcve.eu, which, if the Github project for the web site is anything to go by, began only hours ago.
[1]: https://www.theregister.com/2016/03/09/hackers_spin_up_alternative_cve_system_as_bugs_go_unchecked/
[2]: https://lwn.net/Articles/851849/
Distributed Weakness Filing (DWF) attempted to address a few issues, such as being able to get a vulnerability identifier in the first place. It also provided a place for CVEs not assigned by the traditional CNAs. One problem with the CNA system is that the CNA can reject the assignment outright, and many of the big software vendors are CNAs for their own software (Red Hat, Microsoft, Apache, etc).
I can well believe Windows has got to a stage where security vulnerabilities are not as prevalent (relatively - they're probably absolutely more prevalent) as they once were, but...
Stop counting CVEs!
It's not even accurate enough for a ballpark figure.
CVEs are public (after any embargo). Not all security vulnerabilities are made public, and Microsoft are as guilty as, if not more than, any other vendor. Its CVE counts like this that actually encourage vendors to avoid disclosure if at all possible.
Microsoft handles its own CVEs, as do other vendors such as Red Hat. Sure, they all have guidelines on what to issue CVEs for, but all CVEs are not equal. A single CVE identifier is supposed to cover one issue, yet Microsoft has been known to issue one CVE covering many vulnerabilities.
Disclosure of security vulnerabilities is not exposure to security vulnerabilities. The timely disclosure of vulnerabilities is more likely to prevent exposure because it gives those actually maintaining the systems the opportunity to mitigate the vulnerabilities. The very fact the Microsoft complained about Google's 90-day disclosure policy, that's ~3 months by the way, means they are not fixing vulnerabilities they know about in a timely manner. You can't assume that just because a vulnerability is not widespread public knowledge that attackers don't know about it. This goes even more so for a vulnerability that has already been reported to the vendor -- at least one other actor, the reporter, knows about the vulnerability, and you should assume that others do too.
Q: What's the word's most popular nameserver?
A: BIND
Q: How many security flaws were announced/patched for BIND last year? How many of them were related to DNSSEC?
A: I don't know, I think I lost count. The vast majority of them were DNSSEC related in Amy case.
Are DNSSEC implementations even mature enough to use yet? Sure, somoebody though they were good enough for the root servers, but that doesn't mean they're good enough for everyone else.
Implementing DNSSEC is not trivial to implement and maintain. You need to at least deal with more keys and institute another key rollover policy. One mistake can cause a denial of service for Lots of people. DNS spoofing is not trivial either, and the risk of doing that may be perceived to be less than the effort of maintaining DNSSEC for your domains.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
