To answer your question:

> Does Debian already provide signature on .deb files (that is, provide a manifest of their hashes and and sign each)?

Yes it does. If you look at https://ftp.debian.org/debian/dists/trixie/InRelease it's a PGP-signed file containing a list of files and their hashes. Each of those files (eg https://ftp.debian.org/debian/dists/trixie/main/binary-amd64...) then contains a list of .deb files along with their shasums. In other words, a Debian repo is a set of deb files, metadata files with their hashes, index files with hashes of the metadata files, and PGP signatures for the indexes, so the whole chain can be verified.

This means that anyone can set up a deb mirror by (essentially, there's some extra steps) copying that entire structure and the integrity is guaranteed because only the upstream admins can sign the metadata.

That's exactly where I keep getting caught. I've looked at in-toto a number of times, and each time I've been left wondering "how is this better than a signed list of hashes?".

Which I suppose is what in-toto is at its core, but it's taken me a long time and lots of reading to get to that point, and I'm not seeing the advantages of it (except it being a standard, OK, fair enough).

I must be missing something.

I assume it is meant to not only have hashes of the final output, but also securely record all steps done by the right people and the right inputs during building of the software. But this solves the wrong^1 problems while still leaving the door open for malware. Reproducible builds are the right step forward if you actually care about security of free software ecosystem.

1. I guess this depend on your position. In the context of remote attestation, I think this is also even dangerous / evil.

> In the context of remote attestation, I think this is also even dangerous / evil.

It's cool until it becomes enforced and we no longer hold the keys to our own hardware; bwim the ability to determine which key signers are to be trusted. But I don't think standing in the way of attestation tech is a fruitful tactic - much better to fight for hardware/key control.

The website / service you want to use will not accept your key, but only the key from the organization that makes sure that your software does not make it possible to skip the ads. So I think the only chance to avoid this is to reject such concepts completely from the beginning.

You can always build/compile your own software, having the local 'key' is the ability to do so. I'm not sure what else is implied - how will an external service / website enforce this?

Via remote attestation.

nginx (2004, ok, 22 years), ClickHouse (2016)

That data is in fact made publicly available by Network Rail: https://wiki.openraildata.com/index.php/TD

though interpreting it isn't the easiest thing in the world...

That is fair - though at least they've well defined their standard. It'll be easier than trying to parse that data out of HTML with regexes at least.

It's not that unusual to have an interim CEO hold the reins (read: sign anything that needs the CEO's signature) while a permanent one is found.

That's not what the comment you're responding to is about.

In fact, uv's docs half-suggest this:

> With uv, it turns out that it's often faster to omit pre-built wheels from the cache (and instead re-download them from the registry on each run). On the other hand, caching wheels that are built from source tends to be worthwhile, since the wheel building process can be expensive, especially for extension modules.

https://docs.astral.sh/uv/concepts/cache/#caching-in-continu...

In my experience, the remote shell weirdness is usually because the remote shell doesn’t recognise ghostty’s TERM=xterm-ghostty value. Fixed by either copying over a terminfo with it in, or setting TERM=xterm-256color before ssh’ing: https://ghostty.org/docs/help/terminfo

The terminfo database is one of those thankless xkcd dependencies. In this case, it's been thanklessly maintained since forever by Thomas Dickey.

https://xkcd.com/2347/

Site appears to be hugged to death, repo is: https://github.com/angristan/MacThrottle

Oops, I fixed it, I have not very important Cloudflare Workers in front of the blog (which is on Cloudflare Pages) and somehow they were in fail closed mode and not fail open :(

I have had back luck with them intermittently losing routing. Sometimes re-creating the worker fixes weird issues.

This one is my bad, I've exceeded the 100k free reqs/day (for https://stanislas.blog/2025/02/redirect-dead-links-hugo-imag...), and I didn't enable the setting to bypass it over that limit

Meta don’t use RSC: https://bsky.app/profile/en-js.bsky.social/post/3lmvwmr5rfs2...

> We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC.

(as of April 2025)

And `rails new` required me to install Ruby and Rails. I'm not sure what the point you're making is.