Did you know: when you verify the signature on a digest, you should probably verify that the presented content (that the digest is supposedly of) actually hashes to the same value as the signed digest?
I’m just increasingly disgusted that it seems like the majority of developers are just collectively drugged, high, intoxicated, or some combination thereof, because I don’t understand how I keep stumbling into these things when I’m not even trying to pentest anything. Worse is that this is in a library that people are just blindly importing and trusting.
@arcanicanis you've run into actual signatures on the hashes outside of distro repos?
9/10 when I see digests, they're unsigned and stored/served from the same place hosting the library/binary, lol.
This is with an implementation of HTTP Signatures in fedi. Just as I was looking into someone asking help on implementing HTTP Signatures, I notice the library they pull in doesn’t even validate the digest, just if the signature is valid and nothing else.
This is also why I hate the mentality of “well, surely other people out there are more responsible and educated than me on this domain-specific knowledge, so I’ll just import this random library that seems popular enough”.
lol alex I was just in the middle of typing this:
Agreed. And if the implementation of said software isn't clear to you as the consumer of that software, then something is wrong with the software, the developer, or the protocol/spec it is built against.
Ironically, while the lack of a concise spec is ActivityPub's sin, the lack of a clear spec is Nostr's sin; with the spec split out over so many chunks (NIPs), and not knowing which you "need" to implement, it's confusing.
I mean, HTTP Signatures wasn’t very hard to implement and get working fine and interoperable with other fedi software, and I’ve read portions of the [draft] spec, it’s just not anything usable as a format of portable data that could be relayed between servers. You just also have to check with implementations of what headers they expect to be signed, which is part of the unwritten rules in fedi that you’re not going to find in the HTTP Signatures spec itself.
But if you want to find endless rabbit holes of practically “protocol mills” (if that’s an appropriate moniker?), just dig into some of the distant depths of the Verifiable Credentials suite of standards, or for insane extremes, go through the labyrinth of specs for Solid: https://solidproject.org/TR/
Apparently they even define their own system of HTTP Signatures: https://solid.github.io/httpsig/
depend on the N3 language for manipulating data: https://solidproject.org/TR/protocol#n3-patch-example
https://w3c.github.io/N3/spec/
But outside of the topic of Solid, and as mentioned earlier: at least some parts of Verifiable Credentials can be borrowed into fedi, and narrowly implemented for a specific opinionated use, such as object signatures, as I’ve described in: https://arcanican.is/primer/ap-decentralization.php
But yes, there’s just insane degrees and extents in which people just keep dreaming up new standards, and making things unfathomably more complex than needed, likely just to sell consultancy and to pitch more VC startups.
@arcanicanis @eriner @alex W3C is not about standards anymore, it's about status. Often people who write specs don't care about implementers at all, and if anything useful comes from W3C, be it ActivityPub or Data Integrity spec, it's almost like a miracle.
Verifiable Credentials at least gets recognized by developers outside of W3C bubble, though personally I don't see much value there besides Data Integrity spec and cryptosuites. The only parties who seem to be genuinely interested in Verifiable Credentials are governments that roll out dystopian digital ID and social credit systems, as this post suggests:
@Moon If you're still working on it, you might be interested in this: https://github.com/w3c/activitystreams/issues/584
There's a conflict between AS and VC contexts that probably won't be resolved soon.