It's literally a Git installer.
The overarching point is that the shell itself is not installing anything at shell runtime. E.g. it's the Git Bash installer, not opening `bash`.
This script allows you to see repository status in your prompt. It comes with 5 utility functions that AFAIKS are usable in all common shells:
__git_ps1_show_upstream ()
__git_ps1_colorize_gitstring ()
__git_eread ()
__git_sequencer_status ()
__git_ps1 ()
The `git` package installs a file `/usr/share/bash-completion/completions/git` which is picked up by bash, on Ubuntu, as a pluggable way to extend autocomplete on bash. Many packages do this, on my machine there's 960 files in there (ls -1 /usr/share/bash-completion/completions/ | wc -l).¹ It would be trivial to have a similar mechanism for `bash_rc.d` which allows for a pluggable system to extend and modify your bash. Again, I presume this to be unwanted. I would oppose it.
¹ This is why I was surprised to learn that people like zsh for the reason that it offers tab-completion: I always presumed bash did that out of the box for any installed package already. Turns out it is Ubuntu (or better: Debian) doing this for me.
There is /etc/profile.d/ which serves much the same purpose for login shells, though PS1 is normally a non-exported shell variable so it wouldn't be inherited. You can configure most other aspects of the shell this way, however. And there is also /etc/bash.bashrc which is read before ~/.bashrc, though it doesn't provide a convenient directory for drop-in scripts by default the way /etc/profile does. It would be trivial to add that if desired. (All based on Debian; YMMV.)
If we start treating "apt get will install software that can change my system" as a security issue, we should stop using all electronic devises right now.
And yea: I know, we should have sandboxing, isolation, chroot and whatnot. And we are heading there. Yet in 2022, the vast majority of computers, servers and such are installed using package managers which install packages that have access to all the system. If you count mobile devises amongst "computers" then I guess a majority (Android) does have sandboxing in packages, which solves this particular issue.
Fish allows for custom ones in ~/.config/fish and there is zero reason you cannot install custom ones in ~/.bashrc or user writable (on macOS) /usr/local
> If set, the value of this variable is used as a command which will identify all files that may have changed since the requested date/time.
That’s where you should have been concerned. Just typing a bare return will run some arbitrary code, as you, wherever you might be in the filesystem. If all of that isn’t under your control, someone can do anything to you.
If you think things are locked down strongly enough with sudo and never install anything that might add root files you don't expect you are most likely safe.
This release also adds an environment variable you can set that makes certain that git has a "ceiling" that it never crosses when checking for .git/config files. The idea being that you'd never want git to look above `/user/*/` for instance, as you'd never expect to have a "machine-wide" git config.
Git hooks have always been sketchy as hell.
Can't stand the Mac specific shit my co-workers keep dumping in there.
Wouldn't untrusted git hooks mean that git verify-* are useless since you're already running untrusted code?
>Wait, I thought git hooks aren't pulled from remote.
You are correct. They are not. Other tools may auto-install them (I hate it), but git does not ever.
(Though not completely sure.)
I can cheerfully confirm that I've absolutely never:
- received a git repo as an archive from someone, and then
- changed to root with "su" before unpacking it somewhere, such that
- the chosen location was above the home directory layer of a multi-user system.
- in such a way that one of the directories of the /path/to/home path has a .git/ subdirectory as a direct child, and not as an unpacked-tarball/.git grandchild which would not be accidentally found by git. I.e. that one of these directories exists, which might be found by someone running "git" in their home:
/.git
/path/.git
/path/to/.git
/path/to/home/.git
/foo-project-123/.git
/path/foo-project-123/.git
/path/to/foo-project-123/.git
/path/to/home/foo-project-123/.git
If I did such a thing, I'd care more about what happens when I happen to step on one of the malicious hooks in that repo as root, and less about what happens if users step on it.
Superuser could download some malware and put it into the system PATH. OK, so let's not execute anything in the PATH, unless it is owned by us.
/bin/ls? Not owned by me, don't trust it.
I know a lot of people are interested in better incapsulation for specific programs, and I know there's a lot of work being done in the area, but it's nowhere near as effective, in my opinion, as android and other systems.
linux follows the unix philosophy on this sort of. OK, you're a user, with some shell script, maybe git, maybe bash and it's PS1, I don't care, all I see as a kernel is that, you have permissions to edit this, upload this, send a packet, whatever, have fun!
From that perspective, nothing is wrong. That was my point. You could download s script that does 'rm / -Rf' and there's no security issue. User are given access to do as they please with files.
The issue is users can no longer reasonably trust the software on their system, from home-dialing marketing information and tracking, to having all sorts security issues in their virtual machines and sandboxes, running random code from websites constantly, we need a better way to encapsulate per file, per folder, per camera, per whatever, permissions, implemented at a system level.
Containerisation wouldn’t solve this, bash or similar would almost always be fun with near limitless boundaries.
As long as it's strictly opt-in, it's fine. But it needs to be opt-in to be secure.
(and I bet that many people don't even realize how easy using `git push` to mirror a repo actually is, since git is very commonly used in a centralized fashion)
In any case, this doesn't sound like a good idea at all, as git hooks exist.