How Go mitigates supply chain attacks • Hacker News Board

Re: How Go mitigates supply chain attacks

#261

Post by azth » Mon, Apr 04, 2022, 3:25 AM UTC

randomdata wrote: post #259

azth wrote: post #253

Earlier quoted context omitted.

> What does it have to do with errors? The fact that the former scenario is much more likelier to happen in golang due to its error handling. The former can be caught using unit tests, and should stick out more in languages like Java with scoped try-with-resources blocks that limit the scope of lifetimed variables (another bad design in golang where defers are function scope, not local scope limited, introducing unne…

> At the same time, you don't want to be writing unit tests for every simple scenario. Yup, exactly. In a perfect world you would, but the world ain't perfect. Sooner or later you're accidentally deleting the wrong thing because you didn't test it/didn't test it correctly. And for what reason? A language can guard against that kind of mistake quite well. So, that still leaves us wondering why you don't find it advant…

How do you suggest golang handles stack traces then?

It seems Rust has the same issue by the way: https://docs.rs/error-chain/latest/error_chain/

> If the RUST_BACKTRACE environment variable is set to anything but 0, the earliest non-foreign error to be generated creates a single backtrace

If my understanding is correct, it means that you won't get stack traces for any external libraries or code that does not use this library.

Because Exceptions in Java/C#/etc. are special, you will always have stack traces regardless of which code you're calling.

Re: How Go mitigates supply chain attacks

#262

Post by randomswede » Mon, Apr 04, 2022, 9:08 AM UTC

steveklabnik wrote: post #237

typical182 wrote: post #236

Earlier quoted context omitted.

Hi Steve, first, thanks for weighing in here! I might have misunderstood your comment, but in my GP comment I was indeed attempting to contrast 'go install foo@latest' with 'cargo install foo', which both install binaries. (I wasn't talking about 'go get bar@latest', which now is just for updating or adding dependencies to a project). Also, I'm contrasting what happens by default at the moment either binary install c…

Ah yes, I did miss that, thank you / sorry :) Too many sub-threads around here! I don't know go install's semantics well enough to know if that comparison is true or not, I'm just trying to make sure that Cargo's semantics are clear :)

This is, roughly, what "go install" does:

It will copy a binary to $GOBIN. If the binary is not built, it will be built from source. If the source is not available on the local system, it will be fetched.

During the build, any dependencies of the build target not available of the local system will be fetched.

Re: How Go mitigates supply chain attacks

#263

Post by randomswede » Mon, Apr 04, 2022, 9:21 AM UTC

woojoo666 wrote: post #197

zeeboo wrote: post #90

Earlier quoted context omitted.

Every change that fixes a security issue implies the existence of a change that introduced the security issue in the first place. Why is bumping a version more likely to remove security issues instead of introduce them? The reason why older is better than newer has more to do with the fact that the author has actually tested their software with that specific version, and so there's more of a chance that it actually w…

Security issues aren't introduced intentionally, oftentimes they are found much later on in code that was assumed to be secure. Like the SSL heartbleed vulnerability. Once a vulnerability like that is discovered, you _want_ every developer to update their deps to the most secure version

I'd back that down to "most security issues aren't introduced intentionally".

Re: How Go mitigates supply chain attacks

#264

Post by tormeh » Mon, Apr 04, 2022, 12:58 PM UTC

coder543 wrote: post #179

tormeh wrote: post #104

Earlier quoted context omitted.

I wish we'd stop trying to make broken languages work. This feels like hill-climbing into the strangest local optimum possible. JS is not the best example of an interpreted language. Wouldn't it be better to put Python in the browser than to put JS on the server? Can't wait for WASM to be a first-rate citizen on the web so we don't have to deal with this anymore.

I think you would be surprised to learn that more developers love TypeScript than Python these days, according to one popular survey.[0] All of this is subjective, of course. WASM isn't going to make Python the language of choice for browsers any time soon. [0]: https://insights.stackoverflow.com/survey/2021#section-most-...

I don't think the comparison is entirely fair since one of the main attractions of TS is that it runs in the browser. Python can unfortunately not fill the same role right now. So I'd keep that in mind while looking at that ranking. But yes, I see many people like it. Maybe I'm missing something, but it's still too JavaScript-y for me.

Re: How Go mitigates supply chain attacks

#265

Post by zeeboo » Mon, Apr 04, 2022, 6:18 PM UTC

woojoo666 wrote: post #248

zeeboo wrote: post #220

Earlier quoted context omitted.

My statement had nothing to do with intent. Conversely, once a vulnerability is introduced (intentionally or not), you don't want every developer to update their deps to the newly insecure version.

Exactly, so it's a trade-off, do you want to encourage updates at the risk of malicious updates (like with node-ipc). Or do you want to add friction to updates and thus risk security vulnerabilities persisting for longer. Node chooses one approach, Go chooses the other.

Again, it's not just malicious updates. Normal updates can also introduce security vulnerabilities. For example, I have a dependency at v1.0 and v1.0.1 introduces a security bug unintentionally. It is eventually fixed in v1.1. If I wait to update until v1.1, then I am not vulnerable to that bug whereas an automatic update to v1.0.1 would be vulnerable. My point is that in expectation, updating your dependency could be just as likely to remove a security vulnerability as it is to add one.