14 ms·

If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you wan

by c-cube 5y ago

If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?

tatersolid 5y ago
In commercial software the customers don’t have the source files…
- Perseids 5y ago
  Well, we're in a thread that started with > I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. If there is the possibility to plan ahead from a sufficiently strong bargaining position, you will not end up in the situation you described. The seller should either continue to support it with a good SLA, or you get the source code with a turn-key build system if the seller discontinues its support. Or you switch out the software if the SLA ends. Should you not be able to agree on such terms, I don't think you would have enough influence to tell the seller to write their software in such a way that dependencies are easy to hotfix/upgrade.
  - Spooky23 5y ago
    ROFL. Ok, after putting the unicorns herd to bed, an event happens and congratulations, you now own a license to PeopleSoft v.whatever source code. Oh yeah, you also got the management platform for your network provider too. Now what?
    - yjftsjthsd-h 5y ago
      It's called code escrow and it's a real thing even if it's news to you. Although yes, it's usually an insurance plan you want to never ever need because using it will suck.
jiggawatts 5y ago
The source code is not what is deployed. There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. If it came from an external organisation, things are exponentially harder. Modern deployment systems are largely "one-way", with no way to trigger a full recompile from the deployment end of things. If you have a VM with "SomeRandomBinary.exe" running on it that has a vulnerability in it, you don't have many options. IMHO, typical IT as done in the wild suffers from this write-once attitude, where the chain of provenance is too easily broken. Companies like Google have a very non-typical setup that can be copied only by very small orgs like startups. Typical enterprises look nothing like a startup or a FAANG.
- staticassertion 5y ago
  This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.
  - jethro_tell 5y ago
    It shouldn't be hard for a dev to update a dependency which should trigger an auto build and roll your pipeline. Shouldn't be hard for an upstream vendor to patch and have that pulled to kick off a new build. IDK where this idea that no one can know what's in a dependency tree is coming from but is not ops best practice for more than a decade.
    - bigiain 5y ago
      > IDK where this idea that no one can know what's in a dependency tree is coming from I’d guess people running commercial non source available binaries in production. And outside startups and unicorns, that’s almost everybody. How do you find the dependancy tree for your on prem Oracle db, or your self hosted Atlassion stuff, or your non cloud ServiceNow or PeopleSoft stuff, or your Huawei network management stuff, or or or… And what can you do for any of your cloud hosted saas stuff, beyond telling legal “I dunno, their website hasn’t said whether they’re vulnerable to exploit de jour yet”?

by c-cube 5y ago

If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?

tatersolid 5y ago

In commercial software the customers don’t have the source files…

Perseids 5y ago
Well, we're in a thread that started with > I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. If there is the possibility to plan ahead from a sufficiently strong bargaining position, you will not end up in the situation you described. The seller should either continue to support it with a good SLA, or you get the source code with a turn-key build system if the seller discontinues its support. Or you switch out the software if the SLA ends. Should you not be able to agree on such terms, I don't think you would have enough influence to tell the seller to write their software in such a way that dependencies are easy to hotfix/upgrade.
- Spooky23 5y ago
  ROFL. Ok, after putting the unicorns herd to bed, an event happens and congratulations, you now own a license to PeopleSoft v.whatever source code. Oh yeah, you also got the management platform for your network provider too. Now what?
  - yjftsjthsd-h 5y ago
    It's called code escrow and it's a real thing even if it's news to you. Although yes, it's usually an insurance plan you want to never ever need because using it will suck.

jiggawatts 5y ago

The source code is not what is deployed. There is typically no link back from a deployed system to its source, even if you compiled the binary within your organisation. If it came from an external organisation, things are exponentially harder. Modern deployment systems are largely "one-way", with no way to trigger a full recompile from the deployment end of things. If you have a VM with "SomeRandomBinary.exe" running on it that has a vulnerability in it, you don't have many options. IMHO, typical IT as done in the wild suffers from this write-once attitude, where the chain of provenance is too easily broken. Companies like Google have a very non-typical setup that can be copied only by very small orgs like startups. Typical enterprises look nothing like a startup or a FAANG.

staticassertion 5y ago
This sounds like an ops problem. It shouldn't be hard to tell what's running in your production environment and tie that back to a specific commit.
- jethro_tell 5y ago
  It shouldn't be hard for a dev to update a dependency which should trigger an auto build and roll your pipeline. Shouldn't be hard for an upstream vendor to patch and have that pulled to kick off a new build. IDK where this idea that no one can know what's in a dependency tree is coming from but is not ops best practice for more than a decade.
  - bigiain 5y ago
    > IDK where this idea that no one can know what's in a dependency tree is coming from I’d guess people running commercial non source available binaries in production. And outside startups and unicorns, that’s almost everybody. How do you find the dependancy tree for your on prem Oracle db, or your self hosted Atlassion stuff, or your non cloud ServiceNow or PeopleSoft stuff, or your Huawei network management stuff, or or or… And what can you do for any of your cloud hosted saas stuff, beyond telling legal “I dunno, their website hasn’t said whether they’re vulnerable to exploit de jour yet”?