> 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).
> 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.
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
> 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.
If I were a CodeRabbit customer, I'd still be pretty concerned after reading that.
How can CodeRabbit be certain that the GitHub App key was not exfiltrated and used to sign malicious tokens for customer repos (or even used for that in-situ)? I'm not sure if GitHub supports restricting the source IPs of API requests, but if it does, it'd be a trivial mitigation - and one that is absent from the blog post.
The claim that "no malicious activity occurred" implies that they audited the activities of every repo that used Rubocop (or any other potential unsandboxed tool) from the point that support was added for it until the point that the vulnerability was fixed. That's a big claim.
And why only publish this now, when the Kudelski article makes it to the top of HN, over six months after it was disclosed to them?
> might be good to mention that for transparency, because people can tell anyway and it might feel slightly otherwise
Devil's advocate: why does it matter (apart from "it feels wrong")? As long as the conclusions are sound, why is it relevant whether AI helped with the writing of the report?
I like this style. In a project I worked on we had CI reject any FIXMEs outright and any TODOs that weren't accompanied by an issue ticket[^1], so the hierarchy would be
FIXME: I am leaving a note to myself to not get distracted, but this code is not considered finished/mergeable until it's resolved
XXX: this needs fixing soon, but the code will still be functional without it
TODO: this needs revisiting but the code is perfectly useable without it - a lower priority XXX
NOTE: this does something unusual and you need to bear in mind while working on this code
[^1]: the value of doing (or not doing) this is a subject that has already been extensively rehashed in sibling comments
> But a few instances were to conditionally set one piece of state whenever another piece of state was changed
That use case is explicitly called out on the "You Might Not Need An Effect" article in the docs (which everyone writing React should read, and arguably was published years too late): https://react.dev/learn/you-might-not-need-an-effect
TLDR:
When updating a useState based on another useState, don't use the first useState at all, just compute it inline. If it's expensive, wrap it in a useMemo.
When updating a useState based on props, call the setter directly from the component function, and React will immediately re-render the component (instead of rendering it, running the effect, and then rendering it again).
> Generally, this can be dealt with via policy and moderation to prevent abusive users from causing outsized load on systems, but these processes take time and can be imperfect.
So it’s a case of the engineers accepting that, however hard they try to moderate, these sorts of cases will crop up and they may as well design their infrastructure to handle them.
> if a peaceful protest were to take place during the talk in question, we will not take action, provided the protest is indeed peaceful and does not disrupt the proceedings
Would staging a sit-in explicitly intended to prevent the booked speaker from speaking be classed as “disrupting the proceedings”?