271–280 of 336 posts
Earlier quoted context omitted.
I hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.
I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".
What I haven't seen discussed much is the linking mechanism that allowed the lib to hook into RSA_public_decrypt. Plenty of talk about what could or could not be achieved by even more process separation and the like, but little about that function call redirect. Could it be possible to establish a way to link critical components like the code for incoming ssh with libraries in some tiered trust way? "I trust you when…
Earlier quoted context omitted.
systemd merged a change to using dlopen for compression libraries recently https://github.com/systemd/systemd/pull/31550 which is a safer linking method in that sense.
This hides the dependencies from ldd doesn't it?
My personal takeaways from this: 1. Source distribution tarballs that contain code different from what's in the source repository are bad, we should move away from them. The other big supply chan attack (event-stream) also took advantage of something similar. 1a. As a consequence of (1) autogenerated artifacts should always be committed. 2. Autogenerated artifacts that everyone pagedowns over during code reviews is a…
This is ridiculous, nobody "encourages" every service to depend on it for initialization notifications, you can implement the logic in 10 lines of code or less.
Earlier quoted context omitted.
Notice that the protocol specification is way more complex than that, and already changed since systemd was released. All the library does is sending some data through the socket, but that's not at all what the docs tell you to do.
The docs could be better, sure, but where did this idea what "interfaces can never be changed" come from?
But surely, what is needed is "interfaces can never be changed without redefining your project in a way that makes absolutely obvious it's incompatible with its past". Systemd fails that one too.
Earlier quoted context omitted.
> 1a. As a consequence of (1) autogenerated artifacts should always be committed. Why don't object files and binaries count as autogenerated artifacts? Should we commit those to the repo too? Where is the line between an artifact that should be committed, and one that shouldn't be? > 4. Libsystemd is a problem for the ecosystem. libc will dynamically load libnss-* on a lot of platforms, some of which can link to a bu…
> Is libc a problem for the ecosystem? Absolutely yes. And also the size of the kernel. Those two currently have a much better guaranteed quality than systemd, thus systemd is a much more pressing issue. But they don't stop being a problem just because they are not the largest one.
Is mostly in the hardware support, only a tiny fraction of which is actually active. Linux has a lot of drivers, many of them are crap, but it's not obvious to me that Linux would be better off with no driver than a crap driver.
Earlier quoted context omitted.
They did communicate off list and non publicly, that's as much as we know at the moment. As an open source developer he might have received donations too from the adversary - it's reasonably common for devs to get donations to "say thanks". He might have had voice chats with them, who knows. The emails might be with LEO at the moment but I think its in the public interest for all communications to be released.
It is unfortunate that Lasse Collin has been silent about what he knows about him
Earlier quoted context omitted.
I hope Open Source maintainers and the big companies get the message -- they need to change the financial outlook of open source maintaining.
I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".
Earlier quoted context omitted.
I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…
https://xkcd.com/927/
Earlier quoted context omitted.
I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…
A few things here. First, yes, there's several tools which provide (incomplete) feature selection functionality, you can see some sibling comments for examples. Second, especially in complex projects, the presence of a feature doesn't necessarily mean it's sufficiently complete to be workable. You can run into issues like, say, "I need io_uring, but I need an io_uring op added in version X.Y and so it's not sufficien…
That sounds fine though. If the system claims to provide feature X, you probably want the program in question to compile assuming feature X is available. If the compatibility layer doesn’t work as advertised, a compiler error is a great choice. Let the user choose to turn off that flag in their system configuration when building the project.
I’m not proposing user agent sniffing. I’m proposing something much more fine grained than that. Make something that looks more like the output of configure that build systems can use as input.