ubuntuusers.de

Hallo,

ich möchte apt-p2p verwenden, zur Datenverteilung ist es laut dem Wiki-Eintrag unter anderem notwendig die Datei /ect/apt/sources.list entsprechend anzupassen, sodass APT zuerst bei Peers nach den angeforderten Paketen sucht und erst wenn das nicht klappt, auf die HTTP-Server zurückfällt.

Nun gut, ich habe das alles wie beschrieben getan - jetzt zur eigentlichen Frage: Ich bekomme nach der Bearbeitung der /etc/apt/sources.list bei jedem Paket von Synaptic die Warnung, dass die Software nicht authentifiziert werden konnte ("Sie haben Software vorgemerkt, die nicht authentifiziert werden konnte") und das heißt dass ich mich an diese Warnung gewöhne, dass es ganz normal wird, dass Pakete nicht authentifiziert werden können.

Und das ist in meinen Augen ein ziemlich heftiges Sicherheitsrisiko. Ich habe die Frage - anders formuliert - auch auf answers.launchpad.net gestellt (siehe https://answers.launchpad.net/ubuntu/+source/apt-p2p/+question/129493), aber bisher keine Antwort erhalten. Vielleicht kann mir ja jemand hier weiterhelfen.

Danke im Voraus!

Hallo StefanNagy,

nachdem du schon im Wiki-Forum gepostet hast, hätte ich erwartet, dass du wenigstens den Thread gelesen hast.

In meinem Beitrag vom 19.4. 18:00 Uhr habe ich nämlich dieses Problem angesprochen:

Awebb hat geschrieben:

Ich frage mich zum Beispiel gerade, ob die Dateien, die per p2p kommen auch anständig verifiziert werden, bevor sie mein System vers... >> verschönen.

Noch einmal: Wenn APT den Schlüssel mit dem ein Paket digital signiert ist nicht kennt, dann meckert es herum. Es gibt mindestens eine Abfrage, ob man das Paket trotzdem installieren möchte!

Weiterhin hat maix geschrieben:

Zur Sicherheit: Wenn du die Dateien vom Mirror runterlädst, könnten sie genauso verändert werden. Aber um eben das zu verhindern, werden die Paketlisten mittels GPG signiert (der entsprechende Schlüssel wird mit der Ubuntu-CD geliefert). Die Paketlisten wiederum stehen zu jedem Paket Prüfsummen, womit nach dem Download die Pakete überprüft werden.

Die Frage lautet also nun: Warum erkennt Synaptic/APT nicht, dass deine Pakete signiert sind. Dazu müsst man mal deine sources.list sehen (Fremdquellen vorhanden?), sowie die apt-p2p-Config durchsehen.

Lade die o.g. Dateien mal bitte hoch (No-Paste-Service) und poste die Links hier.

Torsten

Hallo unbekannt1984, danke für deine Antwort!

Ich hab den Thread - auch bzw. gerade die Zeilen die du daraus zitierst - vollständig und genau gelesen, leider habe ich darin keine Antwort auf meine Frage gefunden. Denn alles in dem Thread, ebenso wie im Wiki, lässt mich erwarten dass APT nach der Anpassung der /etc/apt/sources.list keine solche Sicherheitswarnung ausgibt, da die Pakete ja signiert sind (und die Signatur auch korrekt erkannt werden sollte).

Es macht wohl kaum einen Sinn, dir meine /etc/apt-p2p/apt-p2p.conf hochzuladen: ich habe weder diese Konfigurationsdatei verändert, noch eine Kopie in meinem Homeverzeichnis erstellt (wie im Wiki-Artikel unter "Optionale Einstellungen" beschrieben). Ich habe ein frisches System (Maverick) aufgesetzt, apt-p2p installiert und meine /etc/apt/sources.list angepasst (wie im Wiki-Artikel unter "Anpassung der sources.list" beschrieben). Die Portweiterleitung auf meinem Router wurde ja durch die Neuinstallation meines Systems nicht berührt - trotzdem habe ich nocheinmal verifiziert, dass sie funktioniert.

Hier sind trotzdem die beiden Dateien: meine (für die Verwendung von apt-p2p angepasste) /etc/apt/sources.list & meine (völlig unangetastete) /etc/apt-p2p/apt-p2p.conf

Mittlerweile weiß ich auch, dass es sich um keinen Synaptic-Fehler handeln kann - ich bekomme bei APT (im Terminal) die inhaltlich selbe Fehlermeldung: "WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!" - darunter werden alle gewählten Pakete angeführt, d.h. es gibt keine Ausnahme; nach der Veränderung meiner sources.list kann kein einziges Paket mehr authentifiziert werden.

Zu meiner "frischen Neuinstallation" muss ich eines sagen: Ich habe einige Konfigurationsdateien von meinem alten System gesichert und wieder ins Homeverzeichnis eingefügt, darunter auch das Verzeichnis ~/.gnupg - Ich vermute daher, dass mein Problem nichts mit der Konfiguration von apt-p2p zu tun hat, sondern mit GnuPG, genauer: mit den Schlüsseln zur Verifizierung der Pakete. Daher habe ich dieses Problem nun auch im "Sicherheit"-Forum gepostet.

Aufgrund dieser Vermutung habe ich in Synaptic → Einstellungen → Paketquellen → Authentifizierung einmal alle Einträge (also alle öffentlichen Schlüssel) gelöscht und mir danach im Terminal mit "sudo apt-key update" die aktuellen Schlüssel geholt. Da ich die PUEL-Version von Virtualbox brauche (und die entsprechende Paketquelle verwende), habe ich auch den passenden Schlüssel von der SUN/Oracle-Website neu importiert. Leider hat auch das alles nichts gebracht. Langsam bin ich mit meinem Latein am Ende...

Noch etwas: Die Authentifizierung der Pakete funktioniert völlig problemlos, solange ich nicht meine sources.list anpasse (wie im Wiki-Artikel unter "Anpassung der sources.list" beschrieben). Nach meinem Verständnis sollten die beiden Dinge (also ob ich einen Proxy verwende oder nicht) aber nicht wirklich etwas mit der Authentifizierbarkeit der Pakete zu tun haben, oder? Ich denke irgendwo an diesem Punkt liegt des Rätsels Lösung...

Danke nochmal für deine Antwort unbekannt1984 und danke im Voraus für jede Hilfe!

Hallo StefanNagy,

Mittlerweile weiß ich auch, dass es sich um keinen Synaptic-Fehler handeln kann - ich bekomme bei APT (im Terminal) die inhaltlich selbe Fehlermeldung: "WARNUNG: Die folgenden Pakete können nicht authentifiziert werden!" - darunter werden alle gewählten Pakete angeführt, d.h. es gibt keine Ausnahme; nach der Veränderung meiner sources.list kann kein einziges Paket mehr authentifiziert werden.

Liegt daran, das alle Programme zur Paketverwaltung auf APT zurückgreifen...

Zu meiner "frischen Neuinstallation" muss ich eines sagen: Ich habe einige Konfigurationsdateien von meinem alten System gesichert und wieder ins Homeverzeichnis eingefügt, darunter auch das Verzeichnis ~/.gnupg ...

Alt im Sinne von Ubuntu-Version <10.10 ? Dann wirst du wohl auch den "alten Schlüssel" übernommen haben und die aktuellen überschrieben.

...- Ich vermute daher, dass mein Problem nichts mit der Konfiguration von apt-p2p zu tun hat, sondern mit GnuPG, genauer: mit den Schlüsseln zur Verifizierung der Pakete.

Ja, wäre logisch, wenn nicht:

Die Authentifizierung der Pakete funktioniert völlig problemlos, solange ich nicht meine sources.list anpasse (wie im Wiki-Artikel unter "Anpassung der sources.list" beschrieben).

Wenn GnuPG die Pakete die normal geladen werden authentifizieren kann, die gleichen Pakete (mit gleicher Signatur) über apt-p2p aber nicht, dann stimmt etwas nicht...

Versuch erstmal folgendes:

• öffne eines deiner Pakete mit Gdebi und schaue für welchen Release es ist. Die Pakete liegen ja laut Config in /var/cache/apt-p2p.

• probier mal die Pakete mit den Schlüsseln neu zu installieren (denke http://packages.ubuntu.com/maverick/ubuntu-keyring).

Torsten

Hi unbekannt1984,

Wenn GnuPG die Pakete die normal geladen werden authentifizieren kann, die gleichen Pakete (mit gleicher Signatur) über apt-p2p aber nicht, dann stimmt etwas nicht...

Versuch erstmal folgendes:

• öffne eines deiner Pakete mit Gdebi und schaue für welchen Release es ist. Die Pakete liegen ja laut Config in /var/cache/apt-p2p.

Ich habe vorgestern den Cache vollständig entleert, also sowohl /var/cache/apt als auch /var/cache/apt-p2p gelöscht. Es ist also unmöglich, dass alte Pakete drin sind.

• probier mal die Pakete mit den Schlüsseln neu zu installieren (denke http://packages.ubuntu.com/maverick/ubuntu-keyring).

Hab ich gemacht, bringt leider nichts.

Danke nochmal für deine Hilfe. Ich denk du hast schon Recht - wenn dieselben Pakete direkt vom Mirror bezogen authentifiziert werden können, aber nicht wenn ich einen Proxy verwende, dann weist das schon darauf hin dass irgendwas mit apt-p2p nicht passt...

Andererseits hab ich apt-p2p mit der Option "vollständig entfernen" de- und danach neu installiert (also so dass alle Konfigurationsdateien entfernt wurden). Die sources.list passt auch so würd ich sagen. Das spricht wiederum dafür, dass es nicht an apt-p2p liegen kann.

Irgendwie hab ich die Vermutung dass es deswegen irgendwas mit der GnuPG in APT zu tun hat. Meine eigenen Konfigurationsdateien in ~/.gnupg sollten ja eigentlich gar keine Rolle spielen, weil APT unabhängig von den Benutzerschlüsseln arbeitet (also die Schlüsselverwaltung auf einen eigenen User läuft glaub ich).

Ich schau mal weiter...

Hi unbekannt1984,

ich hab mal eine grundsätzliche Frage: verwendest du eigentlich Maverick?

Der Hintergrund für die blöde Frage ist folgender: Nachdem ich jetzt schon etliche Stunden und sehr viele Nerven in diese Sache reingesteckt habe und nicht mehr weiter wusste, hab ich doch ernsthaft mein System völlig neu aufgesetzt (wieder mit Maverick), dabei formatiere ich die root- und die boot-Partition, nur die Daten auf der home-Partition bleiben erhalten.

Bzgl. der home-Partition mach ich das immer so, dass ich meine Einstellungen (also alle versteckten Dateien in meinem Homeverzeichnis) in einen Ordner ~/Sicherung stecke und dann - das erste mal bevor ich Programme verwende - die Einstellungen die ich haben will wieder in das Homeverzeichnis selbst verschiebe. Also sagen wir mal beispielsweise verschiebe ich dann das Verzeichnis ~/Sicherung/.mozilla wieder zu ~/.mozilla

Diesmal habe ich zuerst einmal alle Konfigurationsdateien völlig im "Sicherung"-Verzeichnis belassen, um nichts unnötiges am neuen, frischen System zu ändern. Das einzige, was ich getan habe war, dass ich das Verzeichnis ~/.gnupg erstellt und dort meinen privaten und meinen öffentlichen Schlüssel reinkopiert habe (also secring.gpg und pubring.gpg).

Vor noch jeglicher Paket-Aktualisierung habe ich als allererstes Paket apt-p2p installiert und sofort meine sources.list entsprechend angepasst. Nun habe ich die Paketquellen universe und multiverse aktiviert und danach ein 'sudo apt-get update' und gleich anschließend ein 'sudo apt-get upgrade' durchgeführt. Und was passiert? WARNUNG: Die folgenden Pakete können nicht authentifiziert werden! 😲

Also wenn du auch auf Maverick unterwegs bist, dann pack ichs jetzt langsam gar nicht mehr. Es kann einfach nicht an der einzigen Änderung liegen die ich durchgeführt habe, also an meinem privaten und öffentlichen Schlüssel - die Benutzerschlüssel werden ja von APT gar nicht angetastet...

Langsam werden meine Vermutungen abwegig, aber: Ist es denkmöglich, dass mein Problem etwas damit zu tun hat, dass ich auf einem vollständig verschlüsselten System (wie im Wiki-Artikel System verschlüsseln beschrieben) arbeite?

Sorry - auch wenn es langsam langweilig wird:

Meine Vermutung ist die, dass es eine 'Sicherheitsstufe' gibt, die wir hier die ganze Zeit ignorieren, nämlich die Authentifizierung der Paketquelle. Es ist die ganze Zeit lediglich die Rede von der Signatur der Pakete und den Prüfsummen in den Paketlisten bzw. den einzelnen Paketen. Ich vermute, dass es eine dritte Authentifizierung gibt, und das ist die der Paketquelle selbst - und nur daran scheitert die Prüfung der Authentifizierung meiner Pakete.

Unter dieser Perspektive macht es dann auch Sinn, wenn dieselben Pakete zuerst problemlos authentifiziert werden können und dann nicht mehr - und zwar nur weil ich in meiner sources.list an jede Paketquelle ein http://localhost:9977/ hänge.

Nur eines hält mich von dieser Interpretation ab: Dass niemand außer mir das Problem hat (oder es zumindest nicht als Problem wahrnimmt). Es wäre wirklich sehr hilfreich, wenn andere apt-p2p User mir sagen könnten ob sie das was ich beschreibe bestätigen können oder nicht. Danke im Voraus!

StefanNagy hat geschrieben:

Unter dieser Perspektive macht es dann auch Sinn, wenn dieselben Pakete zuerst problemlos authentifiziert werden können und dann nicht mehr - und zwar nur weil ich in meiner sources.list an jede Paketquelle ein http://localhost:9977/ hänge.

Wenn dem so wäre, würde ich die sources.list wieder in ihren ursprünglichen Zustand versetzen und APT für die Nutzung eines Proxys konfigurieren (hat die selbe Wirkung wie das ändern der sources.list). Jedoch habe ich (mit apt-cacher und apt-cacher-ng) beide Varianten genutzt und nie diese Warnungen bekommen.

ich hab mal eine grundsätzliche Frage: verwendest du eigentlich Maverick?

Ja, ich habe meinen Server (Konsolen-System) jetzt auf Maverick aktualisiert. Auf Desktop und Laptop laufen (noch) ältere Versionen (allerdings Kubuntu) ...

Langsam werden meine Vermutungen abwegig, aber: Ist es denkmöglich, dass mein Problem etwas damit zu tun hat, dass ich auf einem vollständig verschlüsselten System (wie im Wiki-Artikel System verschlüsseln beschrieben) arbeite?

Möglich wäre so ziemlich alles, aber wahrscheinlich ist es nicht. Da du mittlerweile wieder Pakete im apt-p2p-cache liegen hast würde ich vorschlagen das du erstmal das, was ich in meinem zweiten Post geschrieben habe machst (öffnen mit Gdebi).

Weiterhin könnte dir dieser Artikel in unserem Wiki helfen.

Torsten

Hi Torsten,

die Konfiguration von APT für die Nutzung eines Proxys (also apt-p2p) funktioniert bei mir gar nicht.

Ich habe zwei Dinge probiert: Einerseits in Synaptic unter Einstellungen → Einstellungen → Netzwerk → Manuelle Proxy-Konfiguration aktiviert → HTTP-Proxy: localhost (ich habs auch mit 127.0.0.1) probiert & Port: 9977. Wenn ich das so mache, krieg ich beim neu laden der Paketquellen einen 500 Internal Server Error [IP: 127.0.0.1 9977].

Wenn ich APT selbst (also nicht Synaptic) für die Nutzung eines Proxys konfiguriere, also die Datei /etc/apt/apt.conf.d/01proxy mit dem Inhalt

Acquire::http { Proxy "http://127.0.0.1:9977"; };

erstelle, dann bekomme ich dieselbe Meldung, also 500 Internal Server Error [IP: 127.0.0.1 9977].

das apt-p2p Log wirft dann folgendes aus: Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.

Hast du eine Idee woran das liegen könnte? Muss ich für die Konfiguration von APT für die Nutzung eines Proxys irgendwas zusätzlich installieren (also apt-cacher-ng oder sowas)? Ich versteh die Struktur des Wiki-Eintrages dazu nicht ganz, weil die Beschreibung einer Proxy-Nutzung im Artikel zu Lokale Paketquellen/Apt-Cacher-ng (Abschnitt „Apt-fuer-Nutzung-eines-Proxys-konfigurieren“) steht (und nicht in einem allgemeinen Artikel zur Paketverwaltung), aber es ja z.B. sinnlos wäre wenn Synaptic in den Einstellungen einen Reiter für die Einrichtung eines Proxys hätte, wenn das ohne Installation eines zusätzlichen Pakets gar nicht funktioniert...

Wäre super wenn du mir da weiterhelfen könntest. Danke!!

Hallo StefanNagy,

die Konfiguration von APT für die Nutzung eines Proxys (also apt-p2p) funktioniert bei mir gar nicht.

Das steht eigentlich im Widerspruch zu folgendem (von der Projekt-Homepage):

...Apt-P2P will act as a proxy between apt requests and a debian repository server...

Möglich wäre, dass dein Loopback-Interface eine andere IP nutzt, dann sollte es jedoch zumindest mit localhost funktionieren.

Also mit folgendem Inhalt in der 01proxy:

Acquire::http { Proxy "http://localhost:9977"; };

Abgesehen davon mit dem Proxy herumzuspielen, hast du auch noch was anderes von dem, was ich gepostet habe, probiert?

Torsten

die Konfiguration von APT für die Nutzung eines Proxys (also apt-p2p) funktioniert bei mir gar nicht.

Das steht eigentlich im Widerspruch zu folgendem (von der Projekt-Homepage):

...Apt-P2P will act as a proxy between apt requests and a debian repository server...

Tschuldige, ich hab mich da missverständlich ausgedrückt. Was ich meine ist, dass ich den apt-p2p Proxy mit APT anscheinend nur nutzen kann, wenn ich die Adresse des Proxys direkt in die sources.list eintrage (wie im Wiki-Artikel zu apt-p2p beschrieben) - die beiden anderen Methoden, APT zur Nutzung eines Proxys zu bringen (also über die Einstellungen in Synaptic oder die Konfigurationsdatei von APT - wie im Wiki-Artikel zu Lokale Paketquellen/Apt-Cacher-ng (Abschnitt „Apt-fuer-Nutzung-eines-Proxys-konfigurieren“) beschrieben) funktioniert gar nicht, also führt zu der genannten Fehlermeldung. Das wundert mich, weil ich dachte ich würde damit dasselbe bewirken wie wenn ich den Proxy direkt in die sources.list eintrage.

Ich habe auch ausprobiert, die Datei /etc/apt/apt.conf.d/01proxy mit dem von dir genannten Inhalt, also localhost statt 127.0.0.1 zu erstellen. Das bringt nichts, die Fehlermeldung bleibt dieselbe (mein Loopback-Interface nutzt schon 127.0.0.1). Außerdem wäre das nicht denkbar, weil ja das apt-p2p Log wie schon gesagt auch eine Fehlermeldung auswirft: Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.

Zu deinen anderen beiden Hinweisen:

Ich habe versucht ein Paket mit Gdebi (sowie auch mit Gdebi-gtk) zu öffnen und nachzuschauen für welchen Release es ist. Die Info hab ich leider weder in Gdebi noch in Gdebi-gtk gefunden, es wird nur die Paketversion angezeigt. Aber nachdem Gdebi-gtk bei einigen Paket angegeben hat, dass das Paket in derselben Version bereits installiert ist werden es wohl die richtigen Pakete für Maverick sein.

Den von dir verlinkten Artikel hab ich gelesen und auch alles, was unter Paketverwaltung unbrauchbar steht ausprobiert. sudo apt-get check gibt keinerlei Fehlermeldung aus und auch sonst scheint alles OK zu sein.

Hallo StefanNagy,

ich habe gerade mit

sudo apt-key list 

die Schlüssel von meinem Server (Maverick) und meinem Desktop (noch Karmic) verglichen. Da die Schlüssel identisch sind kannst du diese nicht überschrieben haben. Zur Sicherheit kannst du dies aber noch einmal mit der folgenden Ausgabe vergleichen:

/etc/apt/trusted.gpg
--------------------
pub   1024D/437D05B5 2004-09-12
uid                  Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
sub   2048g/79164387 2004-09-12

pub   1024D/FBB75451 2004-12-30
uid                  Ubuntu CD Image Automatic Signing Key <cdimage@ubuntu.com>

Also müsste man den Fehler in der Funktionalität von apt-p2p suchen. Es könnte meiner Ansicht nach an der http-Ersatzverbindung liegen.

Versuch mal den Mirror auf de.archive.ubuntu.com oder den Haupt-Server archive.ubuntu.com zu wechseln. Evtl. hat es ja mit zu seltener Aktualisierung deines Mirrors (bzw. zu wenigen Benutzern dieses Mirrors) zu tun.

Torsten

Hi unbekannt1984,

jaaaaa - das wars!! Also irgendwas hat es mit dem österreichischen Mirror zu tun. Beim der Verwendung des deutschen Mirror oder des Hauptservers tritt das Problem nicht auf. Ich möchte den Thread aber noch nicht auf "gelöst" setzen - mir ging es ja nicht primär darum dass ich diese Fehlermeldung nicht sehen will, sondern ich wollte wissen woran es liegt um das Problem generell zu lösen.

Also jetzt stellt sich noch die Frage, woran es liegt dass dieser Fehler bei Verwendung des österreichischen Mirror auftritt. Ich glaube nicht dass es an der Anzahl der Peers liegt, weil ich teilweise dich einiges von Peers heruntergeladen hab und auch zu Peers hochgeladen hab als ich den österreichischen Mirror verwendet hab...

Vielleicht wär es sinnvoll, einfach mal mit den Betreibern des Mirrors zu sprechen. Ich werde das mal probieren bzw. mal die Leute im Channel #ubuntu-mirrors auf FreeNode ansprechen und dann wieder hier posten.

DANKE jedenfalls für deine Hilfe, Torsten!! 👍

Hallo StefanNagy,

jaaaaa - das wars!!

es freut mich, wenn ich dein Problem lösen konnte (bzw. den entscheidenden Hinweis liefern konnte).

Also jetzt stellt sich noch die Frage, woran es liegt dass dieser Fehler bei Verwendung des österreichischen Mirror auftritt. Ich glaube nicht dass es an der Anzahl der Peers liegt, weil ich teilweise dich einiges von Peers heruntergeladen hab und auch zu Peers hochgeladen hab als ich den österreichischen Mirror verwendet hab...

Wie ich in meinem letztem Post geschrieben habe könnte der österreichische Mirror zu selten aktualisiert werden (also Synchronisation mit dem Hauptserver). Das führt dann zu einer veralteten packages.gz bzw. die gpg-Datei mit den Signaturen der Pakete. Jetzt bekommst du aber über andere Peers schon Pakete die in den Dateien deines Mirrors nicht auftauchen, weshalb diese auch nicht verifiziert werden können.

Derzeit sind ca. 570 (Zahl aus dem Wiki zu apt-cacher-ng) Mirrors bekannt, also ist es nicht verwunderlich, wenn da mal einer nicht ganz so aktuell ist.

Diese Erkenntnis (bzw. die Warnung apt-p2p nicht mit den at-Servern zu verwenden) könnte dann jetzt im Wiki-Thread und im Artikel untergebracht werden.

Torsten

Hallo,

unbekannt1984, danke nochmal für deine Hilfe! Ich kann apt-p2p jetzt problemlos verwenden. Aber auch wenn wir jetzt eine gute Möglichkeit gefunden haben das Problem zu umgehen, besteht es weiterhin. Ich kann es nach wie vor durch Eintragung des österreichischen Mirrors (at.archive.ubuntu.com) reproduzieren.

Die Vermutung von unbekannt1984 (dass es etwas mit der Verzögerung bei der Synchronisation des österreichischen Mirrors mit dem Hauptserver zu tun hat) trifft ziemlich sicher nicht zu. Ich habe mir auf der Liste Official Archive Mirrors for Ubuntu andere Country Mirrors gesucht, die bei der Synchronisation "hinterherhinken" und konnte mit keinem einzigen dieser Server das Problem reproduzieren.

Außerdem hat mir der Autor des Programms, Cameron Dale, auf meine Frage hin geantwortet:

apt-p2p only verifies that the files returned are exactly the ones you requested. If the mirror is out of date, that could definitely cause the problems you are seeing. But it is not a problem with apt-p2p, you could get the same problems using apt directly with an out of date mirror.

Also sollte das Problem ja auch ohne Verwendung von apt-p2p beim betroffenen Mirror auftreten - was aber nicht der Fall ist.

In einem nächsten Schritt habe ich der lagis Internet Serviceprovider GmbH geschrieben, die den österreichischen Ubuntu Country Mirror hostet. Die können sich das Problem auch nicht erklären:

Wir aktualisieren unseren Mirror via Push-Mirroring, d.h. wir erhalten bei jeder Änderung des Archives einen Trigger, der die Aktualisierung auslöst. Damit sollten wir immer so nahe am offiziellen Letztstand sein wie möglich. Wir verwenden auch das vorgeschriebene Zweistufenverfahren, sodass der interne Zustand des Mirrors immer konsistent ist: Die Paketindizes listen nur Pakete, die auch tatsächlich auf unserem Mirror vorhanden sind.

Daher können wir uns derartige Fehler nicht erklären, vor allem nicht, warum dieser angeblich nur mit unserem Mirror auftritt. Wir vermuten aber, dass das Problem in der Art der Verifikation liegt, die apt-p2p durchführt bzw. woher dieses die Indizes bezieht.

Seitdem stehe ich etwas an - ich weiß nicht wirklich weiter. Daher wollte ich euch mal bitten, ob ihr mal probieren könntet das Problem zu reproduzieren. Alles was dazu nötig ist, ist die Installation von apt-p2p und danach eine Portfreigabe sowie die Anpassung der sources.list wie im Wiki-Artikel zu apt-p2p beschrieben - natürlich mit Verwendung des österreichischen Country Mirrors (at.archive.ubuntu.com). Danach die Paketlisten mit sudo apt-get update aktualisieren und mit Synaptic oder sudo apt-get install versuchen, ein Paket zu installieren. Wenn ihr eine Sicherheitswarnung bekommt, dass das Paket (bzw. die Pakete) nicht authentifiziert werden konnte(n) habt ihr das selbe Problem wie ich (bitte probiert es mit mehreren Paketen, ihr müsst sie eh nicht wirklich installieren - die Fehlermeldung kommt vor der letzten Bestätigung der Installation; es gibt einige wenige Pakete, bei denen das Problem nicht auftritt).

Ich hätte gern einfach mal die Bestätigung dass ich nicht der einzige bin, bei dem das Problem auftritt. Dann könnte ich auch den diesbzgl. Bugreport-Status endlich mal auf Confirmed setzen. Danke im Voraus!