4 ms·

I think Java’s DNS namespacing is, at best, only a weak benefit to the supply chain security posture of Java packaging as a whole. I think it’s more that Java i

I think Java’s DNS namespacing is, at best, only a weak benefit to the supply chain security posture of Java packaging as a whole. I think it’s more that Java is (1) a batteries-included language, (2) lacks the same pervasive open source packaging culture that Python, Rust, JS, etc. have, (3) is much more conservative around dependency updates as a community, and (4) lacks a (well-known?) build time code execution vector similar to JS’s install scripts or Python’s setup.py. (Most of these are good things, to be clear!)

TZubiri 10mo ago
There being a compile/runtime difference at all seems quite impactful to dependency mgmt as a whole apparently, I've seen impacts in bc, build times and now security.
rectang 10mo ago
Thanks for this insight-dense comment — and for all the efforts you have put into Trusted Publishing.
fc417fc802 10mo ago
> lacks a (well-known?) build time code execution vector similar to JS’s install scripts or Python’s setup.py How is that leveraged by attackers in practice? Naively I would expect the actual issue to be insufficient sandboxing (network access in particular).
- immibis 10mo ago
  If the attacker can't run code, does it matter whether they're not running code inside or outside of a sandbox?
  - fc417fc802 10mo ago
    If you encase your computer in a block of cement an attacker will have great difficulty breaking into it. Nevertheless it might be useful to know if previous break ins were facilitated by a buffer overflow, a misconfiguration, or something else. Probably you can arrive at solution that is reasonably secure while being significantly more user friendly than the 55 gallon drum filled with a soon to be solid. More seriously - scenarios that call for executing arbitrary tools during a build are common, an increasing number of languages enjoy compile time code execution, and quite a few of those languages don't go out of their way to place any restrictions on the code that executes (many lisps for example).
- woodruffw 10mo ago
  All of the recent “Shai-Hulud” attack waves leveraged build-time execution, since it’s a reliable way to actually execute code on a target (unlike putting the payload in the dependency itself, since the dependency’s own code might not run until much later.) Sandboxing would be a useful layer of defense, but it’s not a trivial one to add to ecosystems where execution on the host is already the norm and assumption.
  - fc417fc802 10mo ago
    I suppose I can understand the backwards compatibility angle. However at least personally I'm of the view that anything accessing the network during a build should be killed with fire. I draw a hard line against using dependencies that won't build in a network isolated environment.
    - woodruffw 10mo ago
      Yeah, I think forbidding network access within build systems is would be a great default to employ. (I wouldn’t be surprised to learn that a large number of packages in Python do in fact have legitimate network build-time dependencies. But it would be great to actually be able to quantify this so the situation could be improved.)
      - TZubiri 10mo ago
        Is it really legitimate to have build time network deps? It just means the full source wasn't published and there's some hidden source being downloaded
        woodruffw 10mo ago
        I don’t know, I don’t have a value position on it. I just think it does happen as a matter of course. (Legitimate seems like a gray area to me — it’s common for applications to have a downloadable installer that then bootstraps the actual program, for example. Is this good or bad? I don’t know!)

TZubiri 10mo ago

There being a compile/runtime difference at all seems quite impactful to dependency mgmt as a whole apparently, I've seen impacts in bc, build times and now security.

rectang 10mo ago

Thanks for this insight-dense comment — and for all the efforts you have put into Trusted Publishing.

fc417fc802 10mo ago

> lacks a (well-known?) build time code execution vector similar to JS’s install scripts or Python’s setup.py How is that leveraged by attackers in practice? Naively I would expect the actual issue to be insufficient sandboxing (network access in particular).

immibis 10mo ago
If the attacker can't run code, does it matter whether they're not running code inside or outside of a sandbox?
- fc417fc802 10mo ago
  If you encase your computer in a block of cement an attacker will have great difficulty breaking into it. Nevertheless it might be useful to know if previous break ins were facilitated by a buffer overflow, a misconfiguration, or something else. Probably you can arrive at solution that is reasonably secure while being significantly more user friendly than the 55 gallon drum filled with a soon to be solid. More seriously - scenarios that call for executing arbitrary tools during a build are common, an increasing number of languages enjoy compile time code execution, and quite a few of those languages don't go out of their way to place any restrictions on the code that executes (many lisps for example).
woodruffw 10mo ago
All of the recent “Shai-Hulud” attack waves leveraged build-time execution, since it’s a reliable way to actually execute code on a target (unlike putting the payload in the dependency itself, since the dependency’s own code might not run until much later.) Sandboxing would be a useful layer of defense, but it’s not a trivial one to add to ecosystems where execution on the host is already the norm and assumption.
- fc417fc802 10mo ago
  I suppose I can understand the backwards compatibility angle. However at least personally I'm of the view that anything accessing the network during a build should be killed with fire. I draw a hard line against using dependencies that won't build in a network isolated environment.
  - woodruffw 10mo ago
    Yeah, I think forbidding network access within build systems is would be a great default to employ. (I wouldn’t be surprised to learn that a large number of packages in Python do in fact have legitimate network build-time dependencies. But it would be great to actually be able to quantify this so the situation could be improved.)
    - TZubiri 10mo ago
      Is it really legitimate to have build time network deps? It just means the full source wasn't published and there's some hidden source being downloaded
      - woodruffw 10mo ago
        I don’t know, I don’t have a value position on it. I just think it does happen as a matter of course. (Legitimate seems like a gray area to me — it’s common for applications to have a downloadable installer that then bootstraps the actual program, for example. Is this good or bad? I don’t know!)