Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Verifikation von AUR PKBUILD dvdisaster (Gelesen 1512 mal)
|
|
Sebastian
Sr. Member
 Offline
Einträge: 487
|
 |
Verifikation von AUR PKBUILD dvdisaster
« am: 12. Januar 2023, 17:47:09 »
|
|
Verifikation von dvdisaster
Im PKGBUILD von dvdisaster ist mir aufgefallen, dass dort der veraltete Hash Algorithmus SHA1 Verwendung findet und zu gleich eine Verifikation über einen GPG Key stattfinden soll.
pkgname=dvdisaster
pkgver=0.79.10
pkgrel=1
provides=('dvdisaster')
pkgdesc="Provides a margin of safety against data loss on newly created ISO, CD, DVD, and BDR media caused by aging or scratches"
arch=('x86_64')
url="https://dvdisaster.jcea.es"
license=('GPL')
depends=('gtk2')
options=('!makeflags')
source=(${pkgname}-${pkgver}.tar.bz2::${url}/downloads/${pkgname}-${pkgver}.tar.bz2
${pkgname}-${pkgver}.tar.bz2.gpg::${url}/downloads/${pkgname}-${pkgver}.tar.bz2.gpg)
sha1sums=('848f6dea242de90201df3eabf445a5825131ebc6'
'5b0378d3130c600f8f7a1eb4b603cb2fca82bc71')
validpgpkeys=('12B31535AF903ADE9E73BA7E5A590EFEF5F6C46C')
|
|
Toll dachte ich mir, um den Download auf einen Defekt zu prüfen, dafür wird der SHA1 Algorithmus noch ausreichen, wenn der Download noch mal mit einer GPG Signatur geprüft wird.
Da ich zu der Vorsichten-Sorte Mensch gehöre, was IT-Sicherheit anbelangt, und ich mir es auch gerne mal unbequem zugunsten der Sicherheit mache. Habe ich mir gedacht, prüfe ich doch lieber die Webseite des Entwicklers von dvdisaster. Dort habe ich dann weitere Ungereimtheiten gefunden, die mich misstrauisch gemacht haben.
- Der Entwickler selbst gibt MD5 Hash summen an. Warum werden die nicht im PKGBUILD verwendet?
- Der Entwickler benutzt zum signieren seiner Software ein ganz anderen Key!
The downloadable dvdisaster packages have been digitally signed using GnuPG so that you can verify that the software is in its original state.
Starting with version 0.79.5, releases are signed with this 4096bit RSA key:
|
|
pub 4096R/64F770B2 2015-10-05
Key fingerprint = E3AF E703 96CC C0D9 E5D8 381C B0DB CA7D 64F7 70B2
uid dvdisaster (pkg signing key #2)
sub 4096R/758BCC23 2015-10-05
|
|
Spätestens da gingen für mich alle Alarmsirenen an und bevor ich das PKGBUILD so baue musste ich genau die URLs prüfen, ob diese Stimmig sind. Indem ich die Software einmal von Hand heruntergeladen habe und selbst einmal die MD5 und die SHA1 Hash Summe berechnet habe, diese war wie im PKGBUILD angeben. Somit lade ich mir die Software zumindest schon mal von der richtigen Quelle herunter.
PGP Key
Blieb also nur noch, die Sache mit dem PGP Key zu klären. Also habe ich einfach mal mir den Key aus dem PKGBUILD genauer angeschaut:
$ gpg --search-keys 12B31535AF903ADE9E73BA7E5A590EFEF5F6C46C
gpg: data source: https://162.213.33.8:443
(1) Carsten Gnörlich (pkg signing key #1)
1024 bit DSA key 5A590EFEF5F6C46C, erzeugt: 2003-08-22
|
|
Auch schon ein ziemlich alter Key mit veralteten Verfahren. Ein Blick in die README teilte mir zumindest schon einmal mit, dass Carsten Gnörlich an dvdisaster mit entwickelt. Das muss aber noch lange nicht heißen, ob der Key echt ist.
Ein Bau versuch
Na gut dachte ich mir, nachdem zumindest die URL richtig erscheint, baue ich das Paket einmal ohne es zu installieren, mal sehen was passiert da ich mit AUR Paketen die PGP Signiert waren auch noch nicht viel Erfahrungen gemacht habe.
yay ludt nun das PKGBUILD herunter, fragte mich, ob es ok ist den Key von Carsten Gnörlich aus dem PKG danach zu suchen und meine Keyring hinzufügen. Und fing das Bauen des Paketes an, soweit sogut.
Als er dann fertig mit bauen war, fragte mich pacman nach meinen Root Passwort. pacman wollte anscheint das Paket installieren.
Es stellten sich für mich nun wieder neue Fragen auf:
- Die heruntergeladene PGP Signatur aus dem PKGBUILD passt eindeutig nicht zum heruntergeladenen Schlüssel, warum wurde trotzdem das Paket gebaut?
- Warum wurde pacman nach dem Bau getriggert, das Paket zu installieren?
Wann werden Signaturen geprüft?
Um herauszufinden, warum das Paket trotz alledem gebaut wurde, war meine erste Anlaufstelle das Arch Wiki - Makepkg#Signature_checking. Dort stand dann folgendes:
If a signature file in the form of .sig or .asc is part of the PKGBUILD source array, makepkg automatically attempts to verify it. In case the user's keyring does not contain the needed public key for signature verification, makepkg will abort the installation with a message that the PGP key could not be verified.
|
|
Erklärung gefunden, der Dateiname der Signatur im PKGBUILD hatte die Endung .gpg und nicht eine der anderen zwei angebenden. Deswegen hat makepkg die heruntergeladene Signatur nicht geprüft und der Download der Datei dvdisaster-0.79.10.tar.bz2.gpg ist somit eigentlich überflüssig gewesen, weil diese überhaupt nicht zum Einsatz kommt.
Da ich noch eine Bestätigung haben wollte, also noch mal im PKGBUILD(5) Handbuch nachgeschlagen. Für unsere Deutschsprachigen hier ein Auszug aus dem Deutschen Handbuch
Dateien im »source«-Feld mit den Endungen .sig, .sign oder .asc werden von Makepkg als PGP-Signaturen erkannt und automatisch zur Überprüfung der Integrität der korrespondierenden Quelldatei verwendet.
|
|
Hier steht sogar die Endung .sign noch mit dabei, das im Arch Wiki nicht erwähnt wurde. Aber leider kein .gpg
makepkg hat alleine nur die SHA1 Hash Summe der Datei geprüft
Warum wurde versucht das Paket zu installieren?
Jetzt blieb für mich noch die Frage, warum yay trotz
yay -Sw bzw. --downloadonly angabe, pacman nach dem Bau des Pakets, getriggert hat dieses zu installieren.
Also in eine Web Suche eingeben:
yay build without install
Und folgende Seite gefunden
build without install - yay -Sw does not work #1373
Scheint schon ein älteres Problem zu sein, was angeblich auch schon gefixt worden sein soll. Da ich jetzt aber auch keine lust mehr hatte dieses Problem ganz genau auf den Kern zu gehen, wollte ich es nun auch dabei belassen.
Fazit
Nachdem ich die Abläufe und Quellen inzwischen nachvollziehen konnte, konnte ich das Paket jedoch mit guten Gewissen auch installieren. Es empfiehlt sich bei Ungereimtheiten immer lieber etwas nachzuforschen bevor man sich etwas Gefährliches reinholt.
Zudem erweitert man durch das Nachforschen ganz nebenbei sein Wissen/Verständnis nachhaltig über Linux.
Um es mir persönlich später etwas einfacher zu machen, halte ich wichtige Dinge auch in meiner persönlichen Wissensdatenbank fest. Diese verwalte ich übringends mit Obsidian
Es ist auf jedenfalls ein schönes Gefühl, wenn man durch eigene Recherchen ein Problem lösen und auch zukünftig besser verstanden hat, woran dies lag. Denn beim folgenden und auch dem nächsten Mal, wird es immer leichter und es geht schneller Lösungen selbst zu finden, da man immer besser die zusammenhänge versteht.
Da ich mich auch schon früher mit dem Thema Pakete bauen beschäftigt habe, fehlt es mir jetzt natürlich auch nicht schwer das PKGBUILD selbst anzupassen, und den aktuellen PGP Key und auch die Signatur mit der richtigen Dateinamen Endung hinzuzufügen. Vor ein paar Monaten ging das noch nicht. Wie man daran aber gut erkennen kann, fügt sich teil wissen immer mehr zu einem ganzen zusammen und wird damit immer leichter sich anzueignen. Weil man nicht mehr so viel aufbereiten muss.
Bleibt neugierig und versucht ruhig denn dingen auf den Grund zu gehen. Es gibt nichts Besseres als sich weiterzubilden.
LG
Sebastian
|
| « Letzte Änderung: 12. Januar 2023, 18:04:12 von Sebastian » |
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #1 am: 13. Januar 2023, 08:29:52 »
|
|
Software jeglicher Art wimmelt nur so von kleinen Ungereimtheiten, von überflüssigen oder sinnfreien Dingen oder von Dingen die vor 20 Jahren mal nötig waren und sich von Version zu Version immer weiter geschleppt haben. Ich sehe das bei meinen eigenen Programmen oder Projekten. Ein Projekt wirklich perfekt zu pflegen erfordert sehr viel Zeitaufwand und Mühe. Viele Projekte sind daher nach dem Motto "wenn es läuft und mir keine groben Fehlfunktionen bekannt sind dann reicht es mir" gepflegt. Tiefer zu suchen fördert dann solche "Leichen" zu Tage. Zu 99,999% ist es nichts Schlimmes. Aber ich gebe Dir Recht: es kann sich jemand mit bösen Absichten hier verstecken. Und da Du mit dem Untersuchen von Paketen nicht der einzige bist unterstreichst Du damit meine oft gemachte Aussage:" Open Source enthält weniger Fehler oder gar Schadcode als proprietäre Software. Weil es jedem die Möglichkeit eröffnet selbst zu schauen ob "alles koscher" ist. Und selbst wenn das weit außerhalb eurer Möglichkeiten liegt. Es gibt Leute für die ist das möglich und die tun das auch: sie überprüfen Dinge die ihnen komisch vorkommen."
Dass einem solche Untersuchungen einen gewaltigen Wissensschub geben steht außer Zweifel. Ich bin dazu übergegangen AUR-Pakete die nicht mehr das tun was sie ollen (oder gar nicht bauen) selbst zu "reparieren" und dann mit makepkg -e zu bauen, wenn der Maintainer nicht reagiert.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #2 am: 14. Januar 2023, 12:30:17 »
|
|
Und da Du mit dem Untersuchen von Paketen nicht der einzige bist unterstreichst Du damit meine oft gemachte Aussage:" Open Source enthält weniger Fehler oder gar Schadcode als proprietäre Software. Weil es jedem die Möglichkeit eröffnet selbst zu schauen ob "alles koscher" ist. Und selbst wenn das weit außerhalb eurer Möglichkeiten liegt. Es gibt Leute für die ist das möglich und die tun das auch: sie überprüfen Dinge die ihnen komisch vorkommen."
|
|
Das war für mich schon so selbstverständlich, dass ich nicht mitbekommen habe, teil eines Prüfsystems zu sein. 
Das, was ich getan habe, habe ich einmal bildlich abgebildet, damit die Prozesse vielleicht klarer werden.
|
Richtig um Hilfe bitten
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #3 am: 15. Januar 2023, 09:26:31 »
|
|
Mittlerweile sind meine Änderungen bis auf eine vom Package Maintainer übernommen worden.
@C2D6:
I applied all the changes that you suggested, with the one exception about the signature.
1) I removed the prepare() function, since as you noted they fixed the name of their .desktop file upstream.
2) Since the developers only publish the MD5 hashes on their upstream website, I switched from SHA1 to MD5. (Even though MD5 is "less secure".)
3) I removed the .gpg/sig file from the source array and removed the validpgpkeys array entirely for a few reasons: (a) this entire time for the PKGBUILD's history, it appears that no such verification was being done in the first place; (b) the derivative PKGBUILDs, among other PKGBUILDs in the AUR, don't make use of verifying signed source files (with the exception of notable software); and (3) it simplifies the PKGBUILD in whole.
I left a comment on the top of the PKGBUILD for those interested in doing the extra steps for verification. 
|
|
https://aur.archlinux.org/packages/dvdisaster#comment-897658
Für mich als IT Sicherheitsfanatiker ist die Entscheidung das die PGP Prüfung aus dem PKBUILD heraus genommen wurde, und jetzt nur noch durch eine schwache MD5 Checksumme Prüfung abgesichert wird, natürlich nicht ganz nachvollziehbar. Trotzdem geht das für mich okay, denn ein bisschen Eigenverantwortung sollte man beim Installieren von Fremdsoftware schon mitbringen und deswegen immer vorher die Quellen überprüfen. Zudem hat er ja auch ein Hinweis zwecks der Prüfung im PKGBUILD hinterlassen.
Meine Empfehlung auf die schwächeren MD5 Prüfsummen anstelle von SHA1 umzusteigen, basierten auf denn Empehlungen vom Arch-Wiki:
The checksum type and values should always be those provided by upstream, such as in release announcements. When multiple types are available, the strongest checksum is to be preferred: b2 over sha512, sha512 over sha384, sha384 over sha256, sha256 over sha224, sha224 over sha1, sha1 over md5, and md5 over ck. This best ensures the integrity of the downloaded files, from upstream's announcement to package building.
|
|
https://wiki.archlinux.org/title/PKGBUILD#Integrity
Das fördert einen schnelleren Vergleich der Summen vom Upstream. Zudem dachte ich mir, ist es nicht schlimm auf MD5 herunterzustufen, wenn die Integrität und Authentizität über PGP sichergestellt wird. Dem ist dann halt jetzt leider nicht so.
Trotzdem ist das PKGBUILD nun aufgeräumter und aktueller, und mit dem Hinweis im PKGBUILD für Leute, die das noch zusätzlich über PGP prüfen möchten, kann ich leben. Wie gesagt, ein gewisser Grad an Vorsicht sollte jeder mitbringen.
Toll an der ganzen Sache in Gegensatz zu proprietäre Software ist, dass alles transparent nachverfolgt werden kann, und somit meiner Meinung nach die Software um einiges sicherer macht.
PS:
Mein yay meldet mir grade es gibt ein Paket Update für das Paket aur/dvdisaster was da wohl geändert wurde?
Wie immer erfährt man das am schnellsten, wenn man sich die Diffs anzeigen lässt, wenn yay einen danach fragt, ob diese Angezeigt werden sollen. Für mich ein muss, diese immer vorher zu kontrollieren. 
LG
Sebastian
|
| « Letzte Änderung: 15. Januar 2023, 09:39:19 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #4 am: 15. Januar 2023, 14:52:33 »
|
|
Die Möglichkeit den Maintainern Issue-Berichte zu senden und so bei der Entwicklung mitzuhelfen ist auch für mich sehr befriedigend. Ich habe so das (berechtigte!) Gefühl bei der Community aktiv mit dabei zu sein und zu unterstützen. Jede kleine Unterstützung ist eine. Und ich selbst werde dadurch auch immer besser.
Aktuell kämpfe ich damit dass bei Arch gestern php8.2 ausgerollt wurde - aber nicht alle Webanwendungen kommen mit 8.2 klar. Also 8.1 neu bauen und als weitere php-fpm aktivieren. Komischerweise stellt sich das auf einem meiner Server bockbeinig - auf den anderen geht es. Ich bin inzwischen zu dem Ergebnis gekommen dass ich einen Tag warte. Eventuell sind noch nicht alle Spiegelserver identisch (es werden je nach Standort der Server unterschiedliche verwendet).
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #5 am: 15. Januar 2023, 17:58:26 »
|
|
Ich habe leider keine Ahnung von PHP und weiß nur soviel das dies eine Serverseitige Skriptsprache ist um HTML Ausgaben zu generieren. Und bedauerlicherweise auch nicht, wofür man php-fpm verwendet.
Hattest du kein altes PHP 8.1 Paket mehr? Bzw. Hilft dir nicht erst mal das PHP 8.1 Paket anzupinnen? Oder sind schon zu viele Pakete von PHP 8.2 abhängig?
Ich bin froh, dass ich ein sehr minimalistisches System zurzeit noch habe, und mich um so Server seitige Dinge nicht kümmern muss.
Trotzdem finde ich diese Dinge spannend und lese und höre gerne darüber. Deswegen wenn du Zeit und Lust hast darüber mehr zu berichten, werde ich versuchen dir zu folgen.
LG
Sebastian
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #6 am: 16. Januar 2023, 08:19:32 »
|
|
Die Sache ist erheblich umfangreicher Sebastian. Man kann (wenn man weiß was man tut) mehrere verschiedene PHP-Versionen vorhalten und dann per(Sub)Domain getrennt nutzen. Am Besten ist freilich wenn die verwendete Web-Software immer die neueste PHP-Version unterstützt - das ist aber leider nicht immer gegeben. Immer wenn so ein Sprung kommt gibt es solche Probleme. Ist nichts Neues - aber bedeutet eben jedesmal Arbeit. "Anpinnen" tue ich generell nichts - im Zweifelsfall müssen die (meist kommerziellen) Anbieter der Software die meine Kunden nutzen nachbessern und anpassen. Ich habe in der Zwischenzeit auf allen Servern ein weiteres PHP (8.1) einsatzbereit gemacht. Jetzt kann aus 7 verschiedenen PHP-Versionen ausgewählt werden was genutzt werden soll. Alle laufen gleichzeitig, und per Domain können das andere sein.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
Sr. Member
Offline
Einträge: 487
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #7 am: 16. Januar 2023, 11:24:30 »
|
|
Ah gut zu wissen, meistens kapselt man so unterschiedliche Versionen ja irgendwie voneinander ab, schon alleine wegen der Abhängigkeiten, so Container Lösungen oder so was Ähnliches.
Ist php-fpm so etwas in der Art? Stelle mir das momentan nicht als Container Lösung vor, sondern eher etwas abstrakter als das dies die PHP Versionen so umbiegt das diese im selben Dateisystem leben können.
Habe auch was von chroot bei php-fpm gelesen, was meine Vermutung bekräftigt.
Aber wie du vielleicht merkst im Server bereich fehlt mir einfach zu viel Hintergrundwissen. Deswegen meine Frage.
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1319
Linux von Innen
|
|
Re:Verifikation von AUR PKBUILD dvdisaster
« Antwort #8 am: 17. Januar 2023, 04:44:52 »
|
|
php-fpm lässt die Prozesse mit dem Benutzer laufen dem der apache-Prozess gehört. Es sind keine Container - alles läuft direkt auf dem System. Aber jede Domain kann mit einem anderen Benutzer laufen. Dementsprechend kann (und das tut es) jede php-Version gleichzeitig mehrfach mit unterschiedlichen Nutzern aktiv sein. Wie geschrieben: es ist komplizierter... Auch hier gibt es genügend Doku im Netz - aber es ist recht spezielles Wissen.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
