On 11/19/15, 5:01 , "openssl-dev on behalf of Tomas Mraz" <openssl-dev-boun...@openssl.org on behalf of tm...@redhat.com> wrote:
>On Čt, 2015-11-19 at 02:12 +0000, Viktor Dukhovni wrote: >> On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote: >> >>> I guess I'm just having a hard time wrapping my head around why, upon >> > hearing that the volunteer-run project is giving years' advance notice >> > that certain features will be removed, the response is insistence that >> > everything must remain supported forever, instead of using the advance >> > notice to investigate alternatives. Volunteers should be allowed to >> > ease up when they need to, after all. >> >> Culture-clash. Security culture says everything remotely weak must >> go, but release-engineering culture emphasizes compatibilty. The >> crypto library is more of a systems component, not a security >> component. The SSL library is more of a security component than >> a systems component, and has algorithm negotiation. > >What about some reasonable middle ground? >1. remove all assembler implementations of not-current crypto Yes, certainly. Legacy stuff is supposed to work. It may work slower. >2. remove all references of it from the libssl Yes, certainly. After all, this is where most of the threats and risks live. >3. remove the respective EVP_add_cipher(), EVP_add_digest(),... from the >OpenSSL_add* functions so the users have to explicitly add these to use >them automatically. Probably yes. Cannot judge the full impact off-hand, but it makes sense. >In future it might be even reasonable to move the implementations into >the libcryptolegacy.so however I am not sure this change is worth it for >1.1.0. I doubt that such a split would make sense. > >I believe the maintenance costs for pure C implementations in such >separate libcryptolegacy or even in the main C library would be quite >minimal. 100% concur, based on my experience maintaining code (going back enough decades to know :). >I would also expect the users of such legacy code to step up >with sharing the maintenance costs. Possibly. Though, as was pointed out, it is often unclear if you are or are not a user - can you tell for certain what crypto mechanisms (if any) protect your archives going back to the oldest one you keep?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
