dev.boringcrypto OpenSSL port

[depa...@redhat.com]

Hello,

[For some initial background] I've been working on a downstream port of the dev.boringcrypto branch which uses OpenSSL instead. We (Red Hat) do not wish to keep these changes downstream and want to contribute them back to the main project. In an effort to do so I've already spoken with Filippo offline about upstreaming the OpenSSL port into the dev.boringcrypto branch such that both the original and the OpenSSL port continue to work (and obviously I stick around to maintain the patches and help with getting CI configured, etc).

With that in mind I've submitted https://github.com/golang/go/pull/43900. It's been a few weeks without any feedback so I wanted to post here just to make sure it doesn't get lost. I imagine things work differently with notifications and Github integration when creating a PR against a non-main branch.

Anyways, I'd love some early impressions and feedback on the direction.

[Kevin Chadwick]

>[For some initial background] I've been working on a downstream port of
>the
>dev.boringcrypto branch which uses OpenSSL instead. We (Red Hat) do not
>
>wish to keep these changes downstream and want to contribute them back
>to
>the main project. In an effort to do so I've already spoken with
>Filippo
>offline about upstreaming the OpenSSL port into the dev.boringcrypto
>branch
>such that both the original and the OpenSSL port continue to work (and
>obviously I stick around to maintain the patches and help with getting
>CI
>configured, etc).

early impressions and feedback on the direction.

I am not a go team developer but may I ask why. It seems to me that boringssl should be perfectly adequate and a more secure codebase?

Personally, I wouldn't want go team members time spent on this. LibreSSL has avoided many OpenSSL cves. Which suggests poor management for a security focussed library!

[depa...@redhat.com]

There is a lot of time and financial investment in having a specific crypto library FIPS certified on a specific platform and ensuring everything works together. For our platform that investment happened to be in OpenSSL. Additionally, on a technical level, the approach taken by the existing dev.boringcrypto implementation is restricted to only linux/amd64, whereas we need more architecture support and flexibility.

Seeing as dev.boringcrypto is essentially an upstream fork, there is more leeway in terms on fitting these changes in and hopefully in the future re imagining the mechanism by which alternate crypto libraries may be used.

Finally, and not to be rude or snarky in any way, but there are Go team members who already work on and maintain this dev.boringcrypto fork. Asking them to review more code for that branch isn't out of the question, and contributing code back to an upstream project is typically seen as being a good citizen of that project. Others have expressed interest in using Go with OpenSSL or another crypto library as well. I think that unless you pay the salary of Go team members you're not in a position to dictate what they should or should not be working on.

[Jared Parsons]

>Others have expressed interest in using Go with OpenSSL or another crypto library as well.

Indeed. This is a feature we're interested in at Microsoft as well (also for FIPS compliance issues). 

[Kevin Chadwick]

> I think that unless you
>pay
>the salary of Go team members you're not in a position to dictate

You are clearly confusing dictatorship for candour. Unless you are being disengenuous.