5

Lately there was a compromised npm package, which was used as a dependency in various projects. The code allowed the attacker to steal funds if certain conditions were met.

Could Tezos become a victim of a similar attack with for example a hijacked OCaml dependency such as a commonly used library? How do the active developers working on the code try to prevent this? Don't quote me on this, but in an older video I can remember @ArthurB talk about code coverage - which is great. Are there other security measures in place? Or is it the job of the bakers to set up a sufficient firewall to prevent outside communication?

Improve this question
3
  • 2
    Can you please name the "compromised npm package"? And a reference to a description of the possible attack you mention? Thank you!
    – Lacramioara
    Feb 1, 2019 at 13:18
  • 3
    I don't think it's relevant to mention the "compromised npm package" specifically. It's a general threat from using 3rd party libraries and something that the core devs should have a strategy to defend against.
    – Klassare
    Feb 1, 2019 at 21:00
  • 1
    @Klassare : It's always good if one can give concrete examples. As for the question itself, the formulation did not hint to a general threat --as the trigger--, but to a specific one ("The code allowed the attacker to steal funds": which code?). If XTZST2O wants to add some references, I'm sure this will be appreciated.
    – Lacramioara
    Feb 2, 2019 at 9:49

1 Answer 1

Reset to default
6

It's something to be careful about. If you look in scripts/version.sh you will see that the opam repository is pinned to a particular hash. This enforces Tezos being compiled against a specific version of the package repository.

This helps a great deal, and protects against the repository being hacked for instance. However, that repo hash may need to be updated over time, as new version of the dependencies are released. This introduces the need to monitoring upstream packages to ensure that they do not introduce backdoors.

This is a thorny problem that every software has to contend with, and there's no silver bullet. Minimizing dependencies, pinning their versions, and reviewing their changes when moving to a newer version is a good start.

Improve this answer
1
  • Pinning dependencies to specific version hashes is kind of a silver bullet in my opinion, even though it requires some effort to edit version.sh.
    – DPF
    Feb 3, 2019 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.