Fossil SCM
Moved the discussion about inadvertent attribution of artifacts and the problems with easy solutions to the problem into the implementation details section of the new caps docs and expanded it to cover recent forum discussions.
Commit
78ad8b749615fa5c21b9d4c72f78edf5e15a23266d461fede1aa1a447f9442ce
Parent
f21bfbeede1755a…
2 files changed
+54
+7
-17
+54
| --- www/caps/impl.md | ||
| +++ www/caps/impl.md | ||
| @@ -41,17 +41,71 @@ | ||
| 41 | 41 | network connection, followed by the required I/O to satisfy the request. |
| 42 | 42 | Either method is plenty fast in that context. |
| 43 | 43 | |
| 44 | 44 | In exchange for this immeasurable cost per hit, we get human-readable |
| 45 | 45 | capability sets. |
| 46 | + | |
| 47 | + | |
| 48 | +## <a name="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? | |
| 49 | + | |
| 50 | +Fossil is more trusting about the content it receives from a remote | |
| 51 | +clone during sync than you might expect. Common manifestations of this | |
| 52 | +design choice are: | |
| 53 | + | |
| 54 | +1. A user may be able to impersonate other users. This can be | |
| 55 | + [accidental](./index.md#defuser) as well as purposeful. | |
| 56 | + | |
| 57 | +2. If your local system clock is out-of-sync with absolute time, | |
| 58 | + artifacts committed to that repo will appear with the “wrong” time | |
| 59 | + when sync’d. If the time sync error is big enough, it can make | |
| 60 | + check-ins appear to go back in time and other bad effects. | |
| 61 | + | |
| 62 | +3. You can purposely overwrite good timestamps with bad ones and push | |
| 63 | + those changes up to the remote with no interference, even though | |
| 64 | + Fossil tries to make that a Setup-only operation. | |
| 65 | + | |
| 66 | +All of this falls out of two of Fossil’s design choices: sync is | |
| 67 | +all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil | |
| 68 | +would have to violate one or both of these principles to filter such | |
| 69 | +problems out of incoming syncs. | |
| 70 | + | |
| 71 | +We have considered auto-[shunning][shun] “bad” content on sync, but this | |
| 72 | +is [difficult][asd] due to [the design of the sync protocol][dsp]. This | |
| 73 | +is not an impossible set of circumstances, but implementing a robust | |
| 74 | +filter on this input path would be roughly as difficult as writing a | |
| 75 | +basic [inter-frame video codec][ifvc]: do-able, but still a lot of | |
| 76 | +work. Patches to do this will be thoughtfully considered. | |
| 77 | + | |
| 78 | +We can’t simply change content as it arrives. Such manipulations would | |
| 79 | +change the artifact manifests, which would change the hashes, which | |
| 80 | +would require rewriting all parts of the block chain from that point out | |
| 81 | +to the tips of those branches. The local Fossil repo must then go | |
| 82 | +through the same process as the remote one on subsequent syncs in order | |
| 83 | +to build up a sync sequence that the remote can understand. Even if | |
| 84 | +you’re willing to accept all of that, this would break all references to | |
| 85 | +the old artifact IDs in forum posts, wiki articles, check-in comments, | |
| 86 | +tickets, etc. | |
| 87 | + | |
| 88 | +The bottom line here is that [**Clone**](./ref.html#g) and | |
| 89 | +[**Write**](./ref.html#i) are a potent combination of user capabilities. | |
| 90 | +Be careful who you give that pair to! | |
| 91 | + | |
| 46 | 92 | |
| 47 | 93 | ----- |
| 48 | 94 | |
| 49 | 95 | *[Back to Administering User Capabilities](./)* |
| 50 | 96 | |
| 97 | +<!-- add padding so anchor links always scroll ref’d section to top --> | |
| 98 | +<div style="height: 75em"></div> | |
| 99 | + | |
| 100 | +[asd]: https://fossil-scm.org/forum/forumpost/ce4a3b5f3e | |
| 101 | +[bc]: ../blockchain.md | |
| 102 | +[dsp]: https://fossil-scm.org/fossil/doc/trunk/www/sync.wiki | |
| 51 | 103 | [for]: ./forum.wiki |
| 104 | +[ifvc]: https://en.wikipedia.org/wiki/Inter_frame | |
| 52 | 105 | [mn]: https://en.wikipedia.org/wiki/Mnemonic |
| 53 | 106 | [ref]: ./ref.html |
| 54 | 107 | [sexp]: http://fossil-scm.org/fossil/artifact?udc=1&ln=1223-1298&name=889d6724 |
| 55 | 108 | [sff]: http://fossil-scm.org/fossil/artifact?udc=1&ln=80-117&name=52d2860f |
| 56 | 109 | [sc]: https://en.cppreference.com/w/c/string/byte/strchr |
| 110 | +[shun]: ../shunning.wiki | |
| 57 | 111 | [ucap]: ./index.md#ucap |
| 58 | 112 |
| --- www/caps/impl.md | |
| +++ www/caps/impl.md | |
| @@ -41,17 +41,71 @@ | |
| 41 | network connection, followed by the required I/O to satisfy the request. |
| 42 | Either method is plenty fast in that context. |
| 43 | |
| 44 | In exchange for this immeasurable cost per hit, we get human-readable |
| 45 | capability sets. |
| 46 | |
| 47 | ----- |
| 48 | |
| 49 | *[Back to Administering User Capabilities](./)* |
| 50 | |
| 51 | [for]: ./forum.wiki |
| 52 | [mn]: https://en.wikipedia.org/wiki/Mnemonic |
| 53 | [ref]: ./ref.html |
| 54 | [sexp]: http://fossil-scm.org/fossil/artifact?udc=1&ln=1223-1298&name=889d6724 |
| 55 | [sff]: http://fossil-scm.org/fossil/artifact?udc=1&ln=80-117&name=52d2860f |
| 56 | [sc]: https://en.cppreference.com/w/c/string/byte/strchr |
| 57 | [ucap]: ./index.md#ucap |
| 58 |
| --- www/caps/impl.md | |
| +++ www/caps/impl.md | |
| @@ -41,17 +41,71 @@ | |
| 41 | network connection, followed by the required I/O to satisfy the request. |
| 42 | Either method is plenty fast in that context. |
| 43 | |
| 44 | In exchange for this immeasurable cost per hit, we get human-readable |
| 45 | capability sets. |
| 46 | |
| 47 | |
| 48 | ## <a name="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? |
| 49 | |
| 50 | Fossil is more trusting about the content it receives from a remote |
| 51 | clone during sync than you might expect. Common manifestations of this |
| 52 | design choice are: |
| 53 | |
| 54 | 1. A user may be able to impersonate other users. This can be |
| 55 | [accidental](./index.md#defuser) as well as purposeful. |
| 56 | |
| 57 | 2. If your local system clock is out-of-sync with absolute time, |
| 58 | artifacts committed to that repo will appear with the “wrong” time |
| 59 | when sync’d. If the time sync error is big enough, it can make |
| 60 | check-ins appear to go back in time and other bad effects. |
| 61 | |
| 62 | 3. You can purposely overwrite good timestamps with bad ones and push |
| 63 | those changes up to the remote with no interference, even though |
| 64 | Fossil tries to make that a Setup-only operation. |
| 65 | |
| 66 | All of this falls out of two of Fossil’s design choices: sync is |
| 67 | all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil |
| 68 | would have to violate one or both of these principles to filter such |
| 69 | problems out of incoming syncs. |
| 70 | |
| 71 | We have considered auto-[shunning][shun] “bad” content on sync, but this |
| 72 | is [difficult][asd] due to [the design of the sync protocol][dsp]. This |
| 73 | is not an impossible set of circumstances, but implementing a robust |
| 74 | filter on this input path would be roughly as difficult as writing a |
| 75 | basic [inter-frame video codec][ifvc]: do-able, but still a lot of |
| 76 | work. Patches to do this will be thoughtfully considered. |
| 77 | |
| 78 | We can’t simply change content as it arrives. Such manipulations would |
| 79 | change the artifact manifests, which would change the hashes, which |
| 80 | would require rewriting all parts of the block chain from that point out |
| 81 | to the tips of those branches. The local Fossil repo must then go |
| 82 | through the same process as the remote one on subsequent syncs in order |
| 83 | to build up a sync sequence that the remote can understand. Even if |
| 84 | you’re willing to accept all of that, this would break all references to |
| 85 | the old artifact IDs in forum posts, wiki articles, check-in comments, |
| 86 | tickets, etc. |
| 87 | |
| 88 | The bottom line here is that [**Clone**](./ref.html#g) and |
| 89 | [**Write**](./ref.html#i) are a potent combination of user capabilities. |
| 90 | Be careful who you give that pair to! |
| 91 | |
| 92 | |
| 93 | ----- |
| 94 | |
| 95 | *[Back to Administering User Capabilities](./)* |
| 96 | |
| 97 | <!-- add padding so anchor links always scroll ref’d section to top --> |
| 98 | <div style="height: 75em"></div> |
| 99 | |
| 100 | [asd]: https://fossil-scm.org/forum/forumpost/ce4a3b5f3e |
| 101 | [bc]: ../blockchain.md |
| 102 | [dsp]: https://fossil-scm.org/fossil/doc/trunk/www/sync.wiki |
| 103 | [for]: ./forum.wiki |
| 104 | [ifvc]: https://en.wikipedia.org/wiki/Inter_frame |
| 105 | [mn]: https://en.wikipedia.org/wiki/Mnemonic |
| 106 | [ref]: ./ref.html |
| 107 | [sexp]: http://fossil-scm.org/fossil/artifact?udc=1&ln=1223-1298&name=889d6724 |
| 108 | [sff]: http://fossil-scm.org/fossil/artifact?udc=1&ln=80-117&name=52d2860f |
| 109 | [sc]: https://en.cppreference.com/w/c/string/byte/strchr |
| 110 | [shun]: ../shunning.wiki |
| 111 | [ucap]: ./index.md#ucap |
| 112 |
+7
-17
| --- www/caps/index.md | ||
| +++ www/caps/index.md | ||
| @@ -220,31 +220,18 @@ | ||
| 220 | 220 | to your OS user name by default. If you later get a login on the remote |
| 221 | 221 | repository under a different name and sync your repo with it, your |
| 222 | 222 | earlier “private” check-ins will get synced to the remote under your OS |
| 223 | 223 | user name! |
| 224 | 224 | |
| 225 | -This is unavoidable because those check-ins are already written durably | |
| 226 | -to [the local Fossil block chain][bc]. Changing a check-in’s user name | |
| 227 | -during sync would require rewriting parts of that block chain, which | |
| 228 | -then means it isn’t actually a “sync” protocol. Either the local and | |
| 229 | -remote clones would be different or the check-in IDs would change as the | |
| 230 | -artifacts get rewritten. That in turn means all references to the old | |
| 231 | -IDs in check-in comments, wiki articles, forum posts, tickets, and more | |
| 232 | -would break. | |
| 233 | - | |
| 234 | 225 | When such problems occur, you can amend the check-in to hide the |
| 235 | 226 | incorrect name from Fossil reports, but the original values remain in |
| 236 | -the repository [forever][shun]. | |
| 237 | - | |
| 238 | -This does mean that anyone with check-in rights on your repository can | |
| 239 | -impersonate any Fossil user in those check-ins. They check in their work | |
| 240 | -under any name they like locally, then upon sync, those names are | |
| 241 | -transferred as-is to the remote repository. Be careful who you give | |
| 242 | -check-in rights to! | |
| 227 | +the repository [forever][shun]. It is [difficult enough][fos] to fix | |
| 228 | +such problems automatically during sync that we are unlikely to ever do | |
| 229 | +so. | |
| 243 | 230 | |
| 244 | 231 | [auo]: /help?cmd=new |
| 245 | -[bc]: ../blockchain.md | |
| 232 | +[fos]: ./impl.md#filter | |
| 246 | 233 | [shun]: ../shunning.wiki |
| 247 | 234 | |
| 248 | 235 | |
| 249 | 236 | |
| 250 | 237 | ## <a name="utclone"></a>Cloning the User Table |
| @@ -292,10 +279,13 @@ | ||
| 292 | 279 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 293 | 280 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because |
| 294 | 281 | the checks for capabilities like [**Read**][o] and [**Write**][i] are |
| 295 | 282 | done against your effective Setup user on the other repo, the check only |
| 296 | 283 | has an effect when done over an `http[s]://` URL. |
| 284 | + | |
| 285 | +<!-- add padding so anchor links always scroll ref’d section to top --> | |
| 286 | +<div style="height: 75em"></div> | |
| 297 | 287 | |
| 298 | 288 | [ref]: ./ref.html |
| 299 | 289 | |
| 300 | 290 | [a]: ./ref.html#a |
| 301 | 291 | [b]: ./ref.html#b |
| 302 | 292 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -220,31 +220,18 @@ | |
| 220 | to your OS user name by default. If you later get a login on the remote |
| 221 | repository under a different name and sync your repo with it, your |
| 222 | earlier “private” check-ins will get synced to the remote under your OS |
| 223 | user name! |
| 224 | |
| 225 | This is unavoidable because those check-ins are already written durably |
| 226 | to [the local Fossil block chain][bc]. Changing a check-in’s user name |
| 227 | during sync would require rewriting parts of that block chain, which |
| 228 | then means it isn’t actually a “sync” protocol. Either the local and |
| 229 | remote clones would be different or the check-in IDs would change as the |
| 230 | artifacts get rewritten. That in turn means all references to the old |
| 231 | IDs in check-in comments, wiki articles, forum posts, tickets, and more |
| 232 | would break. |
| 233 | |
| 234 | When such problems occur, you can amend the check-in to hide the |
| 235 | incorrect name from Fossil reports, but the original values remain in |
| 236 | the repository [forever][shun]. |
| 237 | |
| 238 | This does mean that anyone with check-in rights on your repository can |
| 239 | impersonate any Fossil user in those check-ins. They check in their work |
| 240 | under any name they like locally, then upon sync, those names are |
| 241 | transferred as-is to the remote repository. Be careful who you give |
| 242 | check-in rights to! |
| 243 | |
| 244 | [auo]: /help?cmd=new |
| 245 | [bc]: ../blockchain.md |
| 246 | [shun]: ../shunning.wiki |
| 247 | |
| 248 | |
| 249 | |
| 250 | ## <a name="utclone"></a>Cloning the User Table |
| @@ -292,10 +279,13 @@ | |
| 292 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 293 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because |
| 294 | the checks for capabilities like [**Read**][o] and [**Write**][i] are |
| 295 | done against your effective Setup user on the other repo, the check only |
| 296 | has an effect when done over an `http[s]://` URL. |
| 297 | |
| 298 | [ref]: ./ref.html |
| 299 | |
| 300 | [a]: ./ref.html#a |
| 301 | [b]: ./ref.html#b |
| 302 |
| --- www/caps/index.md | |
| +++ www/caps/index.md | |
| @@ -220,31 +220,18 @@ | |
| 220 | to your OS user name by default. If you later get a login on the remote |
| 221 | repository under a different name and sync your repo with it, your |
| 222 | earlier “private” check-ins will get synced to the remote under your OS |
| 223 | user name! |
| 224 | |
| 225 | When such problems occur, you can amend the check-in to hide the |
| 226 | incorrect name from Fossil reports, but the original values remain in |
| 227 | the repository [forever][shun]. It is [difficult enough][fos] to fix |
| 228 | such problems automatically during sync that we are unlikely to ever do |
| 229 | so. |
| 230 | |
| 231 | [auo]: /help?cmd=new |
| 232 | [fos]: ./impl.md#filter |
| 233 | [shun]: ../shunning.wiki |
| 234 | |
| 235 | |
| 236 | |
| 237 | ## <a name="utclone"></a>Cloning the User Table |
| @@ -292,10 +279,13 @@ | |
| 279 | Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, |
| 280 | tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because |
| 281 | the checks for capabilities like [**Read**][o] and [**Write**][i] are |
| 282 | done against your effective Setup user on the other repo, the check only |
| 283 | has an effect when done over an `http[s]://` URL. |
| 284 | |
| 285 | <!-- add padding so anchor links always scroll ref’d section to top --> |
| 286 | <div style="height: 75em"></div> |
| 287 | |
| 288 | [ref]: ./ref.html |
| 289 | |
| 290 | [a]: ./ref.html#a |
| 291 | [b]: ./ref.html#b |
| 292 |