[cfarm-users] Unable to git pull on gcc112

[Jacob Bachmeyer]

Vincent Lefevre via cfarm-users wrote:
> On 2022-03-30 18:52:23 -0500, Jacob Bachmeyer via cfarm-users wrote:
>   
>> Vincent Lefevre via cfarm-users wrote:
>>     
>>> On 2022-03-29 22:01:26 -0500, Jacob Bachmeyer via cfarm-users wrote:
>>>       
>>>> Jeffrey Walton via cfarm-users wrote:
>>>>         
>>>>> When I try git://github.com/weidai11/cryptopp/:
>>>>>
>>>>> $ git pull
>>>>> fatal: remote error:
>>>>>  The unauthenticated git protocol on port 9418 is no longer supported.
>>>>>           
>>>> While this does not help you, the root of this latter problem seems to be
>>>> that GitHub has decided to deliberately break compatibility with one of
>>>> Git's standard features using "security" as an excuse.  This is, of course,
>>>> ridiculous for public repositories, since public repositories are, well,
>>>> public.
>>>>         
>>> Even though they are public, you still need to have a way to
>>> authenticate the host to ensure that you will not connect to
>>> a fake server (in particular with "git clone").
>>>       
>
> Actually an attack is also possible for "git pull".
>   

Yes, but the solution is the same:  review the code/changes in your 
local repository, then make sure the commit IDs match at the farm.

Failing to review changes from upstream is how the recent node-ipc 
incident did damage.  (Of course, about no one actually does fully 
review patches pulled from upstream, which is why those violations of 
trust do so much damage...)

>> Easily solved by checking the HEAD commit against a known-good ID; either
>> the origin tracking branch in your local copy, or as I have done in the past
>> with GitHub, by looking at the (HTTPS) Web page.  If those IDs match, you
>> have the correct data, with overwhelming probability.  If they do not match,
>> find the differences and you have just caught an attacker in the act.
>>     
>
> AFAIK, this also needs to be done for every branch that will
> potentially be used.
>   

Yes, but for cfarm that should not be a problem, since you should be 
comparing against your local copy.  Also, most of the repositories I 
have used from GitHub have few branches, often only the default "master" 
(now often renamed "main" in a fit of slacktivist stupidity) so these 
checks are usually trivial.  Generally, I avoid GitHub; they get a very 
solid "F" on the FSF's rating scale because the site does not work 
without running nonfree JavaScript, and I make heavy use of NoScript as 
part of my general security policy.

This may actually be another workaround:  keep local copies of 
repositories that you use and push from those to the farm.  Then you 
never need to pull from GitHub on the farm machines, only from your farm 
mirrors, which you update via SSH "git push" from your own machine.  Git 
clones on the same filesystem use hardlinks to share the actual object 
pool, so there is minimal overhead with this setup.

> Most users will not do such checks, so it's quite understandable
> that GitHub disabled an insecure protocol. Nowadays, I don't see
> the point of not using a secure protocol.

Security is always a trade-off and is never entirely without costs.  I 
stand by my original position that GitHub removing choice from the user 
here is bad and wrong.  Rightly, it is up to you to balance risk vs. 
effort to mitigate same as they apply to _your_ situation.

There are also possibilities of attacks effective against HTTP(S) that 
cannot work against other other protocols.  At least one example is 
known.  "Man on the Side" exploits the option of returning a redirect in 
HTTP by racing origin server latency.  A similar attack _may_ be 
possible on HTTPS, if the attacker can complete a TLS negotiation before 
the first origin server reply arrives.  Similar attacks are definitely 
_not_ possible on FTP and the 9418 Git protocol, which do not allow 
servers to refer clients to other servers.  Against this particular type 
of attack, therefore, those plaintext protocols may offer _greater_ 
security than the encrypted HTTPS.


-- Jacob