go-pkcs12
                                
                                
                                
                                    go-pkcs12 copied to clipboard
                            
                            
                            
                        Address a bunch of Issue, and fix a missing `asn1:optional` flag, add a Config for setting options, and Marshal/Unmarshal
Going through the pkcs12 implementation here made me consider that this was missing some things, such as getting the friendly name from a pkcs12 / trust store file. Created a set of Marshal/Unmarshal functions that provide/take algorithm configurations, they provide either a byte (for encoding) or a struct (for decoding) the pkcs12 structure.
The Algorithms are added to the Unmarshal output so the structure can be written back to a file via Marshalling into the same format.
@AGWA Can you take a look at this and let me know what you think?
Is this PR going to get in? I need support for pbeWithSHAAnd128BitRC2-CBC which this PR provides. I created an issue for that: https://github.com/SSLMate/go-pkcs12/issues/43
Same. This has some good fixes, can we get this merged & in a release? 🥺
Bump it up, looking forward any movement on this PR.
Thanks @pschou for your PR. Unfortunately, this PR is extremely large and changes a lot of security-sensitive code and API surface and I just don't have the time to review it.
As I understand it, the most urgent features that people need are:
- Encoding passwordless truststores (in the same format that Java 18 uses)
 - Encoding with modern algorithms (PBES2 with PBKDF2 and AES-256-CBC; the same algorithms that OpenSSL 3 uses by default)
 
I've begun working on a minimal, conservative change that adds the above features. I expect this to take much less time than reviewing this PR would.
CC @pivotal-david-osullivan @Tookmund
Closing in favor of #48. In the future, please consider:
- Filing an issue for feedback before embarking on major rewrites, feature additions, or API changes.
 - Keeping PRs as short as possible, and splitting unrelated changes into different PRs.
 
(This is good advice for all open source projects, not just this one.)