Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> maintainers shouldn't place themselves in the development process.

Then perhaps we as developers should spend more time thinking about and participating in the maintenance process?



Which is exactly what developers have done, and what this guy is complaining about: developers have figured out a different approach to maintenance that works better.


I don't pretend to have an answer but I'm trying to listen to both sides so maybe I can formulate "the question" a little bit better and improve the discussion around this.

It seems like have posts every few months where security professionals, maintainers and sysadmins explain that the "developer usability first" approach to maintenance and dependency management is having massive consequences to our ability to keep systems secure, and to even know if an affected version of a library is on a system.

That is a different problem that doesn't seem to be addressed at all in the current iteration of these tools. If you're aware of efforts to solve that problem in the rust and go ecosystems(since those are the ones cited here) I'd love to read about it.


Knowing whether a vulnerable version is somewhere in your dependency tree, and making sure it gets fixed, is absolutely being done and being made part of CI etc. (I don't know about Rust/Go specifically, but the JVM ecosystem is the subject of similar complaints and we're absolutely doing vunerable dependency scanning and also things like "edge builds" where we bump every transitive dependency to the latest version and see if anything breaks). Nowadays Github itself will give you an alert without you even needing to do anything.

Frankly, most distribution maintainers seem to not know or care about how upstream software is built; they have an idea about what's "best practice" in the handful of languages they're using to build their distribution (which is mostly, like, C and Perl) and insist that they know best, without realising the rest of the world has passed them by.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: