From d4b870e7f91b7018524f7b85dc00b90cc64453bf Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Thu, 12 Dec 2002 04:26:46 +0000 Subject: 2002-12-11 Havoc Pennington * dbus/dbus-types.h: add dbus_unichar * dbus/dbus-internals.c (_dbus_verbose): use _dbus_getenv * dbus/dbus-connection.c (dbus_connection_send_message): return TRUE on success * dbus/dbus-transport.c: include dbus-watch.h * dbus/dbus-connection.c: include dbus-message-internal.h * HACKING: add file with coding guidelines stuff. * dbus/dbus-string.h, dbus/dbus-string.c: Encapsulate all string handling here, for security purposes (as in vsftpd). Not actually using this class yet. * dbus/dbus-sysdeps.h, dbus/dbus-sysdeps.c: Encapsulate all system/libc usage here, as in vsftpd, for ease of auditing (and should also simplify portability). Haven't actually moved all the system/libc usage into here yet. --- HACKING | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 HACKING (limited to 'HACKING') diff --git a/HACKING b/HACKING new file mode 100644 index 00000000..8d0b1756 --- /dev/null +++ b/HACKING @@ -0,0 +1,62 @@ +The guidelines in this file are the ideals; it's better to send a +not-fully-following-guidelines patch than no patch at all, though. We +can always polish it up. + +Mailing list +=== + +The D-BUS mailing list is message-bus-list@freedesktop.org; discussion +of patches, etc. should go there. + +Security +=== + +Most of D-BUS is security sensitive. Guidelines related to that: + + - avoid memcpy(), sprintf(), strlen(), snprintf, strlcat(), + strstr(), strtok(), or any of this stuff. Use DBusString. + If DBusString doesn't have the feature you need, add it + to DBusString. + + There are some exceptions, for example + if your strings are just used to index a hash table + and you don't do any parsing/modification of them, perhaps + DBusString is wasteful and wouldn't help much. But definitely + if you're doing any parsing, reallocation, etc. use DBusString. + + - do not include system headers outside of dbus-memory.c, + dbus-sysdeps.c, and other places where they are already + included. This gives us one place to audit all external + dependencies on features in libc, etc. + + - do not use libc features that are "complicated" + and may contain security holes. For example, you probably shouldn't + try to use regcomp() to compile an untrusted regular expression. + Regular expressions are just too complicated, and there are many + different libc's out there. + + - we need to design the message bus daemon (and any similar features) + to use limited privileges, run in a chroot jail, and so on. + +http://vsftpd.beasts.org/ has other good security suggestions. + +Coding Style +=== + + - The C library uses GNU coding conventions, with GLib-like + extensions (e.g. lining up function arguments). The + Qt wrapper uses KDE coding conventions. + + - Write docs for all non-static functions and structs and so on. try + "doxygen Doxyfile" prior to commit and be sure there are no + warnings printed. + + - All external interfaces (network protocols, file formats, etc.) + should have documented specifications sufficient to allow an + alternative implementation to be written. Our implementation should + be strict about specification compliance (should not for example + heuristically parse a file and accept not-well-formed + data). Avoiding heuristics is also important for security reasons; + if it looks funny, ignore it (or exit, or disconnect). + + -- cgit