> 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.

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.

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

Comments URL: https://news.ycombinator.com/item?id=48334876

Points: 7

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=46875610

Points: 8

# Comments: 0

> 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...

Comments URL: https://news.ycombinator.com/item?id=46412813

Points: 2

# Comments: 2

> 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)

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?

Comments URL: https://news.ycombinator.com/item?id=44881779

Points: 6

# Comments: 0

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?

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