[trishankkarthik]

This is why we designed TUF and in-toto to detect MitM attacks anywhere in the software supply chain between developers and end-users themselves, and provide E2E compromise-resilience.

It's strange that the paper doesn't mention us considering that we have considerable expertise in this very area.

https://www.datadoghq.com/blog/engineering/secure-publicatio...

[tao_oat]

This reads a bit like saying "it's strange that this academic paper doesn't advertise our private company." Especially since TUF and in-toto don't seem to handle the core issue of having to use open-source libraries written by untrusted developers.

[raesene9]

Whilst TUF absolutely does help with some of the cases in the paper and generally, it's important to notice that at least one of the scenarios in the paper may not be covered by solutions like TUF.

I'm thinking of the scenario where a bad actor takes over an existing library with the original owner's blessing, either by contributing and then taking on maintainership, or via payment to the original owner.

In that case ownership of signing keys may transition to the new owners voluntarily, so there would be no noticable change, in terms of signing of packages.

[trishankkarthik]

That's a bit like saying: well, encrypting the iPhone isn't all that jazz, because all I have to do is hit the owner with a $5 wrench.

I mean, yes, but cryptography alone cannot solve that problem. TUF and in-toto provide cryptographic solutions to cryptographic problems, which is much more than anyone else is doing today.