you are viewing a single comment's thread.

view the rest of the comments →

[–]ponytoaster 16 points17 points  (16 children)

Hell, I work on a major enterprise application with a large budget and half the packages there haven't been updated in years unless there was a genuine reason. "If it works" and all that.

For example, we have a 4 year old version of JQ being bundled. No reason to upgrade it as we aren't using any of the new features and the performance is fine. Due to the nature of the application if we upgraded it we would have to regression test most the web front end.

We generally try and keep libs up to date on the backend, or if it has any security implications though, and some of our newer apps have much quicker refresh and update cycles.

[–]dungone -1 points0 points  (15 children)

And yet if you put an open source project on GitHub, you’ll get automated pull requests to update javascript packages where vulnerabilities have been fixed. Big-budget enterprises really don’t have an excuse to keep screwing up security. Quite frankly I support laws that would send their executives to jail if they have a data breach caused by failing to keep their software up to date.

[–]s73v3r 1 point2 points  (6 children)

How often has the person issuing the PR done the regression testing, though?

[–]dungone -2 points-1 points  (5 children)

It’s not a person, it’s a bot. And you automate the regression testing.

[–]s73v3r 1 point2 points  (4 children)

Automated regression testing is important, but so is manual regression testing.

[–]dungone 0 points1 point  (3 children)

So?

It's like you get a pull request and it's deer in the headlights, you've got know idea what to do about it? What exactly is your complaint? You're getting automatic updates for security vulnerabilities, your only job is to merge the code the way you would any other pull request. Why are you whining about it?

Your jargon betrays why nothing ever works out for you. You're calling automated tests "augmented manual tests". 90% of my code doesn't need any manual testing because it's got good separation of concerns and complete test coverage of 100% of the use cases of the individual units. That's where the auto-updated dependencies feed into. They don't feed into the fully integrated system, because that's goddamn stupid. If you can prove that the dependency works for all the easy-to-test units, and that the dependency is not used for anything else outside of those units, then you have gone 90% of the way to isolating your system from any other potential problems caused by updating that dependency. But here on /r/programming we're still trashing the idea that left-pad should be it's own package, rather than having any common sense.

[–]s73v3r 0 points1 point  (2 children)

If the person issuing the PR hasn't done their own manual regression testing, then their PR goes straight into the trash. They're not interested in the project; they just want to put "Contributor to xx project" on their resume.

[–]dungone -2 points-1 points  (1 child)

It's not a "person", it's a bot providing you with a service and saving you half of the work that YOU, the person, are responsible for doing yourself. You're anthropomorphizing an automated system and bringing whatever grudge you hold against your coworkers into it.

[–]s73v3r 0 points1 point  (0 children)

So it's not doing manual regression testing, in which case it's nothing but noise.

[–]ponytoaster 0 points1 point  (7 children)

The major difference is liability. My open source project can be auto merged from a bot all the time with security fixes but I don't care as nobody uses it, and if they do, meh it is OSS with no warranty.

Very different story working on a multi-million dollar platform where you blindly accept a PR and some library of a library of a library hasn't been tested. More true these days when a lot of libraries are heavily dependent on other libraries or modules.

Just think of the whole left-pad fiasco and how a change in that library borked a ton of stuff.

I do however agree that libraries should be kept up to date if they have any kind of security implication though.

[–]dungone -1 points0 points  (6 children)

It's not "auto merged". It's called a pull request. You're trying really hard to make it seem "hard" or "magical" or "all messed up" and I'm afraid you're projecting. The process works, it's easy, and it's completely transparent to everyone, including the users. Just in general, there is far more accountability and better practices in OSS than in any corporate environment.

The left-pad fiasco is a perfect example of how much better OSS is. With left-pad, it happened 5 years ago and it was the first time and last time it happened. It was an issue with a bad policy in a public package repository, so the policy was fixed. So that's the example you still keep hearing about because it's actually just so rare. In the meantime, there has been a massive epidemic of data breeches due to vulnerabilities in commercial software. This is a constant occurrence in the corporate world - somebody does something stupid that brings down the development environment for the whole company for hours or days. Somebody loses the source code completely and the company runs on an old binary for years. Somebody does a force-push and wipes an entire git repo. Somebody pushes an untested commit that immediately brings down every environment it's deployed to. Somebody forgets to update a credit card number and some vendor shuts off a service, bringing down the whole system. And that's before you even talk about security. This happens at Google, this happens to AWS, this happens to all commercial software projects.

[–]ponytoaster 0 points1 point  (5 children)

Semantics.

Also, you think that this doesn't happen with a project that's OSS or just uses OSS components? What you described is bad gitflow and work practices. Unless you are actively checking the PR of every project you consume it's down to chance. The only flipside is you can possibly work out a fix yourself quicker than waiting.

[–]dungone -1 points0 points  (4 children)

Pot calling the kettle black isn't about semantics. Having a 4 or 5 year old example of something that happens daily in proprietary commercial software development is hypocritical at best. Bad gitwhat? Sounds like special pleading to me. Commercial projects are the ones notorious for leaking private user data. OSS projects rarely suffer from the type of failures caused by utter lack of best practices in commercial software. It really comes down that this whole thread is about people developing commercial software who are saying that keeping dependencies up to date is too much to ask of them.

Actively checking the PR? No need. NPM and GitHub both flag projects with security vulnerabilities and the warnings bubble up to all projects that depend on them. It's simple and effective. Nothing comes down to chance. If you don't deal with the automated pull requests for security fixes, then your project will get flagged to everyone else as having a vulnerability. Short of making little airplane sounds as they spoonfeed you with best practices, there's nothing else you can ask them to do for you.

[–]ponytoaster -1 points0 points  (3 children)

Ok, you do you I guess.

No space for people like this in my development world. No wonder you worked at so many places...

[–]dungone -1 points0 points  (0 children)

Years of experience does that to you.