• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Probleme mit XCA [erledig]

/dev/null

Moderator
Teammitglied
Hallo Freunde,

ich habe ggw. ein Problem mit einem meiner wichtigsten Programme: mit XCA, einem grafischen Tool zum (schnellen und massenhaften) Erzeugen von X.509-Zertifikaten. Ich nutze dieses Programm seit etlichen Jahren um damit für an E-Mailverschlüsselung interessierte Nutzer jährlich ein paar Hundert Zertifikate für S/MIME zu erzeugen bzw. deren Request zu zertifizieren.
Genutzt wird die aktuelle Version 0.9.3 aus dem offiziellen Repo.

Nach einem Systemupdate der letzten Tage, ich tippe auf openSSL, kommen heute massenhaft Fehlermeldungen in der Art:
Code:
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
OpenSSL error (NewX509_ext.cpp:160) : error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
OpenSSL error (NewX509_ext.cpp:160) : error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
usw.

Schnell alle unter http://software.opensuse.org/package/xca gefundenen Pakete eines nach dem anderen Installiert - bei allen der gleiche Fehler.

Nun den Quellcode heruntergeladen und selbst zu compilieren versucht.
./configure läuft ohne Fehlermeldung durch, lediglich das:
Code:
which: no linuxdoc in (/usr/lib/mpi/gcc/openmpi/bin:/home/peter/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
Application 'linuxdoc' not found.
No documentation will be generated.
aber damit kann ich leben.

make bringt folgende Fehlermeldung, bei welcher ich nicht weiter weiß:
Code:
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: /home/peter/temp/xca-0.9.3/lib/db_crl.o: undefined reference to symbol '_Znwj@@GLIBCXX_3.4'
/usr/lib/gcc/i586-suse-linux/4.8/../../../../i586-suse-linux/bin/ld: note: '_Znwj@@GLIBCXX_3.4' is defined in DSO /usr/lib/libstdc++.so.6 so try adding it to the linker command line
/usr/lib/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

Was ist da mit "adding it to the linker command line" gemeint?
Hier bin ich wirklich am Ende meines "Lateins" und würde mich über Hilfe freuen.


MfG Peter
 

spoensche

Moderator
Teammitglied
/dev/null schrieb:
Code:
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
OpenSSL error (NewX509_ext.cpp:160) : error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
OpenSSL error (NewX509_ext.cpp:160) : error:0D0C40D8:asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding
OpenSSL error (NewX509_ext.cpp:160) : error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
usw.

Tritt der Fehler auch auf, wenn du mittels OpenSSL ein Zertifikat erzeugst?

/dev/null schrieb:
Was ist da mit "adding it to the linker command line" gemeint?
Hier bin ich wirklich am Ende meines "Lateins" und würde mich über Hilfe freuen.

Versuch mal folgendes:
Code:
LIBS=-l stdc++ make
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Hallo spoensche,

und vielen Dank für deine schnelle Antwort!
Der Test der wichtigsten Befehle auf der Konsole (Einrichtung einer Test-CA und ein Schlüsselpaar) war das erste, was ich gemacht habe. Selbstverständlich funktioniert das alles. Ich könnte natürlich die heute und in den nächsten Tagen ablaufenden Zertifikate auf diese Art und Weise erzeugen - aber da meine Nutzer von mir richtige ordentliche Zertifikate mit allen gängigen Attributen einschließlich der Nutzungsbeschränkung für S/MIME usw. gewohnt sind, würde das eine riesige Tipporgie bedeuten. => fällt somit aus.

Aber ich habe nach meinem "Hilferuf" auch weiter im Netz gesucht. Und hier: http://gitweb.hohnstaedt.de/?p=projects/xca.git;a=summary, also auf dem git des Entwicklers, habe ich gesehen, dass da ein (erstmals anderer) Entwickler einen für OpenSSL 1.0.1i erforderlichen Patch veröffentlicht hat. Es tut sich also etwas, und ohne diesen Patch würde also auch das eigene Compilieren der etwas älteren Quellen weiterhin fehlschlagen. Unabhängig von dem beim gestrigen make aufgetretenen Fehler.

Wie ich den Patch selber in die Quellen integrieren kann, ist leider außerhalb meiner Kenntnisse. Programmierung ist nicht mein Thema ... .

Edit, ein paar Minuten später:
Wer lesen kann ist im Vorteil. Neben dem Patch steht "Snapshot", und das scheint der Quellcode mit dem integrierten Patch zu sein. Aber beim make tritt wieder der gleiche Fehler auf.
Ich habe auch
Code:
LIBS=-l stdc++ make
eingegeben, aber das wars auch nicht:
Code:
peter@mars:~/test/xca> LIBS=-l stdc++ make
If 'stdc++' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf stdc++
peter@mars:~/test/xca>

Fragen über Fragen ...

Ich war in den letzten Jahren, und auch noch vor ein paar Monaten, in recht engem Kontakt mit dem Entwickler von XCA. Und er hat mir dann, wo ich ihm einige Ideen zur Weiterentwicklung des Programms gepostet habe mitgeteilt, dass er aus Arbeits- und anderen Gründen nicht mehr so viel Zeit dafür investieren kann. Ich kann das verstehen und akzeptiere es auch. Ich befürchte deshalb, dass dieses schöne Programm totlaufen wird.

Deshalb werde ich, wenn ich am Montag aus dem Urlaub zurück bin, zuerst mal auf dem seit vier Wochen nicht mehr angefassten, also ungepatchten Desktoprechner die in diesem Jahr ablaufenden Zertifikate ersetzen und mir damit etwas "Luft" verschaffen. Dann werde ich wissen, ob es mit XCA weitergeht - oder eben nicht.


MfG Peter
 

abgdf

Guru
Code:
/usr/lib/libstdc++.so.6: could not read symbols: Invalid operation
klingt natürlich böse. (Wenn er nur die Library nicht findet, könnte vielleicht "ldconfig" was bringen. Bin in dem Bereich aber recht unsicher, vielleicht zerschießt man sich damit auch was.) Wenn er die Library findet, aber mit den Funktionen dort nichts anfangen kann, kann man, denke ich, nichts mehr machen.

Mein Tipp: Setz' Dir 'ne ältere Live-Distro auf, ich mag z.B. Puppy Linux 2.14X:
http://www.murga-linux.com/puppy/viewtopic.php?t=42553
http://www.wisdom-seekers.com/puppy214x.html
Das devx-pet dort bringt auch gleich die Compiler mit. Vielleicht geht es ja damit. Dann könntest Du die Output-Dateien auf Dein Hauptsystem rüberkopieren.
Puppy kann von CD oder Stick laufen, aber auch aus einer bereits bestehenden Linux-Partition. Mit dem sog. "Frugal"-Install muß man also keine eigene Partition dafür einrichten, damit es von Festplatte bootet (etwas seltsam, aber cool).
Wenn Dein Programm an neuere Systeme angepaßt ist, kannst Du Puppy (oder eine andere Ersatz-Distro) wieder runternehmen (wenn Du das dann noch willst :) ).
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Auch an dich, abgdf, meinen Dank!

Aber manchmal macht man es sich einfach viel zu schwer.
Es ist ja nicht so, dass ich täglich meine CA anwerfen muss. Ein bis zwei mal im Monat reicht völlig aus, um mein (freiwilliges) "Pensum" abzuarbeiten. Und da fiel mir heute Nachmittag die temporäre Lösung ein, bis vlt. doch noch einmal eine lauffähige Version im Repo liegt:
Ich installiere mir vor dem Start die "h"-Version von openSSL und Ruhe ist! Und danach erfolgt das Update und die Welt ist wieder in Ordnung.

Immer wenn ich den TrueCrypt-Container mit der CA mounte, werden eh sämtliche Netzwerkverbindungen automatisch gekappt. Da kann ich mit den "Unsicherheiten" der "h"-Version von openSSL gut leben. Und für die Erzeugung der Schlüssel spielt openSSL eh keine Rolle, da ich als RNG den selbigen einer für QES geeigneten Chipkarte verwende.

Fazit: Problem zwar nicht gelöst, aber "kaum noch zu sehen".

MfG Peter
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
So, nachdem ich mit dem o.g. "Trick" die CA um Laufen bekommen und alle ablaufenden Zertifikate ersetzt habe, kann ich mich nun noch ein wenig mit dem Problem befassen.

Wie ich schon schrieb, ist in dem Snapshot der Patch bereits integriert (ich habe einfach mal nach dem Inhalt des Paches in den Quellen "gegrept" - Versuch macht kluch, jetzt weiß ich, dass ein Snapshot ... .)
Damit hat sich das mit der Integration des Patches erledigt.

=> Die Fehlermeldung beim make kommt trotzdem noch.
Die Datei "/usr/lib/libstdc++.so.6" wird mit der installierten "libstdc++6" bereitgestellt (Verlinkt auf -> libstdc++.so.6.0.18)
Jetzt habe ich den Befehl "LIBS="-l stdc++"" auf der Konsole ausgeführt (keine Fehlermeldung). So richtig weiß ich nicht, was dieser Befehl macht, hat IMHO was mit "ldconfig" zu tun?

Trotzdem, die Fehlermeldung bleibt beim Compilieren.


Auch wenn mein "Problem" ja durch Austricksen beseitigt werden konnte, würde ich mein zwischen den Ohren liegendes Problem gerne auch noch lösen. Ich bin dir dankbar, wenn du mir weiterhin hilfst.

MfG Peter
 

abgdf

Guru
/dev/null schrieb:
=> Die Fehlermeldung beim make kommt trotzdem noch.
Die Datei "/usr/lib/libstdc++.so.6" wird mit der installierten "libstdc++6" bereitgestellt (Verlinkt auf -> libstdc++.so.6.0.18)
Jetzt habe ich den Befehl "LIBS="-l stdc++"" auf der Konsole ausgeführt (keine Fehlermeldung). So richtig weiß ich nicht, was dieser Befehl macht, hat IMHO was mit "ldconfig" zu tun?

Trotzdem, die Fehlermeldung bleibt beim Compilieren.
Also, 'LIBS="-l stdc++"' würde halt die Variable $LIBS auf "-l stdc++" setzen.
"-l" in einem Makefile sagt, mit welcher Library verlinkt werden soll:

http://stackoverflow.com/questions/519342/what-is-the-difference-between-i-and-l-in-makefile

Das hieße dann also sowas wie "Verlinke mit libstdc++". Weiß nicht, ob das was bringt, das vor dem "make"-Befehl auszuführen. Aber jedenfalls wird ja ohnehin schon - erfolglos - versucht, mit libstdc++ zu verlinken. Insofern beseitigt der Versuch auch die Fehlermeldung (leider) nicht. Nur zur Erklärung ...

Also, ich denke, das Problem liegt tiefer: Der Source-Code ist in dieser Form nicht mit der libstdc++ des Systems kompatibel. Da kann man mit diesem System und diesem Source-Code nicht viel machen. Man müßte eines davon austauschen. Denn libstdc++ ist ja eine fundamentale Systembibliothek, die man auch nicht einfach ändern oder wechseln kann.
In meinen Linux-Anfängertagen hat mal ein Source-Code gesagt, ihm gefalle meine glibc nicht. Na gut, dachte ich, dann halt ohne glibc, und hab' die (als root) einfach gelöscht. Tja, da konnte ich danach nicht mal mehr was eingeben und mußte das System neu aufsetzen. :lol: Seitdem weiß ich, glibc definiert das System, in etwa wie der Kernel. Daran kann man nicht drehen. Wenn beim Kompilieren eine Fehlermeldung in der Richtung kommt, hilft nichts.
Bei libstdc++ ist es leider ähnlich. Ist halt die C++-Standardbibliothek.

Es könnte höchstens sein, daß Du dem Compiler irgendwie (über eine Option) mitteilen kannst, daß Deine Version davon verwendet werden soll und er sich also auf Deine Version einstellt. Das gibt's manchmal.
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
OK, das waren für mich wertvolle Informationen. So tief bin ich in diese Materie noch nie eingestiegen.
Ich denke, wir beenden diese Übung an dieser Stelle. Ich kann das Programm nutzen, und irgendwann werden (wie bisher) radic, lemmy04, ecsos, draht, aevseev oder gar SUSE eine lauffähige Version veröffentlichen.

Warten wirs ab ...

Nochmals vielen Dank!

MfG Peter
 
OP
/dev/null

/dev/null

Moderator
Teammitglied
Ich möchte diese Sache sauber abschließen.

Mit dem heutigen Update wurde u.a. auch XCA auf Version 0.9.3-4.1 gebracht. Und mit dieser Version hat sich auch das von mir gepostete Problem erledigt.
Ich bedanke mich bei (dem garantiert hier nicht mitlesenden) ecsos für seine Arbeit!


MfG Peter
 
Oben