On Wed, 22 Aug 2012 14:24:20 +0200 rustyBSD said:
> Le 22/08/2012 14:12, Tom Hacohen a écrit :
> > On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
> >> On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen
> >> said:
> >>
> >>> On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
> >>>
ah if only we had C11 support available...
On Wed, Aug 22, 2012 at 1:24 PM, rustyBSD wrote:
> Le 22/08/2012 14:12, Tom Hacohen a écrit :
> > On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
> >> On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen
> said:
> >>
> >>> On 22/08/12 14:51, Carst
Le 22/08/2012 14:12, Tom Hacohen a écrit :
> On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
>> On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen
>> said:
>>
>>> On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen
said:
in related noticings, the return of _desklock_auth() at e_desklock.c:849 is
not used; problem?
On Wed, Aug 22, 2012 at 1:12 PM, Tom Hacohen wrote:
> On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen
> said:
> >
> >> On 22/08/12 14:51, C
On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen said:
>
>> On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen
>>> said:
>>>
To be honest, I don't know how secure we can get
On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen said:
> On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen
> > said:
> >
> >> To be honest, I don't know how secure we can get there because of entry.
> >> We only free (without explicitly e
On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen said:
>
>> To be honest, I don't know how secure we can get there because of entry.
>> We only free (without explicitly erasing) the buffers used internally by
>> entry (elm+edje) and textbl
On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen said:
> To be honest, I don't know how secure we can get there because of entry.
> We only free (without explicitly erasing) the buffers used internally by
> entry (elm+edje) and textblock, so there might be cleartext copies of
> the pass in memor
To be honest, I don't know how secure we can get there because of entry.
We only free (without explicitly erasing) the buffers used internally by
entry (elm+edje) and textblock, so there might be cleartext copies of
the pass in memory anyway...
--
Tom.
On 22/08/12 14:30, Carsten Haitzler (The
On Wed, 22 Aug 2012 12:57:10 +0200 rustyBSD said:
> == src/bin/e_desklock.c ==
> during auth, user's password may be written
> to disk (core dump). To avoid that, the solution
> is to limit core file size to 0 with|| setrlimit(). The
> problem is that once set to 0, the file size can't
> be raise
On Wed, 22 Aug 2012 12:57:10 +0200 rustyBSD said:
> == src/bin/e_desklock.c ==
> during auth, user's password may be written
> to disk (core dump). To avoid that, the solution
> is to limit core file size to 0 with|| setrlimit(). The
> problem is that once set to 0, the file size can't
> be raise
== src/bin/e_desklock.c ==
during auth, user's password may be written
to disk (core dump). To avoid that, the solution
is to limit core file size to 0 with|| setrlimit(). The
problem is that once set to 0, the file size can't
be raised; so we can't reset the size to the value
it was before.
Here
12 matches
Mail list logo
