Hírolvasó

Security updates have been issued by Debian (gzip and xz-utils), Fedora (dhcp and rsync), Mageia (chromium-browser-stable), openSUSE (chromium), SUSE (gzip, openjpeg2, and zabbix), and Ubuntu (klibc).

Steve McIntyre argues that Debian needs to rethink its approach to non-free firmware.

Today, a user with a new laptop from most vendors will struggle to use it at all with our firmware-free Debian installation media. Modern laptops normally don't come with wired ethernet now. There won't be any usable graphics on the laptop's screen. A visually-impaired user won't get any audio prompts. These experiences are not acceptable, by any measure.

Over on the blog for the GNU Guix project, which is a "transactional package manager and an advanced distribution of the GNU system that respects user freedom", the project reflects on its ten-year journey. The post consists of personal accounts from around two dozen contributors about the project, its history, and its community. It’s been ten years today since the very first commit to what was already called Guix—the unimaginative name is a homage to Guile and Nix, which Guix started by blending together. On April 18th, 2012, there was very little to see and no actual "project". The project formed in the following months and became a collective adventure around a shared vision.

Ten years later, it’s amazing to see what more than 600 people achieved, with 94K commits, countless hours of translation, system administration, web design work, and no less than 175 blog posts to share our enthusiasm at each major milestone. It’s been quite a ride!

Version 2.36.0 of the Git source-code management system is out. As usual, the list of new features is long; this GitHub blog post covers some of the highlights:

But this [merge conflict] output can be understandably difficult to interpret. In Git 2.36, --remerge-diff takes a different approach. Instead of showing you the diffs between the merge resolution and each parent simultaneously, --remerge-diff shows you the diff between the file with merge conflicts, and the resolution.

The ftrace and perf subsystems provide visibility into the workings of the kernel; by activating existing tracepoints, interested developers can see what is happening at specific points in the code. As much as kernel developers may resist the notion, though, not all events of interest on a system happen within the kernel. Administrators will often want to look inside user-space processes as well; they would be even happier with a mechanism that allows the simultaneous tracing of events in both the kernel and user space. The user-events subsystem, developed by Beau Belgrave and added during the 5.18 merge window, promises that capability, but users will almost certainly have to wait another cycle to gain access to it.

Security updates have been issued by Debian (abcm2ps and chromium), Fedora (cacti, cacti-spine, and fribidi), and Mageia (crun, docker-containerd, libarchive, mediawiki, and ruby).

The 5.18-rc3 kernel prepatch is out for testing. "It's Sunday afternoon, and you all know what that means. It's time for another release candidate. (Yes, yes, it's also Easter Sunday, but priorities, people!)"

Anybody who might be considering acquiring a "Freedom Phone" might want to have a look at Matthew Garrett's analysis first.

Anyway. We have a company that seems to be combining blockchain and MLM [multi-level marketing], has some opinions about Quantum Entanglement, bases the security of its platform on a set of novel cryptographic primitives that seem to have had no external review, has implemented an API that just hands out personal information without any authentication and an app that appears more than happy to upload all your contact details without telling you first, has failed to update this app to keep up with upstream security updates, and is violating the upstream license.

The Freedom Phone advertises itself as a "Free speech and privacy first focused phone". As documented on the features page, it runs ClearOS, an Android-based OS produced by Clear United (or maybe one of the bewildering array of associated companies, we'll come back to that later). It's advertised as including Signal, but what's shipped is not the version available from the Signal website or any official app store - instead it's this fork called "ClearSignal".

The first thing to note about ClearSignal is that the privacy policy link from that page 404s, which is not a great start. The second thing is that it has a version number of 5.8.14, which is strange because upstream went from 5.8.10 to 5.9.0. The third is that, despite Signal being GPL 3, there's no source code available. So, I grabbed jadx and started looking for differences between ClearSignal and the upstream 5.8.10 release. The results were, uh, surprising.

First up is that they seem to have integrated ACRA, a crash reporting framework. This feels a little odd - in the absence of a privacy policy, it's unclear what information this gathers or how it'll be stored. Having a piece of privacy software automatically uploading information about what you were doing in the event of a crash with no notification other than a toast that appears saying "Crash Report" feels a little dubious.

Next is that Signal (for fairly obvious reasons) warns you if your version is out of date and eventually refuses to work unless you upgrade. ClearSignal has dealt with this problem by, uh, simply removing that code. The MacOS version of the desktop app they provide for download seems to be derived from a release from last September, which for an Electron-based app feels like a pretty terrible idea. Weirdly, for Windows they link to an official binary release from February 2021, and for Linux they tell you how to use the upstream repo properly. I have no idea what's going on here.

They've also added support for network backups of your Signal data. This involves the backups being pushed to an S3 bucket using credentials that are statically available in the app. It's ok, though, each upload has some sort of nominally unique identifier associated with it, so it's not trivial to just download other people's backups. But, uh, where does this identifier come from? It turns out that Clear Center, another of the Clear family of companies, employs a bunch of people to work on a ClearID[1], some sort of decentralised something or other that seems to be based on KERI. There's an overview slide deck here which didn't really answer any of my questions and as far as I can tell this is entirely lacking any sort of peer review, but hey it's only the one thing that stops anyone on the internet being able to grab your Signal backups so how important can it be.

The final thing, though? They've extended Signal's invitation support to encourage users to get others to sign up for Clear United. There's an exposed API endpoint called "get_user_email_by_mobile_number" which does exactly what you'd expect - if you give it a registered phone number, it gives you back the associated email address. This requires no authentication. But it gets better! The API to generate a referral link to send to others sends the name and phone number of everyone in your phone's contact list. There does not appear to be any indication that this is going to happen.

So, from a privacy perspective, going to go with things being some distance from ideal. But what's going on with all these Clear companies anyway? They all seem to be related to Michael Proper, who founded the Clear Foundation in 2009. They are, perhaps unsurprisingly, heavily invested in blockchain stuff, while Clear United also appears to be some sort of multi-level marketing scheme which has a membership agreement that includes the somewhat astonishing claim that:

Specifically, the initial focus of the Association will provide members with supplements and technologies for:

9a. Frequency Evaluation, Scans, Reports;

9b. Remote Frequency Health Tuning through Quantum Entanglement;

9c. General and Customized Frequency Optimizations;

- there's more discussion of this and other weirdness here. Clear Center, meanwhile, has a Chief Physics Officer? I have a lot of questions.

Anyway. We have a company that seems to be combining blockchain and MLM, has some opinions about Quantum Entanglement, bases the security of its platform on a set of novel cryptographic primitives that seem to have had no external review, has implemented an API that just hands out personal information without any authentication and an app that appears more than happy to upload all your contact details without telling you first, has failed to update this app to keep up with upstream security updates, and is violating the upstream license. If this is their idea of "privacy first", I really hate to think what their code looks like when privacy comes further down the list.

[1] Pointed out to me here

comments

Version 9.1 of the GNU coreutils package has been released with lots of small tweaks and improvements. "ls no longer colors files with capabilities by default, as file-based capabilities are very rarely used, and lookup increases processing per file by about 30%. It's best to use getcap [-r] to identify files with capabilities."

Your editor has a certain tendency to accumulate books, to the point that they crowd everything else out of the house. There is a lot to be said for books: a physical book has a user interface that has been optimized over centuries, and one can have a reasonably high degree of certainty that any given book will still work a few decades from now. Neither of those can be said for electronic books, but they do have the advantages of taking less shelf space and being more portable. So electronic books are part of the reading menu, which naturally leads to the search for a free reader for those books; KOReader turns out to be an interesting alternative.

Greg Kroah-Hartman has announced the release of the 5.4.189 and 4.19.238 stable kernels. As usual, they contain important fixes throughout the tree and users should upgrade.

Security updates have been issued by Debian (fribidi and python-django), Fedora (postgresql-jdbc, stargz-snapshotter, and thunderbird), Slackware (git, gzip, and xz), and SUSE (kernel, SDL2, and tomcat).

A large and unexpected opportunity has come my way outside of Netflix that I've decided to try. Netflix has been the best job of my career so far, and I'll miss my colleagues and the culture.
offer letter logo (2014)
flame graphs (2014)
eBPF tools (2014-2019)
PMC analysis (2017)
my pandemic-abandoned
desk (2020); office wall I joined Netflix in 2014, a company at the forefront of cloud computing with an attractive [work culture]. It was the most challenging job among those I interviewed for. On the Netflix Java/Linux/EC2 stack there were no working mixed-mode flame graphs, no production safe dynamic tracer, and no PMCs: All tools I used extensively for advanced performance analysis. How would I do my job? I realized that this was a challenge I was best suited to fix. I could help not only Netflix but all customers of the cloud. Since then I've done just that. I developed the original JVM changes to allow [mixed-mode flame graphs], I pioneered using [eBPF for observability] and helped develop the [front-ends and tools], and I worked with Amazon to get [PMCs enabled] and developed tools to use them. Low-level performance analysis is now possible in the cloud, and with it I've helped Netflix save a very large amount of money, mostly from service teams using flame graphs. There is also now a flourishing industry of observability products based on my work. Apart from developing tools, much of my time has been spent helping teams with performance issues and evaluations. The Netflix stack is more diverse than I was expecting, and is explained in detail in the [Netflix tech blog]: The production cloud is AWS EC2, Ubuntu Linux, Intel x86, mostly Java with some Node.js (and other languages), microservices, Cassandra (storage), EVCache (caching), Spinnaker (deployment), Titus (containers), Apache Spark (analytics), Atlas (monitoring), FlameCommander (profiling), and at least a dozen more applications and workloads (but no 3rd party agents in the BaseAMI). The Netflix CDN runs FreeBSD and NGINX (not Linux: I published a Netflix-approved [footnote] in my last book to explain why). This diverse environment has always provided me with interesting things to explore, to understand, analyze, debug, and improve. I've also used and helped develop many other technologies for debugging, primarily perf, Ftrace, eBPF (bcc and bpftrace), PMCs, MSRs, Intel vTune, and of course, [flame graphs] and [heat maps]. Martin Spier and I also created [Flame Scope] while at Netflix, to analyze perturbations and variation in profiles. I've also had the chance to do other types of work. For 18 months I joined the [CORE SRE team] rotation, and was the primary contact for Netflix outages. It was difficult and fascinating work. I've also created internal training materials and classes, apart from my books. I've worked with awesome colleagues not just in cloud engineering, but also in open connect, studio, DVD, NTech, talent, immigration, HR, PR/comms, legal, and most recently ANZ content. Last time I quit a job, I wanted to share publicly the reasons why I left, but I ultimately did not. I've since been asked many times why I resigned that job (not unlike [The Prisoner]) along with much speculation (none true). I wouldn't want the same thing happening here, and having people wondering if something bad happened at Netflix that caused me to leave: I had a great time and It's a great company! I'm thankful for the opportunities and support I've had, especially from my former managers [Coburn] and [Ed]. I'm also grateful for the support for my work by other companies, technical communities, social communities (Twitter, HackerNews), conference organizers, and all who have liked my work, developed it further, and shared it with others. Thank you. I hope my last two books, [Systems Performance 2nd Ed] and [BPF Performance Tools] serve Netflix well in my absence and everyone else who reads them. I'll still be posting here in my next job. More on that soon... [work culture]: /blog/2017-11-13/brilliant-jerks.html [work culture2]: https://www.slideshare.net/kevibak/netflix-culture-deck-77978007 [Systems Performance 2nd Ed]: /systems-performance-2nd-edition-book.html [BPF Performance Tools]: /bpf-performance-tools-book.html [mixed-mode flame graphs]: http://techblog.netflix.com/2015/07/java-in-flames.html [eBPF for observability]: /blog/2015-05-15/ebpf-one-small-step.html [front-ends and tools]: /Perf/bcc_tracing_tools.png [front-ends and tools2]: /blog/2019-01-01/learn-ebpf-tracing.html [PMCs enabled]: /blog/2017-05-04/the-pmcs-of-ec2.html [CORE SRE team]: /blog/2016-05-04/srecon2016-perf-checklists-for-sres.html [footnote]: /blog/images/2022/netflixcdn.png [Coburn]: https://www.linkedin.com/in/coburnw/ [Ed]: https://www.linkedin.com/in/edwhunter/ [Netflix tech blog]: https://netflixtechblog.com/ [Why Don't You Use ...]: /blog/2022-03-19/why-dont-you-use.html [The Prisoner]: https://en.wikipedia.org/wiki/The_Prisoner [flame graphs]: /flamegraphs.html [heat maps]: /heatmaps.html [Flame Scope]: https://netflixtechblog.com/netflix-flamescope-a57ca19d47bb

Support for developing in the Rust language is headed toward the kernel, though just when it will land in the mainline is yet to be determined. The Rust patches are progressing, though, and beginning to attract attention from beyond the kernel community. When two languages — and two different development communities — come together, the result can be a sort of cultural clash. Some early signs of that are appearing with regard to Rust in the kernel; if the resulting impedance mismatches can be worked out, the result could be a better development environment for everybody involved.

Security updates have been issued by Debian (lrzip), Fedora (community-mysql, expat, firefox, kernel, mingw-openjpeg2, nss, and openjpeg2), Mageia (ceph, subversion, and webkit2), openSUSE (chromium), Oracle (httpd:2.4), Red Hat (kpatch-patch), Slackware (ruby), SUSE (kernel and netatalk), and Ubuntu (gzip and xz-utils).

SUSE has begun to discuss its plans for the next version of SUSE Linux Enterprise on the openSUSE lists. It appears that there will be some significant changes.

Intending to do radical changes (regarding technology- but also design-wise) we choose "Adaptable Linux Platform" or short "ALP" as codename for that next generation. This indicates already that some things will be quite different than a "mere "SLE 15++ would be ;) [...]

Another important point is that we intend to split what was a more generic, everything is closely intertwined into two parts: One smaller hardware enabling piece, a kind of "host OS", and the and the layer providing and supporting applications, which will be container (and VM) based.

Claudio Jeker (claudio@) has just announced the release of OpenBGPD 7.3. He writes:

We have released OpenBGPD 7.3, which will be arriving in the OpenBGPD directory of your local OpenBSD mirror soon. This release includes the following changes to the previous release: * Macro expansion in the config file is improved. It is now possible to expand 'set large-community $myAS:$location:$transit'. * Add initial FIB support for Linux. Routes can be added and removed. Nexthop tracking and dynamic interface detection are not yet implemented. * Major refactoring in the RIB codebase to add multipath support in an upcoming release. OpenBGPD-portable is known to compile and run on FreeBSD, and the Linux distributions Alpine, Debian, Fedora, RHEL/CentOS and Ubuntu. It is our hope that packagers take interest and help adapt OpenBGPD-portable to more distributions. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.

The LWN.net Weekly Edition for April 14, 2022 is available.

Using strings with contents that are supplied by users can be fraught with peril; SQL injection is a well-known technique for attacking applications that stems from that, for example. Generally, database frameworks and libraries provide mechanisms that seek to lead programmers toward doing The Right Thing, with parameterized queries and the like, but they cannot enforce that—inventive developers will seemingly always find ways to inject user input into places it should not go. A recently adopted Python Enhancement Proposal (PEP) provides a way to enforce the use of strings that are untainted by user input, but it uses the optional typing features of the language to do so; those wanting to take advantage of it will need to be running a type-checking program.