September 2023 - wlug - list.wlug.org.nz

Weta Digital’s Technology Division Sold To US Firm
by Lawrence D'Oliveiro 01 Aug '25

01 Aug '25

Let me see if I understand this article <https://www.nzherald.co.nz/business/sir-peter-jackson-to-sell-weta-digital-…> correctly: the part of Weta Digital that used to develop the in-house 3D graphics/effects tools that they use in all those movies is being sold to US-based Unity Software. The part that is left will be called “WetaFX”, and will become a customer of Unity for the use of those tools, no longer doing its own development in-house. By the way, I’ve been looking at the Unity site <https://unity.com/>, and it looks like all their products are rentware (subscription-based).

1 2

List Of IPTV Resources
by Lawrence D'Oliveiro 22 Sep '24

22 Sep '24

This user <https://github.com/iptv-org> just popped up in my GitHub feed. One repo <https://github.com/iptv-org/iptv> claims to be a list of links to over 8000 streaming TV channels from nations all over the world, while the other is a list of tools*, providers and other resources. Do be aware it’s a bit of a mixed bag: yes, there are legitimate channels (no encryption so far that I have noticed), but also some dubious-looking links. *Oddly, FFmpeg and youtube-dl aren’t in the list.

2 5

Enabling Case-Insensitive Filenames On Linux
by Lawrence D'Oliveiro 06 Feb '24

06 Feb '24

The ext4 filesystem has had the “casefold” option for a while now <https://lwn.net/Articles/784041/>. This allows you to specify, when you initialize a new filesystem, that you want file/directory names to be treated as case-insensitive. At the same time, you have to specify that the filenames are to be interpreted as UTF-8 encoding; normally the kernel doesn’t care, it only singles out ASCII slash and NUL bytes for special interpretation, and simply passes through any other byte values in the names. I was able to create such a filesystem, but I wasn’t able to mount it in my last-upgraded-just-a-few-days-ago Debian Unstable setup. When I try, it fails, and in the dmesg log I see Filesystem with casefold feature cannot be mounted without CONFIG_UNICODE Turns out the Debian 5.10 kernel has not been built with this CONFIG_UNICODE option enabled. However, this situation looks set to change shortly, according to <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985689>.

2 3

Lichee Pi 4A: Serious RISC-V Desktop Computing
by Lawrence D'Oliveiro 02 Oct '23

02 Oct '23

This video on Christopher Barnatt’s “Explaining Computers” channel <https://www.youtube.com/watch?v=1apoFXZ9ad8> just came across my feed. It’s an unboxing and initial review of a Sipeed Lichee Pi 4A, a RISC-V-based rival to the Raspberry Pi. Seems the RISC-V desktop ecosystem is approaching maturity rapidly; he was able to boot up the preinstalled Debian system and run included apps like LibreOffice, GIMP and Chromium just fine (albeit with some audio/video performance hiccups in the last one). He says in the video that he was going to spend a week trying to do all his computing on RISC-V machines, with a report on the results due out on Sunday UK time (I suppose Monday our time).

1 2

Vulnerabilities In Exim MTA
by Lawrence D'Oliveiro 30 Sep '23

30 Sep '23

This article <https://arstechnica.com/security/2023/09/critical-vulnerabilities-in-exim-t…> reports on six different security vulnerabilities in the Exim mail transfer agent (MTA), with uncertain status on their fixes. It seems like patches for three of them are available, but only in a private repo, with no clarification of who has access to this repo. Seems like there has been poor communication between Zero Day Initiative (the group that discovered the vulnerabilities) and the Exim project, going back over a year, on these issues. An MTA is the piece of software that receives mail from other machines for users on the local machine (or on other, related machines that it is responsible for), and also forwards mail sent from local users, destined for users on other machines. Exim is the default MTA you get on a Debian installation, if you don’t choose something else (e.g. Postfix). Not sure about Debian derivatives.

1 0

Raspberry Pi 5
by Lawrence D'Oliveiro 28 Sep '23

28 Sep '23

Just heard about the new-generation Raspberry Pi. Here’s a video about a prerelease unit <https://www.youtube.com/watch?v=9hYfQ7bRgZg> which I haven’t even watched yet.

1 0

Linux Interop Is Maturing Fast… Thanks To A Games Console
by Lawrence D'Oliveiro 28 Sep '23

28 Sep '23

Interesting report <https://www.theregister.com/2023/09/27/osseu_steam_os_3/> from the recent European Open Source Summit, about the work being done at Valve and others to improve the ability of the Linux-based Steam Deck handheld console to play games written for Microsoft Windows. And not just to have them playable, but to have them run well, with performance comparable to Microsoft Windows machines. The result, so far, is thousands of games that are usable on the Steam Deck. As a proportion of the total number of games, if I interpret the numbers on the protondb.com home page correctly, that’s 60%—or at least, 60% of games tried by those who submitted reports to the compatibility database. Which is a pretty respectable number. Not enough for world domination yet, but enough to keep the Steam Deck selling, by all accounts. Seems like issues with graphics APIs are not the main problem any more. Now there is a new one: thread/process communication/synchronization primitives. Windows doesn’t use the POSIX/Linux ones, it has a whole set of its own ones, with their own peculiar behaviours. The WINE folks have made a valiant effort to map these onto Linux APIs, but their compatibility layer cannot avoid becoming a performance bottleneck, and it appears this has become a problem for a lot of games. So now there are proposals to add new features to the Linux kernel specifically to make it easier to emulate these idiosyncratic Windows APIs.

1 0

Google quietly corrects previously submitted disclosure for critical webp 0-day
by Peter Reutemann 27 Sep '23

27 Sep '23

'Google has quietly resubmitted a disclosure of a critical code-execution vulnerability affecting thousands of individual apps and software frameworks after its previous submission left readers with the mistaken impression that the threat affected only the Chrome browser. The vulnerability originates in the libwebp code library, which Google created in 2010 for rendering images in webp, a then new format that resulted in files that were up to 26 percent smaller as compared to PNG images. Libwebp is incorporated into just about every app, operating system, or other code library that renders webp images, most notably the Electron framework used in Chrome and many other apps that run on both desktop and mobile devices. Two weeks ago, Google issued a security advisory for what it said was a heap buffer overflow in WebP in Chrome. Google’s formal description, tracked as CVE-2023-4863, scoped the affected vendor as “Google” and the software affected as “Chrome,” even though any code that used libwebp was vulnerable. Critics warned that Google’s failure to note that thousands of other pieces of code were also vulnerable would result in unnecessary delays in patching the vulnerability, which allows attackers to execute malicious code when users do nothing more than view a booby-trapped webp image. On Monday, Google submitted a new disclosure that’s tracked as CVE-2023-5129. The new entry correctly lists libwebp as the affected vendor and affected software. It also bumps up the severity rating of the vulnerability, from 8.8 out of a possible 10 to 10.' -- source: https://arstechnica.com/security/2023/09/google-quietly-corrects-previously… Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

GPUs From All Major Suppliers Are Vulnerable To New Pixel-Stealing Attack
by Peter Reutemann 27 Sep '23

27 Sep '23

'Ars Technica: GPUs from all six of the major suppliers are vulnerable to a newly discovered attack that allows malicious websites to read the usernames, passwords, and other sensitive visual data displayed by other websites, researchers have demonstrated in a paper (PDF) published Tuesday. The cross-origin attack allows a malicious website from one domain -- say, example.com -- to effectively read the pixels displayed by a website from example.org, or another different domain. Attackers can then reconstruct them in a way that allows them to view the words or images displayed by the latter site. This leakage violates a critical security principle that forms one of the most fundamental security boundaries safeguarding the Internet. Known as the same origin policy, it mandates that content hosted on one website domain be isolated from all other website domains. [...] GPU.zip works only when the malicious attacker website is loaded into Chrome or Edge. The reason: For the attack to work, the browser must: 1. allow cross-origin iframes to be loaded with cookies 2. allow rendering SVG filters on iframes and 3. delegate rendering tasks to the GPU For now, GPU.zip is more of a curiosity than a real threat, but that assumes that Web developers properly restrict sensitive pages from being embedded by cross-origin websites. End users who want to check if a page has such restrictions in place should look for the X-Frame-Options or Content-Security-Policy headers in the source. "This is impactful research on how hardware works," a Google representative said in a statement. "Widely adopted headers can prevent sites from being embedded, which prevents this attack, and sites using the default SameSite=Lax cookie behavior receive significant mitigation against personalized data being leaked. These protections, along with the difficulty and time required to exploit this behavior, significantly mitigate the threat to everyday users. We are in communication and are actively engaging with the reporting researchers. We are always looking to further improve protections for Chrome users." An Intel representative, meanwhile, said that the chipmaker has "assessed the researcher findings that were provided and determined the root cause is not in our GPUs but in third-party software." A Qualcomm representative said "the issue isn't in our threat model as it more directly affects the browser and can be resolved by the browser application if warranted, so no changes are currently planned." Apple, Nvidia, AMD, and ARM didn't comment on the findings. ' -- source: https://it.slashdot.org/story/23/09/26/2031222 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0

Linux's Multi-Grain Timestamps Short-Lived: Removed From The Kernel After A Few Weeks
by Peter Reutemann 26 Sep '23

26 Sep '23

'Phoronix: One of the new features merged for the Linux 6.6 kernel was multi-grained timestamps for the VFS layer and wiring it up for the EXT4, Btrfs, XFS, and Tmpfs file-systems. This alternative though to coarse-grained timestamps ended up exposing some problems and this week ahead of Linux 6.6-rc3, the feature has been stripped entirely from the kernel. Multi-grain timestamps were intended for addressing cases where the current coarse-grained timestamps can be ineffective for updating creation/modification times with a lot of I/O potentially happening within the once per jiffy timestamp... Multi-grained timestamps though were only to be selectively enabled to avoid the performance overhead. Christian Brauner of Microsoft who originally submitted the feature for Linux 6.6 went ahead and submitted the pull request, which has already been honored, for dropping the short-lived kernel feature... "As there are multiple solutions discussed the honest thing to do here is not to fix this up or disable it but to cleanly revert. The general infrastructure will probably come back but there is no reason to keep this code in mainline." ' -- source: https://linux.slashdot.org/story/23/09/25/009244 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, Hamilton, NZ Mobile +64 22 190 2375 https://www.cs.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

1 0