731–740 of 797 posts
Earlier quoted context omitted.
There are ecosystems that have package managers but also well developed first party packages. In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.
Sounds to me like another example of embrace - extend - extinguish
Why do the attackers publicly share the keys they found? Like what’s their mission?
My guess would be so they don't have to embed an IP address or hostname in the malware to send secrets to, which could then be blocked or taken down.
I would love to see the equivalent of a linux distro, a curated set of packages and package versions that are known to be compatible and safe. If someone offered this as a paid product businesses would pay for it.
I don’t feel confident there is a way to use npm safely. The basic problem is that of curation, and there not being any except for what you do yourself. Every day brings new surprises, and osv.dev’s npm feed is a continuous horror show. I would love to see the equivalent of a linux distro, a curated set of packages and package versions that are known to be compatible and safe. If someone offered this as a paid produc…
Earlier quoted context omitted.
Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.
The arguments for doing frequent releases partially apply to upgrading dependencies. Upgrading gets harder the longer you put it off. It’s better to do it on a regular schedule, so there are fewer changes at once and it preserves knowledge about how to do it. A cooldown is a good idea, though.
This is only true if you install dependencies that break backwards compatibility.
Personally, I avoid this as much as possible.
Earlier quoted context omitted.
I don't spend significant time making the borrow checker happy, because I learned how to write C++ that works.
¯\_(ツ)_/¯ I'd like to lean into that "YMMV" in my post, I'm coming from low level C that interacts with hardware, can't really speak to higher-level C++. Some things in Rust just don't translate to the way you'd do them in C - e.x. using different types to say if a GPIO pin is input or output adds a ton of boiler plate, but lets the compiler assure you don't mistakenly try and use a pin configured as an input for out…
Rust isn't just C++ with static analysis. The safety is only about 1/3 of what makes me enjoy working with it. Even if I just consider the effort taken before I present something to a compiler, the trait system means I don't spend anywhere near as much time writing copy/copy assignment/move/move assignment constructors.
Some of that 2/3 will be me making choices like ZSTs, but I believe that's a result of it being necessary to grok the whole language and style and the idioms. If I just try to write C in Rust, it will be bad Rust and I'll have a bad time - but the same goes for just writing C++ as C with classes. I deliberately didn't say 'C/C++' in my ancestor post, because I think it's terminology that undermines claims of authority.
I do happen to have embedded experience, but avoid drawing conclusions from it because it is so different to more 'standard' systems development. If you can forgive a tangent: I avoid the whole domain now, because it feels like a ghetto. Standards are poor, tools are poor, pay is seriously poor. If you want to write embedded software, you probably have to work for a hardware company with hardware company's engineering culture and revenue model. That's a pretty crap place to write software in the west. I can't comment on comparing what like to do embedded development in Rust. Frankly, I hope I never can.
Earlier quoted context omitted.
I don’t buy this. I mean, I’m sympathetic to the issue. It’s easy for things to get jumbled when companies are young. But we’re talking about libraries that are used by your customers. To many, this is the externally visible interface to the company. What you describe sounds like a process problem to me. If an $EARLY_EMPLOYEE if the only one with the deploy keys for what is a product of the company, then that’s a pro…
> But those are both people problems… and you can’t solve a people problem with a technical solution. I don’t think it is a people problem in this case: the only reason there’s a person involved at all is because we’ve decided to introduce one as an intermediating party. A more misuse-resistant scheme disintermediates the human, because the human was never actually a mandatory part of the scheme.
Earlier quoted context omitted.
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
I'm a huge Go proponent but I don't know if I can see much about Go's module system which would really prevent supply-chain attacks in practice. The Go maintainers point [1] at the strong dependency pinning approach, the sumdb system and the module proxy as mitigations, and yes, those are good. However, I can't see what those features do to defend against an attack vector that we have certainly seen elsewhere: projec…
There is no airtight technical solution, for any language, for preventing malicious dependencies making it into your application. You can have manual or automated review using heuristics but things will still slip through. Malicious code doesn't necessarily look obvious, like decoding some base64 and piping it into bash, it can be an extremely subtle vulnerability sprinkled in that nobody will find until it's too late.
RE dependency cooldowns I'm hoping Go will get support for this. There's a project called Athens for running your own Go module proxy - maybe it could be implemented there.