Post by @hipsterelectron@circumstances.run

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

having fun looking inside btrfs-progs. we are finding truly historic concentrations of linux in this filesystem

14 Replies

5 Boosts

This comment is unavailable — it may have been deleted or is not visible to you.

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

lmao they make sure to put the siphash license first even though siphash is djbslop and doesn't even do what it says it does and systemd's single hash table isn't exposed to the internet and isn't latency-dependent in the first place

of course poettering will immediately jump to use the slow and broken djb hash function but refuses to accept a libc protocol that ensures he can't dlopen() a backdoored xz-utils like he did in 2023

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

oh that's so cute! pacman lets you declare depends totally separately from the actual dependencies. so there's just no relationship between declared and actual deps at all

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

lmfao look at that optdepends line:

'tpm2-tss: unlocking LUKS2 volumes with TPM2'

despite obviously including tpm2-tss in makedepends

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

ooo iocost is cute

The qos and model values are calculated based on benchmarks collected on the iocost-benchmark[1] project and turned into a set of solutions that go from most to least isolated. Isolation allows the system to remain responsive in face of high I/O load.

so they have a specially-calibrated timing attack made just for you: the user

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

omfg YES it's a facebook project https://github.com/facebookexperimental/resctl-demo/tree/main/resctl-bench/doc

Comprehensive resource control involves the whole system - kernel subsystems such as cgroup2, memory management, file system and block layer, userspace system components and even the SSD.

https://facebookmicrosites.github.io/resctl-demo-website/docs/

The Meta resource control demo, or resctl-demo, is an interactive tool that demonstrates resource control in action. It uses workload simulators that mimic common resource conflicts, and allows you to configure and test different strategies and scenarios for reducing or eliminating resource contention. Because the demo simulates conflicts typically found in large server deployments, the strategies are directly applicable to real-world server fleets.

it's like huggingface for container escapes!

Resource Control Demo Overview | Resource Control Demo

We all want our workloads to utilize our machines as much as possible.

GitHub

resctl-demo/resctl-bench/doc at main · facebookexperimental/resctl-demo

Demonstrate and benchmark various features of Linux resource control in a self-contained package. - facebookexperimental/resctl-demo

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

ugh scary!!!!!!

While resctl-demo concentrates on server scenarios, the resource control strategies are generic and versatile, allowing direct translation to the desktop and other personal device use cases. For example, If we can protect the latency profile of a web server under resource contention, we can protect your web browser from stalling while the rest of the system is working on an all-consuming build job.

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

OMFG LMAO!!!!! https://facebookmicrosites.github.io/resctl-demo-website/docs/get-started/

Installable USB flash drive image
Want to test on your machine?

THIS IS SO BRAZEN

Using the Premade System Images | Resource Control Demo

Comprehensive resource control has many requirements, some of which can be

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

oh also there's this weird web site that mentions "TPM simulators" https://fobnail.3mdeb.com/tpm-simulators/

It is possible to use TPM simulators instead of real TPMs for testing purposes only. Two simulators were tested and are known to be working with Fobnail: Microsoft's and IBM's.

literally only from the two most evil corps ever. this site keeps mentioning trying to use seL4 as a backdoor somehow but i don't think they're gonna succeed https://github.com/seL4/seL4/issues/832 critical support to seL4

GitHub

Using seL4 as a secure bootloader · Issue #832 · seL4/seL4

Hello We are considering using seL4 as a secure bootloader in the Fobnail project We'd like to use it as mini OS that would communicate with a device called Fobnail Token in order verify integrity ...

Using TPM simulators - Fobnail Documentation

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

oh yeah finally btrfs https://github.com/kdave/btrfs-progs/blob/devel/.github/workflows/pull-request.yml

# - name: Musl build
# run: sudo docker run kdave/ci-musl-x86_64 ./test-build $GITHUB_REF_NAME --disable-documentation --disable-backtrace --disable-libudev

they very specifically comment out a musl libc shard on their pull request CI lmao

GitHub

btrfs-progs/.github/workflows/pull-request.yml at devel · kdave/btrfs-progs

Development of userspace BTRFS tools. Contribute to kdave/btrfs-progs development by creating an account on GitHub.

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

so then i find the service that github uses to generate git archives https://github.blog/news-insights/the-library/meet-nodeload-the-new-download-server/

I recently launched the first GitHub node.js project: nodeload. Nodeload replaces the ruby git archive download server. Basically, any time you download a tarball or zip file of any repository branch or tag, you’re going through nodeload.

i.e. this is the project that spack maintainers noticed was literally serving the same release tarballs but generating different checksums for different users

This is a challenging issue because we can’t just store downloads anywhere.

your entire company revolves around serving git at scale and you can't figure out how to cache "downloads"

Either we pre-build archives for every single branch and tag after every repo commit, or we generate each one fresh. Of course, there is a healthy hot cache of built archives to deal with popular requests.

this is why git is completely fucked. it's incredibly nontrivial to convert back and forth from the object database that actually stores file content to the linear directed graph which sometimes just starts crying if it can't find an intermediate ref it needs and you need to start git fetch <commit-id> by hand

this is literally the entire fucking purpose of a filesystem tree with support for snapshots. git being full of shit is is completely nonsensical

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

In the old system, requests to download an archive would create a Resque job. This Resque job actually runs a git archive command on the archive server, pulling data from one of the file servers. Then, the original request sends you to a small ruby Sinatra app to wait for the job. It would essentially just check for the existence of a memcache flag before redirecting to the final download address.

i could write a perl script that did all of this without executing a subprocess. @astraleureka could do it much faster than me. death to ruby on rails apps that max out at 4 requests per second

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

This is a pragmatic solution when time and manpower are your constraints.

uh oh real man incoming

I saw it as a great opportunity for Node.js.

opposite of correct

This is a simple feature that doesn’t depend on much of the site.

the "site" that literally serves git tarballs eat hot chip and lie??? that webbed site????

In fact, the extra moving parts make it seem more complicated than it really is.

yes the three separate services for interfacing with git data are indeed more complicated than necessary

The very nature of serving fresh git archives highlights the strengths of an event driven environment like Node.js, and the weaknesses of a blocking environment like Ruby.

wildly incorrect. ruby at least has a legitimate FFI story so you can call out to c code to interface with git for you. also "blocking" is not a feature of a language, that's a function of a parallelism API

However, I ran into a big roadblock right away: How do I even get the right file server for an archive? How can I authenticate whether a user has access to a private repo?

yes. of course. obviously github would have absolutely no utilities or standard processes used to validate access controls. obviously that's a problem you would have to think about and solve yourself

Rather than reimplementing internal application logic, I went with a simple JSON API call.

wait

From there, nodeload spawns a git archive process, and redirects the user when it’s finished.

so you moved functionality that used to live in the file server.....into a node.js subprocess call. ok

d@nny disc@

@hipsterelectron@circumstances.run 2 days ago

This is just the first iteration of the archive server.

it is clearly the second iteration after the ruby one

My ultimate goal is to get an address like “/mxcl/homebrew/tarball/master” to serve archives without any redirects.

that's not a technical problem, that's an organizational one. and it's a shit fucking excuse for the "redirects" that remain in the endpoint. to wit: https://amass.energy/terminal-outputs/wget-btrfs-tpm-hsts.txt

https://amass.energy/terminal-outputs/wget-btrfs-tpm-hsts.txt

Federation Bot

@Federation_Bot 2 days ago

https://hstspreload.org/#preloading

Since sites tell the browser that they support HSTS when the browser visits, the browser cannot know a site's HSTS policy before the user has visited the site for the first time. As a result, the browser can not require HTTPS until after the first time it has connected to the site, possibly leaving the user unprotected. After this first load, the web browser has the site's HSTS policy and is able to require HTTPS for all subsequent loads.

HSTS Preload List Submission