Git security vulnerability announced

Re:Git security vulnerability announced by berkes on Wednesday April 13, 2022 @02:41AM (#31011843)

On Ubuntu, and I presume therefore many debian derivatives and debian itself, `apt get git` will install a file called `/usr/lib/git-core/git-sh-prompt` (dpkg -S /usr/lib/git-core/git-sh-prompt).

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 ()

On Ubuntu those aren't installed into bash by default, but you need to add it yourself to your ~/.bashrc (or zsh or whatever, but those aren't the default in Ubuntu). The mechanisms aren't in place for a package to inject itself into your prompt, but it isn't unthinkable (though maybe unwanted) to have that. Similar to how tab-complete for bash is handled:

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.

[ Parent | on HN ]

Re:Git security vulnerability announced by nybble41 on Wednesday April 13, 2022 @02:14PM (#31018175)

> 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.

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.)

[ Parent | on HN ]

Re:Git security vulnerability announced by leni536 on Wednesday April 13, 2022 @03:36AM (#31012095)

This feels like tab completion is a more serious attack vector then?

[ Parent | on HN ]

Re:Git security vulnerability announced by berkes on Wednesday April 13, 2022 @09:10AM (#31014178)

Anything installed through `apt` could be an attack vector, but that is silly, really.

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.

[ Parent | on HN ]

Re:Git security vulnerability announced by dahfizz on Wednesday April 13, 2022 @08:17AM (#31013741)

You need to be root to add a file to the basl completions directory, so not really.

[ Parent | on HN ]

Re:Git security vulnerability announced by Fnoord on Wednesday April 13, 2022 @03:45PM (#31019327)

There is no the bash completion directory; there is a default one which happens to be system wide and only root writable (as should be the case in a combination of such circumstances).

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

[ Parent | on HN ]