Brief items

Security quote of the week

Ian Cassels, British mathematician and World War II cryptanalyst, once said that "cryptography is a mixture of mathematics and muddle, and without the muddle the mathematics can be used against you." This mixture is particularly difficult to achieve with public-key algorithms, which rely on the mathematics for their security in a way that symmetric algorithms do not. We got lucky with RSA and related algorithms: their mathematics hinge on the problem of factoring, which turned out to be robustly difficult. Post-quantum algorithms rely on other mathematical disciplines and problems—code-based cryptography, hash-based cryptography, lattice-based cryptography, multivariate cryptography, and so on—whose mathematics are both more complicated and less well-understood. We're seeing these breaks because those core mathematical problems aren't nearly as well-studied as factoring is.

The moral is the need for cryptographic agility. It's not enough to implement a single standard; it's vital that our systems be able to easily swap in new algorithms when required. We've learned the hard way how algorithms can get so entrenched in systems that it can take many years to update them: in the transition from DES to AES, and the transition from MD4 and MD5 to SHA, SHA-1, and then SHA-3.

— Bruce Schneier

Comments (1 posted)

Kernel release status

The 6.0 merge window remains open; it can be expected to close on August 14.

Stable updates: none have been released in the last week. The smallish 5.19.1, 5.18.17, 5.15.60, 5.10.136, 5.4.210, and 4.19.255 updates are in the review process; they are due on August 11.

Comments (none posted)

Quotes of the week

There are many people now who seem to think that running automated fuzz testing of ondisk artifacts to find mischievous behavior and spraying exploit code onto the public mailing list for instant zero-day disclosure is somehow of some social benefit. In the view of this author, the benefit is realized only when the fuzz operators help to **fix** the flaws, but this opinion apparently is not widely shared among security "researchers". The XFS maintainers' continuing ability to manage these events presents an ongoing risk to the stability of the development process.

— Darrick Wong

Which attitude problem?

The attitude problem that PREEMPT_RT is just a niche, but the larger kernel community is happy to consume the benefits of that alleged niche without giving anything back.

Think about that.

— Thomas Gleixner

Comments (4 posted)

OpenSUSE considers dropping reiserfs

As Jeff Mahoney notes in this message to the openSUSE factory list, the reiserfs filesystem has been unmaintained for years and lacks many of the features that users have come to expect. He has thus proposed removing reiserfs from openSUSE Tumbleweed immediately.

I recognize that there may be people out there with disks containing reiserfs file systems. If these are in active use, I would seriously encourage migrating to something actively maintained.

Comments (31 posted)

GitLab plans to delete dormant projects in free accounts (Register)

The Register reports that GitLab is planning to start deleting repositories belonging to free accounts if they have been inactive for at least a year.

GitLab is aware of the potential for angry opposition to the plan, and will therefore give users weeks or months of warning before deleting their work. A single comment, commit, or new issue posted to a project during a 12-month period will be sufficient to keep the project alive.

Comments (76 posted)

Mena Quintero: Paying technical debt in our accessibility infrastructure

On his blog, Federico Mena Quintero posted a transcript of his recent talk at GUADEC 2022 on the technical debt in the GNOME accessibility infrastructure—and what he has been doing to help pay that down. He began the talk by describing the infrastructure and how it came about:

Gnome-shell implements its own toolkit, St, which stands for "shell toolkit". It is made accessible by implementing the GObject interfaces in atk. To make a toolkit accessible means adding a way to extract information from it in a standard way; you don't want screen readers to have separate implementations for GTK, Qt, St, Firefox, etc. For every window, regardless of toolkit, you want to have a "list children" method. For every widget you want "get accessible name", so for a button it may tell you "OK button", and for an image it may tell you "thumbnail of file.jpg". For widgets that you can interact with, you want "list actions" and "run action X", so a button may present an "activate" action, and a check button may present a "toggle" action.

However, ATK is just abstract interfaces for the benefit of toolkits. We need a way to ship the information extracted from toolkits to assistive tech like screen readers. The atspi protocol is a set of DBus interfaces that an application must implement; atk-adaptor is an implementation of those DBus interfaces that works by calling atk's slightly different interfaces, which in turn are implemented by toolkits. Atk-adaptor also caches some things that it already asked to the toolkit, so it doesn't have to ask again unless the toolkit notifies about a change.

Does this seem like too much translation going on? It is! We will see the reasons behind that when we talk about how accessibility was implemented many years ago in GNOME.

Comments (1 posted)