[gnutls-help] Session resumption/unpack error while getting timestamp, expired sessions/db clean questions

[Jonathan Roudiere]

re Nikos,

>> Is GnuTLS should not remove session from cache/db in this case ? I
>> have patched GnuTLS in order to call the db_remove_func function from
>> _gnutls_server_restore_session(), I don't know if this hurt GnuTLS
>> design and should be done in another place or not at all (initially
>> patch was against _gnutls_session_unpack()).
>
> The idea is for the one having control of the DB to do periodical
> purges independently of
> gnutls'  usage. That is why gnutls_db_check_entry_time() is provided
> (at least that was the idea).
> Now about removing a session from _gnutls_server_restore_session(). I
> don't think this is good,
> a session may be resumed multiple times (e.g., a browser downloading
> different images from
> a server in several resumed sessions from the initial one).

Ok, but the module which has in charge to store sessions -- has to set
a lock if it is running in a multithread env and -- if a session isn't
useful anymore then why not removing it instead of waiting for looking
another time in the db, load the session, unpack it and to finally
don't resume session (in handshake). Of course, callback used to
retrieve sessions can do that itself (using
gnutls_db_check_entry_time()) but that (in my case) the expected
behaviour when callbacks are provided to remove session.

>> - Last question, expire_time is set on session itself so why it is not
>> packed with the session data in order to check it when session is
>> unpacked ? and to provide a function like gnutls_db_check_entry_time()
>> which will return remaining time or GNUTLS_E_EXPIRED.
>
> For simplicity. The idea of gnutls_db_check_entry_time() is to be
> called periodically for all
> stored sessions, so it would have to quickly determine the time of the
> session without any
> significant parsing.
>

Ok, in fact I speak about that because as expire_time is set on
session and in many case the module in charge of purging session from
cache db hasn't any idea of which lifetime time has been set
(especially in case of different expire_time per session
characteristics/purpose) else it's required to kept a global to known
expire_time.

Of course maybe I'm wrong that's just ideas.

Thank for your time,

regards,
Joe

> regards,
> Nikos