Simon Richter

We're restarting #HillHacks this year!

Since we don't have the momentum of a yearly event yet (but want to get there again) this might be a bit smaller than previous editions, but this is still an excellent opportunity to meet people in Northwestern India.

This is an "unconference", where the talk schedule is decided mostly by the participants who are there. If you have an interesting project and would like to present it, a digital rights topic you want to talk about, or are interested in what other people are doing, you are more than welcome to join us.

Other coordination before the even happens mostly on the mailing list, which can be found at https://hillhacks.in/mailinglist/ . There are plans for a school program, for an open source hackathon and for some #OpenStreetMap mapping, and I expect that more ideas will come up in the coming weeks as well.

The main event website is at https://hillhacks.in/

I should put the TalosII into a colo facility.

100Gbps is probably too expensive, but it would be cool to see if it can keep up.

Warm hier, aber waren Sie schon mal in meinem Serverraum?

Oh cool, updating the work laptop broke SCIM.

What does one use these days for

- Japanese text input
- ideally, Anthy tables
- needs to work with QT, GTK and XIM

?

The rain is so loud I can't hear the CPU fans anymore.

I should add a public graph "Inbox size" to my personal homepage.

Running my tar parser on all the tar files in the Debian archive, to find cases I haven't handled yet. It's not done yet, but so far I've collected

2 num_read == sizeof s->buffer
3 symlink_size < LEN_LINK_TARGET
3243 unexpected character in octal
780 unhandled file type
17 unused tar header has data
8 value_len < sizeof s->filename

Basically, I've plastered a bunch of checks all over the code that are like assert(), but remain in Release code. All of these are hard errors so far, and I will need to add more checks and also make the parser less strict in places where it is overly so.

"num_read == sizeof s->buffer" means that the tar file is not a multiple of 512 bytes in size.

"symlink_size < LEN_LINK_TARGET" means that the link target field is used completely and not NUL terminated. That's probably legal, but I'm amazed someone is running into this. Also, I suspect there is an encoding for even longer symlinks.

"unexpected character in octal" seems to be mostly octal numbers that are right-justified in the field with spaces, which should be legal.

"unhandled file type" refers to the file type marker inside the archive -- I handle directories, files, symlinks and extension headers for the whole archive and for individual files. So that's a TODO item.

"unused tar header has data" happens when the first byte of the filename is NUL, but there are non-NUL bytes in that block. Need to investigate what these are.

"value_len < sizeof s->filename" means that there is a long file name with more than 255 bytes.

Getting the full statistics will take a while, and then I need to fix the program and re-run everything.

Time to order the good biryani and kebap for the fourth time in a week, I guess.

Spending the rest of my "lunch" break on improving society somewhat.

Doing a small prerelease of my tarball validation tool:

https://psi5.com/~geier/tmp/git-treeof-0.0.20260411.tar.gz

The basic idea is that you can feed it a tar file, and it tells you What Would Git Do™, i.e. it is equivalent to

git init
tar -x
git add -A
git commit -m 'irrelevant'
git rev-parse HEAD^{tree}"

but it does not require a local filesystem, git installation or anything -- it's an isolated program that allocates 64 MB of RAM (that should be enough for everyone) and then activates strict SECCOMP mode before looking at any input data.

The main thing I'm unhappy with is the name, in principle it would be easy to extend this to a tar diff tool, and I also want to add some features like "if you supply the commit object via a separate channel, that can be verified too", so it's not strictly "give me the tree ID for this tarball" anymore.

Also, if you have use cases where it doesn't work, I'd like to collect these as well. I already know about submodules, and I also want to have a mode where I also parse gitignore files.

[computing.png]

Large parts of my timeline are now debating whether resisting the introduction of the "birthdate" column in the user database is part of a fascist takeover and should be resisted.

It is a distraction from the fascist takeover. The walls will come up somewhere else.

If it's not maintained by someone trusted by the government (i.e. an entrenched corporation), it *is* just a database column.

Debating it wastes a lot of energy we would need elsewhere: there is a lot of pending legislation that everyone now treats as if it had already passed, and so the only thing left to do is take a heroic last stand, to at least not be complicit.

We're not at this point yet. There are still things that can be done, but that means organizing against big tech, which means both political opposition, and building out alternate infrastructure if you're too exposed for direct political action.

Even debating whether the people involved are willing collaborators or just politically ignorant is a waste of resources at this point. Their motivations do not matter, they aren't allies either way.

These people aren't in a position to get the database column they created recognized as "trustworthy." Their act was one of symbolic bootlicking, so publicly opposing it likewise only has symbolic meaning.

The actual attestation framework that we will get is most likely some "login with Microsoft/Google/Apple/Canonical/Facebook¹" thing that integrates into the login process and requires no trustworthy components on the user's machine because all it does is forward a token received from one online service to another, and not presenting such a token locks you out from a lot of services, because the services themselves are at risk if they do not require such a token.

*That* is where this is headed, and *that* is what we need to oppose.

Of course open source will be left with local-only accounts. These just won't be able to connect to online fora.

¹ involvement of Facebook still unclear — no good reason for Microsoft and Google to let them have a seat at the table, really. Canonical will be there in the beginning to make it a bit less off-putting to Linux users, but at least their identity management will be merged into Google at some point.

@regehr I think this should be a kernel feature.

There is a scheduling class, SCHED_BATCH, with low priority and very long (1.5s) slices. I think this could be improved even further, by essentially making the slices infinite, yielding CPU in execve() at the point where the process image is smallest, and on memory pressure, swap out the other batch class processes, smallest first. When there are free CPUs, resume the largest batch process.

Users would just make -j with no limit.

What I wrote elsewhere about the California age verification law:

If this is meant as a security system, having it default to "fail-open" is insufficient.

The Unix APIs don't have age information. The systemd project has graciously decided that they are willing participants in this, and have accepted a patch to add a dbus API, and subsequently refused to revert that commit. So, dbus API it is.

If I start "env -u DBUS_SESSION_BUS_ADDRESS firefox", does that mean that the browser must pretend that I'm in elementary school and only present "age-appropriate" material, or will it default to "full access"?

Likewise, will curl/wget be required to implement a dbus query? Do we mandate that build chroots now become full containers with a running dbus instance that has an age information service connected, so they can access the entire Internet, or do we allow bypassing the filter by doing a recursive curl/wget download of an URL and then displaying it locally?

The bits that were added to systemd (and which we cannot remove without creating evidence that we mean to disregard the California legislation) are not sufficient for the stated goal, so we must expect that further enforcement infrastructure becomes mandatory.

This entire law assumes that people are using managed infrastructure exclusively, i.e. with an Apple or Microsoft cloud account, and accessing cloud based services.

There is simply no niche for user-managed infrastructure here, because it circumvents all these enforcement mechanisms. I don't even see it being legal for a sixteen year old to be root on their own computer, like it was for me when I started out, because that would give them access to age-inappropriate material, and we cannot have that.

I fully expect that we will soon reach a point where we have to decide between following US or EU law, with no option to remain compliant with both. A requirement to include the user's age bracket in browser queries is already likely to be in violation of EU data protection legislation.

(1/2)