Brief items

Security quotes of the week

But if users turn on Lockdown Mode, they will be easy to fingerprint and identify, according to a developer who created a proof of concept website that detects whether you have Lockdown Mode enabled or not. In other words, Lockdown Mode users will be easy to detect and they will stand out because Lockdown Mode will presumably be relatively uncommon.

John Ozbay, the CEO of privacy focused company Cryptee, and a privacy activist, told Motherboard that any website or online ad can detect whether some regular features are missing, such as loading custom fonts, one of the features that Lockdown Mode disables.

"Let's say you're in China, and you're using Lockdown Mode. Now, any website that you visit could effectively detect you are using Lockdown Mode, they have your IP address as well. So they will actually be able to identify that the user with this IP address is using Lockdown Mode," Ozbay said in a call. "It's a tradeoff between security and privacy. [Apple] chose security."

— Lorenzo Franceschi-Bicchierai at Motherboard

Today, it's easier to build complex systems than it is to build simple ones. As recently as twenty years ago, if you wanted to build a refrigerator you would create custom refrigerator controller hardware and embedded software. Today, you just grab some standard microcontroller off the shelf and write a software application for it. And that microcontroller already comes with an IP stack, a microphone, a video port, Bluetooth, and a whole lot more. And since those features are there, engineers use them.

— Bruce Schneier

Comments (none posted)

Kernel release status

The current development kernel is 6.0-rc3, released on August 28. Linus said:

So as some people already noticed, last week was an anniversary week - 31 years since the original Linux development announcement. How time flies.

But this is not that kind of historic email - it's just the regular weekly RC release announcement, and things look pretty normal.

Stable updates: 5.19.4, 5.15.63, 5.10.138, 5.4.211, 4.19.256, 4.14.291, and 4.9.326 were all released on August 25. The single-patch 5.19.5 and 5.10.139 releases followed on August 29, and 5.19.6, 5.15.64, and 5.10.140 were released on August 31.

Comments (none posted)

Quote of the week

If the C standard thinks "undefined argument even for inlining use is [undefined behavior]", then it's a case of that paperwork that doesn't reflect reality, and we'll treat it with the deference it deserves - is less than toilet paper.

We have decades of history of doing that in the kernel. Sometimes the standards are just wrong, sometimes they are just too far removed from reality to be relevant, and then it's just not worth worrying about them.

— Linus Torvalds

Comments (3 posted)

Distributions quote of the week

If we insist on a particularly puritanical view of what is source and what is the preferred form for modification, then I think there is a significant risk of producing a distribution which is unquestionably Free Software, but either is missing useful Free software because it would be too hard to get that software into a form that meets our self-imposed policies, or can only contain that software as a result of individual developers putting a heroic amount of effort into meeting those policies - particularly if we always go back to the "true source" and generate from there every time.

— Simon McVittie

Comments (none posted)

Git’s database internals II: commit history queries (GitHub blog)

The GitHub blog has posted a detailed look at how Git stores the commit history to be able to quickly answer queries.

The commit-graph file provides a location for adding new information to our commits that do not exist in the commit object format by default. The new information that we store is called a generation number. There are multiple ways to compute a generation number, but the most important property we need to guarantee is the following:

If the generation number of a commit A is less than the generation number of a commit B, then A cannot reach B.

Comments (4 posted)

Git’s Database Internals III: File History Queries (GitHub blog)

The GitHub blog series on how the Git database works continues with this look at file-history queries.

If these history modes usually have the same output, then why wouldn’t we always use --full-history --simplify-merges? The reason is performance. Not only does simplified history speed up the query by skipping a large portion of commits, it also allows iterative output. The simplified history can output portions of the history without walking the entire history. By contrast, the --simplify-merges algorithm is defined recursively starting at commits with no parents. Git cannot output a single result until walking all reachable commits and computing their diffs on the input path. This can be extremely slow for large repositories.

Comments (none posted)

Sourceware seeking support from the Software Freedom Conservancy

Sourceware.org has long hosted the repositories for many important free-software projects, including much of the GNU toolchain. Frank Ch. Eigler has posted about some changes coming to Sourceware:

Red Hat has been and continues to be a generous sponsor of the hardware, connectivity, and the very modest employee time it requires. We are glad to report there are zero indications of any change to this commitment. Things are stable, new services are coming online, and users seem to be happy. However, it is always good to think about any future needs.

To protect confidence in the long term future of this hosting service, we have reached out to the Software Freedom Conservancy (SFC) to function as a "fiscal sponsor".

Comments (1 posted)