[PATCH] Crypto use in Samba (was: Re: SMB3 encryption performance)

[Michael Ledford]

On Tue, Feb 17, 2015 at 1:48 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> GnuTLS is still looking like the best option on the research so far.  If
> we can find a reliable way to build gnutls in a private prefix, then I
> think that by the time a release with this support is made (later this
> year), a good number of users will be able to take advantage of it one
> way or the other.

I don't think I quite understood what were saying. Are you suggesting
to find a way to prefix all of GnuTLS' methods so they live in its own
namespace? Or simply building a version of GnuTLS in a way that it's
not actually included in the Samba source tree?

> If I ever get time to finish updating Heimdal, then the next step for me
> in that area is to build only with upstream, getting it out of our tree
> and build system.  I would replacing that with a script to build it
> using it's own build system, privately.
>
> Doing the same (automated private build) with GnuTLS would be a good
> first step to demonstrating that this is a viable option.

How would you propose that this automated private build occur? It
seems like you have ideas.

> I think the next step is to see what the interfaces look like when used
> in practice.

I assume this would be actually integrating GnuTLS into parts of Samba
to see what problems or changes would need to take place, if any, to
accommodate it?

Cheers,
Michael

On Tue, Feb 17, 2015 at 1:48 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> On Tue, 2015-02-17 at 15:45 +0100, Volker Lendecke wrote:
>> On Tue, Feb 17, 2015 at 09:36:25AM -0500, Michael Ledford wrote:
>> > > Ok, I believe then we should postpone this whole effort to the point
>> > > when Debian and RHEL by default ship GnuTLS versions that do all we need.
>> >
>> > That's a shame.
>>
>> Well, so is the state of crypto libraries in Unix it seems.  Nothing that
>> we can change. OpenSSL is screwed due to the License issue, GnuTLS is
>> not up to par feature-wise, and I don't want to go down the path of some
>> obscure library that we get dissed over in Debian again. Happened to us
>> with iniparser, won't go there again.
>>
>> > It looks like GnuTLS is aiming for a march release of 3.4
>>
>> This means we have to wait for RHEL8 and Debian next until we can
>> reasonably make use of this in the field, in case both happen to pick
>> it up in time.
>>
>> > <http://nmav.gnutls.org/2014/12/a-quick-overview-of-gnutls-development.html>
>> > which as Andrew pointed out, thank you for looking I totally missed
>> > it, does have the support needed.
>> >
>> > Is there anything that could be done to move this forward in the meantime?
>>
>> Even if we don't ship anything in Samba upstream because we can't afford
>> to do crypto on our own, I would be happy to review/test/host appropriate
>> patches somewhere external for interested OEMs and people who can
>> compile Samba on their own.
>
> GnuTLS is still looking like the best option on the research so far.  If
> we can find a reliable way to build gnutls in a private prefix, then I
> think that by the time a release with this support is made (later this
> year), a good number of users will be able to take advantage of it one
> way or the other.
>
> If I ever get time to finish updating Heimdal, then the next step for me
> in that area is to build only with upstream, getting it out of our tree
> and build system.  I would replacing that with a script to build it
> using it's own build system, privately.
>
> Doing the same (automated private build) with GnuTLS would be a good
> first step to demonstrating that this is a viable option.
>
> I think the next step is to see what the interfaces look like when used
> in practice.
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                       http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
>
>