Refactor the inefficient function to parse PKCS#8 encrypted private keys

[akkahshh24]

Description

Currently, the function to parse the encrypted private key invokes the openssl command, writes temporary files, and reads back the decrypted output. While this works, it's very inefficient.

espresso/lib/certmanager/certmanager.go:122

// Helper function to parse PKCS#8 encrypted private keys
func parseEncryptedPKCS8PrivateKey(data, password []byte) (interface{}, error)

Go's x509 and pem standard libraries already provide support for decrypting encrypted PEM blocks using x509.DecryptPEMBlock.

Benefits

1. No call to external dependencies like openssl
2. No writing to and reading from temp files.

I'd be happy to work on this and create a pull request.

[HVBLEGENDZZ9]

Hi @akkahshh24 , can I work on this issue?

I have previously used the standard x509 and pem libraries in Go. This will be my first open source contribution if I make it happen and if there is no one working on this issue, I can pick it up and come back with an optimization for the function.

Thank you!

[Mrsandeep27]

Pinging because this issue references "the inefficient function" without a link to it. To make this more actionable for contributors:

1. File + function name + line, ideally as a code reference: `security/pkcs8.go:Decode()` or whatever the actual symbol is.
2. Concrete inefficiency: is it allocations per call, repeated parsing of the same input, redundant hashing, or something else? A quick `go test -bench` snippet that demonstrates the hot path would let a contributor measure improvement.
3. Acceptance criteria: target speedup, allocation reduction, etc.

Without these, anyone picking this up has to first reverse-engineer what "the" function is. Happy to attempt the refactor if the maintainers can drop one of: the file reference, a profiling output, or the original incident that surfaced the slowness. If the maintainers prefer, I can also open a PR with my best guess at the target function and you can redirect from there.

[Mrsandeep27]

The issue references "the inefficient function" without a link. To make this actionable for contributors, would help to have:

1. File + function name + line — e.g. `security/pkcs8.go:Decode()` or wherever the actual symbol lives.
2. Concrete inefficiency — allocations per call, repeated parsing, redundant hashing? A quick `go test -bench` snippet showing the hot path lets contributors measure improvement.
3. Acceptance criteria — target speedup, allocation reduction.

Without these, anyone picking this up has to first reverse-engineer what "the" function is. Happy to attempt the refactor if a maintainer can drop one of: the file reference, profiling output, or the original incident that surfaced the slowness.