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.
+ 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
+ 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
+ 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
+ - 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"
+ - 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
+ 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)
- check out a fresh copy from Git
- - verify that the libtool versioning/library soname is
+ - verify that the libtool versioning/library soname is
changed if it needs to be, or not changed if not
- update the file NEWS based on the git history
previous release. Note that bullet points for each of the changelog
items must be indented three more spaces to conform to the
formatting of the other releases there.
-
+
- post to dbus@lists.freedesktop.org announcing the release.
-
+
Making a ".0" stable release
===
reviews and approves
- for fixes that do affect API or protocol, two people
- in the reviewer group have to review and approve the commit, and
+ in the reviewer group have to review and approve the commit, and
posting to the list is definitely mandatory
- if there's a live unresolved controversy about a change,
- make check must pass
- the test suite must be extended to cover the new code
as much as reasonably feasible (see Tests above)
- - the patch has to follow the portability, security, and
+ - the patch has to follow the portability, security, and
style guidelines
- - the patch should as much as reasonable do one thing,
+ - the patch should as much as reasonable do one thing,
not many unrelated changes
No reviewer should approve a patch without these attributes, and
failure on these points is grounds for reverting the patch.