gitattributes: Remove forced-eol output filters#28
Open
CharlemagneLasse wants to merge 1 commit intomupen64plus:masterfrom
Open
gitattributes: Remove forced-eol output filters#28CharlemagneLasse wants to merge 1 commit intomupen64plus:masterfrom
CharlemagneLasse wants to merge 1 commit intomupen64plus:masterfrom
Conversation
After the xz backdoor incident [1] in 2024, distributions began
investing in countermeasures against the attack vectors that were used.
Among other efforts, they started comparing published git sources
against release tarballs - and some switched to using git directly as
the primary source for their builds.
Distributions that perform these integrity checks typically clone
repositories with output filters disabled. This prevents on-checkout
file modifications, which could either serve as an attack vector or
break reproducibility. Since .gitattributes offers no fine-grained
control over this, many tools disable it entirely during checkout.
This is why mupen64plus triggers errors like:
changes detected, the modified files are:
source_dir/projects/msvc/mupen64plus-*.vcxproj
The root cause is the eol output filter. To understand why:
* The text attribute acts as both an input and output filter. The input
side normalizes line endings to LF before committing; the output side
converts them back to either the configured or platform-native ending
on checkout.
* The eol attribute overrides this, forcing a specific line ending
regardless of platform convention on checkout.
In practice, this is unnecessary:
* On Linux, files are already stored with LF in git's object store - no
output conversion needed.
* On Windows, a standard git clone already produces CRLF correctly.
* For cross-compiling Windows binaries on Linux, msbuild parses parses
both line endings as needed.
Removing the forced eol output filter simplifies the checkout behavior,
eliminates unnecessary file modifications, and avoids false positives in
source integrity checks that compare tarballs against git checkout
(variants).
[1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After the xz backdoor incident [1] in 2024, distributions began investing in countermeasures against the attack vectors that were used. Among other efforts, they started comparing published git sources against release tarballs - and some switched to using git directly as the primary source for their builds.
Distributions that perform these integrity checks typically clone repositories with output filters disabled. This prevents on-checkout file modifications, which could either serve as an attack vector or break reproducibility. Since .gitattributes offers no fine-grained control over this, many tools disable it entirely during checkout.
This is why mupen64plus triggers errors like:
The root cause is the eol output filter. To understand why:
The text attribute acts as both an input and output filter. The input side normalizes line endings to LF before committing; the output side converts them back to either the configured or platform-native ending on checkout.
The eol attribute overrides this, forcing a specific line ending regardless of platform convention on checkout.
In practice, this is unnecessary:
On Linux, files are already stored with LF in git's object store - no output conversion needed.
On Windows, a standard git clone already produces CRLF correctly.
For cross-compiling Windows binaries on Linux, msbuild parses parses both line endings as needed.
Removing the forced eol output filter simplifies the checkout behavior, eliminates unnecessary file modifications, and avoids false positives in source integrity checks that compare tarballs against git checkout (variants).
[1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor