Skip to content
  • Simon McVittie's avatar
    spec: Update recommendations for DBUS_COOKIE_SHA1 timeouts · 3f8b2ce5
    Simon McVittie authored
    This had two issues that could damage interoperability.
    
    First, the spec wording suggested that any cookie that had not been
    deleted was suitable for use in authentication. However, this introduces
    a race condition, which is called out in comments in both the reference
    implementation and GDBus: the newest cookie might be less old than the
    arbitrary lifetime when authentication *begins*, but older than the
    lifetime at the time authentication *ends*. As a result, we need a grace
    period during which an old cookie will still be accepted, but a newer
    cookie exists and will be used for new authentication operations.
    
    Second, the spec wording implied that the arbitrary timeouts were
    completely up to the implementor. However, GLib bug
    https://gitlab.gnome.org/GNOME/glib/-/issues/2164
    
     indicates that they
    need to be reasonably compatible: in particular, GDBus servers
    historically didn't allocate new cookies until 10 minutes had passed,
    but libdbus clients would decline to use a cookie older than 5 minutes,
    causing authentication to fail if the gdbus-server test-case (in which
    GDBus and libdbus clients connect to a GDBus server) happened to take
    longer than 5 minutes to run.
    
    While I'm here, also be consistent about calling the secrets "cookies"
    (consistent with the name of the mechanism) rather than "keys" (which
    is what they are called in libdbus' dbus-keyring.c).
    
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    3f8b2ce5