On 01/25/2013 12:45 AM, Simo Sorce wrote:
> On Wed, 2013-01-23 at 14:00 +0100, Tomas Babej wrote:
>> On 01/22/2013 07:39 PM, Dmitri Pal wrote:
>>> On 01/22/2013 10:57 AM, Simo Sorce wrote:
On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote:
> Here I bring the updated version of the patch
On Wed, 2013-01-23 at 14:00 +0100, Tomas Babej wrote:
> On 01/22/2013 07:39 PM, Dmitri Pal wrote:
> > On 01/22/2013 10:57 AM, Simo Sorce wrote:
> >> On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote:
> >>> Here I bring the updated version of the patch. Please note, that I
> >>> *added* a flag at
On 01/22/2013 07:39 PM, Dmitri Pal wrote:
On 01/22/2013 10:57 AM, Simo Sorce wrote:
On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote:
Here I bring the updated version of the patch. Please note, that I
*added* a flag attribute to ipadb_ldap_attr_to_krb5_timestamp
function, that controls whet
On 01/22/2013 10:57 AM, Simo Sorce wrote:
> On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote:
>> Here I bring the updated version of the patch. Please note, that I
>> *added* a flag attribute to ipadb_ldap_attr_to_krb5_timestamp
>> function, that controls whether the timestamp will be checked f
On Tue, 2013-01-22 at 15:50 +0100, Tomas Babej wrote:
> Here I bring the updated version of the patch. Please note, that I
> *added* a flag attribute to ipadb_ldap_attr_to_krb5_timestamp
> function, that controls whether the timestamp will be checked for
> overflow or not. The reasoning behind this
On 01/17/2013 05:18 PM, Simo Sorce wrote:
On Thu, 2013-01-17 at 15:29 +0100, Tomas Babej wrote:
On 01/17/2013 01:56 AM, Dmitri Pal wrote:
On 01/16/2013 12:32 PM, Tomas Babej wrote:
On 01/16/2013 06:01 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
On 01/16/2013
On Thu, 2013-01-17 at 15:29 +0100, Tomas Babej wrote:
> On 01/17/2013 01:56 AM, Dmitri Pal wrote:
>
> > On 01/16/2013 12:32 PM, Tomas Babej wrote:
> > > On 01/16/2013 06:01 PM, Simo Sorce wrote:
> > > > On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
> > > > > On 01/16/2013 02:47 PM, Simo
On 01/17/2013 01:56 AM, Dmitri Pal wrote:
On 01/16/2013 12:32 PM, Tomas Babej wrote:
On 01/16/2013 06:01 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
On 01/16/2013 02:47 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
On 01/15/2013 1
On Thu, 2013-01-17 at 01:16 +0100, Tomas Babej wrote:
> On 01/16/2013 06:57 PM, Simo Sorce wrote:
> > On Wed, 2013-01-16 at 18:32 +0100, Tomas Babej wrote:
> >
> They all use ipadb_ldap_attr_to_time_t() to get their values,
> so the following addition to the patch should be sufficient.
>
On 01/16/2013 12:32 PM, Tomas Babej wrote:
> On 01/16/2013 06:01 PM, Simo Sorce wrote:
>> On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
>>> On 01/16/2013 02:47 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
> On 01/15/2013 11:55 PM, Simo Sorce wrote:
>>
On 01/16/2013 06:57 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 18:32 +0100, Tomas Babej wrote:
They all use ipadb_ldap_attr_to_time_t() to get their values,
so the following addition to the patch should be sufficient.
It will break dates for other users of the function that do not need to
art
On Wed, 2013-01-16 at 18:32 +0100, Tomas Babej wrote:
> >> They all use ipadb_ldap_attr_to_time_t() to get their values,
> >> so the following addition to the patch should be sufficient.
> > It will break dates for other users of the function that do not need to
> > artificially limit the results.
On 01/16/2013 06:01 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
On 01/16/2013 02:47 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
On 01/15/2013 11:55 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
On 01
On Wed, 2013-01-16 at 17:57 +0100, Tomas Babej wrote:
> On 01/16/2013 02:47 PM, Simo Sorce wrote:
> > On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
> >> On 01/15/2013 11:55 PM, Simo Sorce wrote:
> >>> On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
> On 01/15/2013 03:59 PM, Simo S
On 01/16/2013 02:47 PM, Simo Sorce wrote:
On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
On 01/15/2013 11:55 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
On 01/15/2013 03:59 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
Dm
On Wed, 2013-01-16 at 12:52 +0100, Tomas Babej wrote:
> On 01/15/2013 11:55 PM, Simo Sorce wrote:
> > On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
> >> On 01/15/2013 03:59 PM, Simo Sorce wrote:
> >>> On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
> Dmitri Pal wrote:
> > O
On 01/15/2013 11:55 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
On 01/15/2013 03:59 PM, Simo Sorce wrote:
On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
Dmitri Pal wrote:
On 01/15/2013 08:48 AM, Simo Sorce wrote:
On Mon, 2013-01-14 at 16:46 +0100, Tom
On Tue, 2013-01-15 at 17:36 -0500, Dmitri Pal wrote:
> On 01/15/2013 03:59 PM, Simo Sorce wrote:
> > On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
> >> Dmitri Pal wrote:
> >>> On 01/15/2013 08:48 AM, Simo Sorce wrote:
> On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
> > H
On 01/15/2013 03:59 PM, Simo Sorce wrote:
> On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
>> Dmitri Pal wrote:
>>> On 01/15/2013 08:48 AM, Simo Sorce wrote:
On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
> Hi,
>
> Since in Kerberos V5 are used 32-bit unix timestam
On Tue, 2013-01-15 at 15:53 -0500, Rob Crittenden wrote:
> Dmitri Pal wrote:
> > On 01/15/2013 08:48 AM, Simo Sorce wrote:
> >> On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
> >>> Hi,
> >>>
> >>> Since in Kerberos V5 are used 32-bit unix timestamps, setting
> >>> maxlife in pwpolicy to valu
Dmitri Pal wrote:
On 01/15/2013 08:48 AM, Simo Sorce wrote:
On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
Hi,
Since in Kerberos V5 are used 32-bit unix timestamps, setting
maxlife in pwpolicy to values such as days would cause
integer overflow in krbPasswordExpiration attribute.
On 01/15/2013 08:48 AM, Simo Sorce wrote:
> On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
>> Hi,
>>
>> Since in Kerberos V5 are used 32-bit unix timestamps, setting
>> maxlife in pwpolicy to values such as days would cause
>> integer overflow in krbPasswordExpiration attribute.
>>
>> T
On Mon, 2013-01-14 at 16:46 +0100, Tomas Babej wrote:
> Hi,
>
> Since in Kerberos V5 are used 32-bit unix timestamps, setting
> maxlife in pwpolicy to values such as days would cause
> integer overflow in krbPasswordExpiration attribute.
>
> This would result into unpredictable behaviour suc
Hi,
Since in Kerberos V5 are used 32-bit unix timestamps, setting
maxlife in pwpolicy to values such as days would cause
integer overflow in krbPasswordExpiration attribute.
This would result into unpredictable behaviour such as users
not being able to log in after password expiration if pa
24 matches
Mail list logo
