MongoDB Go Driver 1.11.7 Released

Product & Driver Announcements Driver Releases
,
1

The MongoDB Go Driver Team is pleased to release version 1.11.7 of the MongoDB Go Driver.

This release fixes various bugs, including:

  • Parsing certain decimal128 values from Extended JSON can take a long time.
  • Some database errors can cause the driver to unexpectedly mark the database topology as unknown.
  • RewrapManyDataKey should return an error if it’s called with masterKey and without provider.
  • “connectionId” returned in heartbeats may be int64.

It also adds the Cursor.SetBatchSize API, which allows changing the document batch size requested for subsequent cursor iterations.

For more information please see the 1.11.7 release notes.

You can obtain the driver source from GitHub under the v1.11.7 tag.

Documentation for the Go driver can be found on pkg.go.dev and the MongoDB documentation site. BSON library documentation is also available on pkg.go.dev. Questions and inquiries can be asked on the MongoDB Developer Community. Bugs can be reported in the Go Driver project in the MongoDB JIRA where a list of current issues can be found. Your feedback on the Go driver is greatly appreciated!

Thank you,

The Go Driver Team

3 Likes
2

On this version of the driver, I’m having a problem with a self-signed cert.

I use a URI of the form:

'mongodb://admin:foobar@someserver.somedomain:27017/?tls=true&tlsCAFile=/some/path/to/selfsigned.crt'

My application fails as follows:

2023/06/06 17:16:28 No .env file found
2023/06/06 17:16:58 server selection error: server selection timeout, current topology: { Type: Unknown, Servers: [{ Addr: someserver.somedomain:27017, Type: Unknown, Last error: x509: certificate relies on legacy Common Name field, use SANs instead }, ] }

I know it’s loading my local copy of the self-signed cert because if I munge the path, my application does a panic: … no such file or directory.

The URI I am using works with mongosh and compass except that for mongosh and compass I urlencode the leading-slashes in the certificate path as %2F’s.

Any tips, please? Obviously it’s being fussy about the Common Name field, but is there a switch to make it happy, or is this the new strict?

3

@Jack_Woehr that’s an interesting error. That error seems to be returned by the crypto/x509 package starting with Go 1.15. The error could be disabled with the environment variable GODEBUG=x509ignoreCN=0 until the override was removed with Go 1.17. I’m not aware of any recent intentional change in the Go driver that would surface that error.

I have some questions that could help get to the bottom of the error:

  1. Is there a previous version of the Go driver where that error doesn’t happen? If so, what version?
  2. What Go version are you using?
  3. Did you change your Go version recently? If so, what was the previous Go version?
2 Likes
4

In the past I have used Go for MongoDB very infrequently.

In fact, the last time I tried Go with MongoDB, the development MongoDB database was not configured for TLS.

Since that last time, I have configured our development database for TLS and we have been happily accessing it that way, CN and all, via mongosh, compass, and via the PHP Driver, PHP being the language which I am using most for MongoDB development.

So I am afraid I cannot provide helpful details. I asked the question assuming I had omitted some variable or URI component. And the answer, from what you say, would have been “Yes” in earlier versions of the crypto/x509 indirect requirement.

So I guess I should simply comply by updating my self-signed certificates rather than wrestle with the programming interface.

FWIW my Go version is 1.18.1.

5

Thanks for the additional info! The Go TLS standard libraries tend to be relatively aggressive at enforcing secure configuration and deprecating legacy behavior. Since the Go driver uses the TLS standard libraries, it also inherits those strict requirements.

As far as a workaround, you could try using the tlsInsecure=true URI option. However, use that with extreme caution because it disables TLS hostname checking, so it may break the security you hoped to add by enabling TLS. Otherwise, as you also concluded, there’s not really a way to override that specific behavior in Go 1.17+ and you’re stuck updating your certs.

1 Like
6

tlsInsecure=true does the trick, @Matt_Dale
It’s the Dev installation, not exposed outside, so I’m not worried about the insecurity.
The Prod installation will have a genuine certificate.
Thanks for your help.

7

This topic was automatically closed after 90 days. New replies are no longer allowed.