Python Openssl Problem nach Update

J

JochenF

Well-Known Member
Langsam wird FreeBSD anstrengend. Nach dem heutigen Update (pgk upgrade gefolgt von portmaster -a) geht mein Gajim nicht mehr. Hat jemand eine Idee was da los ist? Wenn sowas häufiger vorkommt wechsel ich wieder zurück zu Debian. :-(

Code: 
Traceback (most recent call last):
  File "gajim.py", line 74, in <module>
    import nbxmpp
  File "/usr/local/lib/python2.7/site-packages/nbxmpp/__init__.py", line 14, in <module>
    from . import simplexml, protocol, auth_nb, transports_nb, roster_nb
  File "/usr/local/lib/python2.7/site-packages/nbxmpp/auth_nb.py", line 40, in <module>
    from . import rndg
  File "/usr/local/lib/python2.7/site-packages/nbxmpp/rndg.py", line 25, in <module>
    import OpenSSL.rand
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/__init__.py", line 8, in <module>
    from OpenSSL import rand, crypto, SSL
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/rand.py", line 11, in <module>
    from OpenSSL._util import (
  File "/usr/local/lib/python2.7/site-packages/OpenSSL/_util.py", line 4, in <module>
    binding = Binding()
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 113, in __init__
    self._ensure_ffi_initialized()
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/openssl/binding.py", line 123, in _ensure_ffi_initialized
    cls._modules,
  File "/usr/local/lib/python2.7/site-packages/cryptography/hazmat/bindings/utils.py", line 31, in load_library_for_binding
    lib = ffi.verifier.load_library()
  File "/usr/local/lib/python2.7/site-packages/cffi/verifier.py", line 84, in load_library
    return self._load_library()
  File "/usr/local/lib/python2.7/site-packages/cffi/verifier.py", line 177, in _load_library
    return self._vengine.load_library()
  File "/usr/local/lib/python2.7/site-packages/cffi/vengine_cpy.py", line 149, in load_library
    raise ffiplatform.VerificationError(error)
cffi.ffiplatform.VerificationError: importing '/usr/local/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_f77e154ax78a85b26.so': /usr/local/lib/python2.7/site-packages/cryptography/_Cryptography_cffi_f77e154ax78a85b26.so: Undefined symbol "SSLv2_client_method"
 
schau mal, ob security/py-openssl und net-im/py-nbxmpp installiert sind. Sieht so aus, als könnte er eines der Module nicht importiert werden.

Offtopic Frage an alle: wie markiere ich denn am besten Ports hier im Forum?
Manche schreiben die ja in rot und verlinken die gleich. Gibt's da ne Art Makro dazu oder macht ihr das manuell?
 
JochenF schrieb:
Nach dem heutigen Update (pgk upgrade gefolgt von portmaster -a) geht mein Gajim nicht mehr.
Zum Vergrößern anklicken....
pkg upgrade gefolgt von portmaster -a? Was soll das für einen Sinn machen? Du aktualisierst alles per Package und danach dann nochmal per ports? Wenn du ports verwenden willst, dann reicht portmaster. Wenn du Packages verwenden willst reicht pkg upgrade.

Zum Problem: Lass mal "pkg_libchk -qo" (aus den sysutils/bsdadminscripts) laufen und poste die Ausgabe.

HTH
 
JochenF schrieb:
Wenn sowas häufiger vorkommt wechsel ich wieder zurück zu Debian. :-(
Zum Vergrößern anklicken....
Da das jetzt sehr Offtopic ist, mache ich einen eigenen Beitrag draus. Sonderlich breittreten will ich das jedoch nicht.

Bei Debian hast du
- wenn du stable fährst: ein gajim, das älter ist als deine Oma.
- wenn du unstable fährst: ein ähnlich aktuelles gajim wie bei FreeBSD, dass du aber - wenns blöd läuft - ebenfalls nicht nutzen kannst, weil das ganze System kaputt ist. Bei FreeBSD hast du vielleicht EINEN kaputten Port, da FreeBSD aber das System und die Ports trennt, ein System dass funktioniert.

Das ist KEIN Debian-Bashing. Das ist meine ganz persönliche Erfahrung, die ich nach gut 10 Jahren Debiannutzung gemacht habe. Bei FreeBSD sind es wohl bald ebenfalls 10 Jahre. Ich kann mit dieser "Einschränkung", dass mal ein Port nicht geht, gut leben. ;)
 
Folgendes scheint passiert zu sein:

Das Paket security/py-cryptography baut sich dynamisch eine library zusammen, welche u.a. Symbole aus der openssl Library enthält. Nun wurde diese offenbar durch ein Update aktualisiert und enthält das SSLv2 nicht mehr. Da sich py-cryptography aber nicht geändert hat, wurde auch diese dynamisch erzeugte Library nicht erneuert. Ein Neubau von py-cryptography aus den Ports hat das Problem gelöst.
 
Das hört sich doch gut an. Allerdings habe ich das mit pkg upgrade/portmaster -a noch nicht verstanden. Bitte berichtige mich: mit pkg upgrade holst du dir die neue Packagedatenbank und aktualisierst gleichzeitig alle installierten Pakete. Danach führst du (zB) portsnap fetch update aus um den Portstree zu aktualisieren. Danach kommt noch ein portmaster -a. Letzteres bewirkt doch aber, dass alle installierten Packages/Ports aktualisiert werden. Also auch genau die, die du gerade mit pkg upgrade geholt hast (sofern es bereits eine neuere Version gibt)?
 
Columbo0815 schrieb:
mit pkg upgrade holst du dir die neue Packagedatenbank und aktualisierst gleichzeitig alle installierten Pakete.
Zum Vergrößern anklicken....

Nicht alle. Nur die, die nicht gelocked sind.

Columbo0815 schrieb:
Danach führst du (zB) portsnap fetch update aus um den Portstree zu aktualisieren. Danach kommt noch ein portmaster -a. Letzteres bewirkt doch aber, dass alle installierten Packages/Ports aktualisiert werden.
Zum Vergrößern anklicken....

Nur die, die jetzt in den Ports immer noch neuer sind. Im Idealfall genau die gelockten. In der Praxis aber offenbar ein paar mehr, weil die Binärpakete offenbar hinterher hinken.
 
Ok, an Locking hätte ich aber auch denken können. Danke für die Erläuterung. :) Ich bleibe dennoch bei "Ports-only"
 
Wenn du noch 11-CURRENT nutzt ist es unvermeidbar, dass die Pakete inkompatibel sein können. Es gibt schließlich keine definierte ABI, stattdessen nur ein flüchtiges Ziel dem man mit etwas Abstand folgt.
 
Das Problem besteht sicher auch in 10.1. py-cryptography setzt nicht nur eine ganz bestimmte Version von openssl voraus, sondern auch noch eine ganz bestimmte Konfiguration. Wenn man das Paket baut, analysiert es die aktuell vorhandene openssl Bibliothek und baut sich daraus eine Bibliothek mit Python Bindings zusammen. Sobald sich auch nur eine klitzekleine Kleinigkeit ändert, passen die nicht mehr zusammen. Bei Debian könnte man das Problem lösen, indem man in den Paketabängigkeiten eine ganz bestimmte Version verlangt. Sobald openssl aktualisiert würde, wäre diese Bedingung nicht mehr erfüllt, und die neue openssl Bibliothek würde sich nicht installieren lassen. Zumindest wäre man so gewarnt und es würde kein Schaden entstehen. Bei FreeBSD hingegen lässt sich openssl problemlos aktualisieren und den Schaden hat dann py-cryptography.

Nachdem was ich bisher über FreeBSD Packages und Ports gelernt habe, halte ich die Debian Paketverwaltung für ausgereifter. Es wird da zwar immer über die "Dependency Hell" geschimpft, aber gerade das bewahrt einen ja vor Schäden. Für den Entwickler sicher ein größerer Aufwand, bietet dafür aber auch mehr Sicherheit für den Nutzer.
 
Ich werde mein Thinkpad wohl nächste Woche wieder auf Debian Wheezy zurückstellen. Das FreeBSD 11 macht mir einfach zuviel Arbeit. Momentan läuft zwar wieder alles, aber jetzt kommt auch noch dazu dass der Lüfter fast durchgehend läuft, trotz durchschnittlich nur 1% CPU-Last (war vor dem Update glaube ich nicht so, oder es ist mir nicht aufgefallen).

Columbo0815s Meinung was aktuelle Software betrifft teile ich nicht. Die Software aus Debian Wheezy tut was sie soll, auch wenn sie "älter als meine Oma" ist. Ich wüsste nicht was einen aktuellen Jabber-Client von einem unterscheidet der 2 Jahre alt ist. Mir ist ein stabiles System um das ich mich nicht kümmern muss lieber, als immer aktuelle Software mit immer aktuellen Bugs. Aber darüber braucht man nicht diskutieren, das ist reine Geschmackssache. Ich werde auch nicht auf Debian Jessie upgraden (wegen systemd), sondern das Support-Ende von Wheezy abwarten, dann nochmal FreeBSD anschauen und dann entscheiden.
 
JochenF schrieb:
Ich wüsste nicht was einen aktuellen Jabber-Client von einem unterscheidet der 2 Jahre alt ist. Mir ist ein stabiles System um das ich mich nicht kümmern muss lieber, als immer aktuelle Software mit immer aktuellen Bugs. Aber darüber braucht man nicht diskutieren, das ist reine Geschmackssache.
Zum Vergrößern anklicken....
Ich gebe dir Recht, was die Diskussion anbetrifft. Diese möchte ich auch nicht lostreten. Du darfst benutzen was du möchtest, wenn du glücklich mit Debian bist, dann ist das doch gut! Ich möchte dir jedoch von meiner Erfahrung berichten. Sollte dir das zu Offtopic sein, können wir das gerne per PN weiterführen (sollte es dich überhaupt interessieren). Ich übertreibe in meinem Beispiel absichtlich. ;)

Stell dir Programm XY vor, das bei Debian in Version 1.0 vorliegt. Aktuell gibt es die Version 1.4. In der Version 1.4 sind im Vergleich zu Version 1.0 insbesondere neue Funktionen enthalten (diese brauchen wir nicht, also stört uns die alte Version nicht). Nun erscheint Version 1.5. In dieser Version wurden viele Bugs beseitigt, die insbesondere die neuen Funktionen betreffen. ABER: Es wurde auch ein sicherheitskritischer Bug entdeckt und bereinigt, der bis zur Version 0.9.5 zurückreicht, also auch unsere Version 1.0 betrifft.

Das Projekt XY bereinigt diesen Bug natürlich nur in der aktuellen Version. Wenn Debian meint, es muss die Version 1.0 ausliefern und die „Richtlinien“ erlauben keine neue Version, ist Debian also auf sich gestellt, diesen sicherheitskritischen Bug in der Version 1.0 zu bereinigen. Wer informiert Debian hierüber? Das Projekt XY bestimmt nicht. Also muss z.B. der Debian-Maintainer des Programmes sich ständig über die Änderungen des Projektes informieren. Woher will er wissen, dass der Bug auch in der Version 1.0 enthalten ist? Viele Projekte prüfen das nicht. Wozu auch? Der Bug ist ja in der aktuellen Version bereinigt. Also muss der Maintainer die eingereichten Patches lesen und verstehen, dass dieser Fehler auch in der alten Version ist. Nur ist nun blöderweise die Codezeile 127, die den Fehler enthält in der Version 1.5 in der Zeile 867, weil viele neue Funktionen den Code aufgebläht haben. Ist das nicht extrem aufwändig und vor allem fehleranfällig?

Auf ein Zusatz“problem“, auf das du dich einlässt, gehe ich jetzt nicht ausführlich ein: Du brauchst in 4 Wochen ein Multimediaprogramm. In der verfügbaren Version ist es jedoch nicht enthalten. -> Backports.
 
Ganz konkret könnte in diesem Fall auch hineinspielen, dass FreeBSD zwischen Ports / Paketen und dem Basissystem unterscheidet. Wenn im Basissystem OpenSSL aktualisiert wird, ist es für die Pakete erst einmal unsichtbar. Poudriere (das Programm, was die Pakete baut) hat keinerlei Möglichkeit zu erkennen, dass sich OpenSSL geändert hat und die darauf aufbauenden Pakete zu aktualisieren. In den -STABLE Branches ist das kein Problem, da es keine inkompatiblen Änderungen gibt. In -CURRENT allerdings schon. Daher wird auf den Buildern für -CURRENT ab und an ein kompletter Neubau von allem gemacht. Aber zwischen den Änderungen im Basissystem und dem kompletten Neubau können Lücken sein, die dann zu solchen Problemen führen.

Eine mögliche Lösung wäre, eine zweite Kategorie spezieller Basissystempakete einzuführen. Das Basissystem wird ebenfalls in Pakete zerlegt, allerdings werden sie von pkg anders als normale Pakete behandelt. Das würde auch das Problem von Binärupdates für das Basissystem lösen. Dieser Vorschlag traf aber nicht auf viel Gegenliebe, da man FreeBSDs harte Trennung von Basissystem und Paketen unterlaufen würde. Daher wurde er meines wissen zumindest vorerst nicht mehr weiter verfolgt.
 
JochenF schrieb:
Ich werde mein Thinkpad wohl nächste Woche wieder auf Debian Wheezy zurückstellen. Das FreeBSD 11 macht mir einfach zuviel Arbeit. Momentan läuft zwar wieder alles, aber jetzt kommt auch noch dazu dass der Lüfter fast durchgehend läuft, trotz durchschnittlich nur 1% CPU-Last (war vor dem Update glaube ich nicht so, oder es ist mir nicht aufgefallen).
Zum Vergrößern anklicken....

Da könnte dir so was wie thinkfan unter Linux helfen. Einige Thinkpads regeln die Lüfter anhand vom falschen Temperaturwert, weswegen der Lüfter immer läuft. Indem man die Lüftersteuerung manuell regelt, kann man das umgehen. Ich habe zu Hause eine Version von dem Skript, wenn ich bis morgen nix gepostet habe, erinnere mich noch mal daran.
 
Hier ist es:

Code: 
#!/bin/sh

# v0.2

# (C) 2013 Lars Engels <lars.engels@0x20.net>
#
#   BSD-style copyright and standard disclaimer applies.


sysctl="/sbin/sysctl"

check_interval=3

fan_max=7
fan_min=0


fan_level_mib="dev.acpi_ibm.0.fan_level"
#thermal_mib="dev.cpu.0.temperature"
thermal_mib="dev.acpi_ibm.0.thermal"
auto_control_mib="dev.acpi_ibm.0.fan"

level_1=35
level_2=40
level_3=45
level_4=50
level_5=55
level_6=60
level_7=65

print_verbose() {
    [ -n "${verbose}" ] && echo "$@"
}

enable_auto_control() {
    print_verbose "Enabling Fan auto control."
    ${sysctl} ${auto_control_mib}=1 2>/dev/null
}

disable_auto_control() {
    print_verbose "Disabling Fan auto control."
    ${sysctl} ${auto_control_mib}=0 2>/dev/null
}

get_fan() {
    ${sysctl} -n ${fan_level_mib}
}

set_fan() {
    ${sysctl} ${fan_level_mib}=${1} >/dev/null
}

exit_nomodule() {
    echo "No MIB ${auto_control_mib} found! Is acpi_ibm.ko not loaded?"
    exit 1
}

print_status() {
    ${sysctl} -n ${thermal_mib} 2>/dev/null |
    while read cpu_temp mpci_temp hdd_tmp gpu_tmp ibatt_temp ubatt_temp crap; do
            echo "CPU:              ${cpu_temp}"
            echo "Mini PCI Module:  ${mpci_temp}"
            echo "HDD:              ${hdd_tmp}"
            echo "GPU:              ${gpu_tmp}"
            echo "Built-in battery: ${ibatt_temp}"
            echo "UltraBay battery: ${ubatt_temp}"
        echo "Fan Level:        $(get_fan) of ${fan_max}"
    done
}

trap print_status INFO
trap enable_auto_control INT


[ "${1}" = "-v" ] && verbose=1

disable_auto_control || exit_nomodule

while sleep ${check_interval}; do
    cur_temp=$(${sysctl} -n ${thermal_mib} | cut -d" " -f1)

    if   [ ${cur_temp} -lt ${level_1} ]; then
        level=${fan_min}
    elif [ ${cur_temp} -lt ${level_2} ]; then
        level=1
    elif [ ${cur_temp} -lt ${level_3} ]; then
        level=2
    elif [ ${cur_temp} -lt ${level_4} ]; then
        level=3
    elif [ ${cur_temp} -lt ${level_5} ]; then
        level=4
    elif [ ${cur_temp} -lt ${level_6} ]; then
        level=5
    elif [ ${cur_temp} -lt ${level_7} ]; then
        level=6
    else
        level=7
    fi

    set_fan ${level}
    print_verbose "Temperature=${cur_temp};Fan-Level=${level}"
done
 
Danke für die Hinweise zur Lüftersteuerung. Werde ich mir mal gut merken. Bin momentan wieder zurück zu CrunchBang Linux. Die Updaterei von dem FreeBSD 11 war mir auch irgendwie zu nervig und anstrengend. Wenn das zum Release wird werde ich vielleicht noch mal einen Wechsel wagen. Das 10.1 ist ja leider auf meinem T61 nicht zu gebrauchen, 5 GHz WLAN funktioniert da nicht, und Suspend/Resume geht auch nicht.
 
Gestern habe ich mal das FreeBSD wieder zurück auf die Platte gespielt und die beiden Lüfterprogramme getestet. Funktioniert im Prinzip, aber nicht so gut wie Thinkfan aus dem Linux. Das liegt an der fehlenden Hysterese an den Schaltpunkten. Aber mit den Beispielen kann ich Thinkfan portieren, und dann sollte es eigentlich genauso gut funktionieren.
 
Ah, danke! Dann werkel du mal an der Portierung von thinkfan. Wenn du fertig bist, wäre ich am Ergebnis interessiert, so etwas kann man immer gebrauchen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben