Opportunity: What are the needs of our target user groups?
More secure software. Currently, we use OpenSSL for consensus bits and there are concerns with the internal team continuing this utilization because of OpenSSL's track record (remote memory corruption bug in OpenSSL 3.0.4). The proposal is to instead switch over to use a submoduled-in static linked BoringSSL for consensus bits; i.e. anything in libchain.
Target audience: Who is the target audience and why?
Security/stability issues - applicable to full audience.
Strategic alignment: How does this problem align with our core strategic pillars?
Security/stability issue
Context
Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?
Product differentiation: what would make our solution different?
Audience definition
Solution
Solution name: How should we refer to this product opportunity?
Open SSL Dependency Removal
Purpose: Define the product’s purpose briefly
Success definition: What are the top metrics for the product (up to 5) to define success?
Reimplement HTTP requests via platform provided high level HTTP APIs. This would mean libcurl on Linux, NSURLSession on macOS, and WinHTTP on Windows. This actually has a number of nice benefits like getting cleos HTTP/2 support, system proxy support, ipv6 happy eyeballs, and not needing to deal with the CA store. The downside of course is that it's more code to maintain and different across platforms.
nodeos & keosd
My preference would be to eliminate TLS support in nodeos & keosd. I suspect usage of the HTTPS server in nodeos is extremely rare (some prominent community members regularly discourage its use, even). Likewise, I suspect connecting nodeos to keosd via TLS is extremely rare.
If we must keep TLS support in nodeos & keosd, perhaps look in to system provided TLS implementations such as GnuTLS and Core Transport.
Explore: Previously, as mentioned in the EOS PR above, boringssl's sha256 performance was rather poor. This is important to us. Performance testing with sha256 & r1 key recovery should be performed on the latest version before getting too far in to this change.
stephenpdeos
commented
1 year ago
Problem
Opportunity: What are the needs of our target user groups?
More secure software. Currently, we use OpenSSL for consensus bits and there are concerns with the internal team continuing this utilization because of OpenSSL's track record (remote memory corruption bug in OpenSSL 3.0.4). The proposal is to instead switch over to use a submoduled-in static linked BoringSSL for consensus bits; i.e. anything in libchain.
Target audience: Who is the target audience and why?
Security/stability issues - applicable to full audience.
Strategic alignment: How does this problem align with our core strategic pillars?
Security/stability issue
Context
Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?
Product differentiation: what would make our solution different?
Audience definition
Solution
Solution name: How should we refer to this product opportunity?
Open SSL Dependency Removal
Purpose: Define the product’s purpose briefly
Success definition: What are the top metrics for the product (up to 5) to define success?
Assumptions
Risks: What risks should be considered? https://www.svpg.com/four-big-risks/
Business Objectives/Functionality
Features/Epics
cleos
Reimplement HTTP requests via platform provided high level HTTP APIs. This would mean libcurl on Linux, NSURLSession on macOS, and WinHTTP on Windows. This actually has a number of nice benefits like getting cleos HTTP/2 support, system proxy support, ipv6 happy eyeballs, and not needing to deal with the CA store. The downside of course is that it's more code to maintain and different across platforms.
nodeos & keosd
My preference would be to eliminate TLS support in nodeos & keosd. I suspect usage of the HTTPS server in nodeos is extremely rare (some prominent community members regularly discourage its use, even). Likewise, I suspect connecting nodeos to keosd via TLS is extremely rare.
If we must keep TLS support in nodeos & keosd, perhaps look in to system provided TLS implementations such as GnuTLS and Core Transport.
Need to be mindful of https://github.com/eosnetworkfoundation/mandel/issues/110 & https://github.com/eosnetworkfoundation/product/pull/13 as they mix in to these decisions too. This effort is likely a blocker for https://github.com/eosnetworkfoundation/product/pull/20.
Explore: Previously, as mentioned in the EOS PR above, boringssl's sha256 performance was rather poor. This is important to us. Performance testing with sha256 & r1 key recovery should be performed on the latest version before getting too far in to this change.