21–30 of 302 posts
This certainly came as a surprise to my team today. We operate some number of repositories and the majority of them use https://github.com/actions-ecosystem/action-get-latest-tag - or more specifically, a fork of that repo which more or less works the same way. Midday today our CI/CD started failing. We must have hit this so soon because the `apk add git` in that Dockerfile grabbed the new git version. Evidently the…
This feels like a thing that should be introduced default-off, allowing users to opt in to it first, and once it's been in place update the default, rather than break things suddenly when updating without being able to share a git config between systems which don't upgrade simultaneously.
This certainly came as a surprise to my team today. We operate some number of repositories and the majority of them use https://github.com/actions-ecosystem/action-get-latest-tag - or more specifically, a fork of that repo which more or less works the same way. Midday today our CI/CD started failing. We must have hit this so soon because the `apk add git` in that Dockerfile grabbed the new git version. Evidently the…
[deleted]
Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would pre…
> Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. I'm curious about this -- what's the attack vector here?
Repos can have precommit hooks, which are just executables (usually executable she'll scripts, but anything will do) that will run (as your user) on commit, checkout, etc. I feel like this change is a far bigger one than thought, and it's gonna break some workflows, such as mine where I have a git repo that's shared between multiple "users" that I run applications as. I'm glad I've not gotten too far into this projec…
Well, depending on exactly how much this blocks, this could get pretty awkward -- typing 'git log' in a repo owned by someone else can be awfully handy, even if file system permissions block changing it at all, and putting together a list of all places you might want to do this in advance could get pretty awkward. (Not running hooks, or allowing operations that would trigger them, from non-owned directories would pre…
In lack of CI I still tend to do builds in a container from a separate local user with read-only permissions. I wish they'd add an option to allow it when the user is in the owner group, which could be a decent compromise.
[0]: https://git-scm.com/docs/git-config/2.35.2#Documentation/git...
> Merely navigating to such a space with a Git-enabled `PS1` when there is a maliciously-crafted `/scratch/.git/` can lead to a compromised account. I'm curious about this -- what's the attack vector here?
I'm guessing the goal is to lock down git's security for any potential future vulnerability. If some security issue was discovered with git that could be exploited with a malicious .git directory structure, requiring git directories to be owned by the logged-in user will reduce the impact.
Shouldn't `safe_directory_cb` be checking the key parameter? It's ignoring it completely. So any unrelated config that has a directory in its value will also mark it as safe. Unless I'm misunderstanding something?