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
_______________________________________________
cfarm-users mailing list
[email protected]
https://lists.tetaneutral.net/listinfo/cfarm-users
