ceph + -lssl

ceph + -lssl

[Marcus Watts]

I've been working on better integrating ssl int ceph.
Currently, I have a branch, "wip-openssl" which I've pushed to
github, which builds using gitbuilder, also builds with cmake.
I haven't done much testing with this, so there may be some other
business (with certs and such) to make this actually useful.

commits to make this build:
1/ ba8bfab15255d4b321f200a617bc2e0335676482
	automake: -lssl
2/ 5188536a6e42d9207d45dadc86700546ac12b1a2
	cmake: ssl + crypto
3/ 96fe7c5745584158aa69223e3b2482fc9dcfc8fe
	automake: -lssl -lcrypto (not just -lssl)
4/ a23e063a7db4780f120a2199db55ce5ae816b829
	git: used fixed version of civetweb.
	fixes a warning.

There are some additional commits in wip-openssl to support
build "out of tree".  I'll post a separate message about that.

					-Marcus Watts

Re: ceph + -lssl

[Yehuda Sadeh-Weinraub]

I rebased these 4 commits on top of a recent master, and here's the
new pull request:

https://github.com/ceph/ceph/pull/7825

On Tue, Feb 23, 2016 at 9:09 PM, Marcus Watts <mwatts@redhat.com> wrote:
> I've been working on better integrating ssl int ceph.
> Currently, I have a branch, "wip-openssl" which I've pushed to
> github, which builds using gitbuilder, also builds with cmake.
> I haven't done much testing with this, so there may be some other
> business (with certs and such) to make this actually useful.
>
> commits to make this build:
> 1/ ba8bfab15255d4b321f200a617bc2e0335676482
>         automake: -lssl
> 2/ 5188536a6e42d9207d45dadc86700546ac12b1a2
>         cmake: ssl + crypto
> 3/ 96fe7c5745584158aa69223e3b2482fc9dcfc8fe
>         automake: -lssl -lcrypto (not just -lssl)
> 4/ a23e063a7db4780f120a2199db55ce5ae816b829
>         git: used fixed version of civetweb.
>         fixes a warning.
>
> There are some additional commits in wip-openssl to support
> build "out of tree".  I'll post a separate message about that.
>
>                                         -Marcus Watts
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ceph + -lssl

[Marcus Watts]

On Fri, Feb 26, 2016 at 12:43:24PM -0800, Yehuda Sadeh-Weinraub wrote:
> I rebased these 4 commits on top of a recent master, and here's the
> new pull request:
> 
> https://github.com/ceph/ceph/pull/7825
> 
> On Tue, Feb 23, 2016 at 9:09 PM, Marcus Watts <mwatts@redhat.com> wrote:
> > I've been working on better integrating ssl int ceph.
...

Thanks Yehuda for doing this.

Matt pointed out in the pull request that cmake builds were failing
on this branch.  I've pushed a commit to fix that.

					-Marcus Watts

Re: ceph + -lssl

[Willem Jan Withagen]

On 27-2-2016 08:50, Marcus Watts wrote:
> On Fri, Feb 26, 2016 at 12:43:24PM -0800, Yehuda Sadeh-Weinraub wrote:
>> I rebased these 4 commits on top of a recent master, and here's the
>> new pull request:
>> https://github.com/ceph/ceph/pull/7825
>>
>> On Tue, Feb 23, 2016 at 9:09 PM, Marcus Watts <mwatts@redhat.com> wrote:
>>> I've been working on better integrating ssl int ceph.
> ...
> 
> Thanks Yehuda for doing this.
> 
> Matt pointed out in the pull request that cmake builds were failing
> on this branch.  I've pushed a commit to fix that.

I know I'm not doing the work, but would it be possible to base the work
on for example LibreSSL from OpenBSD or BoringSSL from Google.

From the things I've seen and read about it, these libraries are (good)
attempts to shed a lot of cruft of openssl resulting in a compacter and
better build lib.

Next to the history of OpenBSD which is "not all that bad" for security.
And I'd expect Ceph to only use the more modern parts of the lib, and
thus historical compatibility is not that important here.
--WjW

Re: ceph + -lssl

[Marcus Watts]

On Sat, Feb 27, 2016 at 01:49:08PM +0100, Willem Jan Withagen wrote:
> On 27-2-2016 08:50, Marcus Watts wrote:
> > On Fri, Feb 26, 2016 at 12:43:24PM -0800, Yehuda Sadeh-Weinraub wrote:
> >> I rebased these 4 commits on top of a recent master, and here's the
> >> new pull request:
> >> https://github.com/ceph/ceph/pull/7825
> >>
> >> On Tue, Feb 23, 2016 at 9:09 PM, Marcus Watts <mwatts@redhat.com> wrote:
> >>> I've been working on better integrating ssl int ceph.
> > ...
> > 
> > Thanks Yehuda for doing this.
> > 
> > Matt pointed out in the pull request that cmake builds were failing
> > on this branch.  I've pushed a commit to fix that.
> 
> I know I'm not doing the work, but would it be possible to base the work
> on for example LibreSSL from OpenBSD or BoringSSL from Google.
> 
> From the things I've seen and read about it, these libraries are (good)
> attempts to shed a lot of cruft of openssl resulting in a compacter and
> better build lib.
> 
> Next to the history of OpenBSD which is "not all that bad" for security.
> And I'd expect Ceph to only use the more modern parts of the lib, and
> thus historical compatibility is not that important here.
> --WjW
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I looked at libressl a bit.  It still has the same license emcumbrances
as openssl.  So no real win there.  And, since it's not packaged as part
of many linux distributions, the gpl/ssleay license incompatibility issue
becomes a real problem here.  Hopefully a future version of libressl will
adopt a plain bsd license.  I know they were working hard to discard
the crufty openssl build system, a good thing.  When I worked with an
earlier version of openssl (adding a new hash or encryption algorithm,
I don't remember which today), I remember being disappointed at finding
internal interfaces that just assumed various max sizes of things.  I hope
the libressl folks work on making those things better too.

I'm not familiar with google's "boringSSL".  Do you have some references
for it?  I won't have the time to look at it right now - but I don't mind
learning at least a bit more about it.  I see from wikipedia that it's
yet another fork of openssl - will they fix the license issue?

I did look (mostly superficially) at,
	botan libressl gnutls matrixssl mbed wolfssl cryptlib nss
	& apple's "secure transport"
It was mostly superficial because my first question was "are there
a lot of other people using this" aka "am I going to be debugging
and supporting this myself"?

					-Marcus

Re: ceph + -lssl

[Kyle Bader]

> I looked at libressl a bit.  It still has the same license emcumbrances
> as openssl.  So no real win there.  And, since it's not packaged as part
> of many linux distributions, the gpl/ssleay license incompatibility issue
> becomes a real problem here.  Hopefully a future version of libressl will
> adopt a plain bsd license.  I know they were working hard to discard
> the crufty openssl build system, a good thing.  When I worked with an
> earlier version of openssl (adding a new hash or encryption algorithm,
> I don't remember which today), I remember being disappointed at finding
> internal interfaces that just assumed various max sizes of things.  I hope
> the libressl folks work on making those things better too.
>
> I'm not familiar with google's "boringSSL".  Do you have some references
> for it?  I won't have the time to look at it right now - but I don't mind
> learning at least a bit more about it.  I see from wikipedia that it's
> yet another fork of openssl - will they fix the license issue?
>
> I did look (mostly superficially) at,
>         botan libressl gnutls matrixssl mbed wolfssl cryptlib nss
>         & apple's "secure transport"
> It was mostly superficial because my first question was "are there
> a lot of other people using this" aka "am I going to be debugging
> and supporting this myself"?

BoringSSL

https://boringssl.googlesource.com/boringssl/

This might also be worth a look:

https://github.com/awslabs/s2n

-- 

Kyle Bader

Re: ceph + -lssl

[Willem Jan Withagen]

On 2-3-2016 23:58, Kyle Bader wrote:
>> I looked at libressl a bit.  It still has the same license emcumbrances
>> as openssl.  So no real win there.  And, since it's not packaged as part
>> of many linux distributions, the gpl/ssleay license incompatibility issue
>> becomes a real problem here.  Hopefully a future version of libressl will
>> adopt a plain bsd license.  I know they were working hard to discard
>> the crufty openssl build system, a good thing.  When I worked with an
>> earlier version of openssl (adding a new hash or encryption algorithm,
>> I don't remember which today), I remember being disappointed at finding
>> internal interfaces that just assumed various max sizes of things.  I hope
>> the libressl folks work on making those things better too.
>>
>> I'm not familiar with google's "boringSSL".  Do you have some references
>> for it?  I won't have the time to look at it right now - but I don't mind
>> learning at least a bit more about it.  I see from wikipedia that it's
>> yet another fork of openssl - will they fix the license issue?
>>
>> I did look (mostly superficially) at,
>>         botan libressl gnutls matrixssl mbed wolfssl cryptlib nss
>>         & apple's "secure transport"
>> It was mostly superficial because my first question was "are there
>> a lot of other people using this" aka "am I going to be debugging
>> and supporting this myself"?
> 
> BoringSSL
> 
> https://boringssl.googlesource.com/boringssl/
> 
> This might also be worth a look:
> 
> https://github.com/awslabs/s2n

I myself have spoken to one of the people that works on integration of
LibreSSL in FreeBSD ports (he lives in town here). And yes he tells me
that it is a lot of work, but mainly because of the "liberties" that
openssl allows. And even though LibreSSL attempts to be a plugin
replacement, it are these edge corners which do work, but according the
API should not, that create the porting pain.

So that would be another argument of trying to see if you can hook this
in. I'm sure you will find odd bits and pieces that do not work as
expected. But in the end it will improve you code quality. Same feeling
I have trying to port to FreeBSD. 99,9% is compatible, and sometimes
Linuxisms creep in where the do not have to because POSIX is good enough.

But you are right, on occassion you will hit a wall and damage you nose.
On the other hand, I'm upgrading openssl in all environments I maintain
for the 3 or 4th time in 2 years, because of major bugs in openssl.
Doesn't say there are no bugs in the other implementations.

But it was just a things I was wondering when I saw the implementation
come by. And any implementation is beter than none. So thanx for doing
the work.

--WjW