7 ms·

I eagerly await some concrete implementations of these new ideas. In the meantime I'm waiting for the first big vulnerability in a widely used golang or rust l

by ris 5y ago

I eagerly await some concrete implementations of these new ideas. In the meantime I'm waiting for the first big vulnerability in a widely used golang or rust library to see if downstream projects pinning it also release CVEs as they should (which would probably DDoS the CVE system from the resulting avalanche) or they quietly bump it and move on (in which case their users won't get the nudge to upgrade). This is where someone says "well you should just always be running the latest version of everything", which is of course infeasible on a real life system with thousands of installed packages. And it's not that I don't completely sympathize or understand the advantages of static linking from a developer's point of view - you don't have to sell it to me there.

DaiPlusPlus 5y ago
The design of the Go build and packages system kinda renders that point moot because the expectation is that provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries (e.g. https://github.com/golang/go/issues/2775 https://github.com/golang/go/issues/2775 ).
- Macha 5y ago
  Right, but if every application did distribute as source and could just be recompiled, there would be fewer complaints about the difficulties distributing Linux binaries
- Zababa 5y ago
  > provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries So it's a human solution, and not a technical one, which means that it can and will fail.
  - DaiPlusPlus 5y ago
    That's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. Provided you (and your org) use Go as Google intends then that isn't an issue.
    - Zababa 5y ago
      > That's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. I think it's closer to say that the existance of condoms won't make AIDS and unwanted pregnancies disappear, even if they were 100% effective. Which, if you're trying to eliminate completly AIDS, is a fair claim to make. My point is that you shouldn't assume that everyone is going to follow the Go guidelines, because some people won't, and you don't want your security to rely on that.
Wowfunhappy 5y ago
> This is where someone says "well you should just always be running the latest version of everything", which is of course infeasible on a real life system with thousands of installed packages. Is updating a library with thousands of dependents, without individually testing those dependents, any more feasible?
- CyberShadow 5y ago
  You would have to do that anyway. With static linking, you also have to rebuild those dependents and make sure their users update them as well.
  - Wowfunhappy 5y ago
    I would rather the developers rebuild the dependents, test them, make any necessary fixes, and send me the updated (presumably static) binaries. As opposed to me, as an individual user with no familiarity with the code base, just switching out the pieces and preying nothing goes wrong.
    - ris 5y ago
      And if the upstream developers are unresponsive, or only provide the bump with the latest bleeding-edge version which you can't upgrade to yet?
      - Wowfunhappy 5y ago
        On a system where security is critical, I would probably need to re-evaluate my use of that software. It doesn't necessarily need to be the upstream developer, it could be some other organization analogous to a distro maintainer. What matters is that someone who is familiar with the software and code base has actually tested the update in a purposeful way.
    - AussieWog93 5y ago
      As a small developer who handles my own support, I agree with this sentiment completely!!
bregma 5y ago
It would certainly make the embedded industry more secure if it was always running the latest version of everything. Or at least the ISPs, because imagine the bandwidth they're be able to charge for as everything from your washing machine to your watch to your lightbulbs to your car downloads new images hourly.
- ris 5y ago
  Just imagining the joy of broken firmware updates being pushed out to all my lightbulbs...
alkonaut 5y ago
The difference between dynamically and statically linking doesn’t change the patching story so long as applications ship with all their libs and share nothing. The only difference is that a statically linked app is a large binary blob in a directory while a dynamically linked app is multiple smaller blobs in a directory. Whether or not statically or dynamically linked apps are the future, the idea of system wide shared libraries seems like it’s going away.
- bbarnett 5y ago
  shared ram too. it adds up.
  - mpyne 5y ago
    It does, but we're already moving to a world where deployed apps are one of the very few things running in a container, which is itself running somewhere in a VM, so there's less sharing to achieve.
    - ithkuil 5y ago
      Yeah. In that scenario the distinction between dynamic and static linking is moot. In both cases you need to update the container image and when you do you only fixed that container image and you still need to update all the other images
- mercurialfck 5y ago
  There's absolutely no need for just one-ring-to-rule-them-all copy of libz.so. Shared libraries can be versioned and garbage collected like how habitat (hab) does it: in separate directories.
- IshKebab 5y ago
  Exactly. The issue is not static vs dynamic; it's bundled vs unbundled. You could probably even do an "unbundled" statically linked system, e.g. imagine Debian but everything is statically linked. Doesn't matter that everything is statically linked - if there's a vulnerability in libpng you can still easily update dependencies. Just uses more network / disk space.
ghoward 5y ago
Author here. > I eagerly await some concrete implementations of these new ideas. I'm working on them now! They are not public because of a licensing issue where I need to consult a lawyer first (thanks, GitHub Copilot), but they will be public as soon as that's sorted out.
- Zababa 5y ago
  > They are not public because of a licensing issue where I need to consult a lawyer first (thanks, GitHub Copilot), but they will be public as soon as that's sorted out. Do you mean that you built them using Copilot, or that you don't want Copilot to use them? Or something else entirely?
  - ghoward 5y ago
    I don't want Copilot to use them. Sorry; should have said that.
    - Zababa 5y ago
      No worries, it's nice to know that someone is working on that with the help of actual lawyers!
Zababa 5y ago
> This is where someone says "well you should just always be running the latest version of everything", which is of course infeasible on a real life system with thousands of installed packages. Maybe the problem is have a system with thousands of installed packages? If every application is in its own "space", then a security failure won't affect the rest. If you want the best security, you're going to have to do pretty big tradeoffs. If you're not ready to do them, you're going to have to live with an insecure system. I don't think there is a way around this.
- kbenson 5y ago
  Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. For a system that widely uses dynamic libs, that's fairly easy to do. Check the version of the installed library, along with any patches it might have, and you have a good idea of whether it needs to be updated. Now, imagine there's a zlib exploit. That's a lot of things in the system that need to be updated. It's so ubiquitous that even in a system that's almost entirely built with dynamic libs, there are a few that use it as a static lib, and you'll have to make sure those are updated too (go look at the last zlib CVE and the major distro updates to it and you'll see all those packages, sometimes a couple days later as they discover them too). A world where these are all statically compiled (or bundled separately in containers) is much more complex. It's not impossible, but you don't naturally get some of the work done for you. To some degree we're already going this way with containers though.
  - Zababa 5y ago
    > Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. In which was? Is it because it's hard to know which version of zlib was used in X application, or is it because there is no centralized information about this? Maybe that's an opportunity right there: build a graph of dependencies of a system, and alert when something has been compromized and which are the consequences.
    - 5y ago
dcsommer 5y ago
Are you sure about the "CVE explosion"? From the CNA counting rules https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules https://cve.mitre.org/cve/cna/rules.html#section_7_assignmen... : 7.2.4 If multiple products are affected by the same independently fixable vulnerability, then the CNA: a. MUST NOT assign more than one CVE ID if the products are affected, because they share the vulnerable code. The assigned CVE ID will be shared by the affected products.
- ris 5y ago
  I'm not sure what would actually happen in reality, whether a single CVE would get endless addenda listing the packages affected by an upstream vulnerability. I certainly see plenty of new CVEs go past which are of the form "xyz had a vendored version of abc, which was vulnerable to ..."
mst 5y ago
I believe when heartbleed happened quite a bunch of go progams were yoinking in openssl because the go ssl tooling was still relatively young. I have no idea what actually happened there, I just recall some moderately annoyed sysadmins figuring out how to rebuild go applications by developers who'd since left the company. (this is not a shot at go, this is merely a "there might already be -some- data out there" wrt your question)

by ris 5y ago

DaiPlusPlus 5y ago

The design of the Go build and packages system kinda renders that point moot because the expectation is that provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries (e.g. https://github.com/golang/go/issues/2775 https://github.com/golang/go/issues/2775 ).

Macha 5y ago
Right, but if every application did distribute as source and could just be recompiled, there would be fewer complaints about the difficulties distributing Linux binaries
Zababa 5y ago
> provided you follow Go's guidelines then a Go application should always be easily recompilable, and all external dependencies should always be distributed in source-form, not as binaries So it's a human solution, and not a technical one, which means that it can and will fail.
- DaiPlusPlus 5y ago
  That's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. Provided you (and your org) use Go as Google intends then that isn't an issue.
  - Zababa 5y ago
    > That's like saying condoms are ineffective because you included people too lazy to put them on in the first place in your calculations. I think it's closer to say that the existance of condoms won't make AIDS and unwanted pregnancies disappear, even if they were 100% effective. Which, if you're trying to eliminate completly AIDS, is a fair claim to make. My point is that you shouldn't assume that everyone is going to follow the Go guidelines, because some people won't, and you don't want your security to rely on that.

Wowfunhappy 5y ago

CyberShadow 5y ago
You would have to do that anyway. With static linking, you also have to rebuild those dependents and make sure their users update them as well.
- Wowfunhappy 5y ago
  I would rather the developers rebuild the dependents, test them, make any necessary fixes, and send me the updated (presumably static) binaries. As opposed to me, as an individual user with no familiarity with the code base, just switching out the pieces and preying nothing goes wrong.
  - ris 5y ago
    And if the upstream developers are unresponsive, or only provide the bump with the latest bleeding-edge version which you can't upgrade to yet?
    - Wowfunhappy 5y ago
      On a system where security is critical, I would probably need to re-evaluate my use of that software. It doesn't necessarily need to be the upstream developer, it could be some other organization analogous to a distro maintainer. What matters is that someone who is familiar with the software and code base has actually tested the update in a purposeful way.
  - AussieWog93 5y ago
    As a small developer who handles my own support, I agree with this sentiment completely!!

bregma 5y ago

It would certainly make the embedded industry more secure if it was always running the latest version of everything. Or at least the ISPs, because imagine the bandwidth they're be able to charge for as everything from your washing machine to your watch to your lightbulbs to your car downloads new images hourly.

ris 5y ago
Just imagining the joy of broken firmware updates being pushed out to all my lightbulbs...

alkonaut 5y ago

The difference between dynamically and statically linking doesn’t change the patching story so long as applications ship with all their libs and share nothing. The only difference is that a statically linked app is a large binary blob in a directory while a dynamically linked app is multiple smaller blobs in a directory. Whether or not statically or dynamically linked apps are the future, the idea of system wide shared libraries seems like it’s going away.

bbarnett 5y ago
shared ram too. it adds up.
- mpyne 5y ago
  It does, but we're already moving to a world where deployed apps are one of the very few things running in a container, which is itself running somewhere in a VM, so there's less sharing to achieve.
  - ithkuil 5y ago
    Yeah. In that scenario the distinction between dynamic and static linking is moot. In both cases you need to update the container image and when you do you only fixed that container image and you still need to update all the other images
mercurialfck 5y ago
There's absolutely no need for just one-ring-to-rule-them-all copy of libz.so. Shared libraries can be versioned and garbage collected like how habitat (hab) does it: in separate directories.
IshKebab 5y ago
Exactly. The issue is not static vs dynamic; it's bundled vs unbundled. You could probably even do an "unbundled" statically linked system, e.g. imagine Debian but everything is statically linked. Doesn't matter that everything is statically linked - if there's a vulnerability in libpng you can still easily update dependencies. Just uses more network / disk space.

ghoward 5y ago

Author here. > I eagerly await some concrete implementations of these new ideas. I'm working on them now! They are not public because of a licensing issue where I need to consult a lawyer first (thanks, GitHub Copilot), but they will be public as soon as that's sorted out.

Zababa 5y ago
> They are not public because of a licensing issue where I need to consult a lawyer first (thanks, GitHub Copilot), but they will be public as soon as that's sorted out. Do you mean that you built them using Copilot, or that you don't want Copilot to use them? Or something else entirely?
- ghoward 5y ago
  I don't want Copilot to use them. Sorry; should have said that.
  - Zababa 5y ago
    No worries, it's nice to know that someone is working on that with the help of actual lawyers!

Zababa 5y ago

> This is where someone says "well you should just always be running the latest version of everything", which is of course infeasible on a real life system with thousands of installed packages. Maybe the problem is have a system with thousands of installed packages? If every application is in its own "space", then a security failure won't affect the rest. If you want the best security, you're going to have to do pretty big tradeoffs. If you're not ready to do them, you're going to have to live with an insecure system. I don't think there is a way around this.

kbenson 5y ago
Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. For a system that widely uses dynamic libs, that's fairly easy to do. Check the version of the installed library, along with any patches it might have, and you have a good idea of whether it needs to be updated. Now, imagine there's a zlib exploit. That's a lot of things in the system that need to be updated. It's so ubiquitous that even in a system that's almost entirely built with dynamic libs, there are a few that use it as a static lib, and you'll have to make sure those are updated too (go look at the last zlib CVE and the major distro updates to it and you'll see all those packages, sometimes a couple days later as they discover them too). A world where these are all statically compiled (or bundled separately in containers) is much more complex. It's not impossible, but you don't naturally get some of the work done for you. To some degree we're already going this way with containers though.
- Zababa 5y ago
  > Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. In which was? Is it because it's hard to know which version of zlib was used in X application, or is it because there is no centralized information about this? Maybe that's an opportunity right there: build a graph of dependencies of a system, and alert when something has been compromized and which are the consequences.
  - 5y ago

dcsommer 5y ago

Are you sure about the "CVE explosion"? From the CNA counting rules https://cve.mitre.org/cve/cna/rules.html#section_7_assignment_rules https://cve.mitre.org/cve/cna/rules.html#section_7_assignmen... : 7.2.4 If multiple products are affected by the same independently fixable vulnerability, then the CNA: a. MUST NOT assign more than one CVE ID if the products are affected, because they share the vulnerable code. The assigned CVE ID will be shared by the affected products.

ris 5y ago
I'm not sure what would actually happen in reality, whether a single CVE would get endless addenda listing the packages affected by an upstream vulnerability. I certainly see plenty of new CVEs go past which are of the form "xyz had a vendored version of abc, which was vulnerable to ..."

mst 5y ago

I believe when heartbleed happened quite a bunch of go progams were yoinking in openssl because the go ssl tooling was still relatively young. I have no idea what actually happened there, I just recall some moderately annoyed sysadmins figuring out how to rebuild go applications by developers who'd since left the company. (this is not a shot at go, this is merely a "there might already be -some- data out there" wrt your question)