PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur gotcha - or rather: gitcha!
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur FWIW I reported this to the git ML... lets see
-
-
undefined swelljoe@mas.to shared this topic
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur@mas.to Wow, great example of the beautiful abstract layer provided by Modern Frontend™ broken by underlying email-based infrastructure.
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur i wonder if this works when the diff is hidden within a markdown comment <!— like this —>
That could be an extremely bad vulnerability
-
@zekjur i wonder if this works when the diff is hidden within a markdown comment <!— like this —>
That could be an extremely bad vulnerability
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur genuinely why would this ever be the case in the modern day -
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur Ohh, that's nasty :D
-
@funbaker yes those work in markdown
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur oh, that's hilarious
-
-
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur well there ya go. You put the entire code of your malicious repo in the commit message and just put decoy code as the repo src.
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur classic lack of separation of in-band vs. out-of-band. Very similar to many security vulnerabilities get created, including some of the recent gpg.fail vulnerabilities.
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur weird little footguns
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur For being a central component of software development, "unified context diff" files are surprisingly fragile.
- Tools are supposed to skip "garbage" lines and apply everything that looks like a diff (this is what's happening here).
- Creating and deleting files is a done via implementation-specific hacks. GNU patch for example cannot create or delete an empty file.
- The format of file names is standardized, but the definition is lacking (see above), so Git does something else.
etc.
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur Why would someone design it like that? What's the possible use case for this behavior?
-
PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
Like https://github.com/i3/i3/pull/6564 for example
Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
@zekjur Just fucking stop using github.
-
@max
A strong case can be made though that thepatchtool garbage erasure must only apply to initial “garbage”, rather than initial and inter-chunk garbage. That’s the aspect that causes the surprise here: VCS diffs only ever place commit metadata (including the message) before the actual patch, but thepatchtool allows this metadata (“garbage”) anywhere. At least forgit applythat is an obvious bug in and of itself.Secondly, given this
git showshould have exported the commit message with one leading space on every line, as that is the escaping mechanism specified bypatchfor “garbage” data.Doing both of the above changes would make for a robust mitigation on all levels.
@bmarinov @zekjur @musicmatze