Fossil

Check-in [78ad8b74]
Login

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: 78ad8b749615fa5c21b9d4c72f78edf5e15a23266d461fede1aa1a447f9442ce
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
Unified Diff Ignore Whitespace Patch
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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242

243
244
245
246
247
248
249
250
251
252
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!

This is unavoidable because those check-ins are already written durably
to [the local Fossil block chain][bc]. Changing a check-in’s user name
during sync would require rewriting parts of that block chain, which
then means it isn’t actually a “sync” protocol. Either the local and
remote clones would be different or the check-in IDs would change as the
artifacts get rewritten. That in turn means all references to the old
IDs in check-in comments, wiki articles, forum posts, tickets, and more
would break.

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].

This does mean that anyone with check-in rights on your repository can
impersonate any Fossil user in those check-ins. They check in their work
under any name they like locally, then upon sync, those names are
transferred as-is to the remote repository. Be careful who you give
check-in rights to!


[auo]:  /help?cmd=new
[bc]:   ../blockchain.md
[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







<
<
<
<
<
<
<
<
<


|
|
<
<
<
<
<
>


|







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