# Code Review auf Sicherheit **URL:** \ **Category:** Technik\ **Created:** [19. Januar 2016 um 21:22 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264 "2016-01-19T21:22:36Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![Sheogorath](https://forum.freifunk.net/user_avatar/forum.freifunk.net/sheogorath/32/6038_2.png) [@Sheogorath](https://forum.freifunk.net/u/Sheogorath)\ **Post date:** [13. November 2016 um 17:53 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/41 "2016-11-13T17:53:13Z")
Docker ist und war nie eine Blackbox. Dockerfiles sind Nachvollziehbar. Zumindest bis zu einem Gewissen grad. Wichtig ist, damit man eben eine IDENTISCHE Buildumgebung schafft. Denn was bringen einem Images, die man auf verschiedenen Maschienen mit unterschiedlichen gcc versionen baut? Nichts, denn ggf. wird dort im Detail etwas anders optimiert und schon kannst du nichts mehr vergleichen. Docker ist hier der einfachste Weg konsistent eine Entwicklungsumgebung für alle bereit zu stellen, ohne jemanden einzuschränken. Du kannst natürlich auch alles in Vargrant packen und hoffen, aber das hilft dir halt auch nur bedingt. Tipp: Bevor du dich über Docker in Rage schreibst, bedenke, dass der Fehler nicht in Docker, sondern primär in dessen Benutzungsweise liegt. Hier stellt es übrigens keinen großen Unterschied mehr zu den sonstigen Repos da. Denn auch hier müsste man ja die Sourcen lesen um die Anwendung zu verstehen, was ähnlich wenige tun 😉 Wie auch immer… Wir wollen ja nicht vom Thema abschweifen 😉 Aber wenn du eine Dockerdebatte führen willst, steht dir meine Inbox offen 😉 ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [13. November 2016 um 17:59 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/42 "2016-11-13T17:59:18Z")
ein feiner unterschied liegt darin, das code, den ich mir erst holen muss, auch von anderen benutzt wird und insofern auch von anderen mit gemaintaint wird - und da schaut dann letztendlich irgendwann eher jemand drauf. Einfach weil der potentiell in vielen Projekten steckt, da kann ich auch extern nicht so einfach Dinge hinzufügen oder tun. In einem vorbereitetem Docker File ist das schlicht nicht der Fall - und wenn man hier unter dem Thema „Code Review auf Sicherheit“ schreibt ist Docker zwar Nachvollziehbar - aber absolut kein Gewinn. ---
**Author:** ![Sheogorath](https://forum.freifunk.net/user_avatar/forum.freifunk.net/sheogorath/32/6038_2.png) [@Sheogorath](https://forum.freifunk.net/u/Sheogorath)\ **Post date:** [13. November 2016 um 18:04 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/43 "2016-11-13T18:04:01Z")
Wo liegt das Problem? Das ist doch sehr einfach möglich. In dem dockerimage wird das git repository zum bauen geclont. Das sorgt natürlich dafür, dass alle commits NACHVOLLZIEHBAR vorliegen. Mit einem `git status` kann ich nun schauen ob Dateien manipuliert wurden und ob die Commit-ID stimmt. ist das der Fall… Juhu alles super. Wenn nicht, mhm dann sollte da nochmal wer dran. Den Code selbst kann ich dann eben über GitHub, GitLab, eine Repository verwaltung meiner Wahl machen, bzw. einfach klassisch über die Git-CLI und vi oder emacs. Docker bildet hier nur die Möglichkeit auch die fertigen Builds gegeneinander vergleichbar zu halten. Edit: Ich kann beim commit sogar noch weiter gehen… Ich kann sogar schauen die Signatur noch hinhaut, wenn der commit denn signiert ist. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [14. November 2016 um 00:36 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/44 "2016-11-14T00:36:45Z")
> [@Sheogorath](#): > > Wo liegt das Problem? Das ist doch sehr einfach möglich. In dem dockerimage wird das git repository zum bauen geclont. Nur weil Du eine reprozierbare und vertrauenswürdige Buildumgebung hast, bedeutet das doch noch lagne nicht, dass die Qualität des Codes steigt. Ich sehe auch ehrlich gesagt nicht, wie „reproduzierbare Builds“ überhaupt den Codereview untersützten könnten. Eventuell bringt man damit natürlich mehr Leute ins Boot, klar. Aber sonst? ---
**Author:** ![Sheogorath](https://forum.freifunk.net/user_avatar/forum.freifunk.net/sheogorath/32/6038_2.png) [@Sheogorath](https://forum.freifunk.net/u/Sheogorath)\ **Post date:** [14. November 2016 um 00:41 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/45 "2016-11-14T00:41:47Z")
> [@adorfer](#): > > Nur weil Du eine reprozierbare und vertrauenswürdige Buildumgebung hast, bedeutet das doch noch lagne nicht, dass die Qualität des Codes steigt. Das ist richtig, aber hierum ging es bei der Debatte die ich zuletzt mit fuzzle hat auch nicht. Hierbei ging es darum die resultierenden Images vergleichen zu können. Dafür ist eine solche Buildumgebung die richtige Variante. Die Codequalität kann nun mit den gängigen Mitteln gesteigert werden. Reviews, Refactoring, noch mehr reviews und nicht zuletzt reviews. Diese macht man basierend auf den Commits und ggf. in einem üblichen Refacotoring-Schritt den man ohnehin macht. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [14. November 2016 um 00:50 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/46 "2016-11-14T00:50:13Z")
> [@Sheogorath](#): > > Die Codequalität kann nun mit den gängigen Mitteln gesteigert werden. Reviews, Refactoring, noch mehr reviews und nicht zuletzt reviews. Es muss darum gehen, mehr Leute ins Projekt zu bringen. Gluon (und auch LEDE) sind viel zu schmal aufgestellt, um der Forderung nach „sicherem und gutem Code“ gerecht zu werden. Irgendwelches Nitpicking in Richtung „die GITs und Buildumgebungen sind inkonsistent“, meinetwegen auch von @fuzzle (oder @rubo77) bringt uns in diesem Problem nicht weiter. Was wir hier nun besprechen ist doch eher ein Sicherheitsaudit der jeweiligen Build-Umgebungen und der von den Community genutzten Repositories und Toolchain, würde am eigentlich Gluon/LEDE-Code wenig ändern (hoffentlich…) ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [14. November 2016 um 01:26 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/47 "2016-11-14T01:26:29Z")
na, @rubo77 hat den thread hier ausgegraben, und unwichtig ist das thema an sich ja nicht. Er fing die Diskussion um code und commits und deren Verfügbarkeit an. … darauf eingehend fing der kleine Exkurs dazu an. nur um das nochmal in Erinnerung zu rufen - bzw zusammenzufassen. @adorfer - deinen letzten beitrag versteh ich semantisch nicht, da fehlt nen komma oder irgendwas Sinnvoll halte ich auch das mehr Menschen sich proaktiv mit Code und Netzwerken auseinander setzen. Das dient der Diversität, verteilt Last auf Schultern. Das erfindet das Rad ggf mehrfach neu und führt zu „evolutionärer“ codequalität(sunterschieden). Survival of the fittest - mit ohne bugs. ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [14. November 2016 um 01:49 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/48 "2016-11-14T01:49:58Z")
> [@fuzzle](#): > > deinen letzten beitrag versteh ich semantisch nicht Danke, ich hab’s mal editiert. Wir brauchen in jedem Fall mehr Leute, die testen und sich einbringen. (Und sich auch nicht von den bisweilen rustikalen Umgangsformen auf der Gluon-Mailingliste abschrecken lassen.) ---
**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\ **Post date:** [14. November 2016 um 08:55 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/49 "2016-11-14T08:55:35Z")
## Zusammenfassung: #### 1. Ein externer Prüfer sieht, welche firmware auf einem Router installiert ist, dabei sieht er im Moment nur in der internen config files in `/lib/gluon/gluon-version`, `release` und `site.json`. In den ersten beiden steht z.b. ``` gluon-version:v2016.1.6 release:2016.1.6 ``` Die gluon-version anthält die commit ID nur, wenn man nicht genau auf einem annotated tag gebaut hat, dann steht dort sehr genau z.b. ``` 2016.2~exp1611131432 / gluon-v2016.2.1-3-g0f9a1a9 ``` also commit-id `0f9a1a9` genau 3 commits nach dem tag gluon-v2016.2.1 Außerdem enthält die `site.json` die exact benutzte site config, anhand der könnte ein Prüfer die Firmware genau so nachbauen. ### 2. Hier kommt die Docker Diskussion ins spiel: Wenn man mit einem vorgegebenen Docker image gebaut hätte, dann könnte der Prüfer jetzt das selbe Docker Image nehmen und anhand der site.json und dem gluon-commit die Firmware selbst auch bauen und dann die resultierenden images binär vergleichen. Damit sieht der Prüfer, dass die Firmware wirklich mit diesem Docker image gebaut worden ist. #### 3. Das verschiebt aber natürlich den Angriffsvektor auf das Docker-Image, das jetzt überprüft werden müsste auf Hintertüren: Dazu könnte man eine Anleitung, wie man das Docker Image aus Standard-Paketen erstellt hat veröffentlichen, nachbauen und dann die Docker-Images überprüfen. _Ich hab das wichtigste hier ergänzt: [https://wiki.freifunk.net/Sicherheit](https://wiki.freifunk.net/Sicherheit#Wie_kann_ich_pr.C3.BCfen.2C_ob_die_heruntergeladene_Freifunk-Firmware_auch_wirklich_die_angebotene_ist.3F)_ ---
**Author:** ![anon68922371](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/a/8491ac/32.png) [@anon68922371](https://forum.freifunk.net/u/anon68922371)\ **Post date:** [14. November 2016 um 09:26 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/50 "2016-11-14T09:26:44Z")
Ehrlich gesagt halte ich das für overpowered. Sinnvoller wäre es wenn die commits der genutzten Grundlagen nachvollziehbar wären. Sonst könnte man auch einfach den build Ordner 7zippen, hashen und zum DL anbieten. Das hätte den selben Effekt wie Docker. Ergänzung zum Wiki: Jede Community die den AU nutzt bietet Hash Werte zum überprüfen an. Sie stehen im Manifest. ---
**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\ **Post date:** [14. November 2016 um 12:42 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/51 "2016-11-14T12:42:41Z")
Zuerst einmal sollte der gesamte site-Ordner in der Firmware landen, sodass man sie einfacher nachbauen kann. Alternativ auch gerne der git-commit im site-Ordner. Ich habe nicht den Anspruch, dass die binaries, die rausfallen, identisch sind. Mir reicht es, wenn nach Entpacken, (evtl. strings) und rekursivem diff nur so Dinge wie Datum, Pfad zum build-Verzeichnis und so weiter rauskommen. Wenn man dem Firmware-Bäcker vertraut, reicht es aber, seine Signatur auf dem Manifest und die Hashsumme zu prüfen. ---
**Author:** ![yayachiken](https://forum.freifunk.net/user_avatar/forum.freifunk.net/yayachiken/32/261_2.png) [@yayachiken](https://forum.freifunk.net/u/yayachiken)\ **Post date:** [14. November 2016 um 14:27 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/52 "2016-11-14T14:27:48Z")
Ich glaube du gehst davon aus, dass das gleiche Environment und der gleiche Code zu einer bitweisen identischen Binary führen. Das ist aber nicht zwangsweise der Fall. Debian gibt sich seit einiger Zeit Mühe damit und hat [trotzdem immer noch 20% Pakete die nicht reproducible bauen](https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png). Ist das also überhaupt bei Gluon schon so? Sonst ist die Diskussion imo erstmal müßig. (Wobei es in dem Fall natürlich schön wäre wenn jemand™ sich des Themas annimmt und Gluon entsprechend patcht) ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [14. November 2016 um 15:00 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/53 "2016-11-14T15:00:51Z")
> [@yayachiken](#): > > Ich glaube du gehst davon aus, dass das gleiche Environment und der gleiche Code zu einer bitweisen identischen Binary führen. Meiner Meinung nach hat das trotzdem nichts mit „Codereview“ zu tun. Sondern eben mit Reproduzierbarkeits von Builds (und evtl. dem Signaturprozess in Communities). Oder anders: Ich halte das Thema für so relevant, dass es einen eigenen Thread verdient hätte. ---
**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\ **Post date:** [15. November 2016 um 01:50 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/54 "2016-11-15T01:50:23Z")
ja gerne einen „Reproduzierbarkeits von Builds“ Thread abspalten. Zu code-Review gehört nur, wie man rausfindet, welche commit\_id benutzt wurde, damit man sich das gluon repo zu diesem commit anschauen kann. Dazu gehört auch die Erkenntniss, dass anscheinend dazu die information fehlt, welche site-conf commit-id benuttz wurde. dazu sollten wir mal ein issue im gluon machen, wenns das noch nicht gibt ---
**Author:** ![fuzzle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/fuzzle/32/5599_2.png) [@fuzzle](https://forum.freifunk.net/u/fuzzle)\ **Post date:** [15. November 2016 um 01:53 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/55 "2016-11-15T01:53:41Z")
@rubo77 du meinst sowas wie das hier ? ```auto 0 root@fffr-rauberhaus2:~# cat /lib/gluon/gluon-version v2016.2-28-g5ef3d88 ``` gluon version +28 commits mit id g5ef3d88 - wenn man auf einem tag baut steht da auch „nur“ v2016.2.1 bspw. ---
**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\ **Post date:** [16. November 2016 um 07:41 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/56 "2016-11-16T07:41:11Z")
@fuzzle: das ist der commit aus dem gluon repo. Es fehlt die URL und commit ID, welches site-repo benutzt wurde. Ich hab das mal hier als Pull Request erstellt: [https://github.com/freifunk-gluon/gluon/pull/937](https://github.com/freifunk-gluon/gluon/pull/937) - Add remote URLs and commit-IDs of gluon and site to config files. Hab das getestet, funktioniert, er baut dann images, wo die URL zum git repo und site-repo mit in der config stehen ---
**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\ **Post date:** [11. Januar 2017 um 04:16 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/57 "2017-01-11T04:16:16Z")
Im Master ist jetzt drin, welcher Commit aus dem site-Repository benutzt wurde ``` /lib/gluon/gluon-version /lib/gluon/site-version ``` Die Communities müssen jetzt allerdings Kommunizieren, wo Ihr benutztes site-Repository liegt und ob sie das original Gluon-Repository benutzt haben oder wo der eingene Fork liegt. Man kann im Router jetzt erkennen, mit welchen Gluon- und Site-Repository Commits die Firmware gebaut wurde, aber nicht die Repository-URLs. ---
**Author:** ![rubo77](https://forum.freifunk.net/user_avatar/forum.freifunk.net/rubo77/32/799_2.png) [@rubo77](https://forum.freifunk.net/u/rubo77)\ **Post date:** [17. Juli 2018 um 12:05 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/58 "2018-07-17T12:05:32Z")
Ich habe einen PR erstellt, die neue site-version im config mode auf der Info page anzuzeigen: > > > This will enable the communities to add links to their build structure and repos…itories to the info page. > > (Tested on a build on tag 2018.1.x) > > \## screenshot > > !\[auswahl\_004\](https://user-images.githubusercontent.com/1591563/42863463-95d8cb98-8a63-11e8-8237-4c685c8ffc7b.png) Wenn das so angenommen wird, dann können wir dort auch einen Link zu unserem Site Repository plazieren ---
**Author:** ![wusel](https://forum.freifunk.net/user_avatar/forum.freifunk.net/wusel/32/630_2.png) [@wusel](https://forum.freifunk.net/u/wusel)\ **Post date:** [19. Juli 2018 um 00:49 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/59 "2018-07-19T00:49:18Z")
Wie kleben an jeden Build dies dran: [http://firmware.4830.org/rawhide/factory/ReleaseNotes-1.0.0~34](http://firmware.4830.org/rawhide/factory/ReleaseNotes-1.0.0~34) Wahrscheinlich sollten die Repository-URLs noch mit rein und bei der Gelegenheit der verwendete Checkout für das site-Repo … ---
**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\ **Post date:** [19. Juli 2018 um 02:23 UTC](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264/60 "2018-07-19T02:23:07Z")
Alternativ, man klebt parallel zu „sysupgrade“ und „factory“ noch ein Directory „site“ in das man neben der site.conf und der site.mk auch die modules-Datei und language-Datei und das gepackte Buildlog kopiert. Und das Buildscript ist auch drin. So dass nun prinzipiell jedeR die Firmware nachbauen können sollte. Beispiel: > **[Freifunk Düsseldorf Flingern Firmware Seite](https://images.ffdus.de/stable/site/)** > > Firmware Freifunk Düsseldorf Flingern ![grafik](https://forum.freifunk.net/uploads/default/original/3X/f/0/f01276c449050b89b719949eff24c21970b3c6b8.png) [Vorherige Seite](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264.md?page=2) [Nächste Seite](https://forum.freifunk.net/t/code-review-auf-sicherheit/10264.md?page=4)