publications

I wrote one of the referenced posts describing the history here: https://blog.trailofbits.com/2025/08/20/marshal-madness-a-br... I was also part of the team that audited RubyGems.org: https://github.com/trailofbits/publications/blob/master/revi... Look at TOB-RGM-9 (an informational, largely out-of-scope finding) if you want to understand what could be done to mitigate some of these concerns. Nearly all of these gadget chains rely on Gem library functionality, which has this wonky .gemspec.rz metadata file that sits alongside the actual gem file. I understand that it'd be a challenging, backwards-incompatible change, but moving this file from Marshal to JSON would break a lot of these gadget chains. Perhaps there would be others, but it would raise the bar.

No; Trail of Bits has always had multiple internal groups, including an OSS engineering group that does security and performance engineering. We still do plenty of audits as a company; you can see recent work on that front here[1] :-). Source: I run the group that produced this work. [1]: https://github.com/trailofbits/publications

Should be "DAVE" in the title, but the auto-correction hit it. A related interesting read was the DAVE protocol design review, available here: https://github.com/trailofbits/publications/blob/master/revi...

I'm the author of this post and one of the people behind the audit; happy to answer questions about it. If you're having trouble finding the audit itself (it's linked indirectly), I'm linking a copy here as well[1]. [1]: https://github.com/trailofbits/publications/blob/eb9344f2261...

Disagree, their reputation is tied to their audit quality. But I'm pretty sure in this case the scope was bad. Like they coukd have had audits on "Do I use OpenSSL well?" and then misrepresent that all their privacy claims were audited. Now it seems like Skiff conveniently didn't allow Trail of Bits to publish their reports, they are usually here: https://github.com/trailofbits/publications/tree/master/revi... Disclaimer, I have used Trail of Bits service in the past (and 2 other auditors for an security campaign on a blockchain, cryptography + networking product).

Link to the report: https://github.com/trailofbits/publications/blob/master/revi... They seem to not have analysed client-side of PIP itself, but I suppose there isn't anything you could say that isn't already obvious to everyone.

Ugh, I have been advocating "Solidity--" for years and can't get funding to build it (Trail of Bits). We use two tools to offer quick turnaround automated testing and verification for Solidity: Echidna (like QuickCheck for Solidity) and Manticore (a symbolic verifier). They each let you write high level properties in the span of 1-2 weeks that cover a large amount of potential use cases. Here's an example of what that looks like: https://github.com/trailofbits/publications/blob/master/revi... Here's Echidna: https://github.com/crytic/echidna and Manticore: https://github.com/trailofbits/manticore Sometimes we also use custom static analyses built around Slither's IR during projects too: https://github.com/crytic/slither/wiki/SlithIR

Quote from the the TrailofBits audit report [0] > Anyone with administrative access to the Voatz backend servers will have enough information to fully reconstruct the entire election, deanonymize votes, deny votes, alter votes, and invalidate audit trails That's...sub-optimal [0] https://github.com/trailofbits/publications/blob/master/revi...

FWIW I agree with the intent of this statement. The odd lesson we've learned is that extreme testability can overcome broken tools to create secure code. It's not the outcome you would expect since the orthodox in security engineering is that it depends on secure programming languages, frameworks, and compilers, which we have none of in Ethereum. But somehow people are carrying around hundreds of millions of dollars in smart contracts secured with high-powered testing and verification techniques. It's very weird. I explored this topic a bit in a keynote earlier this year: https://github.com/trailofbits/publications/blob/master/pres... I will also note that our long-term goal for Slither is to directly address some of the problems in Solidity (https://github.com/crytic/slither). It's like 2/3rds of a compiler already. It just needs a littl