From: Marcus Watts <mwatts@redhat.com>
To: Willem Jan Withagen <wjw@digiware.nl>
Cc: Yehuda Sadeh-Weinraub <yehuda@redhat.com>,
ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: ceph + -lssl
Date: Mon, 29 Feb 2016 20:31:02 -0500 [thread overview]
Message-ID: <20160301013102.GB25207@degu.b.linuxbox.com> (raw)
In-Reply-To: <56D19B44.9080005@digiware.nl>
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
next prev parent reply other threads:[~2016-03-01 1:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 5:09 ceph + -lssl Marcus Watts
2016-02-26 20:43 ` Yehuda Sadeh-Weinraub
2016-02-27 7:50 ` Marcus Watts
2016-02-27 12:49 ` Willem Jan Withagen
2016-03-01 1:31 ` Marcus Watts [this message]
2016-03-02 22:58 ` Kyle Bader
2016-03-03 12:55 ` Willem Jan Withagen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160301013102.GB25207@degu.b.linuxbox.com \
--to=mwatts@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=wjw@digiware.nl \
--cc=yehuda@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.