Comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs

Dr. Matthias St. Pierre

Hello,

first of all, I'd like to say that I agree with the core developers that it's a good idea to make
all these OpenSSL structs opaque and provide an API for creation/desruction and member access instead.

I have two comments on the new ECDSA_METHOD_*() and RSA_METHOD_*() APIs in particular,
and a general question concerning the *_METHOD_*() API in general.


1) The ECDSA_METHOD_*() api is not const correct: the "copy constructor" and the name setter
   are lacking a 'const' in the last argument.
   
     ECDSA_METHOD *ECDSA_METHOD_new(ECDSA_METHOD *ecdsa_meth)
     void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, char *name)  

   Instead, I should be

     ECDSA_METHOD *ECDSA_METHOD_new(const ECDSA_METHOD *ecdsa_meth)
     void ECDSA_METHOD_set_name(ECDSA_METHOD *ecdsa_method, const char *name)

   I have prepared a patch fixing the const-correctness, which I'll post to the request tracker.
   
   It would be nice if the change could be added to the 1.0.2 stable branch. Although it's a header change
   it would not break the ABI and force no recompilation of existing code, as far as I understand it,
   since there is no name decoration in C. This opion was also shared by Rich Salz recently:

   Re: [openssl-dev] Missing API features
   On 04/20/2015 10:25 PM, Salz, Rich wrote:>
   > Changing the return type here should be binary compatible on any sane platform, but it might cause source incompatibilities.


   I think it would be better to correct the error right away, before people start working around it
   by casting away the const's in their code.
   
 

2) A corresponding RSA_METHOD_*() api is still completely missing (even on master) and the 'struct rsa_meth_st'
   members are still publicly visible.

   Are there any plans to add it in the near future?



3) Looking at the set of exported functions in util/libeay.num, one sees that the *_METHOD_*() API is still
   rather rudimentary. Are there any plans to change this?

   util/libeay.num:
     DSO_METHOD_null                         2270    EXIST::FUNCTION:
     DSO_METHOD_openssl                      2271    EXIST::FUNCTION:
     DSO_METHOD_dlfcn                        2272    EXIST::FUNCTION:
     DSO_METHOD_win32                        2273    EXIST::FUNCTION:
     DSO_METHOD_dl                           2275    EXIST::FUNCTION:
     DSO_METHOD_vms                          2462    EXIST::FUNCTION:
     EC_METHOD_get_field_type                3528    EXIST::FUNCTION:EC
     DSO_METHOD_beos                         4122    NOEXIST::FUNCTION:
     X509_CRL_METHOD_free                    4241    EXIST::FUNCTION:
     X509_CRL_METHOD_new                     4371    EXIST::FUNCTION:
     ECDSA_METHOD_set_name                   4723    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_flags                  4726    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_sign_setup             4727    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_sign                   4733    EXIST::FUNCTION:EC
     ECDSA_METHOD_new                        4751    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_verify                 4755    EXIST::FUNCTION:EC
     ECDSA_METHOD_free                       4759    EXIST::FUNCTION:EC
     ECDSA_METHOD_set_app_data               4768    EXIST::FUNCTION:EC
     ECDSA_METHOD_get_app_data               4770    EXIST::FUNCTION:EC

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev