21–30 of 137 posts
Earlier quoted context omitted.
OMG that's evil. The diff just shows: + +. + and the dot goes unnoticed
I wonder why they didn't use a non-breaking space or similar. I guess it's possible a nbsp would stand out even more.
Earlier quoted context omitted.
No, as far as I understand the binary files must be pointed at here: '$gl_am_configmake' ... But I don't see how. This: 'gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/`' seem to match the '####Hello####', but, as far as I can see, that's supposed to be the already converted script?! I presumed the binary files not to contain human readable strings, maybe that's the whole confusion.
Opening bad-3-corrupt_lzma2.xz in an editor reveals it indeed has the string ####Hello####. I don't know enough about lzma compression streams to explain how this appears in the "compressed" version of the payload, but it does.
How on earth did any of this make it through a code review and get merged in? It seems absurdly careless, unless I am missing something.
the bad actor was a co-maintainer of the repo (and even more active than the original maintainer for quite some time) with full commit rights. This was strait committed to master, no PR and no review required. edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.
> xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;iYou should probably expect the potential for abuse?
We’re moving towards complexity that is outpacing human ability for any one person to understand, explain, and thus check an entire object.
And for what? Build efficiency? Making a “trick” thing? When was the project ever going to go back and make things simpler? (Never)
Did anyone search github yet for similar head | tail tricks ? I doubt it was invented just for this.
https://github.com/tukaani-project/.github/issues/2
Earlier quoted context omitted.
the bad actor was a co-maintainer of the repo (and even more active than the original maintainer for quite some time) with full commit rights. This was strait committed to master, no PR and no review required. edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.
In addition… if your build system has things like this as OK: > xz -dc $top_srcdir/tests/files/$p | eval $i | LC_ALL=C sed "s/\(.\)/\1\n/g" | LC_ALL=C awk 'BEGIN{FS="\n";RS="\n";ORS="";m=256;for(i=0;i You should probably expect the potential for abuse? We’re moving towards complexity that is outpacing human ability for any one person to understand, explain, and thus check an entire object. And for what? Build efficie…
This is 1990s autoconf bs that has not yet been excised from the Linux ecosystem. Every modern build system, even the really obtuse ones, are less insane than autoconf.
And the original purpose of this was not for efficiency, but to support a huge variety of target OSes/distros/architectures, most of which are no longer used in any real capacity.
Did anyone search github yet for similar head | tail tricks ? I doubt it was invented just for this.
It’s clever but not entirely novel, this is kind of the intended usecase for these
How on earth did any of this make it through a code review and get merged in? It seems absurdly careless, unless I am missing something.
the bad actor was a co-maintainer of the repo (and even more active than the original maintainer for quite some time) with full commit rights. This was strait committed to master, no PR and no review required. edit: also this was heavily obfuscated in some binary files that were marked as test files ("good" and "bad" xz compressed test file). No way to spot this if you don't know what you're looking for.
Code reviews are more about education and de-siloing.