gpg nie podpisał danych krytycznych: nie można zapisać obiektu zatwierdzenia [Git 2.10.0]

Śledziłem kilka artykułów na temat pięknych atrybutów informacji o wersji Git 2.10 . Przechodzenie przez które uaktualniłem gita do 2.10.0 i wprowadziłem zmiany w globalnej .gitconfignastępująco:

[filter "lfs"]
    clean = git-lfs clean %f
    smudge = git-lfs smudge %f
    required = true
[user]
    name = xyz
    email = [email protected]
    signingkey = AAAAAAA
[core]
    excludesfile = /Users/xyz/.gitignore_global
    editor = 'subl' --wait
[difftool "sourcetree"]
    cmd = opendiff \"$LOCAL\" \"$REMOTE\"
    path = 
[mergetool "sourcetree"]
    cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"
    trustExitCode = true
[alias]
    lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
[color "diff"]
    old = red strike
    new = green italic

Ale teraz, gdy próbuję podpisać swoje zobowiązania za pomocą

git commit -a -S -m "message"

Widzę następujący błąd -

Aby odblokować tajny klucz, potrzebujesz hasła

użytkownik: „XYZ (podpisany cyfrowo)”

2048-bitowy klucz RSA, ID AAAAAAAA, utworzony 01.01.2016

błąd: gpg nie podpisał danych krytycznych: nie można zapisać obiektu zatwierdzenia

Uwaga - nadal mogę zatwierdzać zmiany za pomocągit commit -a -m "message"

Czy istnieje sposób na przezwyciężenie tego samego? Lub jakakolwiek zmiana wymagana w gpgkonfiguracjach, aby dogadać się z aktualizacją git?

Aktualizacja 1

Poszukuję także dalszej przydatności, po Czy istnieje sposób na „autosign” zatwierdzający w Git kluczem GPG? . Klucz został już skonfigurowany za pomocą

git config --global user.signingkey ED5CDE14(with my key) 
git config --global commit.gpgsign true

i oczywiście pojawia się ten sam błąd.

Wystąpił ten problem z OSX.

Oryginalna odpowiedź:

Wygląda na to, że aktualizacja gpg (naparu) została zmieniona na lokalizację gpgna gpg1, możesz zmienić plik binarny, w którym git sprawdza gpg:

git config --global gpg.program gpg1

Jeśli nie masz gpg1: brew install gpg1.

Zaktualizowana odpowiedź:

Wygląda na to, że gpg1 jest przestarzałe / „delikatnie przestaje być używane” , więc prawdopodobnie powinieneś zaktualizować gpg2, niestety wymaga to jeszcze kilku kroków / trochę czasu:

brew upgrade gnupg  # This has a make step which takes a while
brew link --overwrite gnupg
brew install pinentry-mac
echo "pinentry-program /usr/local/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
killall gpg-agent

Pierwsza część instaluje gpg2, a druga to włamanie wymagane do jego użycia . Aby rozwiązać problemy, zapoznaj się z tą odpowiedzią (choć dotyczy Linuksa, a nie parzenia), sugeruje dobry test:

echo "test" | gpg --clearsign  # on linux it's gpg2 but brew stays as gpg

Jeśli test zakończy się powodzeniem (brak błędu / danych wyjściowych zawiera sygnaturę PGP), pomyślnie zaktualizowano do najnowszej wersji gpg.

Powinieneś teraz móc ponownie używać podpisywania git!
Warto zauważyć, że musisz mieć:

git config --global gpg.program gpg  # perhaps you had this already? On linux maybe gpg2
git config --global commit.gpgsign true  # if you want to sign every commit

Uwaga: po uruchomieniu zatwierdzonego podpisu możesz go zweryfikować za pomocą:

git log --show-signature -1

który będzie zawierał informacje gpg dla ostatniego zatwierdzenia.

Jeśli używane są gnupg2 i gpg-agent 2.x, należy ustawić zmienną środowiskową GPG_TTY.

export GPG_TTY=$(tty)

Zobacz dokumentację GPG na temat typowych problemów .

Jeśli wszystko zawiedzie, użyj, GIT_TRACE=1aby sprawdzić, co właściwie robi git:

$ GIT_TRACE=1 git commit -m "Add page that always requires a logged-in user"
20:52:58.902766 git.c:328               trace: built-in: git 'commit' '-vvv' '-m' 'Add page that always requires a logged-in user'
20:52:58.918467 run-command.c:626       trace: run_command: 'gpg' '--status-fd=2' '-bsau' '23810377252EF4C2'
error: gpg failed to sign the data
fatal: failed to write commit object

Teraz uruchom ręcznie błędne polecenie:

$ gpg -bsau 23810377252EF4C2
gpg: skipped "23810377252EF4C2": Unusable secret key
gpg: signing failed: Unusable secret key

Okazuje się, mój klucz wygasł, gitnie można go winić.

Mam Sporządzono go przez ten krótki i łatwy przepis:

Automatyczne podpisywanie zatwierdza w systemie macOS (globalnie i przy użyciu różnych IDE):

Zdobądź signingkeyw ten sposób .

brew install gnupg gnupg2 pinentry-mac
git config --global user.signingkey <YOUR_SIGNING_KEY>
git config --global commit.gpgsign true
git config --global gpg.program gpg

Umieść następujące dane w gpg.confpliku (edytuj plik za pomocą nano ~/.gnupg/gpg.confpolecenia):

no-tty

Umieść następujące dane w gpg-agent.confpliku (edytuj plik za pomocą nano ~/.gnupg/gpg-agent.confpolecenia):

pinentry-program /usr/local/bin/pinentry-mac

Aktualizacja :

Może być konieczne wykonanie killall gpg-agentpolecenia po edycji pliku konfiguracji gpg.conf, zgodnie z komentarzami. Jak mówi samoobjaśniające polecenie, to polecenie spowoduje zakończenie działania agenta GPG (Gnu Privacy Guard).

Może pomóc w zabiciu procesu, gpg-agentktóry może utknąć w starych danych. Więc nowy gpg-agentzaczął prosić o hasło.

Postępuj zgodnie z poniższym adresem URL, aby skonfigurować podpisane zatwierdzenie https://help.github.com/en/articles/telling-git-about-your-signing-key

jeśli nadal uzyskiwanie gpg nie udało się podpisać danych krytycznych: nie można zapisać obiektu zatwierdzenia

to nie jest problem z gitem, to z GPG wykonaj poniższe kroki

1.gpg --version

2. echo "test" | gpg --clearsign

jeśli pokazuje:

gpg: signing failed: Inappropriate ioctl for device
gpg: [stdin]: clear-sign failed: Inappropriate ioctl for device

3. następnie użyj export GPG_TTY=$(tty)

4. następnie ponownie spróbuj uzyskać echo "test" | gpg --clearsign podpis PGP.

5. git config -l | grep gpg

gpg.program = gpg commit.gpgsign = true

6. zastosuj git commit -S -m "commitMsz"

Każdemu, kto napotyka ten problem na komputerach MacOS , spróbuj:

1. brew uninstall gpg
2. brew install gpg2
3. brew install pinentry-mac (Jeśli potrzebne)
4. gpg --full-generate-key Utwórz klucz za pomocą algorytmu.
5. Uzyskaj wygenerowany klucz, wykonując: gpg --list-keys
6. Tutaj ustaw klucz git config --global user.signingkey <Key from your list>
7. git config --global gpg.program /usr/local/bin/gpg
8. git config --global commit.gpgsign true
9. Jeśli chcesz wyeksportować swój klucz do GitHub, a następnie: gpg --armor --export <key> i dodaj ten klucz do GitHub w kluczach GPG: https://github.com/settings/keys (z dołączoną linią START i END)

Jeśli problem nadal występuje:

test -r ~/.bash_profile && echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile

echo 'export GPG_TTY=$(tty)' >> ~/.profile

Jeśli problem nadal występuje:

Zainstaluj https://gpgtools.org i podpisz użyty klucz, naciskając Znak z paska menu: Klawisz -> Podpisz

Jeśli problem nadal występuje:

Przejdź do: globalnym .gitconfigpliku, który w moim przypadku jest: /Users/gent/.gitconfig i modyfikować .gitconfig pliku (należy upewnić się, że e-mail i nazwa są takie same, z tym, który został utworzony podczas generowania klucza) :

[user]
	email = [email protected]
	name = Gent
	signingkey = <YOURKEY>
[gpg]
	program = /usr/local/bin/gpg
[commit]
	gpsign = true
	gpgsign = true
[filter "lfs"]
	process = git-lfs filter-process
	required = true
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
[credential]
	helper = osxkeychain

Moje dwa centy tutaj:

Kiedy tworzysz i dodajesz klucz do gpg-agent, definiujesz coś o nazwie passphrase. Teraz, gdy passphrasew pewnym momencie wygasa, igpg musisz wprowadzić go ponownie, aby odblokować klucz, abyś mógł zacząć podpisywać ponownie.

Gdy używasz innego programu, z którym współpracujesz gpg, gpgmonit o podanie hasła nie pojawia się (w zasadzie, gpg-agentgdy demonizowany nie może wyświetlić okna dialogowego wprowadzania wstdin ).

Jednym z rozwiązań jest gpg --sign a_file.txtwprowadzenie hasła, które wprowadziłeś podczas tworzenia klucza, a następnie wszystko powinno być w porządku (gpg-agent powinno się automatycznie podpisać)

Zobacz tę odpowiedź na temat ustawiania dłuższych limitów czasu dla hasła, abyś nie musiał tego robić cały czas.

Lub możesz całkowicie usunąć hasło za pomocą ssh-keygen -p

Edycja: zrób a, man gpg-agentaby przeczytać kilka rzeczy o tym, jak powyższe dzieje się automatycznie i dodaj linie:

GPG_TTY=$(tty)
export GPG_TTY

na swoim .bashrc, jeśli używasz bash (jest to poprawna odpowiedź, ale utrzymuję mój tok myślenia powyżej)

Aktualizacja października 2016: wydanie 871 wspomniano „Podpisywanie przestało działać w Git 2.9.3”

Git dla Windows 2.10.1 wydany dwa dni temu (4 października 2016) naprawił podpisywanie interaktywnych GPG w commits i tagach.

ostatnia zmiana znaku gpg w git (która nie wprowadza żadnego problemu w Linuksie) ujawnia problem w sposobie, w jaki w systemie Windows nie-MSYS2-git wchodzi w interakcje z MSYS2-gpg.

Oryginalna odpowiedź:

Czytając „ 7.4 Git Tools - podpisywanie swojej pracy ”, zakładam, że masz user.signingkeyskonfigurowaną konfigurację.

Ostatnim dużym refaktoryzowaniem (przed Git 2.10) wokół gpg było zatwierdzenie 2f47eae2a , tutaj ten komunikat o błędzie został przeniesiony dogpg-interface.c

Dziennik tego pliku ujawnia ostatnią zmianę w zatwierdzeniu af2b21e (Git 2.10)

gpg2 domyślnie używa już długiego formatu, ale większość dystrybucji wydaje się nadal mieć starszą wersję 1.x ze względu na kompatybilność. Starsze wersje gpg pokazują tylko 32-bitowy krótki identyfikator, co jest dość niepewne.

To nie ma znaczenia dla samej weryfikacji : jeśli weryfikacja się powiedzie, sygnatura pgp jest dobra.
Ale jeśli nie masz jeszcze klucza i chcesz go pobrać lub chcesz dokładnie sprawdzić, który klucz został użyty do weryfikacji i chcesz go sprawdzić, powinniśmy go określić z większą dokładnością.

Sprawdź więc, jak określiłeś swój user.signingkey konfigurację oraz używaną wersję gpg (gpg1 lub gpg2), aby sprawdzić, czy mają one wpływ na komunikat o błędzie.

Istnieje również zatwierdzenie 0581b54, które zmienia warunek gpg failed to sign the datakomunikatu o błędzie (w uzupełnieniu do zatwierdzenia 0d2b664 ):

Obecnie w ogóle nie czytamy ze stderr. Jednak będziemy chcieli w plastrze przyszłości, więc ten przygotowuje również nas tam (iw tym przypadku gpg robi zapis przed przeczytaniem wszystkie wejścia, choć znowu, to jest mało prawdopodobne, że kluczowym uid zapełni się bufor rury).

Zatwierdzenie 4322353 pokazuje, że gpg używa teraz pliku tymczasowego, więc mogą występować odpowiednie problemy.

Przejdźmy do korzystania z obiektu tempfile, który obsługuje dla nas trudne przypadki, i dodajmy brakujące wywołanie czyszczenia.

Ślad git był bardzo odkrywczy dla mojej sytuacji ...

   GIT_TRACE=1 git commit -m "a commit message"

   13:45:39.940081 git.c:344               trace: built-in: git commit -m 'a commit message'
   13:45:39.977999 run-command.c:640       trace: run_command: gpg --status-fd=2 -bsau 'full name <[email protected]>'
   error: gpg failed to sign the data
   fatal: failed to write commit object

Musiałem wygenerować klucz początkowy dla gitsprawdzanego formatu . Najlepiej jest skopiować przekazaną wartość-bsau dzienników w obecnej postaci i użyć poniżej.

Więc staje się

   gpg --quick-generate-key "full name <[email protected]>"

Potem zadziałało.

Mam nadzieję, że to pomaga.

Korzystając z cygwin, niedawno przełączyłem się na gpg2. Potem miałem ten sam problem z podpisywaniem się z git po ustawieniu git config gpg.program gpg2.

Spróbuj echo "test" | gpg2 --clearsignsprawdzić, czy gpg2 działa. Znalazłem to najłatwiejsze rozwiązanie do ustawienia git config gpg.program gpg, ponieważ to działa. Ale w ten sposób otrzymasz lepszy błąd - np. Że musisz zainstalować pinentry.

Na OS X, używając gnupg2via brew musiałem zabić agenta gpg , czasem się zdarza:

pkill -9 gpg-agent

W envrazie potrzeby ustaw zmienną:

export GPG_TTY=$(tty)

Zobacz także typowe problemy z GPG i tę odpowiedź tutaj.

Widziałem podobne odpowiedzi, ale nic dokładnie nie działało dla mnie. W systemie Linux musiałem zabić i uruchomić ponownie za gpg-agentpomocą:

$ pkill gpg-agent
$ gpg-agent --daemon
$ git commit ...

To załatwiło sprawę. Wygląda na to, że musisz również user.signingkeyustawić swój klucz prywatny na podstawie tego, co mówią inne komentarze.

$ git config --global user.signingkey [your_key_hash]

Może być wiszącym agentem gpg.

Spróbuj gpgconf --kill gpg-agent jak omówiono tutaj

Otrzymałem ten błąd na Ubuntu 18.04 i okazało się, że mój klucz wygasł .

Aby to zobaczyć, uruchomiłem to i potwierdziło, że moje klucze wygasły:

gpg --list-keys

Aby to naprawić, uruchomiłem (używając identyfikatora wyświetlonego w poprzednim poleceniu):

gpg --edit-key <ID>

Stamtąd rozszerzył wygaśnięcie key 0i key 1następującą instrukcją , która sprowadzała się do pisania key 0wtedy expirei postępując zgodnie z instrukcjami. Następnie powtarzam dla key 1.

Następnie, aby to przetestować, uruchomiłem:

echo test | gpg --clearsign

A przed poprawką nie powiodło się z błędem:

gpg: brak domyślnego tajnego klucza: brak tajnego klucza
gpg: [stdin]: niepowodzenie kasowania: brak tajnego klucza

Ale po poprawce to samo polecenie pomyślnie podpisało wiadomość, więc wiedziałem, że wszystko znowu działa!

Natrafiłem na ten sam problem. Z przyjemnością informuję, że problem nie leży w tym, git 2.10.0ale w czymgnupg 1.4.21 .

Tymczasowe obniżenie gnupga do 1.4.20 naprawiło problem.

Jeśli używasz homebrew i zaktualizowałeś swoje pakiety tak jak ja, prawdopodobnie możesz po prostu uruchomić, brew switch gnupg 1.4.20aby przywrócić.

Upewnij się, że masz poprawnie ustawiony adres e-mail.

git config --global user.email "[email protected]"

Jeśli wiadomość e-mail przypisana do identyfikatora UID klucza GPG jest inna niż wiadomość e-mail używana w git, musisz dodać kolejny identyfikator użytkownika do swojego klucza LUB użyć klucza, który dokładnie pasuje do wiadomości e-mail.

Możesz dodać kolejny identyfikator UID, używając:

$ gpg --edit-key

Zobacz mo /superuser/293184/one-gnupg-pgp-key-pair-two-emails

Musiałem jakoś przypadkowo zaktualizować gpg, ponieważ dostałem to po próbie sprawdzenia, czy gpg działa:

gpg: WARNING: server 'gpg-agent' is older than us (2.1.21 < 2.2.10)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.

Bieganie gpgconf --kill allnaprawiło to dla mnie.

Mam nadzieję, że to komuś pomoże.

Miałem podobny problem z najnowszymi źródłami Gita (2.12.2) zbudowanymi wraz z najnowszymi źródłami wszystkich jego zależności (Zlib, Bzip, cURL, PCRE, ReadLine, IDN2, iConv, Unistring itp.).

Okazuje się, libreadlineże powodował problemy z GnuPG:

$ gpg --version
gpg: symbol lookup error: /usr/local/lib/libreadline.so.7: undefined symbol: UP

I oczywiście próba uzyskania przydatnych informacji od Gita -vvvnie powiodła się, więc niepowodzenie było tajemnicą.

Aby rozwiązać błąd PGP z powodu ReadLine, postępuj zgodnie z instrukcjami w Nie można zaktualizować lub użyć menedżera pakietów - błąd gpg :

W terminalu:

ls /usr/local/lib

było tam wiele bibliotek readline (libreadline.so.BLAH-BLAH), więc:

su
mkdir temp
mv /usr/local/lib/libreadline* temp
ldconfig

Powyższe odpowiedzi są świetne, ale dla mnie nie zadziałały. Rozwiązaniem mojego problemu było wyeksportowanie zarówno kluczy publicznych, jak i tajnych .

wypisz klucze z komputera, z którego eksportujemy

$ gpg --list-keys
/home/user/.gnupg/pubring.gpg
--------------------------------
pub 1024D/ABCDFE01 2008-04-13
uid firstname lastname (description) <[email protected]>
sub 2048g/DEFABC01 2008-04-13

eksportuj klucze

$ gpg --output mygpgkey_pub.gpg --armor --export ABCDFE01
$ gpg --output mygpgkey_sec.gpg --armor --export-secret-key ABCDFE01

przejdź do maszyny, do której importujemy i importujemy

$ gpg --import ~/mygpgkey_pub.gpg
$ gpg --allow-secret-key-import --import ~/mygpgkey_sec.gpg

bingo bongo, gotowe!

odniesienie: https://www.debuntu.org/how-to-importexport-gpg-key-pair/

ps. Moje klucze zostały pierwotnie wykonane w systemie Windows 7 Bootcamp i wyeksportowałem je na Mac Mac Air (ta sama fizyczna maszyna, inna wirtualnie)

Jestem na Ubuntu 18.04 i dostałem ten sam błąd, martwiłem się także przez tygodnie. Wreszcie zdałem sobie sprawę, że gpg2 nie wskazuje na nic. Po prostu biegnij

git config --global gpg.program gpg

I tada, działa jak urok.

Twoje zatwierdzenia będą teraz weryfikować przy użyciu tagu.

Natknąłem się na ten błąd nie z powodu problemów z konfiguracją, ale dlatego, że mój klucz wygasł. Najłatwiejszym sposobem przedłużenia ważności w OSX jest otwarcie aplikacji pęku kluczy GPG (jeśli masz ją zainstalowaną) i automatycznie poprosi o jej przedłużenie. Dwa kliknięcia i gotowe. Mam nadzieję, że pomaga to innym pracownikom Google :)

To zaczęło się dla mnie nagle pojawiać na Ubuntu, nie jestem pewien, czy zrobiła to ostatnia aktualizacja, ale żaden z istniejących problemów mnie nie dotyczył ( GPG_TTYustawiłem, próbowałem zabić agenta itp.). Samodzielne gpgpolecenie zakończyło się niepowodzeniem z powodu tego błędu:

$ echo "test" | gpg --clearsign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
gpg: signing failed: Operation cancelled
gpg: [stdin]: clear-sign failed: Operation cancelled

Próbowałem uruchomić gpgz --debug-allopcją i zauważyłem poniższy wynik:

gpg: DBG: chan_3 <- INQUIRE PINENTRY_LAUNCHED 27472 gnome3 1.1.0 /dev/pts/6 screen-256color -
gpg: DBG: chan_3 -> END
gpg: DBG: chan_3 <- ERR 83886179 Operation cancelled <Pinentry>
gpg: signing failed: Operation cancelled

Powyższe wskazuje, że jest jakiś problem z pinentryprogramem. Gpg normalnie działa pinentry-cursesdla mnie, więc zmieniłem go na pinentry-tty(musiałem aptitude installto najpierw) i błąd zniknął (chociaż nie otrzymuję już hasła do pełnego ekranu, ale i tak mi się nie podoba). Aby dokonać tej zmiany, musiałem dodać linię pinentry-program /usr/bin/pinentry-ttydo ~/.gnupg/gpg-agent.confi zabić agenta z gpgconf --kill gpg-agent(robi wznowiona następnym razem).

Żadna z powyższych odpowiedzi nie pasowała do mojego problemu. Mój gpgplik binarny ( /usr/local/bin/gpg -> /usr/local/MacGPG2/bin/gpg2) został zainstalowany jako część pakietu GPG , a nie przez brew.

Niemniej jednak czułem, że rada sprowadza się do: „używaj dowolnego pliku gpgbinarnego, który jest najnowszym dostępnym w parzeniu”. Więc próbowałem:

brew update
brew upgrade git
brew install gpg

# the following are suggestions from brew's Caveats, to make `/usr/local/bin/gpg`
# point to the brew binary:
rm '/usr/local/bin/gpg'
brew link --overwrite gnupg2

Potwierdziłem, że poprawnie zmieniłem gpgmój, $PATHaby wskazać nowy plik wykonywalny z brew:

🍔 which gpg
/usr/local/bin/gpg
🍔 ls -l /usr/local/bin/gpg
lrwxr-xr-x  1 burger  admin  33 Feb 13 13:22 /usr/local/bin/gpg -> ../Cellar/gnupg2/2.0.30_3/bin/gpg

I również wyraźnie powiedziałem git, którego pliku gpgbinarnego użyć:

git config --global gpg.program gpg

Cóż, może nie jest to całkowicie wodoszczelne, ponieważ jest wrażliwe na ścieżkę. Właściwie nie posunąłem się aż tak daleko, by potwierdzić ponad wszelką wątpliwość, że git przeszedł na inwokowanie naparu gpg.

W każdym razie: nic z tego nie wystarczyło, aby git commitpomyślnie podpisać moje zobowiązania.

Ostatecznie działała dla mnie aktualizacja GPG Suite . Korzystałem z wersji 2016.7 i stwierdziłem, że aktualizacja do 2016.10 rozwiązała problem.

Otworzyłem GPG Keychain.appi nacisnąłem „Sprawdź aktualizacje…”. W nowej wersji: podpisane zatwierdzenia znów działały poprawnie.

skonfigurowałem po prostu:

brew uninstall gpg 

brew install gpg2

Bardzo podobnie jak @birchlabs, po wielu kopaniach / poszukiwaniach odkryłem, że to nie GPG, a raczej GPG Suite. Zrobiłem to cask reinstall gpg-suitei dla mnie to rozwiązało.

Jeśli zdarzyło się to losowo i działało doskonale w przeszłości, tak jak w moim przypadku, spróbuj wylogować się ( cmd+shift+q) i zalogować ponownie. Pracowałem dla mnie

W moim przypadku żadne z rozwiązań wymienionych w innej odpowiedzi nie zadziałało. Dowiedziałem się, że problem dotyczy jednego repozytorium. Ponowne usunięcie i klonowanie repozytorium rozwiązało problem.

To trochę dziwne, ale upewnij się, że twój terminal jest wystarczająco duży! Możesz stwierdzić, czy jest za mały, uruchamiającecho test | gpg --clearsign - wyświetli dość oczywisty komunikat o błędzie, informujący o tym. Jeśli nie jest wystarczająco duży, Twój agent GPG nie może wyświetlić swojego małego pola ncurses.

Ten nie będzie obowiązywał, jeśli używasz agenta GUI lub czegoś, co nie używa ncurses.