crypto/x509: add CertPool.Equal

[dnephin]

What version of Go are you using (go version)?

go 1.16.x

What did you expect to see?

In response to #45891, x509.CertPool structs can no longer be compared with reflect.DeepEqual, and there is no way to export the certificates, so there is no longer any way to fully compare these structs.

CertPool.Subjects can be used for a shallow comparison, but #45891 (comment) shows that this is not a complete comparison.

By adding an Equal(other CertPool) bool these types can be compared directly, and go-cmp will automatically use the method for comparison.

[bradfitz]

In recent versions of Go, CertPool now internally represents a lazy set of certificates that might not be fully loaded yet.

What does "Equal" mean in this proposal? Would you want it to load them all from disk if they weren't yet?

Can you give some background on when you'd use this?

[dnephin]

In recent versions of Go, CertPool now internally represents a lazy set of certificates that might not be fully loaded yet.

Yes, I believe this change is what prevents reflect.DeepEqual from working as it did before (#45891).

#45891 has some context. We have tests that used reflect.DeepEqual to compare two x509.CertPool, which worked fine in go1.15.x. In Go 1.16.x those tests no longer work because two effectively equivalent cert pools are no longer considered equal.

I would expect Equal to load all the content from disk and compare the content using reflect.DeepEqual, which I think should make it equivalent to using reflect.DeepEqual in go1.15.x.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

/cc @FiloSottile for whether this is a reasonable API addition

[rsc]

Talked to Filippo and he said this was reasonable to do. We are planning to keep the cert pools opaque when they are derived from the system pool, but it is easy to tell if two different pools both include the system pool or not.

Does anyone object to this?

[tmthrgd]

Does anyone actually have a non-test use for this? Or is this something that comes up at all commonly? It sounds like it could end up being an unexpectedly slow and heavy-weight function.

[rsc]

@tmthrgd Filippo says it can be implemented efficiently. The definition of CertPool.Equal would be "same 'use system pool' setting and same additional certificates". So the system pool itself need not be consulted for implementing Equal.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

[tmthrgd]

@tmthrgd Filippo says it can be implemented efficiently. The definition of CertPool.Equal would be "same 'use system pool' setting and same additional certificates". So the system pool itself need not be consulted for implementing Equal.

More than happy to be wrong, but I was basing that off of this request/requirement above: “I would expect Equal to load all the content from disk and compare the content using reflect.DeepEqual[.]” That sounded deceptively expensive to me. Though if it’s not expensive, there doesn’t seem to be any real reason to oppose it.

[rsc]

I would expect Equal to load all the content from disk and compare the content using reflect.DeepEqual, which I think should make it equivalent to using reflect.DeepEqual in go1.15.x.

To be clear, it won't. It will just compare whether two CertPools both say "include what's on disk" or not.

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[gopherbot]

Change https://go.dev/cl/388915 mentions this issue: crypto/x509: add CertPool.Equal

[gopherbot]

Change https://go.dev/cl/398237 mentions this issue: api: add x509.CertPool.Equal to next/46057.txt

[ericlagergren]

// Equal reports whether s and other are equal.

@rolandshoemaker Under what conditions are two CertPools equal? The docs are a truism. I understand wanting to keep it a bit vague, but being too vague just causes people to look at the implementation.