4 ms·

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”?
  - staticassertion 5y ago
    Presumably you would go ask Oracle, and then patch it when they provide a patch.
    - lazide 5y ago
      Hope you’ve got a pretty sweet support contract or you’re going to be waiting awhile. Depending on the product, maybe forever.
      - staticassertion 5y ago
        My point is that patching third party binaries is generally not something companies take responsibility for. They wait for vendors to patch the binaries and ship them.
        jiggawatts 5y ago
        > generally not something companies take responsibility for I have some bad news for you: viruses and hackers don't care about your support contracts and the delays they cause. Actually, I tell a lie: the hackers love them.
        staticassertion 5y ago
        That's not relevant? The original premise here is "compiled languages will make things worse because they're harder to patch" except: a) It's very rare to patch things manually b) It's very rare to develop patches yourself (for 3rd party software) I'm sure some companies out there with many decades old deployments have to do stupid shit like that, but it's hardly the standard.
        lazide 5y ago
        Having been on the receiving end of waiting a long time to get a patch for a actively being exploited zero day - the point is, even if you want to fix it yourself (which I desperately did), you can’t. If it’s some important piece of software you also can’t stop or the business stops - well, you and everyone else is just going to take it in the pants. Many enterprises are in exactly this bind. And support contracts only get you so far.
        staticassertion 5y ago
        I'm losing your point. So, you wanted to patch it, and you couldn't, so how is it bad then that a compiled binary would make patching more difficult?
rocqua 5y ago
It is! But a lot of ops departments have problems! OPs point is that a lot of deployments out there make it really hard to remediate this kind of vuln. Moreover he is arguing that java, as opposed to fat binaries with potentially stripped symbols, made things solvable. He fears that many companies would be much worse off with a big vulnerability in e.g. a rust crate.
- staticassertion 5y ago
  Yes, some places suck. They're going to suck either way. If their system is so backwards that they need to manually patch services because everything is EOL, and compiled code will break their workflow, they have plenty of other shit to deal with. I don't think we should optimize for garbage companies with garbage practices.
  - rocqua 5y ago
    I'd say places lie on a spectrum of sucking. With a lot of places being very important and far from perfect. Those places really should get good security. That means designing for security in the common situation rather than the situation of 'best practices'. I think we should optimize security for say the 80th percentile company as far as not following best practices (i.e. 80% of companies have better practices than what I suggest targeting).
    - staticassertion 5y ago
      In no way is manually writing a patch and then live patching the common situation. The vast majority of cases, and this has been the case for decades, will be that you take responsibility for your own dependencies, and you let your vendors take responsibility for theirs.

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”?
- staticassertion 5y ago
  Presumably you would go ask Oracle, and then patch it when they provide a patch.
  - lazide 5y ago
    Hope you’ve got a pretty sweet support contract or you’re going to be waiting awhile. Depending on the product, maybe forever.
    - staticassertion 5y ago
      My point is that patching third party binaries is generally not something companies take responsibility for. They wait for vendors to patch the binaries and ship them.
      - jiggawatts 5y ago
        > generally not something companies take responsibility for I have some bad news for you: viruses and hackers don't care about your support contracts and the delays they cause. Actually, I tell a lie: the hackers love them.
        staticassertion 5y ago
        That's not relevant? The original premise here is "compiled languages will make things worse because they're harder to patch" except: a) It's very rare to patch things manually b) It's very rare to develop patches yourself (for 3rd party software) I'm sure some companies out there with many decades old deployments have to do stupid shit like that, but it's hardly the standard.
        lazide 5y ago
        Having been on the receiving end of waiting a long time to get a patch for a actively being exploited zero day - the point is, even if you want to fix it yourself (which I desperately did), you can’t. If it’s some important piece of software you also can’t stop or the business stops - well, you and everyone else is just going to take it in the pants. Many enterprises are in exactly this bind. And support contracts only get you so far.
        staticassertion 5y ago
        I'm losing your point. So, you wanted to patch it, and you couldn't, so how is it bad then that a compiled binary would make patching more difficult?

rocqua 5y ago

It is! But a lot of ops departments have problems! OPs point is that a lot of deployments out there make it really hard to remediate this kind of vuln. Moreover he is arguing that java, as opposed to fat binaries with potentially stripped symbols, made things solvable. He fears that many companies would be much worse off with a big vulnerability in e.g. a rust crate.

staticassertion 5y ago
Yes, some places suck. They're going to suck either way. If their system is so backwards that they need to manually patch services because everything is EOL, and compiled code will break their workflow, they have plenty of other shit to deal with. I don't think we should optimize for garbage companies with garbage practices.
- rocqua 5y ago
  I'd say places lie on a spectrum of sucking. With a lot of places being very important and far from perfect. Those places really should get good security. That means designing for security in the common situation rather than the situation of 'best practices'. I think we should optimize security for say the 80th percentile company as far as not following best practices (i.e. 80% of companies have better practices than what I suggest targeting).
  - staticassertion 5y ago
    In no way is manually writing a patch and then live patching the common situation. The vast majority of cases, and this has been the case for decades, will be that you take responsibility for your own dependencies, and you let your vendors take responsibility for theirs.