In STB-style headers the implementation is inside a separate ifdef/endif block which is only activated at a single include point in the whole project. At all other include points the compiler will only parse the public API declarations and skip the implementation block (which is so much faster than parsing and compiling the implementation that the difference to a header which only contains the API declaration doesn't matter much even in large projects).
For instance here is the start of the implementation block in stb_image.h, above that is just "cheap" public API declarations:
While I'm a big fan of keeping declarations and implementations as close as possible, I find that the need to explicitly #define STB_SOMETHING_IMPLEMENTATION before including the header somehow spoils the simplicity of the solution. At this point, I'd rather use a single file that acts as either a .h or a .c based on __INCLUDE_LEVEL__ (a GCC extension, not sure if available for MSC).
> your package manager that uses TLS would be vulnerable
most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues (but they could obviously still have some sort of other backdoor for gpg).
Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.
This seems like an extremely important point, which applies not just to desktop Linux (my OP,) but especially server Linux.
Since I am very much a Linux & infosec muggle, please indulge me with these possibly dumb questions:
What are the mitigations for the lack of provenance in pip/npm?
Does properly configured SELinux do enough? Or is the fact that many of these packages use 80/443 negate that? Or is the fact that a pip/npm package could be comprised after install, during update the main problem?
I always think of that left-pad NPM drama, could that single dev have comprised thousands of systems by changing his update to something much more nefarious, instead of just deleting the package?
Well, it depends on what you consider "properly configured". But I'd say most systems used by developers aren't secured against these attacks. This mostly boils down to (like discussed elsewhere in this thread) that the developer runs his tools as his user, thus malicious software can modify his .bashrc and using that hijack a later sudo invocation to gain full access.
The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.
I don't know what EPP provides (I doubt it'll help you in this case), but AFAIK least ClamAV only matches against known signatures (almost exclusively windows malware), so it can't detect newly created malware.
To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access).
The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).
> MNAO analyzed some of the code and determined that the code provides functionality same as what is currently in Apple App Store and Google Play App Store.
Is this really legal? Because in my mind, providing the same functionality does not violate copyright, since the actual intellectual material is new. And I don't think Mazda has a patent on the ability to control your vehicle over an API.
Most likely this would not stand up in court, given a proficient legal team. I imagine that the hobbyist developer had neither the money nor the inclination to mount a legal defence against a multi-billion dollar company though.
There were no charges filed in this case. The prosecutor correctly ascertained that the allegations were false and the whole thing was a waste of taxpayer money.
If they just provide the same functionality, no. Mazda should lose this under Google v. Oracle. However, reverse engineering is dangerous. They surely read the copyrighted decompiled code. The test is whether the expressive elements of bdr99's implementation are substantially similar.
> They surely read the copyrighted decompiled code
Do they? When it comes to reverse-engineering mobile app APIs, the usual strategy is to observe the network because it's so much easier than making sense of the disassembled binary.
Even if you can decompile, you'd generally use it as an aid to understand the network captures rather than using it as your primary source.
While if possible, it's the best course of action, the truth is these days additions like HSTS make it extremely difficult to MITM.
Additionally, MITM and trying things out on a toaster are one thing, doing the same on a 40k$ machine that can potentially make it impossible to do your commute is another.
This is IMO a prime example where the double team rev eng is key to success: one documents the API, the other uses it without having access to code (whiteroom)
HSTS interferes with MITM when the mobile device in question doesn't allow you to install new certificate authorities (as is slowly becoming the case).
They could argue that by viewing the copyrighted code/implementation, you could effectively infringe by (even subconsciously) writing the same/similar code.
There's merits to this claim if you're indeed implementing some advanced, niche algorithm but it definitely wouldn't apply here as all he's doing is calling HTTP APIs, a very generic and common thing to do.
You may have come across this concept already, but this is where clean rooms come in.
One person views the "contaminated" decompiled code and writes a specification. A separate person writes the code based solely on the specification. This is an accepted method of demonstrating that there is no infringement.
That kind of depends on the language, but it's a fair point. I think it might only matter that the general algorithm/solution is the same, not the lines of text themselves.
This might be the case, but how could Mazda even prove this? Unless they communicate in some weird proprietary binary protocol I could imagine that the API (especially if it's just some JSON/XML REST stuff) can be reverse engineered by MitM traffic analysis.
As I understand it, car manufacturers prevent independent repair shops from lawfully obtaining some of the diagnostics information in the onboard computer by encrypting it with a key that sits on the very same drive. Said encryption is the "technological measure that effectively controls access" and using the key to decrypt it is "circumvention" -- naturally, of the "effective" access control.
(https://www.law.cornell.edu/definitions/uscode.php?def_id=17... to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner)
Mazda might be interpreting the SSL certificate as a similar measure and therefore use of the certificate to decrypt traffic as a similar violation.
From the posted notice[1], they answered "No" to the question "Do you claim to have any technological measures in place to control access to your copyrighted content? Please see our Complaints about Anti-Circumvention Technology if you are unsure." Is that the same thing you are referencing?
> 16k lines of obscure C, riddled with pointer magic and arcane memory manipulations? No thanks
Given the popularity of the library I'd imagine it's quite well tested. I also fail to understand why he attempts to port libshine from C to Go when he could just port the header files from LAME as FFI bindings instead. That should also ensure comparability with windows, as I'm sure such a library us also buildable on windows, given that ffmpeg uses it and ffmpeg works on windows.
Go programmers usually avoid C bindings if at all possible.
Pure Go can be cross-compiled easily, but that goes out the window once you include C code. You can make it a bit easier by using Zig as your c compiler, but it's still a bit of a pain. If you want to expose your code as a Go package, the situation gets even more complicated.
I don't think this has anything to do with "attack surface". This is simply to avoid google collecting ip addresses.
Running nginx might be marginally faster than PHP, but I believe the latency to your server will be far greater than the time it takes the server "to spin up the php interpreter" (doesn't even happen anymore when using FastCGI).
Yes, this is certainly more "far-reaching" than other env vars. But If you have the ability to wreak havoc even if ld-linux wouldn't check for this (obv. PATH being the prime example, but unsetting HOME will almost certainly break some software written by novices (not falling back to the home specified in /etc/passwd)).
And I also could imagine that tools that allow setting arbitrary env vars might filter common troublemakers like PATH, but almost certainly not niche env vars that change the bahviour of ld-linux.
There is also gobject-introspection[0], which is also capable to generate bindings for quite a lot of higher level languages from (gobject based) c-code.
I'm always impressed on how simple it is to use an object I defined in c within python.
I remember my old Nokia brick having the ability to send files and apps through an infrared thingy on its side. You could simply hold two phones side by side from each other and transfer data, but I remember handly anyone using it (I guess it was kind of akwad to use - but probably still simpler than getting the devices paird with bluethooth).
It wasn't nearly as fast the advertised speeds mentioned in the article.
