(gelöst) Kern-Quellen von kernel.org herunterladen

[fischig]

Wie macht man das ohne Browser?

Das hier habe ich versucht:

Code: Alles auswählen

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.232.tar.xz

Fehlermeldung:

Code: Alles auswählen

FEHLER: Dem Zertifikat von »cdn.kernel.org« wird nicht vertraut.
FEHLER: Das Zertifikat von »»cdn.kernel.org«« hat keinen bekannten Austeller

[MaGe]

Das hier habe ich versucht:

Ich auch

Code: Alles auswählen

 wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.232.tar.xz 

linux-4.9.232.tar.xz 100%[===================================>] 89,23M 2,93MB/s in 31s

Keine probleme, frag mich nicht warum.



gruss MaGe

[MaGe]

Hier im Forum Gefunden vielleicht hilft es.

viewtopic.php?t=168633#p1164489



gruss MaGe

[fischig]

Fehlendes Paket ca-certificates war es! Danke!

Ich habe bestimmte eine Dreiviertelstunde im Netz gesucht. Keine Info bezüglich kernel-download gefunden. War ja naheliegend, dass da Zertifikate fehlen, aber warum erwähnt das keiner, der sich lang und breit bemüht „Anleitungen“ zum Kernelbau ins Netz zu stellen, wie man sie denn kriegt.

MIt diesen Suchbegriffen „linux kernel sourcen download“ bin ich nicht fündig geworden.

[Tintom]

Fehlendes Paket ca-certificates war es! Danke!

Ich habe bestimmte eine Dreiviertelstunde im Netz gesucht. Keine Info bezüglich kernel-download gefunden. War ja naheliegend, dass da Zertifikate fehlen, aber warum erwähnt das keiner, der sich lang und breit bemüht „Anleitungen“ zum Kernelbau ins Netz zu stellen, wie man sie denn kriegt.

MIt diesen Suchbegriffen „linux kernel sourcen download“ bin ich nicht fündig geworden.

Nun, für den Kernelbau ist es absolut unerheblich, ob Zertifikate für Webseiten installiert sind oder nicht. Die Kernelquellen kannst du neben der gesicherten Verbindung auch ganz normal über eine ungesicherte http-Verbindung ziehen. Zugegebenermaßen verstehe ich aber auch nicht, warum die ganze Welt über verschlüsselte Verbindungen kommunizieren will. Bei Benutzer/Passwortabfragen sehe ich es noch ein, Telefonie und Chat meinetwegen auch, aber bei Daten, die eh öffentlich im Netz verfügbar sind (z.B. Kernelquellen, Nachrichten), will mir der Mehrwert einer https-Verbindung nicht so recht einleuchten.

[fischig]

Die Kernelquellen kannst du neben der gesicherten Verbindung auch ganz normal über eine ungesicherte http-Verbindung ziehen.

„Normalerweise“ mach' ich das über'n Browser. Der hat noch nie sowas angemeckert (was natürlich daran liegen mag, dass das Paket - aus welchen Gründen auch immer - auf solchen GUI-Maschinen bereits vorhanden ist).

Nun, für den Kernelbau ist es absolut unerheblich, ob Zertifikate für Webseiten installiert sind oder nicht.

Ist es nicht:

Der ERSTE Schritt beim Kernelbau ist das Runterladen der Quellen. Und wenn das ohne Zertifikate nicht funktioniert, ist erst mal nix mit Kernelbau. Die wget-Meldung ist nicht besonders zielführend: Man kann keinem Zertifikat misstrauen, das gar nicht existiert.

[Tintom]

Der ERSTE Schritt beim Kernelbau ist das Runterladen der Quellen. Und wenn das ohne Zertifikate nicht funktioniert, ist erst mal nix mit Kernelbau. Die wget-Meldung ist nicht besonders zielführend: Man kann keinem Zertifikat misstrauen, das gar nicht existiert.

Nochmal: Zertifikate werden nicht benötigt.
Mit wget http://cdn.kernel.org/pub/linux/kernel/ ... 232.tar.xz (beachte: http anstatt https) kannst du dich davon überzeugen.

[fischig]

Das mag wohl so sein, nur:
meine Suchmaschine liefert kein http ohne „s“ im Zusammenhang mit „The Linux Kernel Archives“. Die Eingabe der URL http://www.kernel.org wird sofort in https://www.kernel.org umgewandelt. Und das mit „s“ Zertifikate verlangt werden, ok, weiß außer mir wahrscheinlich jeder Erstklässler!

Wie war das nochmal mit dem öffentlichen Aushang der Pläne für die galaktische Umgehungsstraße?

[KBDCALLS]

Wer wget dazu überreden will/muß ohne gültiges Certifikat zu arbeiten.

• Code: Alles auswählen

  --no-check-certificate

[fischig]

Ich will das mal ein wenig tiefer hängen.

Alles was ich zu kritisieren habe, ist, dass wgets Fehlermeldung so wenig hilfreich war, bzw. dass ich auf keinem„normalen“ Weg, also ohne Insider-Wissen, an Tintoms Url gelangt bin. Ansonsten ist das Thema für mich erledigt.

[eggy]

aber bei Daten, die eh öffentlich im Netz verfügbar sind (z.B. Kernelquellen, Nachrichten), will mir der Mehrwert einer https-Verbindung nicht so recht einleuchten.

Da geht es nicht um Geheimhaltung, sondern darum, dass die Daten auf dem Transportweg nicht manipuliert werden.

Stell Dir folgendes Szenario vor: Alice und Charlie wohnen zusammen in einer WG. Alice läd sich die Kernelquellen herunter, kompiliert ihren Kernel und startet das System. Soweit alles normal. Sie benutzt für den Download das Wlan von Ihrem Mitbewohner Charlie.

Dann erscheint die nächste Kernelversion, wieder läd Alice über Charlies Wlan die Kernelquellen. Inzwischen hat Charlie aber seine "Umbauten" am Wlan fertig gestellt: ein kleiner unscheinbarer transparenter Proxy, der im Regelfall ganz normal arbeitet, nur bei Anfragen an kernel.org statt dem gewünschten Update nun seine Version der Kernelquellen ausliefert. Alice läd die neuen Quellen, baut daraus ihren Kernel und nach dem nächsten Reboot bekommt Charlie jeden Abend ein Protokoll aller Tastendrücke per Mail zugesandt.

Und auf dem Weg zwischen Alice und kernel.org sitzt ja nicht nur Charlie.
Ich hab 14 Hops zu kernel.org, zu cdn.kernel.org sind es noch nen paar mehr.

[MSfree]

Inzwischen hat Charlie aber seine "Umbauten" am Wlan fertig gestellt: ein kleiner unscheinbarer transparenter Proxy...

Dagegen hat man Prüfsummen erfunden, kernel.org nutzt hierzu eine pgp-Signature.

Die pgp-Signature zu einem Kernel-tar.gz kann man auf der Webseite von kernel.org nachsehen. Und man sollte nach dem Download diese pgp-Signature mit der selbst berechneten vergleichen. Sollte da ein Proxy auf dem Weg die Datei manipuliert haben, fällt das beim Signaturenvergleich auf.

Auch harmlosere "Manipulationen", wie Datenübertragungsfehler, kann man mit der Signature einfach aufdecken, sogar. wenn man zur Übertragung unverschlüsseltes HTTP verwendet.

[Lord_Carlos]

Die pgp-Signature zu einem Kernel-tar.gz kann man auf der Webseite von kernel.org nachsehen. Und man sollte nach dem Download diese pgp-Signature mit der selbst berechneten vergleichen. Sollte da ein Proxy auf dem Weg die Datei manipuliert haben, fällt das beim Signaturenvergleich auf.

https://www.kernel.org/category/signatures.html
"Please verify the TLS certificate for this site in your browser before trusting the above information."

Ich nehme an Charlie koennte die ganze Anleitung einfach umschreiben. Wenn Alice sich vorher nicht mit PGP auseinander gesetzt hat ist das auch nicht optimal.

Zugegebenermaßen verstehe ich aber auch nicht, warum die ganze Welt über verschlüsselte Verbindungen kommunizieren will

Kostet ja nichts
Auch kannst du nur sehen auf welche domain ich gehe, schuetzt also auch davor das andere nicht sehen koennen welchen Wikipedia Artikel ich lese. Oder welchen Kernel ich gerade runterlade.

[MSfree]

Kostet ja nichts

Öhm, doch, und das sogar ziemlich heftig.

Früher(c) gab es zahlreiche transparente caching Proxys im Internet, allerdings auch mit den damit verbundenen Gefahren wie der Möglichekeit von Man-in-the-Middle-Manipulationen.

Durch das Caching wurde die Netzlast der Server massiv verringert. Durch die Verschlüsselung muß heute jede Verbindung Point-to-Point aufgebaut werden. So ein Netflix-Serverr muß dann halt mal ein paar Millionen Zuschauer gleichzeitig bedienen. Durch Caching Proxies könnte man das auf ein paar Duzend serverseitige Verbindungen reduzieren. Das bedingt natürlich entsprechend fette Serverhardware, die Geld kostet und Strom verbraucht.

[Lord_Carlos]

Durch das Caching wurde die Netzlast der Server massiv verringert. Durch die Verschlüsselung muß heute jede Verbindung Point-to-Point aufgebaut werden. So ein Netflix-Serverr muß dann halt mal ein paar Millionen Zuschauer gleichzeitig bedienen. Durch Caching Proxies könnte man das auf ein paar Duzend serverseitige Verbindungen reduzieren. Das bedingt natürlich entsprechend fette Serverhardware, die Geld kostet und Strom verbraucht.

Wenn du mehr als 5 Gb/s peak netflix traffic hast, stellt netlfix bei dir ne box auf.
https://openconnect.zendesk.com/hc/en-u ... 0034538352
https://openconnect.netflix.com/de_de/

[Tintom]

Ich will das mal ein wenig tiefer hängen.

Alles was ich zu kritisieren habe, ist, dass wgets Fehlermeldung so wenig hilfreich war, bzw. dass ich auf keinem„normalen“ Weg, also ohne Insider-Wissen, an Tintoms Url gelangt bin. Ansonsten ist das Thema für mich erledigt.

Das Problem ist ein anderes. Menschen vereinfachen Sachverhalte, z.B. "Internet, da muss man www. vorher eingeben". Browser unterstützen dieses Verhalten auch noch, wie in deinem Beispiel mit der automatischen Weiterleitung von http zu https gesehen. Vielleicht möchte ich aber gar nicht über das http-Protokoll zugreifen sondern über ftp. Das korrekte Verhalten wäre etwa so:

$ curl -s -D - http://www.kernel.org -o /dev/null
HTTP/1.1 301 Moved Permanently
<...>
Location: https://www.kernel.org/
<...>

Ich mache eine Anfrage auf die Ressource http://www.kernel.org und der Server sagt mir, dass diese Ressource auf https://www.kernel.org verschoben wurde. Weiter passiert nichts und das ist auch gut so, denn vielleicht möchte ich gar nicht auf die https-Quelle zugreifen.

Wenn dich die Fehlermeldung von wget so sehr stört, kannst du einen Bugreport für das Paket erstellen. Fairerweise muss man aber auch dazu sagen, dass in der Standardeinstellung das Paket ca-certificates zusammen mit wget installiert wird:
$ aptitude show wget
Package: wget
<...>
Recommends: ca-certificates
<...>
Wenn du apt nun angewiesen hast keine recommends zu installieren ist das jetzt kein Problem von wget.

Zugegebenermaßen verstehe ich aber auch nicht, warum die ganze Welt über verschlüsselte Verbindungen kommunizieren will

Kostet ja nichts
Auch kannst du nur sehen auf welche domain ich gehe, schuetzt also auch davor das andere nicht sehen koennen welchen Wikipedia Artikel ich lese. Oder welchen Kernel ich gerade runterlade.

Genau das meine ich. Wenn ich mit einer Tageszeitung in der Fußgängerzone umherlaufe kann das jeder sehen. Welche Informationen leitet ein Betrachter daraus ab? Meinen Bildungsstand? Meine politische Gesinnung? Vielleicht möchte ich aber auch gezielt falsche Informationen streuen und verdecke mit der Tageszeitung das Schmuddelheft darunter. Oder der simpelste Fall: Ich bringe die Tageszeitung nur für jemanden anders mit.

Ich will das auch gar nicht kritisieren, wenn andere Menschen ein Problem damit haben sollen sie weiterhin https-Seiten verwenden.

Die Sache ist nur: Die Zwangsbgelückung mit https führt dazu, dass sich Menschen noch weniger Gedanken machen was sie da eigentlich in die Browserzeile eintippen.

[Lord_Carlos]

Genau das meine ich. Wenn ich mit einer Tageszeitung in der Fußgängerzone umherlaufe kann das jeder sehen. Welche Informationen leitet ein Betrachter daraus ab? Meinen Bildungsstand? Meine politische Gesinnung? Vielleicht möchte ich aber auch gezielt falsche Informationen streuen und verdecke mit der Tageszeitung das Schmuddelheft darunter. Oder der simpelste Fall: Ich bringe die Tageszeitung nur für jemanden anders mit.

Fuer dein ISP* ist es viel viel einfacher HTTP Statistiken zu sammeln und an eine Werbefirma zu verkaufen.
Dich jeden tag zu beobachten was du in der Zeitung liest ist sehr aufwendig.

Ich will das auch gar nicht kritisieren, wenn andere Menschen ein Problem damit haben sollen sie weiterhin https-Seiten verwenden.

Noe, ich will dich auch nicht von https ueberzeugen. Nur erklaeren warum andere es benutzten. Das war ja die Frage.
Es ist einfach .. einfach.
Selbst Forum hier muss eh https sein, sonnst kann man auch die Cookies stehlen. Oder PM mitlesen.


* Oder jemand anderem in Netzwerk.

[fischig]

Ich wollte ja eigentlich hier nichts mehr schreiben, aber sei's drum: Vielleicht findet der eine oder die andere ja meine ob der unerwarteten Fortsetzung der Diskussion umherschweifenden Gedanken doch „nachdenkens“wert:

[@Tintom]
Und das war jetzt kein Insider-Wissen, was du da ausgebreitet hast?
Wie weit würdest du gehen bei der Formulierung des unabdingbaren Vorwissens einer Person, die weiter nichts will, als die Quellen eines Kernels von Kernel.org via wget herunterzuladen?

Wenn dich die Fehlermeldung von wget so sehr stört, kannst du einen Bugreport für das Paket erstellen.

Ich kann das nicht. Und ich werde mich auch nicht um die dafür benötigten Kenntnisse bemühen.[/@Tintom]


Aus sehr berechtigten, aber durchaus nicht alternativlosen Gründen, existiert kein allgemein akzeptiertes Verfahren, dass es auch Tante Tilly ermöglichte, Anmerkungen für Debian-Entwickler/-Betreuer zu formulieren. - Könnte man drüber nachdenken - ist aber nicht mein Bier.

[MSfree]

Wie weit würdest du gehen bei der Formulierung des unabdingbaren Vorwissens einer Person, die weiter nichts will, als die Quellen eines Kernels von Kernel.org via wget herunterzuladen?

Die Frage ist, was bei dir beim ersten Versuch schief gelaufen ist. Ich habe gestern auf Jessie und Buster den wget aus deinem ersten Post durchgeführt und es hat auf Anhieb völlig problemlos und ohne Fehlermeldung funktioniert.

Ich fand es dann doch etwas zu trivial, zu schreiben, daß es bei mir geht. Sowas hilft ja auch in der Regel nicht sonderlich viel. Wir haben ja auch herausgefunden, daß es an den fehlenden ca-certificates lag. Das Paket scheint aber bei einer halbwegs normal verlaufenden Debianiinstallation zum Standardumfang zu gehören. Die Frage muß also eher lauten, was du bei dir anders installiert hattest, daß das Paket nicht vorhanden war.

[fischig]

Das Paket scheint aber bei einer halbwegs normal verlaufenden Debianiinstallation zum Standardumfang zu gehören.

Ich benutze so gut wie nie Standardinstallationen. Und Kernel-Eigenbau ist vielleicht auch nicht gerade Standard. Darf/soll Tante Tilly das nicht mehr können?

Ein „Problem“ hatte ich gar nicht, ich hätte mir auch zu helfen gewusst, wenn's mit wget gar nicht funktioniert hätte. Und abgesehen davon, dass ich's per „Versuch und Irrtum“ selbst herausgefunden hatte, war die Frage nach MaGes zweitem Post auch bereits beantwortet. Tintom hat dann eine weitere Idee eingebracht (http statt https) über den sich jetzt die geneigten Könner im DF den Kopf heiß reden. )

Ich hätte den Thread wohl gar nicht eröffnet, wenn wget mir gesagt hätte, dass es keine gültigen Zertifikate findet, statt mich erst mal glauben zu machen, ich hätte die falschen. Guck dir die gepostete Fehlermeldung an.

[Tintom]

[@Tintom]
Und das war jetzt kein Insider-Wissen, was du da ausgebreitet hast?

Nein, das war eine Wiedergabe von bereits reproduziertem Wissen. Jeder Nutzer von Debian schleppt die Dokumentation in Form von manpages zwangsläufig auf seinem System mit herum. Das ist alles andere als Insider-Wissen.

Wie weit würdest du gehen bei der Formulierung des unabdingbaren Vorwissens einer Person, die weiter nichts will, als die Quellen eines Kernels von Kernel.org via Debianwget herunterzuladen?

Ich setze kein Vorwissen voraus. Aber wenn jemand abseits der ausgetretenen Pfade einer Standardinstallation untwerwegs ist, sind ihm die Forensuche und manpages ein Begriff. Auch muss man den Unterschied zwischen http/s nicht kennen, aber einen Blame auf die Kernelentwickler und wget loszulassen für einen Fehler, den man selbst zu verantworten hat, entbehrt jeder Grundlage.

Ich kann das nicht. Und ich werde mich auch nicht um die dafür benötigten Kenntnisse bemühen.
[...]
kein allgemein akzeptiertes Verfahren, dass es auch Tante Tilly ermöglichte, Anmerkungen für Debian-Entwickler/-Betreuer zu formulieren. - Könnte man drüber nachdenken - ist aber nicht mein Bier.

Du hast anscheinend die Ziele von Debian nicht verstanden - schade. Dein allgemein akzeptiertes Verfahren gibt es schon längst - die Forensuche verrät dir sicher mehr dazu.