28.05.2023 11:21 R.Wieser kirjutas:
>>> Than again, did you know that "BIO_do_connect" is actually a #define of
>>> the
>>> command below it :
>>
>> My IDE tells me that whenever I'm inclined to be interested in such
>> things.
>
> And you're mostly not interested, as long as it works, right ? And by
> that missing that two, directly following each other functions seem to be
> doing the same thing ...
>
> I did notice, and am now wondering why. And if that should not have
> happened, how much I should trust the correctness of the rest of the code.
> :-(

I can tell you why. Openssl has long history and has tried to clean up
its SDK, probably multiple times. Alas, it appears by some reason people
do not want to modify their old code to use new cleaned-up interfaces
and insist on that the same client code which worked with e.g. openssl
0.9.8.0 (released 18 years ago) should still work with todays' version.
Hence, there are lots of #define-s to patch over the differences and to
make the old code compile. In particular, BIO_do_connect() is documented
in the bio.h header file as: "Aliases kept for backward compatibility."

Paavo,

> I can tell you why.
....
> Hence, there are lots of #define-s to patch over the differences and to
> make the old code compile.

Thats not what I was talking about. What was is that there *two* the
identical connect calls in sequence. That isn't good (or should not be).

As for the #define's themselves ? I can understand that calling a function
named "connect" is a lot easier to remember than calling a "BIO_ctrl" one
with a BIO_C_DO_STATEMACHINE argument. Thats not the point.

... Though it does not help my poor brain that a function with "connect" in
its name doesn't do anything like it ...

Regards,
Rudy Wieser

On Sunday, 28 May 2023 at 11:24:18 UTC+3, R.Wieser wrote:
> Scott,
> >>... and those libeay32 and ssleay32DLLs /still/ have 3000+ functions in
> >>them. :-)
> >
> > Not surprising given that openssl is a general purpose cryptographic
> > toolkit,
> Ofcourse. That is why its called "OpenCrypt", and not "OpenSSL".
>
> Oh, wait ... :-p
>
It is OpenSSL made for Secure Sockets Layer. As that can't be made
without cryptography it has libcrypto in it. That libcrypto contains
wide range of cryptographic algorithms used in various Internet standards.
There is wide range of those and nothing to do, only more and more and
more will be standardised as time passes. LOT more.

=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> writes:
>On Sunday, 28 May 2023 at 11:24:18 UTC+3, R.Wieser wrote:
>> Scott,
>> >>... and those libeay32 and ssleay32DLLs /still/ have 3000+ functions in
>> >>them. :-)
>> >
>> > Not surprising given that openssl is a general purpose cryptographic
>> > toolkit,
>> Ofcourse. That is why its called "OpenCrypt", and not "OpenSSL".
>>
>> Oh, wait ... :-p
>>
>It is OpenSSL made for Secure Sockets Layer. As that can't be made
>without cryptography it has libcrypto in it. That libcrypto contains
>wide range of cryptographic algorithms used in various Internet standards.
>There is wide range of those and nothing to do, only more and more and
>more will be standardised as time passes. LOT more.

Indeed, in the last 20 years all the uses of the openssl libraries
in my experience have been for crypto purposes, not for SSL. That
includes time at Verisign (before they divested the certificate business
to Symantec) as well as my current employer.