Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | 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. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | caps-doc |
Files: | files | file ages | folders |
SHA3-256: |
78ad8b749615fa5c21b9d4c72f78edf5 |
User & Date: | wyoung 2019-08-28 23:15:38.701 |
Context
2019-08-28
| ||
23:33 | Documented Public Pages and the default user capability set in www/caps/index.md. ... (check-in: 4671ddb1 user: wyoung tags: caps-doc) | |
23:15 | 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. ... (check-in: 78ad8b74 user: wyoung tags: caps-doc) | |
22:42 | Assorted small improvements to top-level caps doc ... (check-in: f21bfbee user: wyoung tags: caps-doc) | |
Changes
Changes to www/caps/impl.md.
︙ | ︙ | |||
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 | where the nanosecond differences in such implementation details are completely swamped by the millisecond scale ping time of that repo’s network connection, followed by the required I/O to satisfy the request. Either method is plenty fast in that context. In exchange for this immeasurable cost per hit, we get human-readable capability sets. ----- *[Back to Administering User Capabilities](./)* [for]: ./forum.wiki [mn]: https://en.wikipedia.org/wiki/Mnemonic [ref]: ./ref.html [sexp]: http://fossil-scm.org/fossil/artifact?udc=1&ln=1223-1298&name=889d6724 [sff]: http://fossil-scm.org/fossil/artifact?udc=1&ln=80-117&name=52d2860f [sc]: https://en.cppreference.com/w/c/string/byte/strchr [ucap]: ./index.md#ucap | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | 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 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 | where the nanosecond differences in such implementation details are completely swamped by the millisecond scale ping time of that repo’s network connection, followed by the required I/O to satisfy the request. Either method is plenty fast in that context. In exchange for this immeasurable cost per hit, we get human-readable capability sets. ## <a name="filter"></a>Why Doesn’t Fossil Filter “Bad” Artifacts on Sync? Fossil is more trusting about the content it receives from a remote clone during sync than you might expect. Common manifestations of this design choice are: 1. A user may be able to impersonate other users. This can be [accidental](./index.md#defuser) as well as purposeful. 2. If your local system clock is out-of-sync with absolute time, artifacts committed to that repo will appear with the “wrong” time when sync’d. If the time sync error is big enough, it can make check-ins appear to go back in time and other bad effects. 3. You can purposely overwrite good timestamps with bad ones and push those changes up to the remote with no interference, even though Fossil tries to make that a Setup-only operation. All of this falls out of two of Fossil’s design choices: sync is all-or-nothing, and [the Fossil block chain][bc] is immutable. Fossil would have to violate one or both of these principles to filter such problems out of incoming syncs. We have considered auto-[shunning][shun] “bad” content on sync, but this is [difficult][asd] due to [the design of the sync protocol][dsp]. This is not an impossible set of circumstances, but implementing a robust filter on this input path would be roughly as difficult as writing a basic [inter-frame video codec][ifvc]: do-able, but still a lot of work. Patches to do this will be thoughtfully considered. We can’t simply change content as it arrives. Such manipulations would change the artifact manifests, which would change the hashes, which would require rewriting all parts of the block chain from that point out to the tips of those branches. The local Fossil repo must then go through the same process as the remote one on subsequent syncs in order to build up a sync sequence that the remote can understand. Even if you’re willing to accept all of that, this would break all references to the old artifact IDs in forum posts, wiki articles, check-in comments, tickets, etc. The bottom line here is that [**Clone**](./ref.html#g) and [**Write**](./ref.html#i) are a potent combination of user capabilities. Be careful who you give that pair to! ----- *[Back to Administering User Capabilities](./)* <!-- add padding so anchor links always scroll ref’d section to top --> <div style="height: 75em"></div> [asd]: https://fossil-scm.org/forum/forumpost/ce4a3b5f3e [bc]: ../blockchain.md [dsp]: https://fossil-scm.org/fossil/doc/trunk/www/sync.wiki [for]: ./forum.wiki [ifvc]: https://en.wikipedia.org/wiki/Inter_frame [mn]: https://en.wikipedia.org/wiki/Mnemonic [ref]: ./ref.html [sexp]: http://fossil-scm.org/fossil/artifact?udc=1&ln=1223-1298&name=889d6724 [sff]: http://fossil-scm.org/fossil/artifact?udc=1&ln=80-117&name=52d2860f [sc]: https://en.cppreference.com/w/c/string/byte/strchr [shun]: ../shunning.wiki [ucap]: ./index.md#ucap |
Changes to www/caps/index.md.
︙ | ︙ | |||
218 219 220 221 222 223 224 | For example, if you clone someone else’s repo anonymously, turn off autosync, and make check-ins to that repository, they will be assigned to your OS user name by default. If you later get a login on the remote repository under a different name and sync your repo with it, your earlier “private” check-ins will get synced to the remote under your OS user name! | < < < < < < < < < | | < < < < < > | | 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 | For example, if you clone someone else’s repo anonymously, turn off autosync, and make check-ins to that repository, they will be assigned to your OS user name by default. If you later get a login on the remote repository under a different name and sync your repo with it, your earlier “private” check-ins will get synced to the remote under your OS user name! When such problems occur, you can amend the check-in to hide the incorrect name from Fossil reports, but the original values remain in the repository [forever][shun]. It is [difficult enough][fos] to fix such problems automatically during sync that we are unlikely to ever do so. [auo]: /help?cmd=new [fos]: ./impl.md#filter [shun]: ../shunning.wiki ## <a name="utclone"></a>Cloning the User Table When cloning over HTTP, the initial user table in the local clone is set |
︙ | ︙ | |||
290 291 292 293 294 295 296 297 298 299 300 301 302 303 | user][apsu] on both sides of the SSH connection. Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because the checks for capabilities like [**Read**][o] and [**Write**][i] are done against your effective Setup user on the other repo, the check only has an effect when done over an `http[s]://` URL. [ref]: ./ref.html [a]: ./ref.html#a [b]: ./ref.html#b [c]: ./ref.html#c [d]: ./ref.html#d | > > > | 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 | user][apsu] on both sides of the SSH connection. Fossil reuses the HTTP-based [sync protocol][sp] in both cases above, tunnelling HTTP through an OS pipe or through SSH (FIXME?), but because the checks for capabilities like [**Read**][o] and [**Write**][i] are done against your effective Setup user on the other repo, the check only has an effect when done over an `http[s]://` URL. <!-- add padding so anchor links always scroll ref’d section to top --> <div style="height: 75em"></div> [ref]: ./ref.html [a]: ./ref.html#a [b]: ./ref.html#b [c]: ./ref.html#c [d]: ./ref.html#d |
︙ | ︙ |