[PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
Hi,

the attached patch fixes building Samba with MIT Kerberos. The pointer for
model_ops is uninitialized.

error: ‘model_ops’ may be used uninitialized in this function [-Werror=maybe-
uninitialized]

We have in the README.Coding that pointers should be *ALWAYS* initialized!!


Please review and push if OK.


Thanks,


        Andreas

--
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                [hidden email]

0001-s4-kdc-Initilaize-pointer-of-kdc-service-mit.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Thu, Oct 19, 2017 at 05:37:41PM +0200, Andreas Schneider via samba-technical wrote:

> Hi,
>
> the attached patch fixes building Samba with MIT Kerberos. The pointer for
> model_ops is uninitialized.
>
> error: ‘model_ops’ may be used uninitialized in this function [-Werror=maybe-
> uninitialized]
>
> We have in the README.Coding that pointers should be *ALWAYS* initialized!!
>
>
> Please review and push if OK.

RB+. Obvious goodness. We should move towards
enabling compiler switches that force *all* auto
variables to be initialized.


>
> Andreas
>
> --
> Andreas Schneider                   GPG-ID: CC014E3D
> www.cryptomilk.org                [hidden email]

> From a0e0ce4165267a9f392ccc28c39696d95571b461 Mon Sep 17 00:00:00 2001
> From: Andreas Schneider <[hidden email]>
> Date: Thu, 19 Oct 2017 17:32:15 +0200
> Subject: [PATCH] s4:kdc: Initilaize pointer of kdc-service-mit
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> error: ‘model_ops’ may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
>
> Signed-off-by: Andreas Schneider <[hidden email]>
> ---
>  source4/kdc/kdc-service-mit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/source4/kdc/kdc-service-mit.c b/source4/kdc/kdc-service-mit.c
> index 53997d5473d..e6499643e50 100644
> --- a/source4/kdc/kdc-service-mit.c
> +++ b/source4/kdc/kdc-service-mit.c
> @@ -58,7 +58,7 @@ static NTSTATUS startup_kpasswd_server(TALLOC_CTX *mem_ctx,
>         struct loadparm_context *lp_ctx,
>         struct interface *ifaces)
>  {
> - const struct model_ops *model_ops;
> + const struct model_ops *model_ops = NULL;
>   int num_interfaces;
>   int i;
>   TALLOC_CTX *tmp_ctx;
> --
> 2.14.2
>


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-technical
wrote:

> On Thu, Oct 19, 2017 at 05:37:41PM +0200, Andreas Schneider via samba-technical wrote:
> > Hi,
> >
> > the attached patch fixes building Samba with MIT Kerberos. The pointer for
> > model_ops is uninitialized.
> >
> > error: ‘model_ops’ may be used uninitialized in this function [-Werror=maybe-
> > uninitialized]
> >
> > We have in the README.Coding that pointers should be *ALWAYS* initialized!!
> >
> >
> > Please review and push if OK.
>
> RB+. Obvious goodness. We should move towards
> enabling compiler switches that force *all* auto
> variables to be initialized.

-1

Sorry, I think this is wrong.  Sadly there are no automated tests for
the MIT build as part of autobuild, and unless I'm reading the code
wrong, this will just make the use of the kpasswd server fail in the
MIT case as that pointer needs to be filled (as it is elsewhere) in
instead of being set to NULL.

We need the MIT KDC to be a full part of autobuild, with an appropriate
git tag tracked in Samba and built as part of our build process.

Thanks,

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


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Thursday, 19 October 2017 20:57:40 CEST Andrew Bartlett wrote:
> On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-technical
>
> wrote:
> > On Thu, Oct 19, 2017 at 05:37:41PM +0200, Andreas Schneider via samba-
technical wrote:

> > > Hi,
> > >
> > > the attached patch fixes building Samba with MIT Kerberos. The pointer
> > > for
> > > model_ops is uninitialized.
> > >
> > > error: ‘model_ops’ may be used uninitialized in this function
> > > [-Werror=maybe- uninitialized]
> > >
> > > We have in the README.Coding that pointers should be *ALWAYS*
> > > initialized!!
> > >
> > >
> > > Please review and push if OK.
> >
> > RB+. Obvious goodness. We should move towards
> > enabling compiler switches that force *all* auto
> > variables to be initialized.
>
> -1
>
> Sorry, I think this is wrong.  Sadly there are no automated tests for
> the MIT build as part of autobuild, and unless I'm reading the code
> wrong, this will just make the use of the kpasswd server fail in the
> MIT case as that pointer needs to be filled (as it is elsewhere) in
> instead of being set to NULL.

So it needs to be:

const struct model_ops *model_ops = process_model_startup("single");

>
> We need the MIT KDC to be a full part of autobuild, with an appropriate
> git tag tracked in Samba and built as part of our build process.

Well, install a newer libkrb5 on autobuild and we can do that.


        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Fri, Oct 20, 2017 at 07:57:40AM +1300, Andrew Bartlett wrote:

> On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-technical
> wrote:
> > On Thu, Oct 19, 2017 at 05:37:41PM +0200, Andreas Schneider via samba-technical wrote:
> > > Hi,
> > >
> > > the attached patch fixes building Samba with MIT Kerberos. The pointer for
> > > model_ops is uninitialized.
> > >
> > > error: ‘model_ops’ may be used uninitialized in this function [-Werror=maybe-
> > > uninitialized]
> > >
> > > We have in the README.Coding that pointers should be *ALWAYS* initialized!!
> > >
> > >
> > > Please review and push if OK.
> >
> > RB+. Obvious goodness. We should move towards
> > enabling compiler switches that force *all* auto
> > variables to be initialized.
>
> -1
>
> Sorry, I think this is wrong.  Sadly there are no automated tests for
> the MIT build as part of autobuild, and unless I'm reading the code
> wrong, this will just make the use of the kpasswd server fail in the
> MIT case as that pointer needs to be filled (as it is elsewhere) in
> instead of being set to NULL.

Sorry for missing that. Looked like obvious goodness as I assumed
NULL model_ops would be treated as "use default" inside stream_setup_socket().

Should have checked :-(. I'll pull the autobuild.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Thu, 2017-10-19 at 12:12 -0700, Jeremy Allison wrote:
>
>
> Sorry for missing that. Looked like obvious goodness as I assumed
> NULL model_ops would be treated as "use default" inside
> stream_setup_socket().

Sadly not.  Instead Gary and I missed this during the transition when
we removed the forced over-stamping with single.

> Should have checked :-(. I'll pull the autobuild.

Thanks.  

Andrew Bartlett

--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT  
https://catalyst.net.nz/services/samba





Reply | Threaded
Open this post in threaded view
|

working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
>
> Well, install a newer libkrb5 on autobuild and we can do that.

I don't think this is the right approach.  This needs a longer
discussion than I can do right now, but to get started:

The reasons are: 
 - sn-devel is not the only build box for Samba.  

 - We have travis-ci boxes on github and Catalyst's developers use the
scripts our samba-cloud-autobuild repo to build Samba on VMs.

 - It means we could only ever use a feature of MIT krb5 once it is
upstream, released, packaged and installed

Instead, we need to make MIT Kerberos a first-class part of our build
system.  

What I propose is:
 - Our build system uses a git reference (via a submodule or otherwise)
to check out and build MIT krb5
 - In Samba master, this tracks either:
   - MIT master
   - a Samba vendor fork of MIT in limited circumstances
 - In Samba release branches this tracks:
   - the release branch, the released version of MIT krb5 that we will
support
 - This occur in parallel to the Heimdal build

Naturally, coordination will be needed to get patches from master into
MIT releases in time for Samba releases.

This will resolve the issues we have seen so far, being:
 - patches breaking the MIT build
 - MIT Releases being made that break Samba
 - features (like auth logging) being blocked on MIT releases

I also propose we move Heimdal to the same system, once we get the
current upgrade working, so we can finally kick Heimdal out of our
tree.

This proposal needs more work, but I hope it explains things a little.

Thanks,

Andrew Bartlett

--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT  
https://catalyst.net.nz/services/samba





Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> On Thursday, 19 October 2017 20:57:40 CEST Andrew Bartlett wrote:
> > On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-
> > technical

> >
> > Sorry, I think this is wrong.  Sadly there are no automated tests
> > for
> > the MIT build as part of autobuild, and unless I'm reading the code
> > wrong, this will just make the use of the kpasswd server fail in
> > the
> > MIT case as that pointer needs to be filled (as it is elsewhere) in
> > instead of being set to NULL.
>
> So it needs to be:
>
> const struct model_ops *model_ops = process_model_startup("single");

No.  It needs to be like the rest of the code, using task->model_ops.

The line you have there is the one Gary removed when the overstamp
pattern was changed.

Andrew Bartlett
--
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT  
https://catalyst.net.nz/services/samba





Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Friday, 20 October 2017 02:21:41 CEST Andrew Bartlett wrote:

> On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > On Thursday, 19 October 2017 20:57:40 CEST Andrew Bartlett wrote:
> > > On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-
> > > technical
> > >
> > >
> > > Sorry, I think this is wrong.  Sadly there are no automated tests
> > > for
> > > the MIT build as part of autobuild, and unless I'm reading the code
> > > wrong, this will just make the use of the kpasswd server fail in
> > > the
> > > MIT case as that pointer needs to be filled (as it is elsewhere) in
> > > instead of being set to NULL.
> >
> > So it needs to be:
> >
> > const struct model_ops *model_ops = process_model_startup("single");
>
> No.  It needs to be like the rest of the code, using task->model_ops.
>
> The line you have there is the one Gary removed when the overstamp
> pattern was changed.
The attached patchset fixes this and updates the test to work correctly with
latest fixes.


Please review and push if possible.


Thanks,


        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                [hidden email]

mit_kdc_service.patch1.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Friday, 20 October 2017 00:45:22 CEST Andrew Bartlett via samba-technical
wrote:

> On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > Well, install a newer libkrb5 on autobuild and we can do that.
>
> I don't think this is the right approach.  This needs a longer
> discussion than I can do right now, but to get started:
>
> The reasons are:
>  - sn-devel is not the only build box for Samba.  
>
>  - We have travis-ci boxes on github and Catalyst's developers use the
> scripts our samba-cloud-autobuild repo to build Samba on VMs.
>
>  - It means we could only ever use a feature of MIT krb5 once it is
> upstream, released, packaged and installed

You see it from a developer standpoint as you always do. Distributions
especially enterprise distributions have a Kerberos version. This is the
Kerberos version they use through the distribution.

They will not accept that you build Samba with an internel MIT Kerberos
version, you have to use the one from the system!

Why? For security reasons! This way MIT Kerberos gets updated and all
applications, server processes e.g. get the security fix. You do not have to
update 200 packages because each of them has a copy of MIT Kerberos.

> Instead, we need to make MIT Kerberos a first-class part of our build
> system.

It is OK to build a version of MIT Kerberos on those machines for devloperment
but not for users! We are Linux with package managers and this security models
works since a long time because projects to not bundle each library they use!

> What I propose is:
>  - Our build system uses a git reference (via a submodule or otherwise)
> to check out and build MIT krb5

That's fine just for development!

>  - In Samba master, this tracks either:
>    - MIT master
>    - a Samba vendor fork of MIT in limited circumstances

That's extremly bad! An enterprise distribution will not allow a vendor fork
of MIT Kerberos. You use what is in the system or not.

Because of Heimdal included in Samba, Enterprise distributions do not offer
Samba AD.

If you do the same with MIT Kerberos, all my work was "für die Tonne".

>  - In Samba release branches this tracks:
>    - the release branch, the released version of MIT krb5 that we will
> support
>  - This occur in parallel to the Heimdal build

I do not want a copy of yet another Kerberos library in the Samba tree. MIT
Kerberos is maintained by MIT people. Those should decide on features and take
care of it!

It is not a big deal to get features into MIT Kerberos and a developer could
install a development version of MIT Kerberos on their system if needed.
However we should not fork MIT Kerberos libraries.

> Naturally, coordination will be needed to get patches from master into
> MIT releases in time for Samba releases.

No, patches should be created and proposed upstream like with every other Open
Source project out there. We should not fork, it will diverege like we have it
with Heimdal and then you spend a lot of time bringing it up to date.

NO FORK!

> This will resolve the issues we have seen so far, being:
>  - patches breaking the MIT build

We just need the required MIT Kerberos library installed on the system.

>  - MIT Releases being made that break Samba

That's something which is possible with every other library we use too. Do you
want to integrate all of them?

>  - features (like auth logging) being blocked on MIT releases

This is something which happens with other libraries too. It is easy to check
if we can turn on auth logging. An this is happening with other projects too.
So next we fork GnuTLS because it blocks feature X in Samba? And then we fork
glibc ...

> I also propose we move Heimdal to the same system, once we get the
> current upgrade working, so we can finally kick Heimdal out of our
> tree.

Heimdal should be removed from the Samba source tree.


        Andreas


--
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
On Fri, 20 Oct 2017 09:16:25 +0200
Andreas Schneider via samba-technical <[hidden email]>
wrote:

> On Friday, 20 October 2017 00:45:22 CEST Andrew Bartlett via
> samba-technical wrote:
> > On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > > Well, install a newer libkrb5 on autobuild and we can do that.
> >
> > I don't think this is the right approach.  This needs a longer
> > discussion than I can do right now, but to get started:
> >
> > The reasons are:
> >  - sn-devel is not the only build box for Samba.  
> >
> >  - We have travis-ci boxes on github and Catalyst's developers use
> > the scripts our samba-cloud-autobuild repo to build Samba on VMs.
> >
> >  - It means we could only ever use a feature of MIT krb5 once it is
> > upstream, released, packaged and installed
>
> You see it from a developer standpoint as you always do.
> Distributions especially enterprise distributions have a Kerberos
> version. This is the Kerberos version they use through the
> distribution.
>
> They will not accept that you build Samba with an internel MIT
> Kerberos version, you have to use the one from the system!
>
> Why? For security reasons! This way MIT Kerberos gets updated and all
> applications, server processes e.g. get the security fix. You do not
> have to update 200 packages because each of them has a copy of MIT
> Kerberos.
>
> > Instead, we need to make MIT Kerberos a first-class part of our
> > build system.
>
> It is OK to build a version of MIT Kerberos on those machines for
> devloperment but not for users! We are Linux with package managers
> and this security models works since a long time because projects to
> not bundle each library they use!
>
> > What I propose is:
> >  - Our build system uses a git reference (via a submodule or
> > otherwise) to check out and build MIT krb5
>
> That's fine just for development!
>
> >  - In Samba master, this tracks either:
> >    - MIT master
> >    - a Samba vendor fork of MIT in limited circumstances
>
> That's extremly bad! An enterprise distribution will not allow a
> vendor fork of MIT Kerberos. You use what is in the system or not.
>
> Because of Heimdal included in Samba, Enterprise distributions do not
> offer Samba AD.
>
> If you do the same with MIT Kerberos, all my work was "für die Tonne".
>
> >  - In Samba release branches this tracks:
> >    - the release branch, the released version of MIT krb5 that we
> > will support
> >  - This occur in parallel to the Heimdal build
>
> I do not want a copy of yet another Kerberos library in the Samba
> tree. MIT Kerberos is maintained by MIT people. Those should decide
> on features and take care of it!
>
> It is not a big deal to get features into MIT Kerberos and a
> developer could install a development version of MIT Kerberos on
> their system if needed. However we should not fork MIT Kerberos
> libraries.
>
> > Naturally, coordination will be needed to get patches from master
> > into MIT releases in time for Samba releases.
>
> No, patches should be created and proposed upstream like with every
> other Open Source project out there. We should not fork, it will
> diverege like we have it with Heimdal and then you spend a lot of
> time bringing it up to date.
>
> NO FORK!
>
> > This will resolve the issues we have seen so far, being:
> >  - patches breaking the MIT build
>
> We just need the required MIT Kerberos library installed on the
> system.
>
> >  - MIT Releases being made that break Samba
>
> That's something which is possible with every other library we use
> too. Do you want to integrate all of them?
>
> >  - features (like auth logging) being blocked on MIT releases
>
> This is something which happens with other libraries too. It is easy
> to check if we can turn on auth logging. An this is happening with
> other projects too. So next we fork GnuTLS because it blocks feature
> X in Samba? And then we fork glibc ...
>
> > I also propose we move Heimdal to the same system, once we get the
> > current upgrade working, so we can finally kick Heimdal out of our
> > tree.
>
> Heimdal should be removed from the Samba source tree.
>
>
> Andreas
>
>

I thought the whole idea behind getting Samba to work with the system
MIT kerberos, was to get:
A) a more up to date kerberos
B) Samba out of the kerberos business

Am I wrong ?

Rowland

Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
On pe, 20 loka 2017, Rowland Penny via samba-technical wrote:

> On Fri, 20 Oct 2017 09:16:25 +0200
> Andreas Schneider via samba-technical <[hidden email]>
> wrote:
>
> > On Friday, 20 October 2017 00:45:22 CEST Andrew Bartlett via
> > samba-technical wrote:
> > > On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > > > Well, install a newer libkrb5 on autobuild and we can do that.
> > >
> > > I don't think this is the right approach.  This needs a longer
> > > discussion than I can do right now, but to get started:
> > >
> > > The reasons are:
> > >  - sn-devel is not the only build box for Samba.  
> > >
> > >  - We have travis-ci boxes on github and Catalyst's developers use
> > > the scripts our samba-cloud-autobuild repo to build Samba on VMs.
> > >
> > >  - It means we could only ever use a feature of MIT krb5 once it is
> > > upstream, released, packaged and installed
> >
> > You see it from a developer standpoint as you always do.
> > Distributions especially enterprise distributions have a Kerberos
> > version. This is the Kerberos version they use through the
> > distribution.
> >
> > They will not accept that you build Samba with an internel MIT
> > Kerberos version, you have to use the one from the system!
> >
> > Why? For security reasons! This way MIT Kerberos gets updated and all
> > applications, server processes e.g. get the security fix. You do not
> > have to update 200 packages because each of them has a copy of MIT
> > Kerberos.
> >
> > > Instead, we need to make MIT Kerberos a first-class part of our
> > > build system.
> >
> > It is OK to build a version of MIT Kerberos on those machines for
> > devloperment but not for users! We are Linux with package managers
> > and this security models works since a long time because projects to
> > not bundle each library they use!
> >
> > > What I propose is:
> > >  - Our build system uses a git reference (via a submodule or
> > > otherwise) to check out and build MIT krb5
> >
> > That's fine just for development!
> >
> > >  - In Samba master, this tracks either:
> > >    - MIT master
> > >    - a Samba vendor fork of MIT in limited circumstances
> >
> > That's extremly bad! An enterprise distribution will not allow a
> > vendor fork of MIT Kerberos. You use what is in the system or not.
> >
> > Because of Heimdal included in Samba, Enterprise distributions do not
> > offer Samba AD.
> >
> > If you do the same with MIT Kerberos, all my work was "für die Tonne".
> >
> > >  - In Samba release branches this tracks:
> > >    - the release branch, the released version of MIT krb5 that we
> > > will support
> > >  - This occur in parallel to the Heimdal build
> >
> > I do not want a copy of yet another Kerberos library in the Samba
> > tree. MIT Kerberos is maintained by MIT people. Those should decide
> > on features and take care of it!
> >
> > It is not a big deal to get features into MIT Kerberos and a
> > developer could install a development version of MIT Kerberos on
> > their system if needed. However we should not fork MIT Kerberos
> > libraries.
> >
> > > Naturally, coordination will be needed to get patches from master
> > > into MIT releases in time for Samba releases.
> >
> > No, patches should be created and proposed upstream like with every
> > other Open Source project out there. We should not fork, it will
> > diverege like we have it with Heimdal and then you spend a lot of
> > time bringing it up to date.
> >
> > NO FORK!
> >
> > > This will resolve the issues we have seen so far, being:
> > >  - patches breaking the MIT build
> >
> > We just need the required MIT Kerberos library installed on the
> > system.
> >
> > >  - MIT Releases being made that break Samba
> >
> > That's something which is possible with every other library we use
> > too. Do you want to integrate all of them?
> >
> > >  - features (like auth logging) being blocked on MIT releases
> >
> > This is something which happens with other libraries too. It is easy
> > to check if we can turn on auth logging. An this is happening with
> > other projects too. So next we fork GnuTLS because it blocks feature
> > X in Samba? And then we fork glibc ...
> >
> > > I also propose we move Heimdal to the same system, once we get the
> > > current upgrade working, so we can finally kick Heimdal out of our
> > > tree.
> >
> > Heimdal should be removed from the Samba source tree.
> >
> >
> > Andreas
> >
> >
>
> I thought the whole idea behind getting Samba to work with the system
> MIT kerberos, was to get:
> A) a more up to date kerberos
> B) Samba out of the kerberos business
>
> Am I wrong ?
>
You are right and this is what Andreas advocates.

--
/ Alexander Bokovoy

Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
So there's a tension here between the needs of distro's and the needs
of vendors (I'm considering Catalyst via Andrew as a specific Samba
vendor here).

Distros need Samba to work with the libraries shipped with the distro.
An "upstream first" policy for all dependent libraries is a must.

Vendors need flexibility to add new features to both libraries and
Samba to work with them. That sometimes means prototyping features
and after customer approval getting the changes pushed upstream.

I don't want a fork of MIT. No one wants to fork important security
libraries anymore. I don't want to keep a copy of Heimdal anymore. I
think we can all agree on this :-).

Moving both Heimdal and MIT to a git reference to an external tree is
a good idea.

My guess is the difficulty comes from this statement in Andrew's
email:

> What I propose is:
> - Our build system uses a git reference (via a submodule or otherwise)
> to check out and build MIT krb5
> - In Samba master, this tracks either:
>   - MIT master
>   - a "
> - In Samba release branches this tracks:
>   - the release branch, the released version of MIT krb5 that we will
> support
> - This occur in parallel to the Heimdal build

what we need to determine is what "Samba vendor fork of
MIT in limited circumstances" actually means.

So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
I hope we can come to some compromise we can agree on.

I see some hope in Andreas's reply here:

>> What I propose is:
>>  - Our build system uses a git reference (via a submodule or otherwise)
>> to check out and build MIT krb5
>
> That's fine just for development!

>>  - In Samba master, this tracks either:
>>    - MIT master
>>    - a Samba vendor fork of MIT in limited circumstances
>
> That's extremly bad! An enterprise distribution will not allow a vendor fork
> of MIT Kerberos. You use what is in the system or not.

Can we get some consensus on what "is fine for development" means
to both of you ?

Andreas, how do you see Andrew being able to add needed features
to AD+MIT to move our MIT implementation forward ?

Andrew, how do you see being able to separate this out from
master so the distros can keep a supported Samba running against
the default shipped and supported crypto libraries ?

Jeremy.

Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
I tried building Samba against master MIT, to get a sense of what it
takes, and and failed in a quite puzzling way. The failure doesn't seem
related to AD-DC. My steps were:

1. Build git-cloned MIT with --prefix=/home/uri/krb5inst:
a. autoreconf
b. configure --prefix=/home/uri/krb5inst
c. make
d. make install
2. Run an autobuild-ish samba configure:

./configure.developer --with-selftest-prefix=./bin/ab --picky-developer
--with-profiling-data --prefix=/home/uri/s2/bin/samba/prefix
--with-system-mitkrb5 /home/uri/krb5inst --with-system-mitkdc
/home/uri/krb5inst/sbin/krb5kdc

The resulting build failed at lib/krb5_wrap/krb5_samba.c with:

/home/uri/krb5inst/include/profile.h:343:33: error: unused variable
‘et_prof_error_table’ [-Werror=unused-variable]
 extern const struct error_table et_prof_error_table;
                                 ^~~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:40:15: error: typedef
‘profile_filespec_t’ locally defined but not used
[-Werror=unused-local-typedefs]
 typedef char* profile_filespec_t; /* path as C string */
               ^~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:41:15: error: typedef
‘profile_filespec_list_t’ locally defined but not used
[-Werror=unused-local-typedefs]
 typedef char* profile_filespec_list_t; /* list of : separated paths, C
string */
               ^~~~~~~~~~~~~~~~~~~~~~~
/home/uri/krb5inst/include/profile.h:288:3: error: typedef
‘profile_module_init_fn’ locally defined but not used
[-Werror=unused-local-typedefs]
 (*profile_module_init_fn)(const char *residual, struct profile_vtable
*vtable,
   ^~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

I repeated this with Fedora 27 beta - success with system MIT Kerberos,
failure with master MIT.

Usually I'm able to figure out these things but this time I was left
puzzled - same compile switches, "offensive" typedefs and variables in
both versions (as seen in pre-processed code), yet the system krb5
succeeds and my own-built one fails. The only difference in compiler
flags is -I/home/vagrant/krb5inst/include

Thanks,
Uri.

On 10/20/2017 09:56 PM, Jeremy Allison via samba-technical wrote:

> So there's a tension here between the needs of distro's and the needs
> of vendors (I'm considering Catalyst via Andrew as a specific Samba
> vendor here).
>
> Distros need Samba to work with the libraries shipped with the distro.
> An "upstream first" policy for all dependent libraries is a must.
>
> Vendors need flexibility to add new features to both libraries and
> Samba to work with them. That sometimes means prototyping features
> and after customer approval getting the changes pushed upstream.
>
> I don't want a fork of MIT. No one wants to fork important security
> libraries anymore. I don't want to keep a copy of Heimdal anymore. I
> think we can all agree on this :-).
>
> Moving both Heimdal and MIT to a git reference to an external tree is
> a good idea.
>
> My guess is the difficulty comes from this statement in Andrew's
> email:
>
>> What I propose is:
>> - Our build system uses a git reference (via a submodule or otherwise)
>> to check out and build MIT krb5
>> - In Samba master, this tracks either:
>>   - MIT master
>>   - a "
>> - In Samba release branches this tracks:
>>   - the release branch, the released version of MIT krb5 that we will
>> support
>> - This occur in parallel to the Heimdal build
>
> what we need to determine is what "Samba vendor fork of
> MIT in limited circumstances" actually means.
>
> So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
> I hope we can come to some compromise we can agree on.
>
> I see some hope in Andreas's reply here:
>
>>> What I propose is:
>>>  - Our build system uses a git reference (via a submodule or otherwise)
>>> to check out and build MIT krb5
>>
>> That's fine just for development!
>
>>>  - In Samba master, this tracks either:
>>>    - MIT master
>>>    - a Samba vendor fork of MIT in limited circumstances
>>
>> That's extremly bad! An enterprise distribution will not allow a vendor fork
>> of MIT Kerberos. You use what is in the system or not.
>
> Can we get some consensus on what "is fine for development" means
> to both of you ?
>
> Andreas, how do you see Andrew being able to add needed features
> to AD+MIT to move our MIT implementation forward ?
>
> Andrew, how do you see being able to separate this out from
> master so the distros can keep a supported Samba running against
> the default shipped and supported crypto libraries ?
>
> Jeremy.
>


Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On 2017-10-20 at 11:56 -0700, Jeremy Allison via samba-technical wrote:

> So there's a tension here between the needs of distro's and the needs
> of vendors (I'm considering Catalyst via Andrew as a specific Samba
> vendor here).
>
> Distros need Samba to work with the libraries shipped with the distro.
> An "upstream first" policy for all dependent libraries is a must.
>
> Vendors need flexibility to add new features to both libraries and
> Samba to work with them. That sometimes means prototyping features
> and after customer approval getting the changes pushed upstream.
>
> I don't want a fork of MIT. No one wants to fork important security
> libraries anymore. I don't want to keep a copy of Heimdal anymore. I
> think we can all agree on this :-).
>
> Moving both Heimdal and MIT to a git reference to an external tree is
> a good idea.
>
> My guess is the difficulty comes from this statement in Andrew's
> email:
>
> > What I propose is:
> > - Our build system uses a git reference (via a submodule or otherwise)
> > to check out and build MIT krb5
> > - In Samba master, this tracks either:
> >   - MIT master
> >   - a "
> > - In Samba release branches this tracks:
> >   - the release branch, the released version of MIT krb5 that we will
> > support
> > - This occur in parallel to the Heimdal build
>
> what we need to determine is what "Samba vendor fork of
> MIT in limited circumstances" actually means.
>
> So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
> I hope we can come to some compromise we can agree on.
I didn't understand Andrew as suggesting to put a copy of
MIT into our tree. He was talking about a (git) reference.
And I think this is perfectly fine, as Andreas said, for
development purposes.

So what problem are we trying to solve?
The problem that the version of MIT kerberos
available on build systems that the devs are using
(e.g. for autobuild) varies greatly and is frequently
not up to the needs of current Samba.

I see a point in abstracting our development
tree away from those dependencies by providing
a reference to a git tree of mit kerberos so that
we can build against this (at least optionally, if
the system does not provide sufficient krb support)
because krb is kind of special.

I.e. upstream Samba could be made autonomous by this.
This is to my understanding exclusively for the
convenience of developers.

Any downstreams (i.e. vendors and distros) should (or rather
would want to) solve this problem differently by providing
the libs with the needed support in their system.
It should imho also be the default to build against an
external (system) krb lib. And the mode of first fetching
and building a krb version should be exclusive to
"developer" builds and should need to be triggered explicitly.

I also don't think the vanilla upstream should ever reference
any vendor for of krb5, but only official trees. Referencing
vendor krb5-forks would be done in vendor forks of Samba...

Finally, I think once this is implemented, we should do the
same with heimdal if possible: i.e. remove the checked out
copy and replace it by a git reference that can optionally
be used in developer builds....

Just a few thoughts...

Michael


> I see some hope in Andreas's reply here:
>
> >> What I propose is:
> >>  - Our build system uses a git reference (via a submodule or otherwise)
> >> to check out and build MIT krb5
> >
> > That's fine just for development!
>
> >>  - In Samba master, this tracks either:
> >>    - MIT master
> >>    - a Samba vendor fork of MIT in limited circumstances
> >
> > That's extremly bad! An enterprise distribution will not allow a vendor fork
> > of MIT Kerberos. You use what is in the system or not.
>
> Can we get some consensus on what "is fine for development" means
> to both of you ?
>
> Andreas, how do you see Andrew being able to add needed features
> to AD+MIT to move our MIT implementation forward ?
>
> Andrew, how do you see being able to separate this out from
> master so the distros can keep a supported Samba running against
> the default shipped and supported crypto libraries ?
>
> Jeremy.
>

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
On Friday, 20 October 2017 09:00:42 CEST Andreas Schneider via samba-technical
wrote:

> On Friday, 20 October 2017 02:21:41 CEST Andrew Bartlett wrote:
> > On Thu, 2017-10-19 at 21:03 +0200, Andreas Schneider wrote:
> > > On Thursday, 19 October 2017 20:57:40 CEST Andrew Bartlett wrote:
> > > > On Thu, 2017-10-19 at 11:28 -0700, Jeremy Allison via samba-
> > > > technical
> > > >
> > > >
> > > > Sorry, I think this is wrong.  Sadly there are no automated tests
> > > > for
> > > > the MIT build as part of autobuild, and unless I'm reading the code
> > > > wrong, this will just make the use of the kpasswd server fail in
> > > > the
> > > > MIT case as that pointer needs to be filled (as it is elsewhere) in
> > > > instead of being set to NULL.
> > >
> > > So it needs to be:
> > >
> > > const struct model_ops *model_ops = process_model_startup("single");
> >
> > No.  It needs to be like the rest of the code, using task->model_ops.
> >
> > The line you have there is the one Gary removed when the overstamp
> > pattern was changed.
>
> The attached patchset fixes this and updates the test to work correctly with
> latest fixes.
>
>
> Please review and push if possible.

Ping :-)

--
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             [hidden email]
www.samba.org

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Tue, Oct 24, 2017 at 05:40:28AM +0000, Andreas Schneider via samba-technical wrote:
> On Friday, 20 October 2017 09:00:42 CEST Andreas Schneider via samba-technical
> > Please review and push if possible.
>
> Ping :-)

pong and pushed. :)

-slow

--
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] The build with MIT KRB5 doesn't compile after process_prefork has been added

Samba - samba-technical mailing list
On Tue, 2017-10-24 at 09:48 +0200, Ralph Böhme wrote:
> On Tue, Oct 24, 2017 at 05:40:28AM +0000, Andreas Schneider via samba-technical wrote:
> > On Friday, 20 October 2017 09:00:42 CEST Andreas Schneider via samba-technical
> > > Please review and push if possible.
> >
> > Ping :-)
>
> pong and pushed. :)
>
> -slow

Thanks.  The patch is good as far as I'm concerned.

Thanks also to everyone who contributed on the broader thread.  I'll
reply when I get some more time to do your thoughtful contributions
appropriate justice.

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


Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
In reply to this post by Samba - samba-technical mailing list
Thank you all for your contributions to this thread.  I think Michael
covers the issue pretty well, so I'll follow up below:

On Mon, 2017-10-23 at 11:05 +0200, Michael Adam wrote:

> On 2017-10-20 at 11:56 -0700, Jeremy Allison via samba-technical wrote:
> > So there's a tension here between the needs of distro's and the needs
> > of vendors (I'm considering Catalyst via Andrew as a specific Samba
> > vendor here).
> >
> > Distros need Samba to work with the libraries shipped with the distro.
> > An "upstream first" policy for all dependent libraries is a must.
> >
> > Vendors need flexibility to add new features to both libraries and
> > Samba to work with them. That sometimes means prototyping features
> > and after customer approval getting the changes pushed upstream.
> >
> > I don't want a fork of MIT. No one wants to fork important security
> > libraries anymore. I don't want to keep a copy of Heimdal anymore. I
> > think we can all agree on this :-).
> >
> > Moving both Heimdal and MIT to a git reference to an external tree is
> > a good idea.
> >
> > My guess is the difficulty comes from this statement in Andrew's
> > email:
> >
> > > What I propose is:
> > > - Our build system uses a git reference (via a submodule or otherwise)
> > > to check out and build MIT krb5
> > > - In Samba master, this tracks either:
> > >   - MIT master
> > >   - a "
> > > - In Samba release branches this tracks:
> > >   - the release branch, the released version of MIT krb5 that we will
> > > support
> > > - This occur in parallel to the Heimdal build
> >
> > what we need to determine is what "Samba vendor fork of
> > MIT in limited circumstances" actually means.
> >
> > So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
> > I hope we can come to some compromise we can agree on.
>
> I didn't understand Andrew as suggesting to put a copy of
> MIT into our tree. He was talking about a (git) reference.
> And I think this is perfectly fine, as Andreas said, for
> development purposes.
>
> So what problem are we trying to solve?
> The problem that the version of MIT kerberos
> available on build systems that the devs are using
> (e.g. for autobuild) varies greatly and is frequently
> not up to the needs of current Samba.

Yes, and that we need a way to automated this.  My team at Catalyst
increasingly uses infrastructure as code (build hosts created
dynamically in the cloud) and others use travis-ci via GitHub.  

(BTW this transition alone is also an incredible opportunity, and one I
hope others can get on board with soon.)

Because fixing the install on one box won't help, we need a way to say
'use this version', and that in turn gives us a great advantage of
being able to upgrade that version and use different versions for
different builds (not a global one on sn-devel).

It is important to be able to say that Samba 4.7 needs MIT version 1.9,
but 4.8 needs 1.12 for example, and build against exactly those.  That
way we don't accidentally backport use of a new feature without
explicitly bumping the required version.

> I see a point in abstracting our development
> tree away from those dependencies by providing
> a reference to a git tree of mit kerberos so that
> we can build against this (at least optionally, if
> the system does not provide sufficient krb support)
> because krb is kind of special.

Indeed, that is very important.  We once were held back to only using
Kerberos features supported in Solaris (for example), and with the PAC
etc have been on the leading edge of Kerberos features.  In a long-term
where we finally ditch Heimdal, it is quite likely that our users will
need a modern krb5 for Samba to build, even as a file server, and we
should be able to provide it.  Naturally this happens even more often
for a DC.

> I.e. upstream Samba could be made autonomous by this.
> This is to my understanding exclusively for the
> convenience of developers.
>
> Any downstreams (i.e. vendors and distros) should (or rather
> would want to) solve this problem differently by providing
> the libs with the needed support in their system.
> It should imho also be the default to build against an
> external (system) krb lib. And the mode of first fetching
> and building a krb version should be exclusive to
> "developer" builds and should need to be triggered explicitly.
>
> I also don't think the vanilla upstream should ever reference
> any vendor for of krb5, but only official trees. Referencing
> vendor krb5-forks would be done in vendor forks of Samba...
>
> Finally, I think once this is implemented, we should do the
> same with heimdal if possible: i.e. remove the checked out
> copy and replace it by a git reference that can optionally
> be used in developer builds....

Yes, this is my hope.  It is a long road, but we need to get to a spot
where developing new features, which may need to be done in tandem with
upstream projects is equally confident, and where both are fully tested
in autobuild.

Just a few thoughts...

>
> Michael
>
>
> > I see some hope in Andreas's reply here:
> >
> > > > What I propose is:
> > > >  - Our build system uses a git reference (via a submodule or otherwise)
> > > > to check out and build MIT krb5
> > >
> > > That's fine just for development!
> > > >  - In Samba master, this tracks either:
> > > >    - MIT master
> > > >    - a Samba vendor fork of MIT in limited circumstances
> > >
> > > That's extremly bad! An enterprise distribution will not allow a vendor fork
> > > of MIT Kerberos. You use what is in the system or not.
> >
> > Can we get some consensus on what "is fine for development" means
> > to both of you ?
> >
> > Andreas, how do you see Andrew being able to add needed features
> > to AD+MIT to move our MIT implementation forward ?
> >
> > Andrew, how do you see being able to separate this out from
> > master so the distros can keep a supported Samba running against
> > the default shipped and supported crypto libraries ?

This is one of the most fraught parts of the challenge.  Suppose we do
all the right thing, and add a new feature against either upstream
master krb5, but then no release is made in time for our own releases.

And even if the release is made, an enterprise distribution won't ship
a new krb5 just for Samba, let along to support new Samba packages on
old enterprise distributions like SerNet provides.  (Yet this is
incredibly popular in our user communities).

If we are ever going to make the transition to out-of-tree or even to
just MIT, we need to crack this nut, provide something that an
enterprise distribution can live with (pure system packages, but never
update either krb5 or samba), our users can use (need newer, perhaps
even patched krb5 with newer Samba), and our developers can develop
against (need to do a trial autobuild against a proposed set of krb5
patches).

What we can't continue with is where the MIT build of the AD DC is not
tested at all, where assuming a new version requires root@ to change
sn-devel (let alone that this is not the only build platform in use),
and where the model appears to be 'wait for a new MIT version to hit
Fedora rawhide'.

Thanks,

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


Reply | Threaded
Open this post in threaded view
|

Re: working long-term with the MIT KRB5 codebase in the AD DC

Samba - samba-technical mailing list
Hi,

I tend to hope that with the next import of heimdal, we would have been
able to use a system Heimdal.

But the work I had to do in the last weeks shows to me that it's not
that easy :-(

As we don't have tests to show our KDC behaves exactly like a Windows
DC, we're so far away of being able to rely on a more or less fixed
system version of a KDC.

The actual problem was a customer with a complex web application
using IIS on Windows 2012, which makes use of S4U2Proxy in order to
communicate between frontend and backend servers.

It took a week comparing traces between Windows and Samba in order
to eleminate the differences in the generated Kerberos tickets
(including the PAC) in order to finally find that we hit the
timestamp mismatch between ticket and PAC problem again.

Kerberos might not be as complex as SMB1, but it's not far from that.
Which means we need real low level tests to prove we're implementing
things correctly, without relying on kerberos client libraries
or manual testing with Windows, we're basically where we were with SMB1
15 years ago.

Unless we have the prove that we're really compatible with a Windows
DC, we'll have to rely on having custom versions of the KDC code we use,
in order to provide a ready to use version of a KDC.

The reason why things like git submodule, which rely on downloading
code from a specific url, is a bad idea, see
https://git.samba.org/?p=metze/samba/wip.git;a=blob;f=submodule-problems.txt;h=48a2a63c9c9f28b4df09b3f73608ccbd6eda480b;hb=9842196d2de6e673d50f0749bf9734914456c66d
for the reasons why.

But in general build hosts typically don't have internet access
and wouldn't be able to download things automatically.

I'm fine with moving heimdal to third_party, after the next import
and then maintain our known good state in the lorikeet-heimdal repo
where we can rebase it more easily on heimdal master and try to
keep the patchset minimal (0 patches if possible).

In order to have a tested KDC with MIT I'd propose to have it also
under third_party, every other option is not useful for the near future,
until we can really rely on having a stable code base in the upstream
Kerberos projects (maybe only MIT in future).

The fact that we need to implement a lot of new Kerberos features soon,
in order to keep up with Windows 2012/2016 makes it even more problematic.

I hope to find the time to create the start for low level
kerberos tests, using pyasn1 and some python bindings for
the krb5_crypto_* apis. Then we're hopefully be able to
build something similar to the dcerpc raw protocol tests.

For the reference, here're the bug reports I've recently opened:

S4U2Proxy requests with encrypted authorization-data are rejected by a
Samba KDC
https://bugzilla.samba.org/show_bug.cgi?id=13131

The KDC on an RWDC doesn't send error replies in some situations··
https://bugzilla.samba.org/show_bug.cgi?id=13132

The content of the S4U_DELEGATION_INFO PAC element is filled wrong by a
Samba KDC
https://bugzilla.samba.org/show_bug.cgi?id=13133

Padding/alignment of PAC elements is done wrong on Samba KDCs
https://bugzilla.samba.org/show_bug.cgi?id=13134

The KDC logic arround msDs-supportedEncryptionTypes differs from Windows
https://bugzilla.samba.org/show_bug.cgi?id=13135

A Samba KDC doesn't include the RID of the primary group also in the rid
array of groups
https://bugzilla.samba.org/show_bug.cgi?id=13136

S4U2Proxy tickets from a Samba KDC don't pass PAC verification checks
(authtime mismatch)
https://bugzilla.samba.org/show_bug.cgi?id=13137

The attempts to fix this can be found here:
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/v4-7-s4u2proxy
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/v4-5-s4u2proxy

It will be a challenge to bring the fixes to our users
as it's currently completely untested code mostly.

metze

Am 28.10.2017 um 11:57 schrieb Andrew Bartlett via samba-technical:

> Thank you all for your contributions to this thread.  I think Michael
> covers the issue pretty well, so I'll follow up below:
>
> On Mon, 2017-10-23 at 11:05 +0200, Michael Adam wrote:
>> On 2017-10-20 at 11:56 -0700, Jeremy Allison via samba-technical wrote:
>>> So there's a tension here between the needs of distro's and the needs
>>> of vendors (I'm considering Catalyst via Andrew as a specific Samba
>>> vendor here).
>>>
>>> Distros need Samba to work with the libraries shipped with the distro.
>>> An "upstream first" policy for all dependent libraries is a must.
>>>
>>> Vendors need flexibility to add new features to both libraries and
>>> Samba to work with them. That sometimes means prototyping features
>>> and after customer approval getting the changes pushed upstream.
>>>
>>> I don't want a fork of MIT. No one wants to fork important security
>>> libraries anymore. I don't want to keep a copy of Heimdal anymore. I
>>> think we can all agree on this :-).
>>>
>>> Moving both Heimdal and MIT to a git reference to an external tree is
>>> a good idea.
>>>
>>> My guess is the difficulty comes from this statement in Andrew's
>>> email:
>>>
>>>> What I propose is:
>>>> - Our build system uses a git reference (via a submodule or otherwise)
>>>> to check out and build MIT krb5
>>>> - In Samba master, this tracks either:
>>>>   - MIT master
>>>>   - a "
>>>> - In Samba release branches this tracks:
>>>>   - the release branch, the released version of MIT krb5 that we will
>>>> support
>>>> - This occur in parallel to the Heimdal build
>>>
>>> what we need to determine is what "Samba vendor fork of
>>> MIT in limited circumstances" actually means.
>>>
>>> So long as this *doesn't* mean "a copy of MIT in our tree on samba.org"
>>> I hope we can come to some compromise we can agree on.
>>
>> I didn't understand Andrew as suggesting to put a copy of
>> MIT into our tree. He was talking about a (git) reference.
>> And I think this is perfectly fine, as Andreas said, for
>> development purposes.
>>
>> So what problem are we trying to solve?
>> The problem that the version of MIT kerberos
>> available on build systems that the devs are using
>> (e.g. for autobuild) varies greatly and is frequently
>> not up to the needs of current Samba.
>
> Yes, and that we need a way to automated this.  My team at Catalyst
> increasingly uses infrastructure as code (build hosts created
> dynamically in the cloud) and others use travis-ci via GitHub.  
>
> (BTW this transition alone is also an incredible opportunity, and one I
> hope others can get on board with soon.)
>
> Because fixing the install on one box won't help, we need a way to say
> 'use this version', and that in turn gives us a great advantage of
> being able to upgrade that version and use different versions for
> different builds (not a global one on sn-devel).
>
> It is important to be able to say that Samba 4.7 needs MIT version 1.9,
> but 4.8 needs 1.12 for example, and build against exactly those.  That
> way we don't accidentally backport use of a new feature without
> explicitly bumping the required version.
>
>> I see a point in abstracting our development
>> tree away from those dependencies by providing
>> a reference to a git tree of mit kerberos so that
>> we can build against this (at least optionally, if
>> the system does not provide sufficient krb support)
>> because krb is kind of special.
>
> Indeed, that is very important.  We once were held back to only using
> Kerberos features supported in Solaris (for example), and with the PAC
> etc have been on the leading edge of Kerberos features.  In a long-term
> where we finally ditch Heimdal, it is quite likely that our users will
> need a modern krb5 for Samba to build, even as a file server, and we
> should be able to provide it.  Naturally this happens even more often
> for a DC.
>
>> I.e. upstream Samba could be made autonomous by this.
>> This is to my understanding exclusively for the
>> convenience of developers.
>>
>> Any downstreams (i.e. vendors and distros) should (or rather
>> would want to) solve this problem differently by providing
>> the libs with the needed support in their system.
>> It should imho also be the default to build against an
>> external (system) krb lib. And the mode of first fetching
>> and building a krb version should be exclusive to
>> "developer" builds and should need to be triggered explicitly.
>>
>> I also don't think the vanilla upstream should ever reference
>> any vendor for of krb5, but only official trees. Referencing
>> vendor krb5-forks would be done in vendor forks of Samba...
>>
>> Finally, I think once this is implemented, we should do the
>> same with heimdal if possible: i.e. remove the checked out
>> copy and replace it by a git reference that can optionally
>> be used in developer builds....
>
> Yes, this is my hope.  It is a long road, but we need to get to a spot
> where developing new features, which may need to be done in tandem with
> upstream projects is equally confident, and where both are fully tested
> in autobuild.
>
> Just a few thoughts...
>>
>> Michael
>>
>>
>>> I see some hope in Andreas's reply here:
>>>
>>>>> What I propose is:
>>>>>  - Our build system uses a git reference (via a submodule or otherwise)
>>>>> to check out and build MIT krb5
>>>>
>>>> That's fine just for development!
>>>>>  - In Samba master, this tracks either:
>>>>>    - MIT master
>>>>>    - a Samba vendor fork of MIT in limited circumstances
>>>>
>>>> That's extremly bad! An enterprise distribution will not allow a vendor fork
>>>> of MIT Kerberos. You use what is in the system or not.
>>>
>>> Can we get some consensus on what "is fine for development" means
>>> to both of you ?
>>>
>>> Andreas, how do you see Andrew being able to add needed features
>>> to AD+MIT to move our MIT implementation forward ?
>>>
>>> Andrew, how do you see being able to separate this out from
>>> master so the distros can keep a supported Samba running against
>>> the default shipped and supported crypto libraries ?
>
> This is one of the most fraught parts of the challenge.  Suppose we do
> all the right thing, and add a new feature against either upstream
> master krb5, but then no release is made in time for our own releases.
>
> And even if the release is made, an enterprise distribution won't ship
> a new krb5 just for Samba, let along to support new Samba packages on
> old enterprise distributions like SerNet provides.  (Yet this is
> incredibly popular in our user communities).
>
> If we are ever going to make the transition to out-of-tree or even to
> just MIT, we need to crack this nut, provide something that an
> enterprise distribution can live with (pure system packages, but never
> update either krb5 or samba), our users can use (need newer, perhaps
> even patched krb5 with newer Samba), and our developers can develop
> against (need to do a trial autobuild against a proposed set of krb5
> patches).
>
> What we can't continue with is where the MIT build of the AD DC is not
> tested at all, where assuming a new version requires root@ to change
> sn-devel (let alone that this is not the only build platform in use),
> and where the model appears to be 'wait for a new MIT version to hit
> Fedora rawhide'.
>
> Thanks,
>
> Andrew Bartlett
>


signature.asc (853 bytes) Download Attachment
12