[iqy]

>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path.

Why should that be a problem if you use the official repo, handled by MongoDB themselves?

[pilif]

Because as I said later in my post, sometimes a vendor's response to a security issue is "please update to the latest major release".

Let's say you're using version 1.1 of some software and you're hit by a remotely exploitable unauthenticated RCE.

You want to patch it, but the vendor says that the only fix is to update to 2.0.

How quickly can you adjust your software to work with that major release that might contain non-backwards compatible changes? Are you going to be quicker than the time it takes malware authors to write bots to hit that RCE?

There's also a second example which is automated updates: Our infrastructure automatically applies OS package updates via `apt-get`.

Thanks to Debian only ever updating packages for security reasons and only very rarely shipping new bugs, this is an actually workable practice.

But once you start adding 3rd party vendors who, for example, believe that once puppet 4 is released it's totally safe to just publish puppet 4 as a replacement of puppet 3 previously in the 3rd party repo, this becomes a very dangerous practice.

[chrisseaton]

How does this work? How are RedHat able to reach into any of the thousands of projects in their repository and fix bugs and vulnerabilities? How do they have people on staff who understand all those codebases and algorithms?

Do RedHat support engineers get tickets like 'bug in the energy minimisation algorithm of GraphViz - go in, learn that field of computer science, and fix it'?

[paulryanrogers]

IIRC Redhat is a downstream consumer of many projects. And they have their own repositories and format (RPM). So yes, they do fix bugs in their copies and employee people who know, or can learn, the critical packages.

Hopefully they still send patches upstream to the original projects.

[bdavis__]

Yes, that is exactly how it works. Provided the bug reporter has a support contract and enough clout.

[quantummkv]

It is the upstream vendor that issues fixes. What RedHat does is that it takes the commits that fix the bug and merge them into their forks and release.

[chrisseaton]

> It is the upstream vendor that issues fixes.

So if you have a bug in a RedHat package, and you're paying $100k a year RedHat support contract, all they really do is open a GH issue with the upstream to ask them to fix it? And then you just wait hoping they fix it so RedHat can cherry pick it?

[myWindoonn]

We don't know. I'm going to tell you a short story, though.

Rumor has it that KMS[1] was developed entirely because a deep-pocketed RH customer was annoyed that their workstations showed a fraction of a second of the boot/init log, and wanted a more seamlessly-graphical boot.

This feature was not universally welcomed by the kernel community. It excluded BSD cousins and frustrated nVidia and AMD/ATI. I remember standing next to the DRM/KMS maintainer while Linus yelled at us.

RH absolutely will interact with upstream on behalf of their customers. They don't just "open a GH issue"; they present designs, code, rationale, and evidence to upstream. I wonder whether this is something that Oracle does, but it doesn't sound like it.

[1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Kerne...

[throwaway2048]

Backporting fixes (and fixes ONLY, not new features, and new bugs, with new incompatabilities) onto an older version of software that comes in RHEL is not trivial.

[bubblethink]

They have the core repo and other less/un-supported repos/channels. They'll support everything in the main repo.

[geofft]

It's a matter of scaling. If your job is "I want to run MongoDB," then it makes sense to track MongoDB's repo. If your job is "I want to run 100 different applications," then tracking 100 upstream repos (and dealing with their usually 80%-competent jobs of handling library dependencies, etc.) is no fun.

I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from.

I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.

[sascha_sl]

because a lot of people have support contracts with red hat

now they'll be forced to also have one with mongodb (if their deployment is critical enough to already have red hat support they'll probably just caugh up the money)