x/crypto/openpgp: a couple of packages do not invoke .Close and hence leak io.Closer values in some return paths

[odeke-em]

Internally at Orijtech Inc, while doing security audits and supply chain analyses for the Cosmos security team, we've found a bunch of leaking resources in a couple of packages

golang.org/x/crypto/openpgp/packet/compressed.go:98:3: leaking resource created on line 91
golang.org/x/crypto/openpgp/packet/literal.go:75:3: leaking resource created on line 68
golang.org/x/crypto/openpgp/packet/literal.go:79:3: leaking resource created on line 68
golang.org/x/crypto/openpgp/packet/literal.go:84:3: leaking resource created on line 68
golang.org/x/crypto/openpgp/packet/symmetrically_encrypted.go:268:3: leaking resource created on line 261
golang.org/x/crypto/openpgp/packet/symmetrically_encrypted.go:276:3: leaking resource created on line 261
golang.org/x/crypto/openpgp/packet/symmetrically_encrypted.go:281:3: leaking resource created on line 261
golang.org/x/crypto/openpgp/clearsign/clearsign.go:315:4: leaking resource created on line 300

and this problem exists due to the lack of finesse in defers and in using named error returns that can be used to close values.

/cc to my colleagues @willpoint @elias-orijtech @kirbyquerby

[gopherbot]

Change https://go.dev/cl/413835 mentions this issue: openpgp/*: properly invoke .Close on errors

[dmitshur]

Thanks for reporting. Please note #44226.

[cagedmantis]

Closing since the package is frozen and deprecated.

[odeke-em]

Thank you for chiming in @dmitshur and @cagedmantis! I wouldn't close this issue though as though are more of security fixes than bug fixes, or at least we can fly them as security fixes.