201–210 of 217 posts
Earlier quoted context omitted.
The idiom for this is “biting your nose off to spite your face.” You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.
It's impossible to get AAA games (and most AA games) without some form of DRM (with some notable exceptions), the same as high(er) budget media productions. The Kindle was already 8 years old when I got it, isn't it better to re-use it with more current software? The same with router hardware that gets exploited to flash OpenWRT. It's very hard to get a modern Smartphone (with acceptable cameras, battery life, perfor…
That being said: I don't think the world is necessarily a worse place if (1) everybody's devices are more secure, and (2) consumers are a whole are disincentivized from buying into ecosystems that fundamentally don't respect their rights. At the risk of sounding like the luddite you mentioned: maybe we really could use a little separation between technology and literally every other domain of our lives.
Earlier quoted context omitted.
Software inhibiting user freedom (like drm) often gets broken using buffer overflows, string parsing mistakes, ... (as seen on many game consoles). Broken (drm) software allows for more user-freedom. If this software was using Rust, it would be much harder to break them than is currently the case. And tbh, I have to concur (somewhat). I have lost little-to-nothing due to software exploits, but have gained significant…
The idiom for this is “biting your nose off to spite your face.” You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.
Earlier quoted context omitted.
Unsure why people keep referring to static linking as a positive in this thread? Downstream consumers of statically-linked binaries have no practical way to scan their systems for known-vulnerable versions of libraries, that seems a profoundly negative consequence to me.
In Go you can use "go version -m my-go-binary" and get a list of dependencies and other build information. For example (may wrap a bit ugly on HN): [~]% go version -m =godoc /home/belta/bin/godoc: go1.18.3 path golang.org/x/tools/cmd/godoc mod golang.org/x/tools v0.1.12 h1:VveCTK38A2rkS8ZqFY25HIDFscX5X9OoEhJd3quQmXU= dep github.com/yuin/goldmark v1.4.13 h1:fVcFKWvrslecOb/tg+Cc05dkeYx540o0FuFt3nUVDoE= dep golang.org/x…
Earlier quoted context omitted.
In Go you can use "go version -m my-go-binary" and get a list of dependencies and other build information. For example (may wrap a bit ugly on HN): [~]% go version -m =godoc /home/belta/bin/godoc: go1.18.3 path golang.org/x/tools/cmd/godoc mod golang.org/x/tools v0.1.12 h1:VveCTK38A2rkS8ZqFY25HIDFscX5X9OoEhJd3quQmXU= dep github.com/yuin/goldmark v1.4.13 h1:fVcFKWvrslecOb/tg+Cc05dkeYx540o0FuFt3nUVDoE= dep golang.org/x…
That's a great solution, actually. I'm not familiar with go, but I thought it compiled to native code and did not require a virtual machine at runtime. So is this metadata enforced/inserted by the compiler into the binary, or does it require specific build tooling that may or may not be available on end-user systems?
I think there's a lot of potential for better tooling here in the form of language support, package manager support, etc.
Earlier quoted context omitted.
> Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. There are well-known, proven solutions to the memory management problems that affect OpenSSL (a C library) in a regular basis, and there are languages that implement those solutions. Among them, Rust, Ada and others.
While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without having a performance impact? While a language which prevents certain memory errors by design is going to be safe by design, it's entirely possible this bug is in code so hot that it has been repeatedly optimized further and further and that an equivalent imple…
It always is. Because it's a C project where memory management is done manually. And everything done manually is subject to human error.
Doing C-style a capella memory management in 2022 is not necessary.
> how do you know for sure that it is and that rust would have prevented it without having a performance impact
Because much of the safety features Rust implements for memory management happens at compile time not at runtime.
Earlier quoted context omitted.
They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1]. Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years. [1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=3…
Rust doesn't have GC, but it has very good automatic memory management. GC or memory management doesn't make programs immune to buffer overflows, which is the most common security vulnerability these days, while use-after-free is at 4th place.
(I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
Earlier quoted context omitted.
Note that the ring maintainer has long since stopped yanking releases. More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.
The the old yanking policy was extra work I did with the intent to help people. It was unfortunate that Cargo had that bug, but also I should have been much more diplomatic in how I dealt with it. I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and elimin…
Earlier quoted context omitted.
Oh no. Just because they donate their time and effort the community can't criticise them; even if how they work and interact with the community hurts and embarrasses the community... it was all free after all and the community added nothing to it! /s That's really not how it works when you work with others and use other's resources and time. Nobody's entitled to their effort, but they're also not immune to criticism…
Then stop using ring? It just sounds like you want to have your cake and eat it too.