71–80 of 322 posts
Earlier quoted context omitted.
I feel like my version control system is better about highlighting the changed characters than these solid green or red strings.
It's git, so it can show a vastly better diff, just not from a URL with hardcoded diff settings.
Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/
I feel like my version control system is better about highlighting the changed characters than these solid green or red strings.
A side by side in something like "meld" will highlight changes but also means you're reading the full context as it will exist in the code base.
My number one complaint about "code review" is the number of people who simply run their eyes over the diff (in private orgs) because management says "code review" and that's as far as they ever take that in terms of defining outcomes.
Earlier quoted context omitted.
Is this by design, or by legacy? I mean, is there a better way to do this? Seems really flawed to me.
It’s by “design”, in the sense that C and C++ provide no better way to really know for sure that the functions you want to call really exist. In more modern languages we rely on metadata and semver, but none of that exists for C and C++.
Answer: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd... Description of Linux's Landlock access control system if you are not familiar with it: https://docs.kernel.org/userspace-api/landlock.html xz official (maybe...) incident response page: https://tukaani.org/xz-backdoor/
It seems like Lasse Collin is back on the scene and maybe pissed?
Most of us are humans after all, and being social creatures we tend to take violations of trust quite deeply.
Earlier quoted context omitted.
Ah yes but thanks to C being cursed due to includes and macros this is harder to do
Huh, the code with a dot is not legal C. It is CMake issue that the test breaks here.
Earlier quoted context omitted.
It’s by design. The job of autotools is to find “ground truth” about whatever environment you’re compiling against. It’s meant to discover if you can use a feature by actually seeing whether it works, not just by allow-listing a known set of compiler or library versions. This is because the whole point is to allow porting code to any environment where it’ll work , even on compilers you don’t know about. Think back to…
I don’t know. In my code I’d always compile and check at runtime?
Again, this is intended to be portable software. It is designed to work on lots of OS’s, with lots of compilers, in a lot of future environments that don’t even exist yet.
If you have a security feature for example, which uses the pledge() syscall on OpenBSD, but you can only use that feature on OpenBSD systems, you have two choices:
- Conditionally compile it based on whether you’ve detected that this is an OpenBSD target at build time, or,
- Conditionally compile it based on whether some sample code that uses pledge() builds successfully.
You can’t defer this decision until runtime, because it would require linking to pledge() symbols even though they may not exist on this system, which would cause the executable to fail to link at runtime, unless you completely rearchitected to use a plugin model, which is overkill.
So given the above are your main two options, the latter is preferred mainly because it allows new systems to come in and be compatible with old ones (maybe someone adds pledge() support to Linux one day) without having to fudge the uname command or something. This was super important in the early Unix days… perhaps less so now, but it’s still a good way to write portable software that still can take advantage of platform-specific features.
Earlier quoted context omitted.
It’s by design. The job of autotools is to find “ground truth” about whatever environment you’re compiling against. It’s meant to discover if you can use a feature by actually seeing whether it works, not just by allow-listing a known set of compiler or library versions. This is because the whole point is to allow porting code to any environment where it’ll work , even on compilers you don’t know about. Think back to…
I don’t know. In my code I’d always compile and check at runtime?
Earlier quoted context omitted.
It seems like Lasse Collin is back on the scene and maybe pissed?
If he is innocent and a victim as much as everyone else in all this, I won't blame him for wanting blood. Most of us are humans after all, and being social creatures we tend to take violations of trust quite deeply.
I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this. + # A compile check is done here because some systems have + # linux/landlock.h, but do not have the syscalls defined + # in order to actually use Linux Landlock. Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilit…
Fixing headers or extra tests would not have prevented this, as there is no indication the headers were broken in the first place, and extra tests could have been compromised (or ignored for release tarball) some other way.
[1] https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb8...
Earlier quoted context omitted.
If he is innocent and a victim as much as everyone else in all this, I won't blame him for wanting blood. Most of us are humans after all, and being social creatures we tend to take violations of trust quite deeply.
Truly seems that way currently. He said he'd really dig in starting next week and just checked his email on vacation and saw this whole mess.
His commits on these links look legit to me. It's a sad situation for him if he wasn't involved.