noauthority.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Long live NAS!

Administered by:

Server stats:

1.4K
active users

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.

Matt Hamilton

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

@arcanicanis @eriner HTTP Signatures are unacceptably complex. It's like 100 pages of how to do the same thing 20 different ways, written by academics who never implemented it. After doing something simpler, it's amazing this ever caught on.

@alex @arcanicanis

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.

solidproject.orgSolid Technical Reports

@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:

https://w3c.social/users/w3c/statuses/111901528209971717

w3c.socialWorld Wide Web Consortium (@w3c@w3c.social)The Verifiable Credentials WG invites implementations of the Verifiable Credentials Data Model v2.0 Credentials (like driver's licenses, university degrees or government-issued passports ) are a part of our daily lives. This spec provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. Please give comments and implementation feedback in the Github repo by 01 April. https://www.w3.org/news/2024/w3c-invites-implementations-of-verifiable-credentials-data-model-v2-0/
@silverpill @alex @eriner @arcanicanis thanks for the update since I am actually working on these (on the backburner though)

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

GitHubRemoving the domain constraints on the AS mediaType property · Issue #584 · w3c/activitystreamsBy iherman
@silverpill Thank you, I am very busy at work lately but I want to keep on top of this and do it eventually.