The interesting thing about the eMudhra issue is that it's not just your cloud environments that you need to be worried about. Think about this scenario:
Developer runs `pip install ruff` with pip < 26.2.2 on a public wifi network at their local coffee shop. Wifi network is spoofed, forwards all traffic except pip. Intercepts the pip requests and returns a malicious package. Machine is instantly compromised.
So any local development environment is also very susceptible to this kind of attack until pip, certifi, node, etc. get upgraded.
We've got good tools for finding this kind of issue CI/CD and our cloud environments. But good luck finding and patching every virtual environment on your local machine.
Do pip / certifi / node bundle their own trusted certificate authorities? Surely you should just be able to remove the compromised intermediate certificates from whatever store you're using and pip / certifi / node refer to the operating system's CA store and prevent that.
pip (and Python more broadly) rely on certifi for certificates, which bundles its own certificates. You have to explicitly point certifi to a different cert store if you don't want it to use bundled certs.
By the time you are connecting to spoofed WiFi networks you are already in trouble, using this vector seems like a really convoluted attack at that point.
Perhaps? But sub "spoofed" for "Free Wifi" and it doesn't seem to convoluted?
The point is that we've been able to trust SSL to protect us on open networks. We might not trust the owner of the infrastructure, but SSL meant that we could tell when our request had been tampered with. That's no longer the case.
Places like airports would be an absolute disaster. I’ve done so much dev work sitting in one and it would be easy enough to put a fake WiFi access point in a lounge.
we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.
75% of the problem is the detective work identifying among 1000 dependency trees running in your datacenter, and reporting the BOMs typically requires a bespoke step for each one. Every process should take a dump-BOM signal to make gathering the BOM from every cpu common , quick & instant.
Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.
Trying to respond to a signal is a nightmare of routing and lifecycle bugs. Never mind the fact that most dependencies won't be registered. Currently file/process signature matching is ok for major runtimes, and tends to fail on specific version detection. This would effectively formalise that.
I could see it being a successful standardisation for major runtimes and many libraries that wouldn't currently be detected - but take up would never be universal. A kind of CVE search stamp.
if it's in the elf then the kernel could handle the interrupting. that way every app wouldn't need to implement the handler. just a named BOM symbol and when the kernel sees the `kill -s BOM <PID>` it reads that BOM symbol without calling any app code.
You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.
i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.
The interesting thing about the eMudhra issue is that it's not just your cloud environments that you need to be worried about. Think about this scenario:
Developer runs `pip install ruff` with pip < 26.2.2 on a public wifi network at their local coffee shop. Wifi network is spoofed, forwards all traffic except pip. Intercepts the pip requests and returns a malicious package. Machine is instantly compromised.
So any local development environment is also very susceptible to this kind of attack until pip, certifi, node, etc. get upgraded.
We've got good tools for finding this kind of issue CI/CD and our cloud environments. But good luck finding and patching every virtual environment on your local machine.
Do pip / certifi / node bundle their own trusted certificate authorities? Surely you should just be able to remove the compromised intermediate certificates from whatever store you're using and pip / certifi / node refer to the operating system's CA store and prevent that.
pip (and Python more broadly) rely on certifi for certificates, which bundles its own certificates. You have to explicitly point certifi to a different cert store if you don't want it to use bundled certs.
I agree and I’m also surprised in 2026 that these revocation lists don’t update dynamically. Something like ntp for root certificates would be great.
By the time you are connecting to spoofed WiFi networks you are already in trouble, using this vector seems like a really convoluted attack at that point.
Perhaps? But sub "spoofed" for "Free Wifi" and it doesn't seem to convoluted?
The point is that we've been able to trust SSL to protect us on open networks. We might not trust the owner of the infrastructure, but SSL meant that we could tell when our request had been tampered with. That's no longer the case.
Places like airports would be an absolute disaster. I’ve done so much dev work sitting in one and it would be easy enough to put a fake WiFi access point in a lounge.
we need more standardized BOM reporting. a common signal "kill -s BOM <PID>" that has the process dump it's BOM to /dev/ttys3 . the lowest-level most common / primitive interface. no APIs, exec()s needed.
75% of the problem is the detective work identifying among 1000 dependency trees running in your datacenter, and reporting the BOMs typically requires a bespoke step for each one. Every process should take a dump-BOM signal to make gathering the BOM from every cpu common , quick & instant.
Its probably better to embed clearer strings in the binary that conform to some spec. Then searching over binaries would find them.
Trying to respond to a signal is a nightmare of routing and lifecycle bugs. Never mind the fact that most dependencies won't be registered. Currently file/process signature matching is ok for major runtimes, and tends to fail on specific version detection. This would effectively formalise that.
I could see it being a successful standardisation for major runtimes and many libraries that wouldn't currently be detected - but take up would never be universal. A kind of CVE search stamp.
if it's in the elf then the kernel could handle the interrupting. that way every app wouldn't need to implement the handler. just a named BOM symbol and when the kernel sees the `kill -s BOM <PID>` it reads that BOM symbol without calling any app code.
but there needs to be a way to query the running tasks so the control plane could query running VMs without querying the FS
You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.
i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.
Good point on that. The bom signal could be relayed. E.g. for a runtime, or multi tenant app, the parent runtime would relay the bom signal.
Presumably the runtime would have the loaded symbol table, which could be used in lieu of a BOM summary.
[flagged]
[flagged]