Re: Exit code 255 after large clone (32-bit PowerPC)

On 2021-07-27 at 00:51:05, Ævar Arnfjörð Bjarmason wrote:

On Mon, Jul 26 2021, brian m. carlson wrote:

quoted

[[PGP Signed Part:Undecided]]
On 2021-07-26 at 17:54:07, Evan Miller wrote:

quoted

What did you do before the bug happened? (Steps to reproduce your issue)

$ git clone -v git@github.com:macports/macports-ports.git
Cloning into 'macports-ports'...
remote: Enumerating objects: 1223319, done.
remote: Counting objects: 100% (685/685), done.
remote: Compressing objects: 100% (341/341), done.
remote: Total 1223319 (delta 289), reused 608 (delta 252), pack-reused 1222634
Receiving objects: 100% (1223319/1223319), 244.46 MiB | 1.09 MiB/s, done.
Connection to github.com closed by remote host.

This message is the relevant detail here.  This means that the
connection was reset, which could be due to the remote host (GitHub),
but is more likely due to a network issue of some sort.  You'll have to
do normal network troubleshooting to see why that might be.

It could very well be related to the fact that you're running a nearly
14-year old operating system, but I just can't say for certain.  It's
not a bug in Git, however.

I'm not so sure it's not, I think the "Connection to github.com closed
by remote host" message is emitted by the C library, not Git itself (we
don't seem to have that exact wording anywhere, but maybe I missed
it).

That message comes from OpenSSH.  I've seen it quite frequently in
various other (non-Git) cases.  I think it's fair for us to exit
unsuccessfully if OpenSSH exits unsuccessfully in this case.  For
example, an attacker could try to tamper with the connection and send
additional data, which OpenSSH would detect and exit unsuccessfully for.
We also in general need to detect truncation attacks, which OpenSSH will
do for us here.

It's possible that if there's an older version of OpenSSH being used,
that the problem happens to be related to a bug of some sort.  There
were some versions which had various bugs that could be triggered by a
rekey, which, if the threshold is set low enough, could be the cause of
this particular problem.

I think the fact that it's not being seen with HTTPS is the ultimate
clue here.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA