Libelektra: fcrypt / gpgme / crypto: Testfall schlägt fehl

Anscheinend ist auch gpgme betroffen:

 62/137 MemCheck #103: testmod_gpgme ....................***Failed   44.22 sec

GPGME        TESTS

==================

[repetitions cut]


GPGME        TESTS

==================


OK closing connection

Terminating gpg-agent returned with status “256”GPGME        TESTS

==================


/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:227: error in test_encryption_decryption: kdb get failed

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:243: error in test_encryption_decryption: key type not restored to string during decryption

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:244: error in test_encryption_decryption: key content not restored during decryption

/home/jenkins/workspace/libelektra_PR-1950-LKQXQDFYJCAZVRKFRKER3H4ZYYVI5QHMP5O7HG5TCW7WRVITCO5A/src/plugins/gpgme/testmod_gpgme.c:254: error in test_encryption_decryption: key content not restored during decryption


gpgme Results: 45 Tests done — 4 errors.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-1950/34/pipeline

@petermax2 eine idee?

um ehrlich zu sein, nein. Die Returncodes sind keine Dokumente, könnten aber bedeuten:

./src/gpg-error.h.in:968:#define GPGRT_LOG_RUN_DETACHED 256
./src/gpg-error.h.in:1175:#define ARGPARSE_FLAG_STOP_SEEN 256  /* Set to true if a "--" has been seen. */

Ich konnte die Bedeutung von 256 nicht finden, indem ich den Code durchblätterte.

Auch kann ich das Problem nicht wie üblich lokal reproduzieren. :enttäuscht:

Danke fürs reinschauen!

Reproduzieren wird eher schwierig, scheint nur sporadisch und nur im Master-Zweig ( @sanssecours oder hast du es auch in einer PR gesehen?) zu geben.

Wer druckt

OK closing connection

und

Terminating gpg-agent returned with status “256”

?

Ich habe das sporadisch gesehen, als ich an einer PR arbeitete. Es verschwand nach dem Wiederaufbau.

Ich glaube, ich habe es auch auf meinen privaten Jenkins unter extrem hoher Last gesehen. Ist es überhaupt möglich, dass hier etwas mal rauskommt?

Ist es überhaupt möglich, dass hier etwas mal rauskommt?

Könnte sein! Abhängig von der Implementierung von libassuan.

Statusupdate: Ich habe immer noch keine Ahnung, wie ich dieses Problem beheben kann. Alle Ideen sind willkommen!

Danke für das Update!

Ich denke, der Weg nach vorn besteht darin, es den GPG-Leuten zu melden. Wir kennen bereits alles Relevante, wie den Exit-Code. Aber nur sie können (wenn überhaupt) interpretieren, wie dies geschehen kann.

Wenn sie sagen: ohh, ja, dieser Fehler tritt manchmal auf, sollten wir bedenken, dass unsere Plugins gpg erneut ausführen, wenn dieser Fehler auftritt.

Übrigens. Ich bin mir nicht sicher, ob dieses Problem noch auftritt. Ich habe sie vor kurzem nicht gesehen.

Übrigens. Ich bin mir nicht sicher, ob dieses Problem noch auftritt. Ich habe sie vor kurzem nicht gesehen.

Wir haben testmod_fcrypt auf dem Jenkins-Build-Server deaktiviert .

Danke für die Erinnerung. Und auf den anderen Build-Systemen trat das Problem nie auf?

Und auf den anderen Build-Systemen trat das Problem nie auf?

Könnte sein, aber laut Beschreibung von Issue #2439 schlägt testmod_fcrypt nur regelmäßig auf dem Jenkins-Build-Server fehl.

Wenn jemand einen Fehler bemerkt, bitte hier posten.

Wir haben auch genau den gleichen Fehler beobachtet, der von testmod_crypto auf Debian Unstable während der letzten PR verursacht wurde (#3395 ).

https://github.com/ElektraInitiative/libelektra/blob/2e6a5795fde79158f3102c04859dc1091a9dc1d8/src/plugins/crypto/gpgagent_teardown.h#L15

Ich werde diesen Abschnitt so umschreiben, dass er execv verwendet, um ein besseres Verständnis davon zu bekommen, was auf dem Build-Server passiert.

Sollte der Fehler erneut auftreten, können Sie dieses Problem gerne erneut öffnen.

Der Fehler ist wieder aufgetreten, ich recherchiere noch.

Bitte ping mich, wenn der Fehler erneut auftritt.

Ist wieder mit

 80/137 MemCheck  #87: testmod_gpgme ....................***Failed   43.49 sec

GPGME        TESTS

==================

[... mpranj truncated a little bit here ...]

GPGME        TESTS

==================



/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:227: error in test_encryption_decryption: kdb get failed

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:243: error in test_encryption_decryption: key type not restored to string during decryption

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:244: error in test_encryption_decryption: key content not restored during decryption

/home/jenkins/workspace/libelektra_PR-3419/src/plugins/gpgme/testmod_gpgme.c:254: error in test_encryption_decryption: key content not restored during decryption



gpgme Results: 45 Tests done — 4 errors.

Ich weiß nicht, ob wir für jedes Plugin separate Issues eröffnen oder einfach dieses Meta-Thema behalten sollen?

Ich denke, es ist der gleiche (oder ein sehr ähnlicher) gpg-Fehler. Ich denke nicht, dass es notwendig ist, ein weiteres Thema zu eröffnen.

gpgme (oder gpgme in Kombination mit valgrind) scheint Probleme zu verursachen, wenn die Ausgabe von stdout und stderr umgeleitet wird.

GPGME        TESTS
==================

==155492== Warning: invalid file descriptor 1012 in syscall close()
==155492== Warning: invalid file descriptor 1013 in syscall close()
==155492== Warning: invalid file descriptor 1014 in syscall close()
==155492== Warning: invalid file descriptor 1015 in syscall close()
==155492==    Use --log-fd=<number> to select an alternative log fd.
==155492== Warning: invalid file descriptor 1016 in syscall close()
==155492== Warning: invalid file descriptor 1017 in syscall close()
==155492== Warning: invalid file descriptor 1018 in syscall close()
==155491== 
==155491== HEAP SUMMARY:
==155491==     in use at exit: 25,235 bytes in 176 blocks
==155491==   total heap usage: 802 allocs, 626 frees, 119,751 bytes allocated
==155491== 
==155491== LEAK SUMMARY:
==155491==    definitely lost: 0 bytes in 0 blocks
==155491==    indirectly lost: 0 bytes in 0 blocks
==155491==      possibly lost: 0 bytes in 0 blocks
==155491==    still reachable: 23,146 bytes in 163 blocks
==155491==         suppressed: 2,089 bytes in 13 blocks
==155491== Reachable blocks (those to which a pointer was found) are not shown.
==155491== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==155491== 
==155491== For counts of detected and suppressed errors, rerun with: -v
==155491== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
GPGME        TESTS
==================


gpgme Results: 45 Tests done — 0 errors.
==155462== 
==155462== HEAP SUMMARY:
==155462==     in use at exit: 4,833 bytes in 39 blocks
==155462==   total heap usage: 955 allocs, 916 frees, 698,713 bytes allocated
==155462== 
==155462== LEAK SUMMARY:
==155462==    definitely lost: 0 bytes in 0 blocks
==155462==    indirectly lost: 0 bytes in 0 blocks
==155462==      possibly lost: 0 bytes in 0 blocks
==155462==    still reachable: 3,241 bytes in 35 blocks
==155462==         suppressed: 1,592 bytes in 4 blocks
==155462== Reachable blocks (those to which a pointer was found) are not shown.
==155462== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==155462== 
==155462== For counts of detected and suppressed errors, rerun with: -v
==155462== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Ich denke, dies würde erklären, warum die Testausgabe mehrmals in die Protokolldateien geschrieben wird.

GPGME        TESTS
==================

[truncated output]

GPGME        TESTS
==================

GPGME        TESTS
==================


gpgme Results: 45 Tests done — 0 errors.

Ist dieses Problem jetzt behoben?

@petermax2 hat Teile der Kryptotests umgeschrieben und in separate CI-Jobs verschoben ( debian-buster-cryptoplugins und debian-stretch-cryptoplugins ).

Ich habe nicht gesehen, dass diese Tests seit diesen Verbesserungen versagt haben. Ich denke, es kann sicher geschlossen werden.

Freut mich zu hören, dass es jetzt funktioniert. Danke für die Rückmeldung!