Heimdal 1.6

classic Classic list List threaded Threaded
61 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Heimdal 1.6

Jelmer Vernooij-2
Hello,

What are the current plans for Heimdal 1.6, is there a roadmap for a
stable 1.6.0 ?

At the moment we're shipping a 1.6 release candidate of Heimdal in Debian,
because Samba 4 required features only present post-1.5 [1]. Since we're going to
switch Samba in Debian over to using its bundled copy of Heimdal in Debian [2],
I am wondering what we should do with the main Heimdal package. It would be
nice to be back on a stable Heimdal version by the next Debian release.

Cheers,

Jelmer

[1] Our expectation was that 1.6.0 would be released well ahead of Debian's freeze.
[2] http://lists.alioth.debian.org/pipermail/pkg-samba-maint/2015-May/017379.html
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Nico Williams
On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
> What are the current plans for Heimdal 1.6, is there a roadmap for a
> stable 1.6.0 ?

There will be a 1.7 release, skipping over 1.6, and soon to be branched
from master.

Speaking for myself, few changes are needed to make a 1.7, and perhaps
we could make a 1.7rc1 now (Jeff?  Love?):

 - finish my iprop improvements
 - do something about RAND_bytes() (it requires locks, but Heimdal can't
   initialize OpenSSL lock callbacks, so when Heimdal is the first user
   of OpenSSL in a process, it's then not MT-safe)
 - improve KDC timout fallback strategy

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Stefan (metze) Metzmacher
Am 04.06.2015 um 18:25 schrieb Nico Williams:

> On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
>> What are the current plans for Heimdal 1.6, is there a roadmap for a
>> stable 1.6.0 ?
>
> There will be a 1.7 release, skipping over 1.6, and soon to be branched
> from master.
>
> Speaking for myself, few changes are needed to make a 1.7, and perhaps
> we could make a 1.7rc1 now (Jeff?  Love?):
>
>  - finish my iprop improvements
>  - do something about RAND_bytes() (it requires locks, but Heimdal can't
>    initialize OpenSSL lock callbacks, so when Heimdal is the first user
>    of OpenSSL in a process, it's then not MT-safe)
>  - improve KDC timout fallback strategy
It would be great to get changes from Samba merged back to upstream
before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
but there's a bit more I'm currently working on and hopefully be finished
shortly.

metze


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

Re: Heimdal 1.6

Quanah Gibson-Mount-3
In reply to this post by Nico Williams
--On Thursday, June 04, 2015 12:25 PM -0500 Nico Williams
<[hidden email]> wrote:

> On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
>> What are the current plans for Heimdal 1.6, is there a roadmap for a
>> stable 1.6.0 ?
>
> There will be a 1.7 release, skipping over 1.6, and soon to be branched
> from master.
>
> Speaking for myself, few changes are needed to make a 1.7, and perhaps
> we could make a 1.7rc1 now (Jeff?  Love?):
>
>  - finish my iprop improvements
>  - do something about RAND_bytes() (it requires locks, but Heimdal can't
>    initialize OpenSSL lock callbacks, so when Heimdal is the first user
>    of OpenSSL in a process, it's then not MT-safe)
>  - improve KDC timout fallback strategy

Has Heimdal been fixed now so that a library only build can be done?  The
process for building just the libraries (basically so that I can provide
gssapi support to cyrus-sasl) is rather tedious with 1.5.x:

        $(MAKE) -C include
        $(MAKE) -C base
        $(MAKE) -C lib/roken
        $(MAKE) -C lib/vers
        $(MAKE) -C lib/com_err
        $(MAKE) -C lib/asn1
        $(MAKE) -C lib/libedit
        $(MAKE) -C lib/sl
        $(MAKE) -C lib/hcrypto
        $(MAKE) -C lib/wind
        $(MAKE) -C lib/hx509
        $(MAKE) -C lib/sqlite
        $(MAKE) -C lib/ipc
        $(MAKE) -C lib/krb5
        $(MAKE) -C lib/ntlm
        $(MAKE) -C lib/gssapi

Also, I generally see some issues with man page installation during builds
from lib/gssapi:

/usr/bin/install -c -m 644 ./mech/mech.cat5
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/cat5/mech/mech.5
ln: failed to access
'/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/man5/mech/mech.5':
No such file or directory
ln: failed to create symbolic link
'/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/man5/mech.5':
File exists
cp: cannot stat
'/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/man5/mech/mech.5':
No such file or directory
ln -f
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/cat5/mech/mech.5
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/cat5/mech.5
ln: failed to access
'/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/man5/mech/mech.5':
No such file or directory
ln -s mech/mech.5
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/man5/qop.5
ln -f
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/cat5/mech/mech.5
/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/debian/tmp/opt/zimbra/common/share/man/cat5/qop.5
make[6]: Leaving directory
`/home/build/p4/zimbra/main/ThirdParty/heimdal/zimbra-heimdal/lib/gssapi'


I don't know if those have been fixed since 1.5.3?

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Andrew Bartlett
In reply to this post by Stefan (metze) Metzmacher
On Thu, 2015-06-04 at 21:16 +0200, Stefan (metze) Metzmacher wrote:

> Am 04.06.2015 um 18:25 schrieb Nico Williams:
> > On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
> >> What are the current plans for Heimdal 1.6, is there a roadmap for a
> >> stable 1.6.0 ?
> >
> > There will be a 1.7 release, skipping over 1.6, and soon to be branched
> > from master.
> >
> > Speaking for myself, few changes are needed to make a 1.7, and perhaps
> > we could make a 1.7rc1 now (Jeff?  Love?):
> >
> >  - finish my iprop improvements
> >  - do something about RAND_bytes() (it requires locks, but Heimdal can't
> >    initialize OpenSSL lock callbacks, so when Heimdal is the first user
> >    of OpenSSL in a process, it's then not MT-safe)
> >  - improve KDC timout fallback strategy
>
> It would be great to get changes from Samba merged back to upstream
> before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
> but there's a bit more I'm currently working on and hopefully be finished
> shortly.

Thanks metze, I was about to ask the same.

My current work for Heimdal is at:
https://github.com/abartlet/heimdal/tree/lorikeet-heimdal-201505130438-plus-lorikeet-heimdal-patches

The attempt to get Samba to use it is at
https://git.samba.org/abartlet/samba.git/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/import-lorikeet-heimdal-201505130638

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: Heimdal 1.6

Nico Williams
In reply to this post by Stefan (metze) Metzmacher
On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
> It would be great to get changes from Samba merged back to upstream
> before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
> but there's a bit more I'm currently working on and hopefully be finished
> shortly.

OK.  I'm looking at this now.  Comments:

 - https://github.com/abartlet/heimdal/commit/4ae2ee50b843f4ecc3748c3e3e3fa41c7fdf8b88

   What compiler is complaining about this?

 - https://github.com/abartlet/heimdal/commit/aed6e73231c5a3aa5cd3fd000749eb3af626b190

   Why terminate at the first incorrect PA?  Shouldn't we try all of
   them?  It would be better to write:

1622     krb5_error_code ret = 0;
1623     krb5_error_code pa_ret = 0;
...
1784             if (pa) {
1785                 ret = pat[n].validate(r, pa);
1786                 if (ret)
1787                     pa_ret = ret;
1788                 if (ret == 0) {
1789                     kdc_log(context, config, 0,
1790                             "%s pre-authentication succeeded -- %s",
1791                             pat[n].name, r->client_name);
1792                     found_pa = 1;
1793                     r->et.flags.pre_authent = 1;
1794                 }
1795             }
1796         }
1797         if (!found_pa) {
1798             ret = pa_ret;
1799             if (ret)
1800                 goto out;
1801         }
1802     }
1803
1804     if (found_pa == 0) {

   ?

   This way we still try all the PAs and keep the last failed PA's error
   code and message.  But we get to try all of them.

I think that's all I got.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Andrew Bartlett
On Thu, 2015-06-04 at 17:48 -0500, Nico Williams wrote:

> On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
> > It would be great to get changes from Samba merged back to upstream
> > before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
> > but there's a bit more I'm currently working on and hopefully be finished
> > shortly.
>
> OK.  I'm looking at this now.  Comments:
>
>  - https://github.com/abartlet/heimdal/commit/4ae2ee50b843f4ecc3748c3e3e3fa41c7fdf8b88
>
>    What compiler is complaining about this?

The commit comes from Samba, where we compile with -Werror and
-Wuninitialised et all, but I don't have the exact combination recorded.
The background is that Volker has been combining those with -O3 and
finding many similar issues.  After some nasty use of un-initilaised
variable bugs in Samba, we are becoming quite strict on this.  Sadly
many of the patches don't apply upstream (see the reverts in the samba
branch I linked to), but this is one of the few that did.

>  - https://github.com/abartlet/heimdal/commit/aed6e73231c5a3aa5cd3fd000749eb3af626b190
>
>    Why terminate at the first incorrect PA?  Shouldn't we try all of
>    them?  It would be better to write:
>
> 1622     krb5_error_code ret = 0;
> 1623     krb5_error_code pa_ret = 0;
> ...
> 1784             if (pa) {
> 1785                 ret = pat[n].validate(r, pa);
> 1786                 if (ret)
> 1787                     pa_ret = ret;
> 1788                 if (ret == 0) {
> 1789                     kdc_log(context, config, 0,
> 1790                             "%s pre-authentication succeeded -- %s",
> 1791                             pat[n].name, r->client_name);
> 1792                     found_pa = 1;
> 1793                     r->et.flags.pre_authent = 1;
> 1794                 }
> 1795             }
> 1796         }
> 1797         if (!found_pa) {
> 1798             ret = pa_ret;
> 1799             if (ret)
> 1800                 goto out;
> 1801         }
> 1802     }
> 1803
> 1804     if (found_pa == 0) {
>
>    ?
>
>    This way we still try all the PAs and keep the last failed PA's error
>    code and message.  But we get to try all of them.

If a user sending multiple passwords (ENC-CHAL and ENC-TS) in one
request, should we really be trying them both?  

What is the meaning of a request with PK-INIT, ENC-CHAL and ENC-TS, and
if we are going support more than one at once, will you write a test to
keep the behaviour consistent?  

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: Heimdal 1.6

Nico Williams
On Fri, Jun 05, 2015 at 11:48:56AM +1200, Andrew Bartlett wrote:

> On Thu, 2015-06-04 at 17:48 -0500, Nico Williams wrote:
> > On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
> > > It would be great to get changes from Samba merged back to upstream
> > > before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
> > > but there's a bit more I'm currently working on and hopefully be finished
> > > shortly.
> >
> > OK.  I'm looking at this now.  Comments:
> >
> >  - https://github.com/abartlet/heimdal/commit/4ae2ee50b843f4ecc3748c3e3e3fa41c7fdf8b88
> >
> >    What compiler is complaining about this?
>
> The commit comes from Samba, where we compile with -Werror and
> -Wuninitialised et all, but I don't have the exact combination recorded.
> The background is that Volker has been combining those with -O3 and
> finding many similar issues.  After some nasty use of un-initilaised
> variable bugs in Samba, we are becoming quite strict on this.  Sadly
> many of the patches don't apply upstream (see the reverts in the samba
> branch I linked to), but this is one of the few that did.

I get that, and I'm not surprised _a_ compiler did complain about this,
but I was curious as to which compiler complained.

> >  - https://github.com/abartlet/heimdal/commit/aed6e73231c5a3aa5cd3fd000749eb3af626b190
> >
> >    Why terminate at the first incorrect PA?  Shouldn't we try all of
> >    them?  It would be better to write:
> >
> > 1622     krb5_error_code ret = 0;
> > 1623     krb5_error_code pa_ret = 0;
> > ...
> > 1784             if (pa) {
> > 1785                 ret = pat[n].validate(r, pa);
> > 1786                 if (ret)
> > 1787                     pa_ret = ret;
> > 1788                 if (ret == 0) {
> > 1789                     kdc_log(context, config, 0,
> > 1790                             "%s pre-authentication succeeded -- %s",
> > 1791                             pat[n].name, r->client_name);
> > 1792                     found_pa = 1;
> > 1793                     r->et.flags.pre_authent = 1;
> > 1794                 }
> > 1795             }
> > 1796         }
> > 1797         if (!found_pa) {
> > 1798             ret = pa_ret;
> > 1799             if (ret)
> > 1800                 goto out;
> > 1801         }
> > 1802     }
> > 1803
> > 1804     if (found_pa == 0) {
> >
> >    ?
> >
> >    This way we still try all the PAs and keep the last failed PA's error
> >    code and message.  But we get to try all of them.
>
> If a user sending multiple passwords (ENC-CHAL and ENC-TS) in one
> request, should we really be trying them both?  
>
> What is the meaning of a request with PK-INIT, ENC-CHAL and ENC-TS, and
> if we are going support more than one at once, will you write a test to
> keep the behaviour consistent?  

I hadn't realized that no pseudo-PAs have validate() methods.  Indeed,
this patch is fine.

Thanks,

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Andreas Schneider
In reply to this post by Nico Williams
On Thursday 04 June 2015 11:25:41 Nico Williams wrote:

> On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
> > What are the current plans for Heimdal 1.6, is there a roadmap for a
> > stable 1.6.0 ?
>
> There will be a 1.7 release, skipping over 1.6, and soon to be branched
> from master.
>
> Speaking for myself, few changes are needed to make a 1.7, and perhaps
> we could make a 1.7rc1 now (Jeff?  Love?):
>
>  - finish my iprop improvements
>  - do something about RAND_bytes() (it requires locks, but Heimdal can't
>    initialize OpenSSL lock callbacks, so when Heimdal is the first user
>    of OpenSSL in a process, it's then not MT-safe)
>  - improve KDC timout fallback strategy

If someone is still working on Heimdal and wants to add features, here is a
hack to get RC4 working with gss_wrap_iov()

https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-gss_wrap_iov

The rc4-hmac stuff for gss_wrap_iov() is working for the DCERPC
case but an important feature missing for this is the lack of support for
GSS_IOV_BUFFER_TYPE_STREAM.


Cheers,


        -- andreas


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

Reply | Threaded
Open this post in threaded view
|

Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Andrew Bartlett
In reply to this post by Nico Williams

On Thu, 2015-06-04 at 22:45 -0500, Nico Williams wrote:
> On Fri, Jun 05, 2015 at 11:48:56AM +1200, Andrew Bartlett wrote:
> > On Thu, 2015-06-04 at 17:48 -0500, Nico Williams wrote:
> > > On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
> > > > It would be great to get changes from Samba merged back to upstream
> > > > before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
> > > > but there's a bit more I'm currently working on and hopefully be finished
> > > > shortly.

> I hadn't realized that no pseudo-PAs have validate() methods.  Indeed,
> this patch is fine.

So, what do I need to do to get this reviewed and merged?

There is more significance to this than just a few stray patches.  Samba
is at a cross-roads here - we started using and developing Heimdal
because we had an interactive development relationship with Love, and we
got a lot of great things done in a short period of time.

We maintained (and to some extent still maintain, which is why we have
the patches above) a branch of Heimdal with some samba-specific patches
that we called lorikeet-heimdal.  We have been working to reduce the
number of additional patches to zero, and I think we are close.

That tree was periodically copied into Samba, but sadly the last import
was quite some time ago.  Since then, there has been a very strong push
to have MIT Kerberos support added to Samba, and the team involved there
is very close to having a working set of patches.

This leads us to the cross-roads I mention above.  The level of
integration we have with a Kerberos library in Samba is quite extreme,
given we have to provide KDC database libraries etc.  Additionally
having Heimdal in-tree has become a burden, so I'm really keen to move
to just using a verified upstream Kerberos release, installed on the
target system.

The question is, can Heimdal support that role?  If we had to make
changes to Heimdal for a new feature, could we expect the patches to be
merged (given these patches haven't been)?  

Otherwise, do we wait for the RedHat work to have us work with MIT
Kerberos, and when we do, should we try to support both a modern MIT and
and a 5 year old in-tree Heimdal, or just switch to MIT?  

I realise this sounds like an ultimatum, but I feel we need to openly
discuss this, and also hear from the Heimdal community about how we
should be better participants.

Thanks,

Andrew Bartlett

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






--
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: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Nico Williams
On Wed, Jun 17, 2015 at 5:02 AM, Andrew Bartlett <[hidden email]> wrote:
> So, what do I need to do to get this reviewed and merged?

I'm building, testing, and pushing.  Sorry about that.  I was
traveling last week and let this drop.

Nico
--
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive

Jeffrey Altman-2
In reply to this post by Andrew Bartlett
On 6/17/2015 6:02 AM, Andrew Bartlett wrote:

>
> On Thu, 2015-06-04 at 22:45 -0500, Nico Williams wrote:
>> On Fri, Jun 05, 2015 at 11:48:56AM +1200, Andrew Bartlett wrote:
>>> On Thu, 2015-06-04 at 17:48 -0500, Nico Williams wrote:
>>>> On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
>>>>> It would be great to get changes from Samba merged back to upstream
>>>>> before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
>>>>> but there's a bit more I'm currently working on and hopefully be finished
>>>>> shortly.
>
>> I hadn't realized that no pseudo-PAs have validate() methods.  Indeed,
>> this patch is fine.
>
> So, what do I need to do to get this reviewed and merged?
For one, patience.  Unlike MIT Kerberos there are no developers whose
primary job is to work on Heimdal.  Those that work on Heimdal do so in
their spare time or as funding permits.

> There is more significance to this than just a few stray patches.  Samba
> is at a cross-roads here - we started using and developing Heimdal
> because we had an interactive development relationship with Love, and we
> got a lot of great things done in a short period of time.
>
> We maintained (and to some extent still maintain, which is why we have
> the patches above) a branch of Heimdal with some samba-specific patches
> that we called lorikeet-heimdal.  We have been working to reduce the
> number of additional patches to zero, and I think we are close.
>
> That tree was periodically copied into Samba, but sadly the last import
> was quite some time ago.  Since then, there has been a very strong push
> to have MIT Kerberos support added to Samba, and the team involved there
> is very close to having a working set of patches.
>
> This leads us to the cross-roads I mention above.  The level of
> integration we have with a Kerberos library in Samba is quite extreme,
> given we have to provide KDC database libraries etc.  Additionally
> having Heimdal in-tree has become a burden, so I'm really keen to move
> to just using a verified upstream Kerberos release, installed on the
> target system.
>
> The question is, can Heimdal support that role?  If we had to make
> changes to Heimdal for a new feature, could we expect the patches to be
> merged (given these patches haven't been)?  
>
> Otherwise, do we wait for the RedHat work to have us work with MIT
> Kerberos, and when we do, should we try to support both a modern MIT and
> and a 5 year old in-tree Heimdal, or just switch to MIT?  
>
> I realise this sounds like an ultimatum, but I feel we need to openly
> discuss this, and also hear from the Heimdal community about how we
> should be better participants.
>
> Thanks,
>
> Andrew Bartlett
I cannot speak to what Samba should or should not do.  Your File
System's AuriStor File System and OpenAFS also have very strong
dependencies on Kerberos.  We attempt to use the OS provided Kerberos
when possible but have found that for many platforms we wish to support
including OSX, Windows and various Linux distributions that the
necessary functionality is not exported or otherwise available.  As such
we must provide a private Kerberos install and for that we have selected
Heimdal.  To support that Your File System staff submits changes to
Heimdal and funds the development of the Windows port.  That  being said
YFS does not have the resources to promptly review, test commit and
package third party submissions.

Many of the other active contributors are funded by organizations that
rely upon Heimdal for internal use but do not require formal packaged
releases.  As such, they too cannot provide the resources to promptly
review, test and package Heimdal releases.

If I had my preference there would be no lorikeet-heimdal fork and Samba
would strictly work from the Heimdal Git repository.  AuriStor and
OpenAFS pull the required subsets of the Heimdal git repo into our
respective repositories and only permit upstream submissions for
externally maintained code.  Is that something that Samba would consider
doing?

Jeffrey Altman




smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Andrew Bartlett
In reply to this post by Nico Williams
On Wed, 2015-06-17 at 17:42 -0500, Nico Williams wrote:
> On Wed, Jun 17, 2015 at 5:02 AM, Andrew Bartlett <[hidden email]>
> wrote:
> > So, what do I need to do to get this reviewed and merged?
>
> I'm building, testing, and pushing.  Sorry about that.  I was
> traveling last week and let this drop.

On a more meta level, what are the current, correct procedures for
submitting patches?  Are github pull requests the preferred method?

Thanks,

Andrew Bartlett

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






Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive

Jeffrey Altman-2
On 6/17/2015 7:11 PM, Andrew Bartlett wrote:

> On Wed, 2015-06-17 at 17:42 -0500, Nico Williams wrote:
>> On Wed, Jun 17, 2015 at 5:02 AM, Andrew Bartlett <[hidden email]>
>> wrote:
>>> So, what do I need to do to get this reviewed and merged?
>>
>> I'm building, testing, and pushing.  Sorry about that.  I was
>> traveling last week and let this drop.
>
> On a more meta level, what are the current, correct procedures for
> submitting patches?  Are github pull requests the preferred method?
github pull requests are the best method we have at the moment.

Jeffrey Altman




smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Nico Williams
In reply to this post by Andrew Bartlett
On Wed, Jun 17, 2015 at 10:02:34PM +1200, Andrew Bartlett wrote:
> So, what do I need to do to get this reviewed and merged?

Merged.  (I'd already reviewed.)
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive

Andrew Bartlett
In reply to this post by Jeffrey Altman-2
On Wed, 2015-06-17 at 19:09 -0400, Jeffrey Altman wrote:
>
> If I had my preference there would be no lorikeet-heimdal fork and
> Samba
> would strictly work from the Heimdal Git repository.  AuriStor and
> OpenAFS pull the required subsets of the Heimdal git repo into our
> respective repositories and only permit upstream submissions for
> externally maintained code.  Is that something that Samba would
> consider
> doing?

Yes, we are trying to get to that point.  I would like to go further
and be able to rely on releases (as Debian will only package as
release, and packaging policies are very strict on not having bundled
libraries), but this is the first step I'm trying to get to.

Currently I'm blocked on a double-counting of bad passwords I need to
chase down, and then to do the required testing with Windows.

Thanks,

Andrew Bartlett

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






Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Paul Robert Marino
In reply to this post by Nico Williams
Well Red Hat probably won't budge on the whole MIT kerberos thing because of freeIPA they have hard coded it to MIT kerberos in LDAP ( specificly 389 server) the real catch point for Red Hat is that the database schema for the two in LDAP are different. Also last I looked at the code they were actually calling the kadmin command in places to work around in some of the upstream python modules to work around issues they had with the libraries.

Supposedly Red Hat was supposed to have done all the work needed on the MIT Kerberos side last year but I think they found it was a bigger hurdle than they originally thought.

The good news is Heimdal is now in EPEL and fedora. If the effort with FreeIPA  can be swung to utilize Heimdal as an option as well then I think all of Red Hats objections will go away.

Most of the big things they didn't like about Heimdal such as custom versions of some libraries to work around known bugs have been resolved by pushing the changes to the upstream projects which is why they have finally allowed it in EPEL and Fedora.

  Original Message  
From: Nico Williams‎
Sent: Wednesday, June 17, 2015 19:22
To: Andrew Bartlett
Reply To: [hidden email]
Cc: [hidden email]; Stefan (metze) Metzmacher; Jelmer Vernooij
Subject: Re: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

On Wed, Jun 17, 2015 at 10:02:34PM +1200, Andrew Bartlett wrote:
> So, what do I need to do to get this reviewed and merged?

Merged. (I'd already reviewed.)
Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive (was: Re: Heimdal 1.6)

Henry B Hotz
In reply to this post by Andrew Bartlett
I may want to add to the workload by submitting patches, but I’ve no time to review patches. Sorry.

On Jun 17, 2015, at 3:02 AM, Andrew Bartlett <[hidden email]> wrote:

> On Thu, 2015-06-04 at 22:45 -0500, Nico Williams wrote:
>> On Fri, Jun 05, 2015 at 11:48:56AM +1200, Andrew Bartlett wrote:
>>> On Thu, 2015-06-04 at 17:48 -0500, Nico Williams wrote:
>>>> On Thu, Jun 04, 2015 at 09:16:47PM +0200, Stefan (metze) Metzmacher wrote:
>>>>> It would be great to get changes from Samba merged back to upstream
>>>>> before 1.7rc1. See https://github.com/heimdal/heimdal/pull/129 for a start,
>>>>> but there's a bit more I'm currently working on and hopefully be finished
>>>>> shortly.
>
>> I hadn't realized that no pseudo-PAs have validate() methods.  Indeed,
>> this patch is fine.
>
> So, what do I need to do to get this reviewed and merged?
>
> There is more significance to this than just a few stray patches.  Samba
> is at a cross-roads here - we started using and developing Heimdal
> because we had an interactive development relationship with Love, and we
> got a lot of great things done in a short period of time.
>
> We maintained (and to some extent still maintain, which is why we have
> the patches above) a branch of Heimdal with some samba-specific patches
> that we called lorikeet-heimdal.  We have been working to reduce the
> number of additional patches to zero, and I think we are close.
>
> That tree was periodically copied into Samba, but sadly the last import
> was quite some time ago.  Since then, there has been a very strong push
> to have MIT Kerberos support added to Samba, and the team involved there
> is very close to having a working set of patches.
>
> This leads us to the cross-roads I mention above.  The level of
> integration we have with a Kerberos library in Samba is quite extreme,
> given we have to provide KDC database libraries etc.  Additionally
> having Heimdal in-tree has become a burden, so I'm really keen to move
> to just using a verified upstream Kerberos release, installed on the
> target system.
>
> The question is, can Heimdal support that role?  If we had to make
> changes to Heimdal for a new feature, could we expect the patches to be
> merged (given these patches haven't been)?  
>
> Otherwise, do we wait for the RedHat work to have us work with MIT
> Kerberos, and when we do, should we try to support both a modern MIT and
> and a 5 year old in-tree Heimdal, or just switch to MIT?  
>
> I realise this sounds like an ultimatum, but I feel we need to openly
> discuss this, and also hear from the Heimdal community about how we
> should be better participants.
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team         http://samba.org
> Samba Development and Support, Catalyst IT   http://catalyst.net.nz/services/samba
>
>
>
>
>
>
> --
> Andrew Bartlett                       http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
>
>

Personal email.  [hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.7, Samba4 and keeping Heimdal alive

Dewayne
In reply to this post by Paul Robert Marino
Thank-you for that very useful update.

As an aside, I've been using heimdal for 10 years in FreeBSD ;)

Cheers, Dewayne.

Reply | Threaded
Open this post in threaded view
|

Re: Heimdal 1.6

Stefan (metze) Metzmacher
In reply to this post by Andreas Schneider
Am 15.06.2015 um 17:54 schrieb Andreas Schneider:

> On Thursday 04 June 2015 11:25:41 Nico Williams wrote:
>> On Thu, Jun 04, 2015 at 03:36:09PM +0000, Jelmer Vernooij wrote:
>>> What are the current plans for Heimdal 1.6, is there a roadmap for a
>>> stable 1.6.0 ?
>>
>> There will be a 1.7 release, skipping over 1.6, and soon to be branched
>> from master.
>>
>> Speaking for myself, few changes are needed to make a 1.7, and perhaps
>> we could make a 1.7rc1 now (Jeff?  Love?):
>>
>>  - finish my iprop improvements
>>  - do something about RAND_bytes() (it requires locks, but Heimdal can't
>>    initialize OpenSSL lock callbacks, so when Heimdal is the first user
>>    of OpenSSL in a process, it's then not MT-safe)
>>  - improve KDC timout fallback strategy
>
> If someone is still working on Heimdal and wants to add features, here is a
> hack to get RC4 working with gss_wrap_iov()
>
> https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-gss_wrap_iov
>
> The rc4-hmac stuff for gss_wrap_iov() is working for the DCERPC
> case but an important feature missing for this is the lack of support for
> GSS_IOV_BUFFER_TYPE_STREAM.
I have improved that a bit and make sure it works with Samba.

Together with some additional changes required for cross-forest trusts
the changes
can be found under (and attached)
https://git.samba.org/?p=metze/heimdal/wip.git;a=shortlog;h=refs/heads/heimdal-for-upstream

The Samba branch can be found here:

https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-forest-ok
and
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master4-forest-tmp

I'll do some testing against Windows DCs later this week.

metze

heimdal-for-upstream-01.patches.txt (93K) Download Attachment
signature.asc (205 bytes) Download Attachment
1234