You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work at Amazon Web Services (AWS) with the AWS Libcrypto (AWS-LC) team. AWS-LC is Amazon's fork of BoringSSL that is actively maintained, and has a history of upstreaming improvements to BoringSSL where possible. As such we have remained largely as compatible drop-in in projects where BoringSSL is supported, requiring minimal to no compatibility patches. The work to enable BoringSSL as the backing cryptographic implementation of the crypto standard library packages has been valuable to our team, making it easy for us to easily patch and use AWS-LC alternatively.
We are interested in upstreaming this patch to the Go compiler directly, which would enable our customers the ability to leverage CPU specific architectural optimizations for platforms like AWS Graviton2, AWS Graviton3, and recent optimizations for Intel processors supporting AVX-512. Additionally, we provide a FIPS mode that operates in a manner similar to BoringSSL. We would like for users to have the ability to consume the Go compiler source code, enable the relevant build flags, and produce a version of the Go compiler that uses AWS-LC for the crypto standard library packages. We believe that this is best accomplished by upstreaming that support directly, rather then maintaining a Go compiler fork, or providing users patch files that they would apply to their own source tree. The feature would be considered experimental by nature, and its support level would be no more then what is currently present for the BoringSSL integration.
Before moving forward with creating a pull request for such integration, we wanted to get a gut check on whether you would be open to this idea. If so, we would perform the necessary work to get this properly integrated, and would utilizes CI infrastructure for the AWS-LC GitHub project to track the Go compiler source tree to continually verify this level integration. We would long-term own keep this integration functional, and making necessary modifications as required.
Just wanted to circle back on this proposal issue as there hasn't been any movement on this since the initial creation.
Just wanted to give a heads up that in the interim we plan to maintain a minimal patch set and associated CI in our repository (aws-lc) for tracking interoperability between our project and Go. Long-term we would still like to work together to move towards a solution as outlined in the proposal.
We considered this in #33281 and declined it because we don't want to commit to a specific shape of plug for the pluggable modules, nor to maintaining that plug. We do not even officially support BoringCrypto for use outside Google. So for now I am afraid you will need to maintain your patch separately.
rsc
changed the title
proposal: crypto: Supporting AWS Libcrypto (AWS-LC) as provider for cryptographic implementations.
proposal: crypto: allow replacing BoringCrypto with AWS Libcrypto
Dec 14, 2023
Hello Go maintainers,
I work at Amazon Web Services (AWS) with the AWS Libcrypto (AWS-LC) team. AWS-LC is Amazon's fork of BoringSSL that is actively maintained, and has a history of upstreaming improvements to BoringSSL where possible. As such we have remained largely as compatible drop-in in projects where BoringSSL is supported, requiring minimal to no compatibility patches. The work to enable BoringSSL as the backing cryptographic implementation of the crypto standard library packages has been valuable to our team, making it easy for us to easily patch and use AWS-LC alternatively.
We are interested in upstreaming this patch to the Go compiler directly, which would enable our customers the ability to leverage CPU specific architectural optimizations for platforms like AWS Graviton2, AWS Graviton3, and recent optimizations for Intel processors supporting AVX-512. Additionally, we provide a FIPS mode that operates in a manner similar to BoringSSL. We would like for users to have the ability to consume the Go compiler source code, enable the relevant build flags, and produce a version of the Go compiler that uses AWS-LC for the
crypto
standard library packages. We believe that this is best accomplished by upstreaming that support directly, rather then maintaining a Go compiler fork, or providing users patch files that they would apply to their own source tree. The feature would be considered experimental by nature, and its support level would be no more then what is currently present for the BoringSSL integration.Before moving forward with creating a pull request for such integration, we wanted to get a gut check on whether you would be open to this idea. If so, we would perform the necessary work to get this properly integrated, and would utilizes CI infrastructure for the AWS-LC GitHub project to track the Go compiler source tree to continually verify this level integration. We would long-term own keep this integration functional, and making necessary modifications as required.
Thank you
References:
https://github.com/aws/aws-lc
The text was updated successfully, but these errors were encountered: