Libelektra: tes menelurkan agen gpg tak terbatas

Terima kasih telah melaporkan masalah tersebut!

@ petermax2 Apakah mungkin bahwa perintah gpg selama pengujian memunculkan gpg-agents?

Ups, saya pikir gpg akan selalu terhubung ke agen yang sama. Saya akan menyelidiki.

@ markus2330 ini juga merupakan alasan mengapa ada begitu banyak agen gpg di v2 yang dilaporkan dengan userid Anda, karena kontainer buruh pelabuhan berjalan dengan 1000: 1000.

tetapi masalahnya tidak terbatas pada buruh pelabuhan: debian-stretch-minimal memiliki> 250 di antaranya juga

beberapa node tidak terpengaruh karena mereka diatur untuk menelurkan gpg-agent untuk jenkins yang digunakan oleh pengujian (mungkin, harus mengonfirmasi)

Terima kasih telah melihat ini!

beberapa node tidak terpengaruh karena mereka diatur untuk menelurkan gpg-agent untuk jenkins yang digunakan oleh pengujian (mungkin, harus mengonfirmasi)

Jika kita tidak dapat menemukan cara untuk membunuh agen yang kita mulai, kita cukup mensyaratkan bahwa lingkungan sudah memiliki agen-gpg (# 1888).

Mungkin agen gpg tidak diharuskan untuk memulai sama sekali dan kami dapat menekannya selama pengujian. Tapi saya harus melihatnya di malam hari.

mh biasanya GPG_AGENT_INFO harus diset ketika satu dimulai, di masa lalu kita membersihkan variabel lingkungan sehingga mungkin telah menjelaskan beberapa permulaan di masa lalu. Tidak tahu mengapa itu masih terjadi sekarang ...

@ petermax2 pengujian yang membutuhkan gpg-agent (ditemukan dengan mengganti nama gpg-agent menjadi gpg-agent.bak;)):

• testmod_fcrypt
• testmod_crypto_openssl
• testmod_crypto_gcrypt

testmod_crypto_botan harus berjalan persis seperti testmod_crypto_gcrypt dan testmod_crypto_openssl . Apakah pengujian Botan berjalan di server?

@ petermax2 mungkin ya. di lingkungan tempat saya menguji tidak ada botan yang diinstal. itu berjalan namun di sini dan mungkin juga agen pemijahan.

Tidak sesederhana itu. Saya mencoba memanggil gpg dengan argumen --no-autostart selama pengujian unit, namun gpg masih memulai agen. --no-use-agent itu lucu. Halaman manual berbunyi:

--no-use-agent 
              This is dummy option. gpg2 always requires the agent.

Jika kita tidak dapat menemukan cara untuk membunuh agen yang kita mulai, kita cukup mensyaratkan bahwa lingkungan sudah memiliki agen-gpg (# 1888).

Bisakah kita mencobanya?

Atau gunakan cron-job

pgrep gpg-agent | xargs -d "\n" kill

atau yang serupa di server build / container?

Saya akan melakukan tes untuk memeriksa apakah ada agen yang tersedia, jika tidak memulainya dan mempertahankan pid itu. dalam tes pembersihan, hentikan agen. yang lainnya adalah retasan.

Anda benar, satu-satunya pertanyaan adalah di mana memulai dan berhenti harus terjadi. Melakukan ini di dalam agen / buruh B / M kami tampaknya lebih mudah daripada dalam pengujian unit kami yang ditulis dalam C.

Inilah yang saya pelajari sejauh ini:

Dimungkinkan untuk menekan start otomatis dari gpg-agent dengan opsi --no-autostart , jika digunakan secara konsisten dengan semua panggilan gpg . Namun, tanpa gpg-agent gpg2 tidak dapat melakukan operasi apapun, yang membutuhkan kunci privat (yaitu dekripsi, tanda tangan).

Dimungkinkan juga untuk membayar gpg-agent --server tetapi kemudian gpg2 tidak dapat terhubung ke agen. Variabel lingkungan GPG_AGENT_INFO tidak digunakan lagi dan tidak lagi dianggap oleh gpg2 .

Saya akan mencoba untuk membayar dan mengeksekusi gpg-agent --daemon . Saya hanya perlu cara untuk mengetahui PID dari mulai gpg-agent sehingga saya dapat SIGTERM ketika tes selesai.

Melakukan ini di dalam agen / buruh B / M kami tampaknya lebih mudah daripada dalam pengujian unit kami yang ditulis dalam C.

Jauh lebih mudah, saya kira :-)

Saya pikir keputusan Anda tepat untuk menggunakan cara default dari gpg untuk terhubung ke agen.

Sebagai alternatif untuk memulai / menghentikan gpg-agent, kita juga dapat menonaktifkan "use-agent" di .gnupg / gpg.conf

saya tidak punya masalah dengan satu agen mulai otomatis (dan bahkan menjalankannya). Saya punya masalah dengan tes berikutnya memulai yang baru

Saya pikir keputusan Anda tepat untuk menggunakan cara default dari gpg untuk terhubung ke agen.

Dalam lingkungan produksi, ini adalah pilihan yang lebih baik. Di mesin saya crypto dan fcrypt selalu terhubung ke agen yang sama dan integrasi dengan Yubikey saya bekerja dengan sangat baik.

di lingkungan pengujian kami, kami harus menyimpan satu instance agen dan menjalankannya sebelum memulai pengujian. Menurut saya masalahnya adalah kita membersihkan lingkungan, seperti yang disebutkan @ingwinlu sebelumnya.

Saya pikir masalahnya adalah kita membersihkan lingkungan

kita tidak seharusnya lagi. tapi masalahnya tetap ada

Jika gpg-agent mencoba untuk berkomunikasi melalui lingkungan yang jelas tidak dapat berfungsi, pengujian selanjutnya tidak akan pernah mendapatkan lingkungan yang disetel oleh pengujian yang dijalankan sebelumnya.

Saya paling suka mengikuti dua opsi berikut:

1. kita dengan benar memulai / menghentikan agen gpg di dalam kontainer dan dokumen di TESTING.md yang perlu dijalankan oleh agen gpg (lihat # 1888).
2. kami menonaktifkan startup agen gpg (menonaktifkan "use-agent" di .gnupg / gpg.conf seharusnya berfungsi, meskipun tidak mengujinya) dan mendokumentasikannya di TESTING.md (lihat # 1888).

Setup, di mana daemon dimulai sesuai permintaan tanpa cara global untuk mengetahui apakah daemon telah dimulai (dan env vars tidak global tetapi khusus proses), tampaknya rusak. Kami tidak boleh mencoba memperbaikinya dalam pengujian.

https://stackoverflow.com/questions/27459869/how-to-stop-gpg-2-1-spawning-many-agents-for-unit-testing

Alasan Anda menelurkan banyak agen adalah direktori beranda yang berbeda menggunakan opsi --homedir, jika tidak, satu agen akan digunakan. Dari GnuPG 2.1, semua komunikasi dengan agen dilakukan melalui soket di homedirectory GnuPG.

Kami tidak menggunakan opsi homedir. Dan https://dev.gnupg.org/T3218 menggambarkan solusi stackoverflow sebagai "solusi (sangat canggung)".

Mungkin hanya memulai gpg-agent adalah varian paling tahan masa depan (dengan cara yang terkontrol dalam lingkungan kita). Sepertinya mereka dalam versi terbaru startup gpg-agent sudah tidak opsional lagi. (yang membuat pilihan saya 2. di atas tidak masuk akal)

Kami tidak menggunakan opsi homedir.

Ya saya belum menemukan dari mana asalnya tetapi cocok dengan masalahnya (lihat op) karena semua agen melahirkan dengan yang berbeda.

Itu adalah petunjuk yang bagus, saya mengetahui bahwa startup gpg-agent tidak lagi opsional.

Yang membuatnya sangat jelas bahwa kita perlu memulai dan menghentikannya. Dan jangan mencoba menghindari awal.

Kami tidak menggunakan opsi homedir.

Ya saya belum menemukan dari mana asalnya tetapi cocok dengan masalahnya (lihat op)

Kami tidak menggunakan opsi --home-dir secara eksplisit, tetapi ps -ef mengungkapkan bahwa gpg entah bagaimana mengaturnya.

https://wiki.archlinux.org/index.php/GnuPG

$ GNUPGHOME digunakan oleh GnuPG untuk menunjuk ke direktori tempat file konfigurasinya disimpan. Secara default $ GNUPGHOME tidak diset dan $ HOME Anda digunakan sebagai gantinya; dengan demikian, Anda akan menemukan direktori ~ / .gnupg tepat setelah instalasi.
Untuk mengubah lokasi default, jalankan gpg dengan cara ini $ gpg --homedir path / to / file atau setel variabel lingkungan GNUPGHOME.
``
@ petermax2 dapatkah Anda memeriksa apakah HOME tersedia di testsuite Anda?

juga menarik https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html :

Buat direktori sementara, buat (atau salin) konfigurasi yang sesuai dengan kebutuhan Anda, buat gpg menggunakan direktori ini baik menggunakan variabel lingkungan GNUPGHOME, atau opsi --homedir. GPGME mendukung ini juga pada basis per-konteks, dengan memodifikasi info mesin konteks. Sekarang jalankan operasi apa pun yang Anda suka, impor dan ekspor materi kunci seperlunya. Setelah selesai, Anda dapat menghapus direktori tersebut. Semua layanan backend GnuPG yang dimulai akan mendeteksi ini dan ditutup

Menguji ini di wadah saya dan membersihkan proses secara otomatis seperti yang dijanjikan.

@ petermax2 dapatkah Anda memeriksa apakah HOME tersedia di testsuite Anda?

Ya, HOME tersedia:

HOME = /tmp/elektra-test.3vLR4L

Oke, jadi sesuatu di suite pengujian menimpa HOME menjadi direktori tmp (yang bagus). Jika masih tersedia selama pembersihan, sebaiknya dilepas saja untuk menghentikan agen. Itu akan menjadi perbaikan yang ideal.

Jika kita hanya menetapkan GNUPGHOME hanya satu contoh gpg-agent yang muncul. GNUPGHOME tidak ditimpa sebelum tes dimulai.

Dengan set GNUPGHOME , hanya satu gpg-agent yang berjalan setelah beberapa pengujian berjalan.

Saya rasa ini adalah solusi paling sederhana.

Perlu diingat bahwa jika Anda membagikan direktori beranda, Anda mungkin tidak dapat menjalankan pengujian secara paralel.
Dan Anda masih perlu menghapus GNUPGHOME setelahnya (Anda tidak ingin pgp-agent yang berlama-lama menjawab panggilan untuk pengguna yang masuk kan?).

Dan apa yang akan terjadi jika sistem target relai pada GNUPGHOME, jadi Anda perlu menyimpan env yang ada dan memulihkannya secara manual setelah pengujian.

Saya akan menghargai jika kita dapat mengambil langkah mundur dan melihat bagaimana pengujian tersebut dapat memengaruhi mesin pengguna, bukan hanya lingkungan server pengujian.

Anda mungkin tidak dapat menjalankan pengujian secara paralel.

Saya menjalankan skrip:

#!/bin/bash
mkdir /tmp/x
export GNUPGHOME=/tmp/x
for run in {1..1000000}
do
    ctest -R crypto_openssl &
done

tanpa masalah. GPG harus menangani penguncian, dll.

Anda tidak ingin pgp-agent yang berlama-lama menjawab panggilan untuk pengguna yang masuk, bukan?

Ini adalah cara gpg-agent dirancang: ini berjalan selamanya sampai sesi pengguna berakhir. Itu tidak menulis PID-nya ke suatu tempat, tidak ada perintah untuk keluar. Ini hanya bereaksi terhadap SIGTERM .

Saya mencoba untuk fork gpg-agent dari dalam pengujian unit dengan opsi --server , jadi kami akan memiliki PID ke kill sesudahnya. Tapi kemudian gpg-agent tidak membuka soket yang diperlukan di $GNUPGHOME dan tes unit membuka kembali contoh lain dari agen (yang berjalan dalam mode --daemon ). Juga tidak ada cara untuk menghasilkan gpg-agent membuka soket apa pun ketika dalam mode --server (Saya memeriksa ini dengan kode sumber gpg-agent ).

gpg-agent sulit dikendalikan dan hampir tidak didokumentasikan. Saya bahkan membaca kode sumber gpg-agent . Kasus penggunaan kami tidak tercakup. Satu-satunya pilihan adalah SIGTERM .

paralelisme

Saya lebih memikirkan Anda ingin memisahkan gpg-agen yang seharusnya tidak saling memengaruhi. yaitu Anda hanya ingin agen a memiliki kunci pengujian a, dan agen b memiliki kunci untuk pengujian b. Jika itu tidak diperlukan maka rumah tmp yang di-hardcode sudah cukup.

membunuh gpg-agent

Ketika pertama kali menyelidiki masalah ini, saya menemukan sebuah situs web (ditautkan di atas) yang menyatakan bahwa cara yang diharapkan untuk menutup gpg-agent temp adalah dengan menghapus direktori home gpg-nya.

Jadi jika Anda menyetel GNUPGHOME ke /tmp/elektra_tests/gpg dan selama pembersihan percobaan hapus direktori tmp ini seharusnya baik-baik saja.

Jadi, jika Anda menyetel GNUPGHOME ke / tmp / elektra_tests / gpg dan selama pembersihan percobaan hapus direktori tmp ini seharusnya baik-baik saja.

Berhasil! Saya akan mengintegrasikan perbaikan ini ke dalam kasus uji crypto dan fcrypt . Terima kasih atas tipnya!

Saya memiliki prototipe yang berfungsi. PR akan datang besok.

Harus diperbaiki dengan # 2056. Silakan buka kembali jika masalah masih terjadi.