37 ms·

> Audit and auto-update tools will be complaining about use of an unmaintained crate. Not the case here but sometimes a library (with no dependencies) is reall

• ben_jones 3y ago
  > I wish audit tools and corporate policies are smart The ball is in the court of the enterprise purchaser mandating the auditing company and they don’t give a ** if your dev team has to hot swap a yaml parsing library
  • jimbokun 3y ago
    They should. They are paying devs a ton of money to futz around with code that works perfectly well and is just as secure today as it was yesterday. So you have security theater and TPS reports consuming the time of some of your most highly compensated human resources.
    • anotherhue 3y ago
      > just as secure today as it was yesterday. Agreed but the gotcha is when a new issue comes out and there is no security fix available. It would be enough to say 'we are comfortable patching this if a CVE is found', but at that point they might as well start to maintain it.
• appplication 3y ago
  Been doing this software thing for a bit now… while what you say is true in that it is possible in some rare cases, I think it’s a bit of a straw man exception. Code is, in the general sense, unfortunately never complete, regardless of how complete it seems in its context. The issue is that the context is always changing. It is almost like suggesting there is an evolutionarily perfect organism. At best, one suited perfectly well to the current context can exist, but that perfect suitability falls off the second the environment changes. And the environment always changes. I totally get the sentiment, but I think the idea that any code is ever complete is unfortunately just not a realistic one to apply outside of select and narrow contexts.
  • michaelt 3y ago
    If I wrote a library to open jpegs, it correctly loads all standard jpegs, and it's free of security issues - is that not complete? It's not like it's desirable for standard formats to one day start getting interpreted in a different way.
    • gtirloni 3y ago
      It's free of security issues in the current context, that's the point. You depend on calling a standard library function that was found deficient (maybe it's impossible to make it secure) and deprecated. Now there is a new function you should call. Your software doesn't work anymore when the deprecated function is removed. Sure, you can say your software is feature complete but you have to specify the external environment it's supposed to run on. And THAT is always changing. You're both right but looking at different timelines. Relevant: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html https://www.oreilly.com/library/view/software-engineering-at...
    • ranger207 3y ago
      > and it's free of security issues That's a biiiiig if
    • ruszki 3y ago
      Just to add another thing that changes to the other ones which were already mentioned by sibling comments: “standard jpegs” are not necessarily set in stone.
  • slowmovintarget 3y ago
    Another Clojure programmer just got her parentheses-encrusted wings. There are Clojure packages that go untouched for years... not because they're abandoned, but because they are stable and good enough.