[cfarm-users] Unable to git pull on gcc112

[Jacob Bachmeyer]

Segher Boessenkool wrote:
> On Thu, Mar 31, 2022 at 09:24:20PM -0500, Jacob Bachmeyer via cfarm-users wrote:
>   
>> 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.
>>     
> [...]
>   
> Security should be tight by default, and it should be super easy to set
> up something in a secure way.

Agreed, but with emphasis on "by default" -- the option almost always 
should exist.

> Git fails in that first thing currently,
>   

Not quite -- arguably Git has no default here, since you must specify a 
protocol for all non-local clones.  Offering the HTTPS URL for 
copy-and-paste for cloning a repository is perfectly reasonable for a 
public repository hosting service to do, as long as the 
trivially-derivable HTTP and Git URLs also work for users that want or 
need them.

> but GitHub's recent move fails in the latter for a non-trivial fraction
> of users.  But they obviously feel they have to do something, and I
> applaud them for that.
>   

"We need to do something.  ...  This is something, therefore we must do it."

> All of this is off-topic for this list, so let's leave it at that.

Uh, no, you do not get to end the conversation with your position 
unanswered like that.


Bringing this back to the list topic, that balance of risk and 
mitigation efforts applies here:  assuming that an attack is more likely 
to be "near" the origin server than "near" the client, the risk is 
similar between your up-to-date workstation and the much older cfarm 
machines, but the efforts required to mitigate that risk at the "git 
clone" or "git pull" stage are wildly different:  next to nothing on 
your workstation (it is already set up with current TLS CA certificates 
and the latest TLS versions) and very significant on the cfarm machines 
(possibly extensive software upgrades and TLS troubleshooting).

Defaults are fine, but removing options (as GitHub has done here) is bad 
and wrong.  Also, do not conflate "encrypted" with "secure" and vice 
versa.  Cryptography is _not_ magic security pixie dust.  Remember the 
Debian OpenSSL PRNG fiasco?

So there are other mitigations possible on the cfarm machines, such as 
verifying branch tip commit IDs after "git pull" or eliminating GitHub 
from the picture entirely and pushing (using SSH) from your workstation 
to a bare repository mirror at the farm, then updating your "working" 
clone using a local "git pull" on the farm machine.


-- Jacob