Libelektra: fcrypt / gpgme / crypto: caso de teste falha

Parece que o gpgme também foi afetado:

 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 alguma ideia?

para ser honesto, não. Os códigos de retorno não são documentos, mas podem significar:

./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. */

Não consegui encontrar o significado de 256 folheando o código.

Também não consigo reproduzir o problema localmente, como de costume. : desapontado:

Obrigado por dar uma olhada!

A reprodução será bastante difícil, parece ocorrer apenas esporadicamente e apenas no branch master ( @sanssecours ou você viu isso também em um PR?).

Quem imprime

OK closing connection

e

Terminating gpg-agent returned with status “256”

?

Eu vi isso esporadicamente enquanto trabalhava em um PR. Ele desapareceu após a reconstrução.

Acho que também vi isso em meus jenkins particulares sob carga extremamente alta. É possível que algo ocorra aqui?

É possível que algo ocorra aqui?

Pode ser! Dependendo da implementação do libassuan.

Atualização de status: ainda não tenho ideia de como solucionar esse problema. Todas as ideias são bem-vindas!

Obrigado pela atualização!

Acho que o caminho a seguir é relatar isso ao pessoal do GPG. Já sabemos tudo o que é relevante, como o código de saída. Mas apenas eles podem (se houver) interpretar como isso pode ocorrer.

Se eles disserem: ohh, sim, esse erro às vezes ocorre, devemos considerar que nossos plug-ins executam o gpg novamente se esse erro acontecer.

Por falar nisso. Não tenho certeza se ainda existem ocorrências desse problema. Eu não os vi recentemente.

Por falar nisso. Não tenho certeza se ainda existem ocorrências desse problema. Eu não os vi recentemente.

Desativamos testmod_fcrypt no servidor de compilação Jenkins .

Obrigado pela lembrança. E nos outros sistemas de compilação o problema nunca ocorreu?

E nos outros sistemas de compilação o problema nunca ocorreu?

Pode ser, mas de acordo com a descrição do problema # 2439 testmod_fcrypt só falha regularmente no servidor de compilação do Jenkins.

Se alguém notar uma falha, poste aqui.

Também observamos exatamente o mesmo erro causado por testmod_crypto no Debian instável durante o último PR (# 3395).

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

Vou reescrever esta seção para usar execv fim de obter uma melhor compreensão do que está acontecendo no servidor de compilação.

Se o erro ocorrer novamente, sinta-se à vontade para reabrir este problema.

O erro ocorreu novamente, ainda estou pesquisando.

Faça ping para mim se o erro ocorrer novamente.

Aconteceu com gpgme novamente . (Não sei se devemos abrir problemas separados para cada plug-in ou apenas manter este meta-problema?)

 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.

Não sei se devemos abrir questões separadas para cada plugin ou apenas manter este meta-problema.

Acho que é o mesmo (ou muito semelhante) erro relacionado ao gpg. Não creio que seja necessário abrir outra edição.

gpgme (ou gpgme em combinação com valgrind) parece causar problemas se a saída de stdout e stderr estiver sendo redirecionada.

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)

Acho que isso explicaria por que a saída do teste é gravada nos arquivos de log várias vezes.

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

[truncated output]

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

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


gpgme Results: 45 Tests done — 0 errors.

Este problema foi corrigido agora?

@ petermax2 reescreveu partes dos testes de criptografia e os moveu para trabalhos de CI separados ( debian-buster-cryptoplugins e debian-stretch-cryptoplugins ).

Não vi esses testes falharem desde essas melhorias. Acho que pode ser fechado com segurança.

Fico feliz em saber que está funcionando agora. Obrigado pelo feedback!