3 ms·

The article gives up on its clickbait headline almost immediately: > Of course you cannot do that with everything, you cannot read all the source code for the

by smt88 4y ago

The article gives up on its clickbait headline almost immediately: > Of course you cannot do that with everything, you cannot read all the source code for the kernel of the operating system you're running, you cannot read all the code that makes up the compiler or interpreter you're using, but that is not the point at all, of course some level of trust is always required. The point is that you need to do it when you're dealing with code you are writing and importing! OK, so we're drawing an arbitrary line of what we read and what we don't. A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions. There's just no way around this. We all trust code we haven't read and have to continue doing it. Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it.

deleted 4y ago
[deleted]
javajosh 4y ago
>There's just no way around this. Wrong. The way around it is to write small amounts of code. We should be searching for local minima instead of convenience. Tightly integrated, batteries included programs like redbean show one way. Clojure, with its emphasis on terse, composable objects shows another. Those who write web clients using only HTML, CSS and JavaScript show yet another. We require a reusable set of small primitives that can be examined, mastered, and recombined to suit our purpose. We do not require...a great deal of what we now have.
- smt88 4y ago
  Web clients require authentication on the backend. Authentication requires cryptography, and it's idiotic to write your own crypto libraries. So at a minimum, you'd still need to read and understand many thousands of lines of some of the most complex code in common use. It's not realistic and it's never going to be common practice.
sys_64738 4y ago
> The article gives up on its clickbait headline almost immediately I find often it’s not the content of the article that’s relevant. It’s generally not as there’s a lot of trash out there. But they do raise good discussion topic that lead to active conversation. I find that is the real value for me personally.
chrisandchris 4y ago
> There's just no way around this. We all trust code we haven't read and have to continue doing it. If compared to other industries: We all drive a car we never fully inspected ourselves, fly a plane we have't looket at ourselves and eat food we didn't see where it grew. How can we adapt the supply chain in software engineering that we can have the same level of trust (or trusted parties)?
- smt88 4y ago
  All of those industries are incredibly heavily regulated, especially flying on planes. I agree: we should have this much regulation for software security. The stakes are extremely high.
tommyage 4y ago
> OK, so we're drawing an arbitrary line of what we read and what we don't. Imo the line is not arbritary. You are including an library/framework for a purpose. The code path for this purpose should be explored. Recently I allowed a friend of mine to DDOS my server. He used unvisited software. Now my server suffers from thousand wild guesses daily. Previously, I had ten visitors a day. Therefore I conclude that the software leaked my server. And his learning: Don't trust any software; Exspecially if the software is for malicious purposes in the first place.. > A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions. I think it is a valid assumption to increase the trust in frameworks with a giant user base. React is from Facebook, isn't it? So I would have read the path _and_ random internals to picture the trustworthiness. > There's just no way around this. We all trust code we haven't read and have to continue doing it. It shouldn't be black-and-white thinking. When introducing a _new_ dependency I see myself responsible for estimating the trustworthiness. But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical... > Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it. Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. So better grasp it before deciding to build upon it. Another comment stated that we are trusting cars we drive, etc. etc. This is about the users running our code. A proper craftsman will inspect its material, before using it in quality products. When building a throwable tool for his work, he doesn't spent to much time worrying, of course.
- smt88 4y ago
  > React is from Facebook, isn't it? Yes, but it uses a massive number of libraries that were not developed at Facebook. > But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical... Postponing dependency updates is very, very bad for security. That is not a solution to supply-chain attacks. > Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. The whole point of APIs is that we do not need to understand the inner workers of code that we're calling. How many of us use bcrypt and couldn't tell you anything about the underlying algorithm?

by smt88 4y ago

deleted 4y ago

[deleted]

javajosh 4y ago

>There's just no way around this. Wrong. The way around it is to write small amounts of code. We should be searching for local minima instead of convenience. Tightly integrated, batteries included programs like redbean show one way. Clojure, with its emphasis on terse, composable objects shows another. Those who write web clients using only HTML, CSS and JavaScript show yet another. We require a reusable set of small primitives that can be examined, mastered, and recombined to suit our purpose. We do not require...a great deal of what we now have.

smt88 4y ago
Web clients require authentication on the backend. Authentication requires cryptography, and it's idiotic to write your own crypto libraries. So at a minimum, you'd still need to read and understand many thousands of lines of some of the most complex code in common use. It's not realistic and it's never going to be common practice.

sys_64738 4y ago

> The article gives up on its clickbait headline almost immediately I find often it’s not the content of the article that’s relevant. It’s generally not as there’s a lot of trash out there. But they do raise good discussion topic that lead to active conversation. I find that is the real value for me personally.

chrisandchris 4y ago

> There's just no way around this. We all trust code we haven't read and have to continue doing it. If compared to other industries: We all drive a car we never fully inspected ourselves, fly a plane we have't looket at ourselves and eat food we didn't see where it grew. How can we adapt the supply chain in software engineering that we can have the same level of trust (or trusted parties)?

smt88 4y ago
All of those industries are incredibly heavily regulated, especially flying on planes. I agree: we should have this much regulation for software security. The stakes are extremely high.

tommyage 4y ago

> OK, so we're drawing an arbitrary line of what we read and what we don't. Imo the line is not arbritary. You are including an library/framework for a purpose. The code path for this purpose should be explored. Recently I allowed a friend of mine to DDOS my server. He used unvisited software. Now my server suffers from thousand wild guesses daily. Previously, I had ten visitors a day. Therefore I conclude that the software leaked my server. And his learning: Don't trust any software; Exspecially if the software is for malicious purposes in the first place.. > A basic web application at this point is going to import at least 10k lines of other people's code. A React app probably uses millions. I think it is a valid assumption to increase the trust in frameworks with a giant user base. React is from Facebook, isn't it? So I would have read the path _and_ random internals to picture the trustworthiness. > There's just no way around this. We all trust code we haven't read and have to continue doing it. It shouldn't be black-and-white thinking. When introducing a _new_ dependency I see myself responsible for estimating the trustworthiness. But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical... > Reading code doesn't even guarantee finding security flaws. Most of us aren't security researchers, and none of us can understand an entire project's source code the first time we read it. Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. So better grasp it before deciding to build upon it. Another comment stated that we are trusting cars we drive, etc. etc. This is about the users running our code. A proper craftsman will inspect its material, before using it in quality products. When building a throwable tool for his work, he doesn't spent to much time worrying, of course.

smt88 4y ago
> React is from Facebook, isn't it? Yes, but it uses a massive number of libraries that were not developed at Facebook. > But yes, with an increasing amount of dependencies the process of updating such needs more effort as well. But then, we can postpone such updates, if the application under development is safety critical... Postponing dependency updates is very, very bad for security. That is not a solution to supply-chain attacks. > Well, one should be able to judge about the workings imo. Otherwise maintainability can get painful in the long run. The whole point of APIs is that we do not need to understand the inner workers of code that we're calling. How many of us use bcrypt and couldn't tell you anything about the underlying algorithm?