Consider removing mongo-db-driver dependency

[padamstx]

In #90, I reported a vulnerability that strfmt users have started to see reports of, due to the strfmt->mongo-db-driver->packr dependency chain. As soon as a new version of mongo-db-driver is available that bumps its packr dependency, we should change this project to use the newer mongo-db-driver version in order to avoid the vulnerability.

However, while looking for alternate ways to address the vulnerability, I noticed that the only real dependency that the strfmt project has on mongo-db-driver is its "bson" package. So, I was wondering about the feasibility of removing the mongo-db-driver dependency altogether. Is there perhaps an alternate implementation of the "bson" functionality that would suffice? Perhaps there's a way to extract out the mongo-db-driver "bson" package into its own module so that strfmt can depend on just that by itself?
Removing the mongo-db-driver dependency would also significantly reduce the dependency drag currently associated with the project.

[youyuanwu]

Previously https://github.com/go-mgo/mgo was an alternative, but it has been deprecated. I am not aware of any replacement.

[kzys]

The driver package and the associated BSON implementation are maintained by MongoDB, Inc. I think it would be better to use the one instead of alternatives.

That being said, the entire MongoDB driver is too much for what this package needs. It would be great if they can separate BSON from the MongoDB driver.

Another alternative may be making BSON part separate from this package, but this wouldn't straightforward.

[padamstx]

I wonder if the MongoDB folks would be willing to separate out their BSON functionality into a different package. That way, strfmt and the Mongo driver packages could both prereq it as needed.

[casualjim]

I'm not in favor of using alternative packages except for the official ones. Unofficial implementations tend to bitrot as people move on, so to ensure compatibility it's safer to depend on the official package for longer term. The reason mgo got removed was for this exact reason.

However if mongodb folks could split off bson or just even put a go.mod file in that directory we should be good.

[hown3d]

I wonder if the MongoDB folks would be willing to separate out their BSON functionality into a different package. That way, strfmt and the Mongo driver packages could both prereq it as needed.

Quick update regarding separation of the bson package. There is a ticket in the MongoDB jira tracking this feature.

[Smidra]

This project is a dependency of our dependency. At one point it stopped working, because mongodb driver moved a tag which destroyed the checksums. This suprised us, because we are not using mongo db. I followed the trail here.

Basically, yeah, it would be greatly appriciated if the BSON project split from Mongo DB driver. :)
More about the versions: https://www.mongodb.com/community/forums/t/mongodb-go-driver-1-13-0-released/252730/3

Also, thank you for your time and effort working on Go-OpenAPI projects. They work woderfully.

[fredbi]

I've also had a lot of issues with this dependency.

Here is what I could do (@youyuanwu , @casualjim please advise):

• create a separate module in this repository (with its own go.mod) that would expose all the strfmt types extended with the mongo-specific methods, e.g. github.com/go-openapi/strfmt/contribs/bson
• remove the mongo dependency from the base types

Also this would break go-swagger, so here is the suggested update:

• advise mongo users to codegen with a distinct option to import github.com/go-openapi/strfmt/contribs/bson instead of github.com/go-openapi/strfmt
• fix a few codegen issues when dealing with initializers and zero values of such extended types

[casualjim]

Not necessary. We can just depend on the bson module and get rid of the heavy dependency. We amongst others asked them to split bson off from the rest.
No need to separate it out further, this is adequate to reduce the dependency chain and reduce the risk associated with the dependency

I am definitely not in favor for any kind of breaking change.

[casualjim]

This PR should be enough to get people going again I think: #110

[casualjim]

Another option instead of a different package is using build tags so that the MongoDB stuff is only included if you build with -tags mongo

[fredbi]

Another option instead of a different package is using build tags so that the MongoDB stuff is only included if you build with -tags mongo

Yes I thought about this one too. This is a bit tedious for user, but apart from some extra documentation, this is indeed the simplest way to go. I can give this idea a try, so we may discuss on actual code

[fredbi]

Another option instead of a different package is using build tags so that the MongoDB stuff is only included if you build with -tags mongo

Yes I thought about this one too. This is a bit tedious for user, but apart from some extra documentation, this is indeed the simplest way to go. I can give this idea a try, so we may discuss on actual code

@casualjim I've quickly materialized your idea with the build tag. I am not sure it really cuts the dependency: sure, it will not build this code, but the chain of dependencies is resolved like all build tags are resolved (exception: "build ignore").
On a trial strfmt with all bson code protected by a build tag, the go.mod still keeps the driver.
When importing this repo from, say go-swagger, the go.mod there still keeps the driver. And so do go mod download, and go mod vendor. Same with go list -m all...

Seems to me that this is not enough.

[fredbi]

Here is a quick sample for build tag solution: https://github.com/fredbi/strfmt/tree/feat/mongo-build-tag
Even though is doesn't prevent the dependency from bubbling up, it's a bit of a relief to have regrouped all those mongo-related calls.