Package: gpg-sq
Version: 0.11.2-7
Severity: normal
When a recipient is not "trusted" by gpg, this works:
echo foo | gpg --armor -e -r RECIPIENT
But this doesn't:
echo foo | gpg-sq --armor -e -r RECIPIENT
I think it's because of the way the terminal is handled. Here's what
it looks like in gpg:
> echo foo | gpg --armor -e -r RECIPIENT
gpg: 0000000000000000: There is no assurance this key belongs to the named user
sub rsa4096/0000000000000000 2022-01-31 RECIPIENT <recipi...@torproject.org>
Primary key fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Subkey fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) y
-----BEGIN PGP MESSAGE-----
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000==
=0000
-----END PGP MESSAGE-----
I've redacted PII from the output. But the point is: the key is not
trusted, gpg is worried, prompts me for confirmation, I accept, and
yay, an encrypted blob.
chameleon seems to stumble along the way somewhere:
> echo foo | gpg-sq --armor -e -r RECIPIENT
gpg: 0000000000000000: There is no assurance this key belongs to the named user
sub rsa4096/0000000000000000 2022-01-31 RECIPIENT <recipi...@torproject.org>
Primary key fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Subkey fingerprint: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) gpg: -: encryption failed: Unusable public key
Boom!
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (1, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gpg-sq depends on:
ii libbz2-1.0 1.0.8-6
ii libc6 2.40-5
ii libgcc-s1 14.2.0-12
ii libgmp10 2:6.3.0+dfsg-3
ii libhogweed6t64 3.10-1+b1
ii libnettle8t64 3.10-1+b1
ii libsqlite3-0 3.46.1-1
ii libssl3t64 3.4.0-2
Versions of packages gpg-sq recommends:
ii sq 0.40.0-2
gpg-sq suggests no packages.
-- no debconf information
