ingydotnet/git-hub

`git hub issue-new` error — “New issue failed: Problems parsing JSON”

Opened this issue · 2 comments

8573 commented 
$ git hub issue-new Raynes/refheap
New issue failed: Problems parsing JSON
$ git hub -v issue-new Raynes/refheap
curl --request POST https://api.github.com/repos/Raynes/refheap/issues -d {"title":"SSLLabs.com’s SSL Server Test says refheap.com is vulnerable to CVE-2014-0224","body":[SSLLabs.com’s SSL Server Test] [ssltest], [run on www.refheap.com] [results],
states that:

> This server is vulnerable to the [OpenSSL CCS vulnerability (CVE-2014-0224)]
> [cvepost] and exploitable.

The linked blog post seems to state that this issue can be fixed by updating
one’s OpenSSL version.

[ssltest]: <https://www.ssllabs.com/ssltest/>
[results]: <https://www.ssllabs.com/ssltest/analyze.html?d=www.refheap.com>
[cvepost]: <https://community.qualys.com/blogs/securitylabs/2014/06/13/ssl-pulse-49-vulnerable-to-cve-2014-0224-14-exploitable>

} --header Authorization: token ******** --user-agent git-hub-0.1.4 --dump-header /Users/<me>/.git-hub/cache/head --output /Users/<me>/.git-hub/cache/out --stderr /Users/<me>/.git-hub/cache/err --silent --show-error

New issue failed: Problems parsing JSON

API status code: 400

API error output:
Bad Request

See files in: /Users/<me>/.git-hub/cache/59528375875752589c03ab152ae95129dadf1101/

I’ve uploaded the referenced head and out files (the ones in
~/.git-hub/cache being identical to those in
~/.git-hub/cache/59528375875752589c03ab152ae95129dadf1101) to Gist
(https://gist.github.com/8573/88e6ee519413f4c70729); the err files
are empty.

8573 commented

However, git hub issue-new filed this issue successfully, the apparent
differences being that this issue was filed from the working tree of my clone
of the target GitHub repository, and I did not explicitly specify the target
GitHub repository:

$ git hub issue-new
New issue created: 'https://github.com/ingydotnet/git-hub/issues/148'
dhduvall commented

I've had a similar issue with creating pull requests. I tracked it down to the value of the "body" element of the JSON request having literal newlines in it, which I could reproduce simply by running the same curl command stand-alone. Once I replaced those newlines with "\n", then the curl command worked.

I ended up fixing this in json-escape() by putting a second ${back} in the RHS of the substitution for \n, but I don't know if that breaks anything else. (And because of that I don't know whether it's this same issue.)

Seems like this would be less of a problem in a language other than shell, but I wouldn't want a simple bug to trigger a full project rewrite. :)