On Thu, Dec 11, 2014 at 6:51 AM, Stuart Henderson wrote:
> On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
>> 2014-12-11 15:40 GMT+03:00 Stuart Henderson :
>> > On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
>> >> Hello,
>> >>
>> >> For the historic reasons there is a significant amount o
Short answer Dmitry: No.
Doing so doesn't solve a real problem, and creates many others. Sure
we might not like it ourselves and would never build new software this
way, but removing this legacy at this stage would only break things
for no benefit. (We're very happy to break things when there is
On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
> 2014-12-11 15:40 GMT+03:00 Stuart Henderson :
> > On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
> >> Hello,
> >>
> >> For the historic reasons there is a significant amount of duplicated
> >> functionality.
> >> For example one can use ope
2014-12-11 15:40 GMT+03:00 Stuart Henderson :
> On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
>> Hello,
>>
>> For the historic reasons there is a significant amount of duplicated
>> functionality.
>> For example one can use openssl rsa/dsa/ec to create/modify private/public
>> keys
>> or it'
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
> Hello,
>
> For the historic reasons there is a significant amount of duplicated
> functionality.
> For example one can use openssl rsa/dsa/ec to create/modify private/public
> keys
> or it's possible to just use a generic openssl genpkey/pkey
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public keys
or it's possible to just use a generic openssl genpkey/pkey interface. I'd like
to suggest to clean up the first set of command
