Bram Verburg

Sorry for ignoring this PR for so long, we've been discussing the best way forward in the EEF SecurityWG. We are considering moving maintenance of this Mix and Rebar3 plugins...

Hmm, according to the spec this element is optional: ```xml The component that the BOM describes. ``` It might make sense to add it, but I don't think other tools...

There must have been a stale file leftover from an experimental branch when I packaged the Hex release. Sorry about that! What's stopping you from moving to a later version?

> 0.8.9 is the latest version on hex.pm 🤦‍♂️ I will push 0.8.10 soon. Thanks for the report!

Thanks for the fixes! My 2c about the others: It is great to see the move towards "secure by default" in `ssl` in recent OTP releases, but when it comes...

@u3s glad I could help: contributing OCSP support to OTP has long been on my list of things I wanted to do, but I never got around to it. Nice...

This is the first time I see the OTP purl `pkg:otp/[email protected]` used as referencing an OTP release. Is this really the right way to express that? Right now I believe...

> I took the naming based on EEF convention that Elixir is under `pkg:otp/[email protected]` (https://security.erlef.org/specs/otp_purl_type) In an Elixir release there is an elixir application, and the version numbers are the...

Unfortunately Erlang/OTP's `:public_key` application sometimes has two internal representations for the same object: `:plain` and `:otp`, where the latter tends to be the result of slightly deeper parsing. This is...

> BTW, you can also simplify your first two lines to just ca_sk_struct = X509.PrivateKey.new_ec(:secp256r1)... ...or, if you want to call Erlang/OTP directly, `:public_key.generate_key({:namedCurve, :secp256r1})`. I would avoid using the...