MongoDB 3.6 has reached End-Of-Life

[hackathi]

The installer downloads and installs MongoDB 3.6:

https://github.com/fkie-cad/FACT_core/blob/6502430e223f3365b6f62a2ce6b9c77b1ee9a4ec/src/install/db.py#L41-L48

This Version has reached End-Of-Life in April 2021: https://www.mongodb.com/support-policy/lifecycles Further, on fedora, the installer explicitely installs mongodb-3.6.8, which is affected by a number of security vulnerabilities (example, there are more serious vulnerabilities).

Is there any reason not to use a supported version (5.0.2 would be the latest, but 4.x would suffice)? AFAICT, everything boils down to pymongo anyways, which happily supports newer mongodb versions.

I haven't tested with the MongoMgr, though. But from a quick glance it should work fine with 5.x.

[hackathi]

As a sidenote, I realize that there is no other option than using a third-party repository for mongo. But in all reality, no software should just randomly install package signing keys onto my machine that aren't even bundled but downloaded on the fly.

[hackathi]

Furthermore, fedora has also determined that mongodb is not free software (SSPL) and removed it from its repositories. I'm unsure whether the installer actually works on fedora right now, seeing that no maintained fedora release has a mongodb package.

[rhelmke]

We are aware of the dusty version in use here and there is an ongoing internal conversation about this topic.

[...] SSPL [...]

... unfortunately this is one half of said conversation. In lights of cloud providers stretching the AGPL to the maximum, it is somehow understandable that MongoDB took a turn by re-licensing their products. However, some parts of the SSPL introduce uncertainty. The other (active) half of our conversation is on how to move forward. Sadly, there is no immediate fix for now. The EoL MongoDB dependency will disappear once we concluded upon this topic.

[hackathi]

Personally, I do not care about mongos license. I'm fine with installing mongo from a third party source.

I do however care about ancient software with known, unpatched bugs on my system. Having done some testing, manually installing mongo 5.something works just fine.

Since it's a dependency that's technically installed by the user, no licensing issue should arise for FACT, whether mongo uses AGPL or SSPL. If it is a dealbreaker for some users, I'd suggest updating the default, documenting that the latest AGPL-licensed version works just fine and not use any features introduced in a later version. Or in other words: let your users choose.

This is another prime example of an issue that is only an issue because the installer want's to do everything for the user. What if I want to run mongo in a docker container? I can't, because for some reason FACT implements its own service management, and tightly couples it with a bunch of scripts (update_statistics, update_variety, ...) in a way that just does not make sense.

All of these scripts could work just well with an outside-provided mongo server. None of them need to manage the server lifetime.

I do see why doing lifetime management is important for testing. But if it's as tightly coupled as it is now, it's hard to write good tests to validate the code against multiple mongo versions. I understand that testing multiple versions of everything might not be feasible (although, running a CI in multiple environments validating against three active mongo branches doesn't particularly sound like state explosion to me), and that is fine. I don't expect you to go out of your way to validate FACT against a huge range of monogodb versions. But this doesn't mean that it's a good idea to force the user to use an outdated version.

To put it frankly: if I run FACT with mongo 5.0.2 and run into problems, you could reasonably expect me to (a) file a quality bug report, and (b) probably send you a PR with a fix that works on both 3.6 (that's your supported version atm) and 5.0.2 and include a regression test. But if I have to go out of my way to install FACT in a way that I can test this, everytime I encounter a problem I would have to make absolutely sure that I didn't miss a step in the installer I ran by hand. And that's extra time I probably won't spend.

[jstucke]

As @rhelmke said, we will discuss internally how we will proceed. Making the installed version selectable by the user is a good idea. Switching to a different database would be a massive task at this point.

The new license of newer MongoDB versions could only be a problem if you provide FACT as a service for others and not if you run it yourself or internally in your network.

[dorpvom]

821 Solves this Issue. We are now running on PostgreSQL :grin: