|
1
|
# Fossil Push Policy |
|
2
|
|
|
3
|
"Fossil Push Policy" or "FPP" is a proposed mechanism to help project |
|
4
|
administrators help enforce project development policies by restricting |
|
5
|
the kinds of changes that can be pushed up into a community server. |
|
6
|
|
|
7
|
## Background |
|
8
|
|
|
9
|
The default behavior of Fossil is that any developer who has push |
|
10
|
privileges on a repository can push any content. Project-specific |
|
11
|
policy choices, such as "don't land unapproved changes on trunk" |
|
12
|
or "don't reopen a closed ticket" are enforced administratively, not |
|
13
|
by Fossil itself. Fossil maintains a detailed audit trail so that policy |
|
14
|
violations can be traced back to their source, and so that |
|
15
|
violators can be duly reprimanded. Fossil also provides mechanisms |
|
16
|
so that unapproved changes can be excised from critical branches without |
|
17
|
deleting history. But by default, Fossil |
|
18
|
does not attempt to disallow unauthorized changes from occurring in the |
|
19
|
first place. |
|
20
|
|
|
21
|
Nothing can prevent a developer from making non-conforming and/or |
|
22
|
unauthorized change in a private client-side clone of a Fossil repository |
|
23
|
since the client-side repository is under the complete control of the |
|
24
|
developer who owns it. |
|
25
|
Any automatic policy enforcement must happen on the common repository |
|
26
|
when the developer attempts to push. |
|
27
|
|
|
28
|
FPP is *not* a security mechanism. FPP is not intended to allow |
|
29
|
untrusted individuals to push to a common repository. FPP does not |
|
30
|
guarantee that no undesirable changes ever get pushed. Rather, FPP |
|
31
|
is designed as an administrative aid and an automatic mechanism to prevent |
|
32
|
accidents or misunderstandings. |
|
33
|
|
|
34
|
## Example Use Cases |
|
35
|
|
|
36
|
Here are examples of the kinds of pushes that FPP is designed to prevent |
|
37
|
for unauthorized users: |
|
38
|
|
|
39
|
* Do not allow check-ins on trunk (or some other |
|
40
|
important branch). |
|
41
|
|
|
42
|
* Do not allow changes to specific files within |
|
43
|
the project. |
|
44
|
|
|
45
|
* Do not allow changes to specific wiki pages. |
|
46
|
|
|
47
|
* Do not allow changes to tickets unless the ticket is in specific |
|
48
|
state. |
|
49
|
|
|
50
|
* Do not allow new branches unless the branch name |
|
51
|
matches a specific GLOB, LIKE, or REGEXP pattern. |
|
52
|
|
|
53
|
* Do not allow tags to be added to a check-in created by a different |
|
54
|
developer. |
|
55
|
|
|
56
|
The foregoing is not an exhaustive list of the kinds of behavior that FPP |
|
57
|
is intended to detect and prevent; it is just a representative sample of |
|
58
|
the kinds of changes FPP is able to detect and disallow. |
|
59
|
|
|
60
|
Rules can be written such that they apply only to specific users, |
|
61
|
user classes — e.g. “developer” — or to everyone other than administrators. |
|
62
|
Administrators can also be subject to FPP rules, though they have the |
|
63
|
option to override. |
|
64
|
|
|
65
|
## Mechanism |
|
66
|
|
|
67
|
FPP is a set of rules contained in a single configuration setting. |
|
68
|
The rules consist of paired Boolean expressions and error messages. |
|
69
|
At the end of each push request received by the server, all |
|
70
|
expressions are evaluated, and if any are true, the push |
|
71
|
fails with its associated error message. |
|
72
|
|
|
73
|
If a push fails, the end user will have to repair their local repository |
|
74
|
clone before retrying the push. For example, if the trunk branch is |
|
75
|
protected by FPP, they can amend their commit to make it appear as the |
|
76
|
start of a new branch off trunk, at which point the push should succeed. |
|
77
|
This is a serious inconvenience to the developer who violated the |
|
78
|
policy, but this is intentional, intended to motivate the developer |
|
79
|
to better follow the rules in the future. |
|
80
|
|
|
81
|
## Client Side Warnings |
|
82
|
|
|
83
|
FPP rules are downloaded on a "fossil clone" and on "fossil config pull fpp". |
|
84
|
When rules exist on the client side, then certain client-side operations |
|
85
|
(such as "fossil commit") |
|
86
|
are also evaluated for rule violations, and appropriate warnings are issued. |
|
87
|
However, for client-side operations, rules can always be overridden, since |
|
88
|
the owner of the client-side clone is always administrator for their private |
|
89
|
clone. Early rule check-in helps prevent the client-side repository |
|
90
|
from becoming unpushable due to typos or other accidents that would have |
|
91
|
caused a rule violation. |
|
92
|
|