[HN Gopher] Supply Chain Attacks on Linux Distributions - Fedora...
___________________________________________________________________
Supply Chain Attacks on Linux Distributions - Fedora Pagure
Author : akyuu
Score : 63 points
Date : 2025-03-19 19:58 UTC (4 days ago)
(HTM) web link (fenrisk.com)
(TXT) w3m dump (fenrisk.com)
| ufo wrote:
| I've got to say, Git resignifying -- and requiring --end-of-
| options instead is bonkers
| musicale wrote:
| The pathway of untrusted/malicious input -> trusted command
| line argument seems to be a common problem, and one that could
| possibly be mitigated by better type/taint checking.
|
| It looks like there is some prior work in this area, but it
| hasn't resulted in commonly available implementations (even
| something basic like a type/taint checking version of exec()
| etc. on one side and getopt() etc. on the other.)
| PhilipRoman wrote:
| I could've sworn I remember something about bash and glibc
| cooperating to indicate which arguments come from expanded
| variables but I cannot find anything on the internet or in
| the sources. Either I'm going insane or it was an unmerged
| proposal.
| superb_dev wrote:
| > We can't change git's shell to /sbin/nologin or /bin/false, or
| users wouldn't be able to connect over SSH.
|
| Git actually has a solution for this! I don't know if it would
| work with the custom python stuff going on, but you can set the
| login shell to `git-shell`
| jbverschoor wrote:
| Or just use git over https. And heck, if that's such a big
| problem, switch to a vcs that you can properly manage
| xenophonf wrote:
| You shouldn't use Git over HTTPS. With SSH, you can use a
| hardware authenticator that requires both proof of ownership
| (i.e., the unlock PIN) and proof of possession (i.e.,
| physical touch) out of the box. That's technically possible
| over HTTPS, of course, but I have yet to see a Git server
| that works that way.
| jbverschoor wrote:
| Why not? Your password manager or passkeys do the same
| thing.
|
| Heck, just true the public key as the authentication
| header.
|
| Or use authentication certificates.
|
| If ssh is such a big problem, use something else
| rwteueru wrote:
| is anything you described actually possible with git
| tooling as it exists today, or are you just spewing
| random loosely related words?
|
| how does the git client use a passkey for https?
| arccy wrote:
| credential helpers:
|
| like the github cli:
| https://cli.github.com/manual/gh_auth_setup-git
|
| or git-credential-manager: https://github.com/git-
| ecosystem/git-credential-manager
| Joel_Mckay wrote:
| The key difference is https certificates often require
| signing authority integrity, and leak-free SSL libraries.
|
| Traditionally both facets of the 3rd party trust model
| have had CVE over the years. SSL protocol
| misconfiguration is also very common, and connections can
| be downgraded by adversaries into a vulnerable version of
| the protocol.
|
| It could be argued ssh is a weaker Trust on first use
| model, but in most cases the keys will rarely change for
| the short service life of the server instance... and the
| server may be setup from a local physical terminal, and
| keys communicated out-of-band to remote users.
|
| At some point one has to admit if someone really wants in
| they will physically pull the drive in the data center.
| However, people using web vulnerability scanners on your
| systems are less of a nuisance.
|
| Best regards =3
| Joel_Mckay wrote:
| Agreed, the ssh service on many git servers like gitea use
| their own user specific process instances to handle the
| connection.
|
| Combined with port-knocking and fail2ban, the setup has
| proven rather reliable over the years. The Go language can
| make surprisingly resilient servers if you have the memory
| available.
|
| The ssh key handling in gitea requires manual setup, and
| thus does not necessarily even have to use the same
| administrative user login key sets.
|
| Best regards =3
| awesome_dude wrote:
| FTR the "Proof of possession" relies on a (specific) random
| number being received from a device.
|
| It won't be long before that hardware device that is
| supposedly being held by a person becomes a soft device,
| which will then be impersonated.
| arccy wrote:
| it supports the mac osxkeychain for storing credentials
|
| https://git-scm.com/docs/gitcredentials#_available_helpers
| amelius wrote:
| Yeah, I tried that, but it doesn't work well with git-lfs
| (large file storage). At least, it didn't last time I tried.
___________________________________________________________________
(page generated 2025-03-23 23:00 UTC)