btoo

FAQ on the xz-utils backdoor (CVE-2024-3094)

This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.

Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.

Background

Range Types (`T[X:Y]`) for TypeScript

A Range Type is a type that produces a new tuple or array type that derives from T by dropping the excess ordered elements of T outside of the range starting at offset X (inclusive) through offset Y (exclusive).

A Range Type is denoted using a : operator in what would otherwise be an Indexed Access Type:

type T = [1, 2, 3][0:2];

any: magic, ill-behaved type that acts like a combination of never (the proper [bottom type]) and unknown (the proper [top type])
- Anything except never is assignable to any, and any is assignable to anything at all.
- Identities: any & AnyTypeExpression = any, any | AnyTypeExpression = any
- Key TypeScript feature that allows for [gradual typing].
unknown: proper, well-behaved [top type]
- Anything at all is assignable to unknown. unknown is only assignable to itself (unknown) and any.
- Identities: unknown & AnyTypeExpression = AnyTypeExpression, unknown | AnyTypeExpression = unknown

Prefer over any whenever possible. Anywhere in well-typed code you're tempted to use any, you probably want unknown.

The following section is not part of monet.js documentation, but I think it's worth showing how we can compose readers using fp-ts.

Reader composition

Let's say we have the following piece of code:

interface Dependencies {
  logger: { log: (message: string) => void }
 env: 'development' | 'production'

A compile-time 4-Bit Virtual Machine implemented in TypeScript's type system. Capable of running a sample 'FizzBuzz' program.

Syntax emits zero JavaScript.

type RESULT = VM<
  [
    ["push", N_1],         // 1
    ["push", False],       // 2
 ["peek", _], // 3

Does event delegation actually improve performance?

Event delegation works by attaching a single event listener to a parent element to catch events bubbling up from the children. Many people believe this is more performant than attaching event listeners to each child. I am not convinced this is always true.

Let's start with a common example of event delegation. Here we have a list of elements:

<ul id="item-list">
  <li data-cost="12">Item 1</li>
  <li data-cost="18">Item 2</li>
  <li data-cost="6">Item 3</li>
 ...

	/// Create an ``ImmersiveSpaceState`` in your view, wrap it with `@State` and modify your view content with ``immersiveSpaceHelper()``.
	/// Example:
	/// ```swift
	/// struct MyView: View {
	/// @State
	/// var immersiveSpaceState = ImmersiveSpaceState(id: "my-immersive-space-id")
	///
	/// var body: some View {
	/// Toggle("Show/Hide Immersive Space", isOn: $immersiveSpaceState.show)
	/// .immersiveSpaceHelper($immersiveSpaceState)

	type TastyFruit = { fruit: 'blueberry' \| 'raspberry' } & { portion: 3 \| 5 \| 7 \| 11 } & { tasty: true };

	type SomeTimesTasty = { fruit: 'orange' \| 'banana' } & { portion: 1 \| 2 } & { tasty: boolean };

	type NastyFruit = { fruit: 'lemon' } & { portion?: 1 } & { tasty: false };

	type Fruit = TastyFruit \| SomeTimesTasty \| NastyFruit;

	const numberOfUniqueInstances = (2 * 4 * 1) + (2 * 2 * 2) + (1 * 2 * 1);

	// babel.config.js
	module.exports = {
	"presets": [
	"module:metro-react-native-babel-preset",
	],
	"plugins": [
	["module-resolver", {
	"root": ["./src"],
	"extensions": [".js", ".ts", ".tsx", ".ios.js", ".android.js"]
	}],

	// The two main components are the interfaces
	// Generic<T, Context> and GenericArg<"identifier">

	// Generic basically structurally replaces types in T that are GenericArg<S>
	// for some `S extends keyof Context` with `Context[S]`
	// See the test cases for specific uses.

	// ====== TESTING
	// Pass through for trivial types
	type Test00 = Generic<number>;