ad.
This made me look in the repo and the upstream fix is now public:
https://github.com/heimdal/heimdal/commit/1a6a6e462dc2ac6111f9e02c6852ddec4849b887
Here is an issue with additional information:
https://github.com/heimdal/heimdal/issues/353
--
Patrik Lundin
On 2017-11-07 10:55:08, Patrik Lundin wrote:
> On 2017-11-06 13:08:25, Viktor Dukhovni wrote:
> >
> > See:
> >
> > https://github.com/heimdal/heimdal/commit/d2130e3312089a3142e89b316d2900fa21855726
> >
>
> Interesting! I notice that patch does not apply t
changed.
>
Thanks for setting the record straight, and sorry for the confusion on
my part.
Maby it is just me but I was surprised to have "get" not reflect the
actual contents in the database.
--
Patrik Lundin
On 2017-11-07 11:21:45, Roland C. Dowdeswell wrote:
> On Tue, Nov 07, 2017 at 10:55:08AM +0100, Patrik Lundin wrote:
> >
>
> > Additionally, I see that the prune code basically figures out the most
> > recent keyset timestamp that is older than the ticket maximum lifetime
On 2017-11-07 10:55:08, Patrik Lundin wrote:
>
> Would it make sense to alter the code to also remove that most recent
> (but too old) keyset? The only functional difference of the diff below
> is the "<" to "<=" change at the bottom, but it felt like it w
DB_Ext_KeySet(keys, i);
/*
* Removing the i'th element shifts the tail down, continue
===
I can open a PR at github if this makes sense to you. I have been able to test
it successfully against 7.4.0 at least.
--
Patrik Lundin
On 2017-11-06 17:55:05, Patrik Lundin wrote:
>
> While it can still be displayed with kadmin (and authenticated to with kinit)
> the dump and load will fail:
> ===
> root@kdc-lab-master1:~# kadmin -l load hdb-backup
> hdb-backup:2:error
m
with the kadmin load command. The fact that I am able to kinit with the
account (prior to dump/load where it disappears) makes me want to zero
in on the kadmin code.
--
Patrik Lundin
On 2017-10-12 11:38:57, Nico Williams wrote:
> On Thu, Oct 12, 2017 at 05:38:32PM +0200, Patrik Lundin wrote:
> >
> > To summarize this tread: The --reset flag should currently not be used
> > in a production systems since ipropd-master is unable to parse the
> > resul
y
will be at version 0, unable to reach version 2 via log entries
since version 1 was removed from the log in step #5.
Regards,
Patrik Lundin
case with the newly init'ed
database it will only update the timestamps on the initial uber record
and not touch any of the entries.
> >
> >That would be unfortunate ;-)
>
> it would, but truncating the log doesn't set the version to 0.
>
See above.
Regards,
Patrik Lundin
ot;.
Unless I am missing something this would mean that if something like the code
above was added back, truncating the log to version 0 would make all slaves
fetch the complete database over and over again until a modification bumps the
version at the master.
Regards,
Patrik Lundin
2:31
===
I am aware that iprop has gone through quite a lot of changes a while
back so I wonder if this might be a regression introduced then. Since
not even a fresh 'init' of the database will cause a log version number
of "0" I guess this will only be noticed once you attempt to do manual
resets.
Regards,
Patrik Lundin
s this means releases
prior to this date are safe from this specific DoS while it effects
everything since.
Do you have any idea when a new release fixing this will be made
available? I am just asking because it appears no official 7.x release
is suitable for use as a public facing KDC at this time.
Regards,
Patrik Lundin
log of old keys.
I know of no way to clean up old keys short of setting a new password
via kadmin where the --keepold flag is optional, and this is not really
doable for normal users.
Regards,
Patrik Lundin
15 matches
Mail list logo
