Weiß jemand hier, wie man den Open-Source-Code von Trezor aufschlüsseln kann?
- Dieses Thema hat 7 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 10 Monaten, 2 Wochen von
.
-
Beiträge
-
-
Nach dem jüngsten Ledger-Fiasko habe ich gesehen, wie viele Leute die Bedeutung von Open-Source-Code verherrlichen. Ich vertraue jedoch immer noch darauf, dass eine dritte Person den Code für mich aufschlüsselt, um zu bestätigen, dass er 100% sicher ist – wir alle kennen den Satz “don’t trust, verify”. Ich versuche, ein Video über dieses Thema auf Youtube zu finden, aber es gibt keine.
Für eine durchschnittliche Person, die nur Krypto von der Börse kaufen und auf eine HW übertragen möchte, wie können wir den Open-Source-Code leicht verstehen, so dass er 100% sicher ist und man ihm vertrauen kann?
Woher weiß ich, dass Trezor eine plötzliche Änderung am Quellcode vorgenommen hat, unsere Seed-Phrasen extrahiert und sie wieder rückgängig macht?
Vielen Dank!
-
If you‘re not a developer it’s gonna be hard to almost impossible to understand the code by yourself. That said, you‘ll probably just kinda learn how to code just by trying hard enough. It‘s not magic.
The firmware is [here](https://github.com/trezor/trezor-firmware). In the „pull requests“ tab you can see the currently proposed code changes, „closed“ pull requests were either accepted into the code or rejected (different icons). Each pull request will usually contain or link to a description of the feature it implements or the issue it fixes. There is also the concrete code change proposed as well as some discussion with other developers about the general approach or details of the code. I can imagine this is the best place to follow development if you are really interested.
There is much more to GitHub that you can learn about, including ways to access (all) older states of the code (and documentation) should you need to.
[docs.trezor.io/trezor-firmware](https://docs.trezor.io/trezor-firmware/) explains some general aspects of the functionality and code layout as well as how to build the firmware yourself. With this info and the history on GitHub you could build an old version if you need to, or even maintain your own by copying only the changes to the code that you like.
Although, understanding parts of the code will be hard even for developers, and if all the people at the top of [this list](https://github.com/trezor/trezor-firmware/graphs/contributors) will turn bad right now then you will probably not notice them secretly adding a malicious feature. Some people might, though, and a community of new developers could copy the code and develop it in a new direction if there is a need.
-
*how do we understand the open source code easily*
It’s a bit like asking “how do I understand Greek easily?” Before Google translate was a thing.
You do this by learning to code, while learning to code is not easy, it will make understanding code feasible.
You could also pay developer you intimately trust to break it down for you.
-
-
-
Well I guess there are two levels of understanding.
– Understanding WHAT it is doing
– Understanding HOW it is doing itThe first is the “easier” of the two. All it requires is for you to be able to read and follow the code. The second requires you to understand the math behind the code. Getting you to the first part just requires (lots) of reading.
1. [Read the 120 MD files](https://github.com/search?q=repo%3Atrezor%2Ftrezor-firmware+path%3A*.md&type=code) – Click `preview` on the top for formatting.
2. [Read old Developer’s Portal](https://web.archive.org/web/20210622223259/https://wiki.trezor.io/Portal:Developer)
3. [Read the three Doc Decks](https://docs.trezor.io/)
4. [Read the 200 Learn Docs](https://trezor.io/learn) (expand the left hand TOC)
5. [Start at TrezorCTL entrypoint](https://github.com/trezor/trezor-firmware/blob/python/v0.13.6/python/src/trezorlib/cli/trezorctl.py#L424) and follow it
6. [Review trezor-common repo](https://github.com/trezor/trezor-common), specifically the proto buffers (protb) and MD files
7. [Study the 127 page Python Tutorial](https://docs.python.org/3/tutorial/index.html)
8. Focus on `core` since it’s written in Python, while `legacy` is in C.All told, it’s about 400-500 pages worth of material to review, but still smaller than your average novel. Don’t worry if you don’t understand a specific piece, just keep on reading and you may find that new material will clarify earlier points of confusion.
-
Two things:
1. You have to put your trust somewhere: https://youtu.be/cONG2ZNjJ0c
2. Reproducible builds https://docs.trezor.io/trezor-firmware/common/reproducible-build.html -
The question is not if you are trusting someone, the question is who are you trusting.
If the code is open source, then you are trusting than in a community of individuals, different organizations as well as the manufacturer to do its due diligences and ensure that the firmware and hardware its not malicious.
If the code is private you are trusting a single organization that the software and hardware is actually what it claims to be.
In essence when you go from private to public code, you go from a single point of failure to multiple redundancy.
That being said no solution is 100% secure.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
