On 2017-10-14 11:40:30 [+1100], Damien Miller wrote:
> The compatibility layer is unversioned, incomplete, barely documented
> and seems to be unmaintained. Because it isn't a library, they require
> it to be added to downstream projects directly. This isn't even close
> to a solution.
It can't be a library like lib-ossl-compat.so or so. All data struct
became opaque and all that "compat" layer is doing is providing the
accessor functions which have to be used in openssl 1.1 and were not
around in earler openssl versions. So you can use the accessor function
and don't have to care about the crypto library.
Providing a library like lib-ossl-compat.so would required to be
compiled against the same libssl.so _and_ would require a so bump each
time the now opaque struct has been modified (since it would export the
hidden opaque struct). This would defeat the purpose of making them
opaque in the first place.
What they did is simply collect the accessor which were needed in order
to be able to compile against both versions.
Are you saying, that you do not accept a wrapper like
static inline int
EVP_CIPHER_CTX_key_length(const EVP_CIPHER_CTX *ctx) {
return ctx->key_len;
}
and prefer accessing
ctx->key_len
directly instead? Except for the different function, the resulting code
should be identical when compiled against libressl. It also shouldn't be
problemantic from the security / maintainance point of view since the
wrapper does exactly what you would do while using libressl anyway.
The worst thing that could happen is that you perform some kind of
access which is not yet covered by a wrapper function. But this isn't
something you should care about, the openssl 1.1 users would notice it
and send I patch. I guess you might be annoyed but those patches. Other
than that, it should be fine.
> In the absence of any progress, I'm considering adding some build sugar
> to simplify the process of building (and possibly fetching) LibreSSL as
> port of the OpenSSH build process. AFAIK Apple's OpenSSH distribution is
> already linked against LibreSSL (and of course, OpenBSD does too), so
> IMO it's had enough road-testing for general use.
Please don't. This reads like you are thinking about embedding a library
into the openssh project. Distros don't like this. It has security
implications.
> -d
Sebastian
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
