Cloning a (large) repository from GitHub.com over HTTPS seems to error out before the clone completes. However cloning over authenticated SSH seems to have higher likelihood of success.
remote: Enumerating objects: 8305, done.
remote: Counting objects: 100% (8305/8305), done.
remote: Compressing objects: 100% (6563/6563), done.
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL (err 8)
error: 7793 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
To follow up on this. I found a discussion of a similar issue on the GitHub community forum and it appears this issue may be because of slow connections (<1MB/s) and may not be an issue with Tor usage per se. Unfortunately GitHub staff do not actively monitor that forum and attempts by others at contacting customer support have not led to a resolution.
Perhaps if others encounter this issue they could also contact GitHub support and note down the mentioned ticket numbers to attempt to obtain priority for this issue.
That was me (hoping to gain a larger audience and further information regarding this issue)
What GitHub repositories are you reliably reproduce this issue against?
torvalds/linux is big (~5GB) and works for this, but there are others I have succeeded in attempted reproduction including nodejs/node and v8/v8. I do not think this is an issue of any individual repository. Reproducing this issue is a condition of a) the connection speed being low enough and b) the required data to transfer being high enough that (presumably) due to a server-side issue with GitHub.com it is triggered.
For various reasons, I am no longer participating on the Tor Project Forum, so I will address your issue on the Whonix Forums instead. Try downloading each GitHub repository’s ZIP file from Whonix using the Tor Browser and/or Terminal using wget or similar:
Another idea is to change Tor circuits by either waiting ten minutes or temporarily disconnecting from the Tor network, which will affect the maximum bandwidth speed:
I have not encountered the same issue during brief testing. However those are singular checkouts as opposed to full repository clones. In addition others on the GitHub community forum have claimed to have tested file downloads from GitHub.com and have not encountered the same issues as with repository clones via HTTPS.
Another idea is to change Tor circuits by either waiting ten minutes or temporarily disconnecting from the Tor network, which will affect the maximum bandwidth speed
git under Whonix-Workstation is uwt wrapped by default which enforces stream-isolation (and thus a different circuit) for multiple invocations. Obviously to rule other factors out I have tested a normal Linux distribution with a manually configured SOCKS proxy behind Whonix-Gateway and can reproduce the same issue.
Looking through the GitHub discussion, here is a comment that may be relevant towards addressing your issue:
Right, generic Tor troubleshooting steps only apply to the Tor Project Forum, not the Whonix Forum.
I will mention that my security practices strictly prevent me from participating on Big Tech platforms, so I am unable to handle this task on your behalf.
Agree to disagree. While I am not going to encourage overuse of Big Tech platforms participation can be achieved with an understanding and practice of OpSec in place to avoid risks of security. But that is a discussion for a different topic.
And it is ok. It seems like there is enough feedback from others.
Okay, well what I can do is migrate all three GitHub repositories to Codeberg and see if you are able to clone them there instead:
This assumes your main objective is to clone the repositories themselves, so if Codeberg works fine for your needs, I have no issue migrating any amount of GitHub (and/or other forges’) repositories you point at until GitHub officially addresses this issue.
Thank you. But these repositories were merely used as examples to demonstrate this issue for GitHub support. So I do not exactly need to clone them for usage in this case.