DEV Community

loading...

Discussion on: Papers We Love - Reflecting on Trusting Trust

Collapse
ben profile image
Ben Halpern

1) Amazing how little has changed in so many ways.

2)

The moral is obvious. You can't trust code that you did not totally create yourself.

With the proliferation of open source, how do we reconcile this? I think responsible checks/tooling/etc. can account for this, but

I have watched kids testifying before Congress. It is clear that they are completely unaware of the seriousness of theft acts.

This remains painfully true, and with the simplicity of pulling in code from npm and elsewhere, this problem must only be getting worse.

Coming to mind:

hackernoon.com/im-harvesting-credi...

Collapse
hoelzro profile image
Rob Hoelz Author

As far as the attack described in the paper itself goes, I alluded to how the Rust team addressed this in the comments to Jess' introductory post: manishearth.github.io/blog/2016/12... I assume that the GCC/Clang/etc teams have also incorporated this fix.

However, one problem that we weren't dealing with back then was the sheer amount of code that ends up folded into an application. Maybe we can try to compensate for this with tooling, but attackers love to find tools' blind spots!

One idea I kind of like is having permissions be more granular - even more granular than the application level. So you'd have an application that needs network access, but it calls a third party module that perhaps entirely trustworthy - let's say it's a checksum calculation library. The checksum calculation library would specify in its package metadata that it only needs compute power, so if it lied about that, the code would get SIGKILL'd/throw an exception/whatever. I think one could pull this off in native code with some memory segmentation/call gate magic, but it would need to be supported all the way down to the kernel level, and memory segmentation is passé, so I don't think this would ever get implemented as anything other than a toy. With the rise of WASM and the ability to call functions created from different contexts, however, maybe this could happen.

That being said, I don't think this would take off - it would undoubtedly introduce too much overhead, plus it would be very tedious to work with, and our industry seems to prefer sacrificing these kind of protections to avoid tedium.