diff options
author | Havoc Pennington <hp@redhat.com> | 2003-04-18 17:45:34 +0000 |
---|---|---|
committer | Havoc Pennington <hp@redhat.com> | 2003-04-18 17:45:34 +0000 |
commit | d3fb6f35716ff1d6f6644dea2043d539007811de (patch) | |
tree | 46716f651f7e3d1ab87d427ac192de409aafb28a /doc | |
parent | e0b284c7e38f0c002b2173d85ab89dc18700867c (diff) |
2003-04-18 Havoc Pennington <hp@pobox.com>
* dbus/dbus-auth.c (record_mechanisms): memleak fixes
* dbus/dbus-sysdeps.c (_dbus_string_save_to_file): fix some
memleaks
* dbus/dbus-keyring.c (add_new_key): fix a memleak, and
on realloc be sure to update the pointer in the keyring
* dbus/dbus-string.c (_dbus_string_zero): compensate for align
offset to avoid writing to unallocated memory
* dbus/dbus-auth.c (process_rejected): return FALSE if we fail to
try the next mechanism, so we properly handle OOM
* dbus/dbus-keyring.c (_dbus_keyring_new_homedir): fix double-free
on OOM.
(_dbus_keyring_new): fix OOM bug
(_dbus_keyring_new_homedir): always set error; impose a maximum
number of keys we'll load from the file, mostly to speed up the
test suite and make its OOM checks more useful, but also for
general sanity.
* dbus/dbus-auth.c (process_error_server): reject authentication
if we get an error from the client
(process_cancel): on cancel, send REJECTED, per the spec
(process_error_client): send CANCEL if we get an error from the
server.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/dbus-specification.sgml | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/doc/dbus-specification.sgml b/doc/dbus-specification.sgml index 02feed3f..ad3b9adc 100644 --- a/doc/dbus-specification.sgml +++ b/doc/dbus-specification.sgml @@ -606,9 +606,13 @@ command present or permitted only in new protocol versions, and if an ERROR is received instead of an appropriate response, fall back to using some other technique. - </para><para> - If an ERROR is sent, the server or client MUST continue as if the - command causing the ERROR had never been received. + </para> + <para> + If an ERROR is sent, the server or client that sent the + error MUST continue as if the command causing the ERROR had never been + received. However, the the server or client receiving the error + should try something other than whatever caused the error; + if only canceling/rejecting the authentication. </para> </sect2> <sect2 id="auth-examples"> |