blob: 5e037e5275b38d0463489abe717e3ac3eaccb389 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Hacking PackageKit
Coding Style
------------
Please stick to the existing coding style.
Tabs should be hard (not expanded to spaces), and set equivalent to
8 spaces.
Please consider enabling git's default pre-commit hook:
$> cd PackageKit
$> chmod +x .git/hooks/pre-commit
This hook will run before every checkin, and check your changes for
suspicious use of whitespace.
In the C files use the following convention.
The number of spaces and tabs are very important!
/* map the roles to policykit rules */
if (role == PK_ROLE_ENUM_UPDATE_PACKAGE ||
role == PK_ROLE_ENUM_UPDATE_SYSTEM) {
policy = "org.freedesktop.packagekit.update";
} else if (role == PK_ROLE_ENUM_REMOVE_PACKAGE) {
policy = "org.freedesktop.packagekit.remove";
}
and please DO NOT use "!" for a null pointer or boolean - it's too easy to miss
in an audit...
/* check the search term */
ret = pk_engine_search_check (search, error);
if (ret == FALSE) {
return FALSE;
}
Functions are nearly always the same format, gtk-doc is optional:
/**
* pk_engine_search_name:
**/
gboolean
pk_engine_search_name (PkEngine *engine, const gchar *search, GError **error)
{
gboolean ret;
PkTransactionItem *item;
g_return_val_if_fail (engine != NULL, FALSE);
g_return_val_if_fail (PK_IS_ENGINE (engine), FALSE);
return TRUE;
}
Finally: DO NOT COMMIT TRAILING WHITESPACE.
Security
--------
Remember:
* The daemon is running as the root user
- no FIXME or TODO code please
* If the daemon crashes, then that's a DOS
* Text from the user (over the dbus interface) is insecure!
- even filters and enumerated values can be wrong
- users can use dbus-send to do bad stuff as users
* Never allocate a buffer on user input
* Output from backends is trusted, they are run from standard locations
Use flawfinder to find obvious security problems. Use "ITS4: ignore" if you are
totally 100% sure that it's not a problem.
Submitting Patches
------------------
Use 'git format-patch' to generate patches against a checked out copy
of the source.
For Example:
$> cd PackageKit
HACK HACK HACK
$> git commit -m "My first commit"
HACK HACK HACK
$> git commit -m "My second commit"
$> git format-patch -M HEAD^^
0001-My-first-commit.patch
0002-My-second-commit.patch
Send these patches in an introductory email as attachments to
packagekit-list@lists.freedesktop.org
|
