keybase.io generates an unusable curl command for uploading a public key

[isislovecruft]

Hi!

I'm sorry for filing this here, but it seemed like the keybase-issues repo was unused and I wasn't sure where to file it. I can re-file if you'd prefer it to go elsewhere.

When I try to import my public key through the new account creation process on keybase.io, it eventually generates a hefty shell script which calls curl with some JSON containing a new signature of the public key and some nonce/timestamp stuff. However, it looks like curl is unwilling to do that, apparently due to refusing to make a buffer large enough for the public key:

∃!isisⒶwintermute:~ ∴ chmod +x keybase-curl-thing.sh 
∃!isisⒶwintermute:~ ∴ ./keybase-curl-thing.sh 

You need a passphrase to unlock the secret key for
user: "Isis <isis@torproject.org>"
4096-bit RSA key, ID B8938BC5E86C046F, created 2017-09-08
         (subkey on main key ID A3ADB67A2CDB8B35)

./keybase-curl-thing.sh: line 2: /usr/bin/curl: Argument list too long
∃!isisⒶwintermute:(master=)~/code/sources/curl ∴ curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP 

[maxtaco]

Try a different shell

…

On Fri, Feb 23, 2018 at 7:21 PM isis agora lovecruft < ***@***.***> wrote: Hi! I'm sorry for filing this here, but it seemed like the keybase-issues <https://github.com/keybase/keybase-issues> repo was unused and I wasn't sure where to file it. I can re-file if you'd prefer it to go elsewhere. When I try to import my public key <https://gist.github.com/isislovecruft/8ac1569425fd3d029576f0ebc83933a6> through the new account creation process on keybase.io, it eventually generates a hefty shell script <https://gist.github.com/isislovecruft/a974d2795f4d330d94795b4c43fbcf47> which calls curl with some JSON containing a new signature of the public key and some nonce/timestamp stuff. However, it looks like curl is unwilling to do that, apparently due to refusing to make a buffer large enough for the public key: ∃!isisⒶwintermute:~ ∴ chmod +x keybase-curl-thing.sh ∃!isisⒶwintermute:~ ∴ ./keybase-curl-thing.sh You need a passphrase to unlock the secret key for user: "Isis ***@***.***>" 4096-bit RSA key, ID B8938BC5E86C046F, created 2017-09-08 (subkey on main key ID A3ADB67A2CDB8B35) ./fucking-unusable.sh: line 2: /usr/bin/curl: Argument list too long ∃!isisⒶwintermute:(master=)~/code/sources/curl ∴ curl --version curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10682>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA05_7meKdEvRtwAiVMqt3033G8Sgipcks5tX1X-gaJpZM4SRp0V> .

[isislovecruft]

@maxtaco That was bash. I also tried fish and zsh.

[maxtaco]

Do you have a ginormous public key? This works for everyone else.

…

On Fri, Feb 23, 2018 at 7:24 PM isis agora lovecruft < ***@***.***> wrote: @maxtaco <https://github.com/maxtaco> That was bash. I also tried fish and zsh. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10682 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA05_6P7vBvXF21ZujC0vSQOUy3zsFyiks5tX1bSgaJpZM4SRp0V> .

[isislovecruft]

@maxtaco Yep! I even exported it with gpg2 --export-options "export-minimal" -a --export a3adb67a2cdb8b35 to get the smallest version possible. The problem is that it has about 20 something subkeys. (It also couldn't be imported into Github until I debugged stuff with their devs for a bit.)

[dabura667]

iirc there’s an evironment var for the max length of an arg in bash.

Though curl might choke on it. Maybe there’s a setting in curl...

Once you get bash and curl to play nice with your arg size... if there was still an issue, then that would be a keybase issue.

Also, iirc, you could just upload the master pubkey only, and tell people to pull keys from a keyserver using the figerprint verified by keybase.

[charles-dyfis-net]

@dabura667, not a bash thing, and not an environment variable as such -- the execv syscall will fail (from any calling language) if combined argv and environment variable size are beyond ARG_MAX (an operating-system invariant defined in limits.h).

If one wanted to avoid this, one would write code that pipes the arbitrarily-long content on stdin (as emitted by, say, echo or printf, or a heredoc or herestring) and tells curl to read from same, since shell builtins (not requiring an execv() to invoke) are not subject to this limit.

[charles-dyfis-net]

So, concretely: We'd want to make it --data-urlencode public_key=@- inside of the curl argument list, and either put a printf '%s' "...public key here..." | up at the top of the script (to fork a separate process and provide a FIFO with the relevant content); or <<'EOF', the public key, and a line containing only EOF, at the bottom (to generate a temporary file w/ same content; often a little faster to execute).

printf is suggested rather than echo in the former case on account of the ambiguities in the latter's specification, though so long as literal backslashes aren't allowed within ASCII-encoded keys, those ambiguities may be moot.

[dabura667]

@charles-dyfis-net So going off OPs gist... would I change it to this? https://gist.github.com/dabura667/6cd53a4bafec81f9b9daa5cb7ade2243

[charles-dyfis-net]

That should work (in bash -- POSIX only requires redirections to be honored at the front or end of a simple command, and heredocs are conventionally only at the end). For stylistic convention, better syntax-highlighting-engine support, and compatibility with more shells I'd suggest that <<'EOF' should be at the very end of the command, rather than immediately after the public_key=@-; common syntax-highlighting engines don't recognize the beginning of a heredoc except at the last line. See fork of the gist at https://gist.github.com/charles-dyfis-net/d91d8659f235f360ed0f2477a916ab1f

[dabura667]

@isislovecruft I tried this and curl passed!!!!!!!!!! but gpg failed (because I don't have your private key)

Copy paste this whole thing into your terminal and it should work.

https://gist.githubusercontent.com/dabura667/6cd53a4bafec81f9b9daa5cb7ade2243/raw/3bfd19bb3149caab390be27089884c8f087ff0bb/fixed.sh

Or generate a new one, and perform the following changes:

1. Cut the large pubkey and the " marks surrounding it.
2. replace the whole thing with @- like you see in my gist
3. At the end of the command (https://keybase.io/_/api/1.0/key/add.json) add <<'XENDOFFILEX'
4. Then add a line break and paste your pubkey.
5. then add another line break after your key and type XENDOFFILEX
6. then add another line break after the XENDOFFILEX part.
7. Copy paste the whole thing into your terminal.

It should work.

[kbabioch]

This is also an issue for me, the generated command should be working out of the box, so rather than showing the wrong command, the working version should be generated.

[keybase-travis]

I don’t think the command is wrong; rather I think it is puking because your PGP key is really big. You can likely fix the command in an editor to work around your shell’s shortcomings. Maybe with a temporary file.

On Sun, Nov 25, 2018 at 6:10 PM Karol Babioch ***@***.***> wrote: This is also an issue for me, the generated command should be working out

of the box, so rather than showing the wrong command, the working version should be generated. —

…

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10682 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOXH3630rfjhpcD-bfpHOGDOQvk6UkIOks5uyyN3gaJpZM4SRp0V> .

[charles-dyfis-net]

@keybase-travis, ...the command is suboptimal insofar as it cares about key size at all. See the alternative I provided earlier in this ticket which does not (as it passes the key on stdin, rather than either an environment variable or an argv element, both of which are subject to ARG_MAX).

It's not "a shell's shortcoming" in any respect -- the failure comes straight from the operating system's execve() syscall, as there's only a limited amount of space available for the combination of environment variables and arguments. This would happen even if you were doing the invocation straight from C.

[maxtaco]

Ok, now I remember, we'll schedule a ticket, thanks.