When possible, please submit patches and requests for review via GitHub
as a pull request. This will ensure the patch is not lost and provides
the ability to apply comments both on the pull request as well as
comment inline to the patch.
The patch will be tested by the Continuous Integration sys
I may have not yet shared my final version of the patch which gives
the user as much error message(s) that are extractable from both the
context and the return code:
$ diff -u error_string.c.orig error_string.c
--- error_string.c.orig 2017-07-11 07:14:16.0 +0200
+++ error_string.c 20
On Thu, Oct 05, 2017 at 08:01:00PM +0200, Harald Barth wrote:
> I may have found it! The 1.5.X KDC has a mile long function
> _kdc_as_rep() which in the middle somewhere has
>
> e_text = "No ENC-TS found";
Ahh, ok, got it.
Nico
--
> I looked for that and couldn't find it.
I may have found it! The 1.5.X KDC has a mile long function
_kdc_as_rep() which in the middle somewhere has
e_text = "No ENC-TS found";
That function looks quite different in 7.X
> So, to reproduce just mark a principal as expired and try to kinit
On Thu, Oct 05, 2017 at 12:28:29PM -0400, Jeffrey Hutzelman wrote:
> Both, I think. kinit (and other clients) ought to report something
> like "error_message (e_text)", unless the e_text is empty or the same
> as the message for the error code. of course, more complex variations
> are possible, wha
On Thu, Oct 05, 2017 at 12:06:51PM -0400, Greg Hudson wrote:
> If my theory is correct, the KDC is sending unhelpful e_text and/or
> Heimdal is too trusting in using the e_text in preference to the string
> corresponding to the error code. In this case, concatenating the error
> code string with t
On October 5, 2017 12:06:51 PM EDT, Greg Hudson wrote:
>On 10/05/2017 07:52 AM, Harald Barth wrote:
>> And because the return code ret is the same as the error_code in the
>> context, krb5_get_error_message() just copies the string from the
>> context. However, if krb5_get_error_message() does its
On 10/05/2017 07:52 AM, Harald Barth wrote:
> And because the return code ret is the same as the error_code in the
> context, krb5_get_error_message() just copies the string from the
> context. However, if krb5_get_error_message() does its own lookup of
> -1765328383 it gets "Client's entry in data
On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote:
> I'm currently looking at why kinit can not give a decent error message
> on the easy fact that a credential has expired. Well, now with 7.4.0
> it handles "password expired" but "principal expired" still gives:
So, to reproduce just m
On Thu, Oct 05, 2017 at 10:37:26AM +0200, Harald Barth wrote:
> I'm currently looking at why kinit can not give a decent error message
> on the easy fact that a credential has expired. Well, now with 7.4.0
> it handles "password expired" but "principal expired" still gives:
>
> kinit: krb5_get_ini
I wrote:
> + strncat(cstr, ", ", sizeof(buf));
> + return strdup(strncat(cstr, str, sizeof(buf)));
which is broken and buggy usage of strncat(), so don't copy that.
Harald.
Well, I' making some progress.
The context I get when krb5_init_creds_get() returns is
$23 = {etypes = 0x0, cfg_etypes = 0x0, etypes_des = 0x0, as_etypes = 0x0,
tgs_etypes = 0x0, permitted_enctypes = 0x0, default_realms = 0x0,
max_skew = 300, kdc_timeout = 30, host_timeout = 3, max_retries
I'm currently looking at why kinit can not give a decent error message
on the easy fact that a credential has expired. Well, now with 7.4.0
it handles "password expired" but "principal expired" still gives:
kinit: krb5_get_init_creds: No ENC-TS found
which is very broken from a user support grou
13 matches
Mail list logo
