Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch fossil-as-blockchain Excluding Merge-Ins
This is equivalent to a diff from 991b089925 to 87b1385dac
2020-10-11
| ||
06:51 | Greatly expanded the simple definition of "blockchain" in the eponymous doc to include more details of common blockchain implementations to draw clearer parallels. This causes our conclusion to flip around from the prior version of this doc, but it's worth keeping the doc because it serves to compare and contrast Fossil to other systems. check-in: 1ddb400886 user: wyoung tags: trunk | |
2020-10-08
| ||
08:48 | Drew better analogies between Bitcoin's answer to the 51% attack and to GitHub in the new Anonymity section of the blockchain doc to show that Fossil doesn't even try to provide the sorts of behavior that allow fully anonymous contribution to a blockchain. Closed-Leaf check-in: 87b1385dac user: wyoung tags: fossil-as-blockchain | |
08:10 | Added a para to the prior section. check-in: 69e0ea54a7 user: wyoung tags: fossil-as-blockchain | |
07:04 | Small clarity fix in the new CAP theorem doc check-in: 8a9facbb3e user: wyoung tags: trunk | |
04:11 | Merged trunk changes in check-in: 95203913c0 user: wyoung tags: fossil-as-blockchain | |
04:11 | Added fragment identifiers to the new CAP theorem doc. check-in: 991b089925 user: wyoung tags: trunk | |
2020-10-07
| ||
07:07 | Removed an extraneous space from pikchrshow DOM output. pikchr command error output now prepends a newline to pikchr-level errors to keep line number comment alignment intact for the first line. check-in: c3b2671f6d user: stephan tags: trunk | |
Changes to www/blockchain.md.
|
| | | > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > | > > > | > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > | > > | > > > > > > > > > > > > > | | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > | > > > > | > > > > > > > > | > > | | | > > | > > | > > > > > > > > | > | > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > | 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 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 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 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 | # Is Fossil A Blockchain? The Fossil version control system shares a lot of similarities with other blockchain based technologies, but it also differs from the more common sorts of blockchains. This document will discuss the term’s applicability, so you can decide whether applying the term to Fossil makes sense to you. ## The Dictionary Argument The [Wikipedia definition of "blockchain"][bcwp] begins: > "A blockchain…is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree)." By that partial definition, Fossil is indeed a blockchain. The blocks are Fossil’s ["manifest" artifacts](./fileformat.wiki#manifest). Each manifest has a cryptographically-strong [SHA-1] or [SHA-3] hash linking it to one or more “parent” blocks. The manifest also contains a timestamp and the transactional data needed to express a commit to the repository. If you traverse the Fossil repository from the tips of its [DAG] to the root by following the parent hashes in each manifest, you will then have a Merkle tree. Point-for-point, Fossil follows that definition. Every change in Fossil starts by adding one or more manifests to the repository, extending this tree. [bcwp]: https://en.wikipedia.org/wiki/Blockchain [DAG]: https://en.wikipedia.org/wiki/Directed_acyclic_graph [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 <a id="currency"></a> ## Cryptocurrency Because blockchain technology was first popularized as Bitcoin, many people associate the term with cryptocurrency. Fossil has nothing to do with cryptocurrency, so a claim that “Fossil is a blockchain” may fail to communicate the speaker’s concepts clearly due to conflation with cryptocurrency. Cryptocurrency has several features and requirements that Fossil doesn’t provide, either because it doesn’t need them or because we haven’t gotten around to creating the feature. Whether these are essential to the definition of “blockchain” and thus disqualify Fossil as a blockchain is for you to decide. Cryptocurrencies must prevent three separate types of fraud to be useful: * **Type 1** is modification of existing currency. To draw an analogy to paper money, we wish to prevent someone from using green and black markers to draw extra zeroes on a US $10 bill so that it claims to be a $100 bill. Cryptocurrencies apply digital signatures to each block so that a given block of currency’s face value cannot be changed after it is created. The [proof-of-work][pow] aspect prevents the creator from setting its initial value fraudulently. * **Type 2** is making new counterfeit $10 bills that look sufficiently like the original to pass in commerce. Cryptocurrencies chain blocks together and establish a sufficiently hard work problem to create new currency that Type 2 frauds are impractical short of doing the actual mining needed to produce legitimate cryptocurrency. * **Type 3** is double-spending existing legitimate cryptocurrency. There is no analogy in paper money due to its physical form; it is a problem unique to digital currency due to its infinitely-copyable nature. Cryptocurrencies prevent Type 3 frauds by making the *prior* owner of a block sign it over to the new owner. To avoid an O(n²) auditing problem as a result, cryptocurrencies also use a chain of hashes to make checking for double-spending quick and easy. How does all of this compare to Fossil? 1. <a id="signatures"></a>**Signatures.** Cryptocurrencies use a chain of [digital signatures][dsig] to prevent Type 1 and Type 3 frauds. This chain forms an additional link between the blocks, separate from the hash chain that applies an ordering and lookup scheme to the blocks. [_Blockchain: Simple Explanation_][bse] explains this “hash chain” vs. “block chain” distinction in more detail. Fossil has [a disabled-by-default feature][cs] to call out to an external copy of [PGP] or [GPG] to sign commit manifests before inserting them into the repository. You may wish to couple that with a server-side [after-receive hook][arh] to reject unsigned commits. Although there are several distinctions you can draw between the way Fossil’s commit signing scheme works and the way block signing works in cryptocurrencies, only one is of material interest for our purposes here: Fossil commit signatures apply only to a single commit. Fossil does not sign one commit over to the next “owner” of that commit in the way that a blockchain-based cryptocurrency must when transferring currency from one user to another, beacuse there is no useful analog to the double-spending problem in Fossil. The closest you can come to this is double-insert of commits into the blockchain, which we’ll address shortly. What Fossil commit signatures actually do is provide in-tree forgery prevention, both Type 1 and Type 2. You cannot modify existing commits (Type 1 forgery) because you do not have the original committer’s private signing key, and you cannot forge new commits attesting to come from some other trusted committer (Type 2) because you don’t have any of their private signing keys, either. Cyrptocurrencies also use the work problem to prevent Type 2 forgeries, but the application of that to Fossil is a matter we get to [later](#work). If Fossil signatures prevent Type 1 and Type 2 frauds, why then are they not enabled by default? Because they are defense-in-depth measures, not the minimum sufficient measures needed to prevent repository fraud in Fossil. Fossil provides its primary protections through other means. Although you have complete control over the contents of your local Fossil repository clone, you cannot perform Type 1 forgery on its contents short of executing a [preimage attack][prei] on the hash algorthm. ([SHA3-256][SHA-3] by default in the current version of Fossil.) Even if you could, Fossil’s sync protocol will prevent the modification from being pushed into another repository: the remote Fossil instance says, “I’ve already got that one, thanks,” and ignores the push. Thus, short of breaking into the remote server and modifying the repository in place, you couldn’t even make use of a preimage attack if you had that power. This is an attack on the server itself, not on Fossil’s data structures, so while it is useful to think through this problem, it is not helpful to answering our questions here. The Fossil sync protocol also prevents the closest analog to Type 3 frauds in Fossil: copying a commit manifest in your local repo clone won’t result in a double-commit on sync. In the absence of digital signatures, Fossil’s [RBAC system][caps] restricts Type 2 forgery to trusted committers. Thus once again we’re reduced to an infosec problem, not a data structure design question. (Inversely, enabling commit clearsigning is a good idea if you have committers on your repo whom you don’t trust not to commit Type 2 frauds. But let us be clear: your choice of setting does not answer the question of whether Fossil is a blockchain.) If you’re wondering why Fossil’s current commit signing feature is not enabled by default and why it doesn’t verify signatures on commits, it is because Fossil is not itself a [PKI], and there is no way for regular users of Fossil to link it to a PKI, since doing so would likely result in an unwanted [PII] disclosure. There is no email address in a Fossil commit manifest that you could use to query one of the public PGP keyservers, for example. It therefore becomes a local policy matter as to whether you even *want* to have signatures, because they’re not without their downsides. 2. <a id="work"></a>**Work Contests.** Cryptocurrencies prevent forgery by setting up some sort of contest that ensures that new coins can come into existence only by doing some difficult work task. This “mining” activity results in a coin that took considerable work to create, which thus has economic value by being a) difficult to re-create, and b) resistant to [debasement][dboc]. Fossil repositories are most often used to store the work product of individuals, rather than cryptocoin mining machines. There is generally no contest in trying to produce the most commits. There may be an implicit contest to produce the “best” commits, but that is a matter of project management, not something that can be automatically mediated through objective measures. Incentives to commit to the repository come from outside of Fossil; they are not inherent to its nature, as with cryptocurrencies. Moreover, there is no useful sense in which we could say that one commit “re-creates” another. Commits are generally products of individual human intellect, thus necessarily unique in all but trivial cases. This is foundational to copyright law. 3. <a id="lcr"></a>**Longest Chain Rule.** Cryptocurrencies generally need some way to distinguish which blocks are legitimate and which not. They do this in part by identifying the linear chain with the greatest cumulative [work time](#work) as the legitimate chain. All blocks not on that linear chain are considered “orphans” and are ignored by the cryptocurrency software. It inverse is sometimes called the “51% attack” because a single actor would have to do slightly more work than the entire rest of the community using a given cryptocurrency in order for their fork of the currency to be considered the legitimate fork. This argument soothes concerns that a single bad actor could take over the network. The closest we can come to that notion in Fossil is the default “trunk” branch, but there’s nothing in Fossil that delegitimizes other branches just because they’re shorter, nor is there any way in Fossil to score the amount of work that went into a commit. Indeed, [forks and branches][fb] are *valuable and desirable* things in Fossil. This much is certain: Fossil is definitely not a cryptocurrency. Whether this makes it “not a blockchain” is a subjective matter. [arh]: ./hooks.md [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction [caps]: ./caps/ [cs]: /help?cmd=clearsign [dboc]: https://en.wikipedia.org/wiki/Debasement [dsig]: https://en.wikipedia.org/wiki/Digital_signature [fb]: ./branching.wiki [GPG]: https://gnupg.org/ [PGP]: https://www.openpgp.org/ [PII]: https://en.wikipedia.org/wiki/Personal_data [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure [pow]: https://en.wikipedia.org/wiki/Proof_of_work [prei]: https://en.wikipedia.org/wiki/Preimage_attack <a id="dlt"></a> ## Distributed Ledgers Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If we can convince ourselves that Fossil is also a distributed ledger, then we might think of Fossil as a peer technology, having at least some qualifications toward being considered a blockchain. A key tenet of DLT is that records be unmodifiable after they’re committed to the ledger, which matches quite well with Fossil’s design and everyday use cases. Fossil puts up multiple barriers to prevent modification of existing records and injection of incorrect records. Yet, Fossil also has [purge] and [shunning][shun]. Doesn’t that mean Fossil cannot be a distributed ledger? These features only remove existing commits from the repository. If you want a currency analogy, they are ways to burn a paper bill or to melt a [fiat coin][fc] down to slag. In a cryptocurrency, you can erase your “wallet” file, effectively destroying money in a similar way. These features do not permit forgery of either type described above: you can’t use them to change the value of existing commits (Type 1) or add new commits to the repository (Type 2). What if we removed those features from Fossil, creating an append-only Fossil variant? Is it a DLT then? Arguably still not, because [today’s Fossil is an AP-mode system][ctap] in the [CAP theorem][cap] sense, which means there can be no guaranteed consensus on the content of the ledger at any given time. If you had an AP-mode accounts receivable system, it could have different bottom-line totals at different sites, because you’ve cast away “C” to get AP-mode operation. Because of this, you could still not guarantee that the command “`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil variant would guarantee that everyone got the same result. (Everyone not partitioned away from the majority of the network at any rate, in the CP case.) What are the prospects for CA-mode or CP-mode Fossil? [We don’t want CA-mode Fossil][ctca], but [CP-mode could be useful][ctcp]. Until the latter exists, this author believes Fossil is not a distributed ledger in a technologically defensible sense. The most common technologies answering to the label “blockchain” are all DLTs, so if Fossil is not a DLT, then it is not a blockchain in that sense. [ctap]: ./cap-theorem.md#ap [ctca]: ./cap-theorem.md#ca [ctcp]: ./cap-theorem.md#cp [cap]: https://en.wikipedia.org/wiki/CAP_theorem [dlt]: https://en.wikipedia.org/wiki/Distributed_ledger [DVCS]: https://en.wikipedia.org/wiki/Distributed_version_control [fc]: https://en.wikipedia.org/wiki/Fiat_money [purge]: /help?cmd=purge [shun]: ./shunning.wiki <a id="dpc"></a> ## Distributed Partial Consensus If we can’t get DLT, can we at least get some kind of distributed consensus at the level of individual Fossil’s commits? Many blockchain based technologies have this property: given some element of the blockchain, you can make certain proofs that it either is a legitimate part of the whole blockchain, or it is not. Unfortunately, this author doesn’t see a way to do that with Fossil. Given only one “block” in Fossil’s putative “blockchain” — a commit, in Fossil terminology — all you can prove is whether it is internally consistent, that it is not corrupt. That then points you at the parent(s) of that commit, which you can repeat the exercise on, back to the root of the DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks] does. If cryptocurrencies worked this way, you wouldn’t be able to prove that a given cryptocoin was legitimate without repeating the proof-of-work calculations for the entire cryptocurrency scheme! Instead, you only need to check a certain number of signatures and proofs-of-work in order to be reasonably certain that you are looking at a legitimate section of the whole blockchain. What would it even mean to prove that a given Fossil commit “*belongs*” to the repository you’ve extracted it from? For a software project, isn’t that tantamount to automatic code review, where the server would be able to reliably accept or reject a commit based solely on its content? That sounds nice, but this author believes we’ll need to invent [AGI] first. A better method to provide distributed consensus for Fossil would be to rely on the *natural* intelligence of its users: that is, distributed commit signing, so that a commit is accepted into the blockchain only once some number of users countersign it. This amounts to a code review feature, which Fossil doesn’t currently have. Solving that problem basically requires solving the [PKI] problem first, since you can’t verify the proofs of these signatures if you can’t first prove that the provided signatures belong to people you trust. This is a notoriously hard problem in its own right. A future version of Fossil could instead provide [consensus in the CAP sense][ctcp]. For instance, you could say that if a quorum of servers all have a given commit, it “belongs.” Fossil’s strong hashing tech would mean that querying whether a given commit is part of the “blockchain” would be as simple as going down the list of servers and sending each an HTTP GET `/info` query for the artifact ID, concluding that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is hypothetical, because Fossil doesn’t do this today. [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence [rcks]: /help?cmd=repo-cksum <a id="anon"></a> ## Anonymity Many blockchain based technologies go to extraordinary lengths to allow anonymous use of their service. As typically configured, Fossil does not: commits synced between servers always at least have a user name associated with them, which the remote system must accept through its [RBAC system][caps]. That system can run without having the user’s email address, but it’s needed if [email alerts][alert] are enabled on the server. The remote server logs the IP address of the commit for security reasons. That coupled with the timestamp on the commit could sufficiently deanonymize users in many common situations. It is possible to configure Fossil so it doesn’t do this: * You can give [Write capability][capi] to user category “nobody,” so that anyone that can reach your server can push commits into its repository. * You could give that capability to user category “anonymous” instead, which requires that the user log in with a CAPTCHA, but which doesn’t require that the user otherwise identify themselves. * You could enable [the `self-register` setting][sreg] and choose not to enable [commit clear-signing][cs] so that anonymous users could push commits into your repository under any name they want. On the server side, you can also [scrub] the logging that remembers where each commit came from. That info isn’t transmitted from the remote server on clone or pull. Instead, the size of the `rcvfrom` table after initial clone is 1: it contains the remote server’s IP address. On each pull containing new artifacts, your local `fossil` instance adds another entry to this table, likely with the same IP address unless the server has moved or you’re using [multiple remotes][mrep]. This table is far more interesting on the server side, containing the IP addresses of all contentful pushes; thus [the `scrub` command][scrub]. Because Fossil doesn’t remember IP addresses in commit manifests or require commit signing, it allows at least *pseudonymous* commits. When someone clones a remote repository, they don’t learn the email address, IP address, or any other sort of [PII] of prior committers, on purpose. Some people say that private, permissioned blockchains (as you may imagine Fossil to be) are inherently problematic by the very reason that they don’t bake anonymous contribution into their core. The very existence of an RBAC is a moving piece that can break. Isn’t it better, the argument goes, to have a system that works even in the face of anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies do this, for example: anyone can “mine” a new coin and push it into the blockchain, and there is no central authority restricting the transfer of cryptocurrency from one user to another. We can draw an analogy to encryption, where an algorithm is considered inherently insecure if it depends on keeping any information from an attacker other than the key. Encryption schemes that do otherwise are derided as “security through obscurity.” You may be wondering what any of this has to do with whether Fossil is a blockchain, but that is exactly the point: all of this is outside Fossil’s core hash-chained repository data structure. If you take the position that you don’t have a “blockchain” unless it allows anonymous contribution, with any needed restrictions provided only by the very structure of the managed data, then Fossil does not qualify. Why do some people care about this distinction? Consider Bitcoin, wherein an anonymous user cannot spam the blockchain with bogus coins because its [proof-of-work][pow] protocol allows such coins to be rejected immediately. There is no equivalent in Fossil: it has no technology that allows the receiving server to look at the content of a commit and automatically judge it to be “good.” Fossil relies on its RBAC system to provide such distinctions: if you have a commit bit, your commits are *ipso facto* judged “good,” insofar as any human work product can be so judged by a blob of compiled C code. This takes us back to the [digital ledger question](#dlt), where we can talk about what it means to later correct a bad commit that got through the RBAC check. We may be willing to accept pseudonymity, rather than full anonymity. If we configure Fossil as above, either bypassing the RBAC or abandoning human control over it, scrubbing IP addresses, etc., is it then a public permissionless blockchain in that sense? We think not, because there is no [longest chain rule](#lcr) or anything like it in Fossil. For a fair model of how a Fossil repository might behave under such conditions, consider GitHub: here one user can fork another’s repository and make an arbitrary number of commits to their public fork. Imagine this happens 10 times. How does someone come along later and *automatically* evaluate which of the 11 forks of the code (counting the original repository among their number) is the “best” one? For a computer software project, the best we could do to approximate this devolves to a [software project cost estimation problem][scost]. These methods are rather questionable in their own right, being mathematical judgement values on human work products, but even if we accept their usefulness, then we still cannot say which fork is better based solely on their scores under these metrics. We may well prefer to use the fork of a software program that took *less* effort, being smaller, more self-contained, and with a smaller attack surface. [alert]: ./alerts.md [capi]: ./caps/ref.html#i [mrep]: /help?cmd=remote [scost]: https://en.wikipedia.org/wiki/Software_development_effort_estimation [scrub]: /help?cmd=scrub [sreg]: /help?cmd=self-register # Conclusion This author believes it is technologically indefensible to call Fossil a “blockchain” in any sense likely to be understood by a majority of those you’re communicating with. Within a certain narrow scope, you can defend this usage, but if you do that, you’ve failed any goal that requires clear communication: it doesn’t work to use a term in a nonstandard way just because you can defend it. The people you’re communicating your ideas to must have the same concept of the terms you use. What term should you use instead? Fossil stores a DAG of hash-chained commits, so an indisputably correct term is a [Merkle tree][mt], named after [its inventor][drrm]. You could also use the more generic term “hash tree.” Fossil is a technological peer to many common sorts of blockchain technology. There is a lot of overlap in concepts and implementation details, but when speaking of what most people understand as “blockchain,” Fossil is not that. [drrm]: https://en.wikipedia.org/wiki/Ralph_Merkle [mt]: https://en.wikipedia.org/wiki/Merkle_tree |
Changes to www/caps/admin-v-setup.md.
︙ | ︙ | |||
44 45 46 47 48 49 50 | things that the Setup user has not changed from the stock configuration. In this way, an Admin-only user can avoid overriding the Setup user's choices. You can also look at the role of Admin from the other direction, up through the [user power hierarchy][ucap] rather than down from Setup. An Admin user is usually a “super-developer” role, given full control over | | | | 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | things that the Setup user has not changed from the stock configuration. In this way, an Admin-only user can avoid overriding the Setup user's choices. You can also look at the role of Admin from the other direction, up through the [user power hierarchy][ucap] rather than down from Setup. An Admin user is usually a “super-developer” role, given full control over the repository’s managed content: versioned artifacts in [the hash tree][bc], [unversioned content][uv], forum posts, wiki articles, tickets, etc. We’ll explore these distinctions in the rest of this document. [bc]: ../blockchain.md [ucap]: ./index.md#ucap [uv]: ../unvers.wiki |
︙ | ︙ | |||
156 157 158 159 160 161 162 | Shunned page to Admin users rather than reserve it to Setup users because one of the primary purposes of [the Fossil shunning system][shun] is to clean up after a spammer, and that's exactly the sort of administrivia we wish to delegate to Admin users. Coupled with the Rebuild button on the same page, an Admin user has the power to delete the repository's entire | | | | 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 | Shunned page to Admin users rather than reserve it to Setup users because one of the primary purposes of [the Fossil shunning system][shun] is to clean up after a spammer, and that's exactly the sort of administrivia we wish to delegate to Admin users. Coupled with the Rebuild button on the same page, an Admin user has the power to delete the repository's entire [hash tree][bc]! This makes this feature a pretty good razor in deciding whether to grant someone Admin capability: do you trust that user to shun Fossil artifacts responsibly? Realize that shunning is cooperative in Fossil. As long as there are surviving repository clones, an Admin-only user who deletes the whole hash tree has merely caused a nuisance. An Admin-only user cannot permanently destroy the repository unless the Setup user has been so silly as to have no up-to-date clones. * **Moderation**: According to the power hierarchy laid out at the top of this article, Admins are greater than Moderators, so control over what Moderators can do clearly belongs to both Admins and to the Setup user(s). |
︙ | ︙ | |||
342 343 344 345 346 347 348 | restriction. (chroot, jails, SELinux, VMs, etc.) Since it makes no sense to trust Admin-only users with <tt>root</tt> level access on the host system, we almost certainly don't want to allow them to change such settings.</p> * **SQL**: The Admin → SQL feature allows the Setup user to enter raw SQL queries against the Fossil repository via Fossil UI. This not | | | 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 | restriction. (chroot, jails, SELinux, VMs, etc.) Since it makes no sense to trust Admin-only users with <tt>root</tt> level access on the host system, we almost certainly don't want to allow them to change such settings.</p> * **SQL**: The Admin → SQL feature allows the Setup user to enter raw SQL queries against the Fossil repository via Fossil UI. This not only allows arbitrary ability to modify the repository hash tree and its backing data tables, it can probably also be used to damage the host such as via `PRAGMA temp_store = FILE`. * **Tickets**: This section allows input of aribtrary TH1 code that runs on the server, affecting the way the Fossil ticketing system works. The justification in the **TH1** section below therefore applies. |
︙ | ︙ |
Changes to www/caps/impl.md.
︙ | ︙ | |||
60 61 62 63 64 65 66 | 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 | | | 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 | 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 hash tree][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 |
︙ | ︙ |
Changes to www/caps/ref.html.
︙ | ︙ | |||
75 76 77 78 79 80 81 | <tr id="d"> <th>d</th> <th>n/a</th> <td> Legacy capability letter from Fossil's forebear <a href="http://cvstrac.org/">CVSTrac</a>, which has no useful | | | 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 | <tr id="d"> <th>d</th> <th>n/a</th> <td> Legacy capability letter from Fossil's forebear <a href="http://cvstrac.org/">CVSTrac</a>, which has no useful meaning in Fossil due to the nature of its durable Merkle tree design. This letter was assigned by default to Developer in repos created with Fossil 2.10 or earlier, but it has no effect in current or past versions of Fossil; we recommend that you remove it in case we ever reuse this letter for another purpose. See <a href="https://fossil-scm.org/forum/forumpost/43c78f4bef">this post</a> for details. </td> |
︙ | ︙ |
Changes to www/checkin_names.wiki.
︙ | ︙ | |||
286 287 288 289 290 291 292 | # [#timestamps | Timestamps], with preference to ISO8601 forms # [#tagpfx | tag:TAGNAME] # [#root | root:BRANCH] # [#merge-in | merge-in:BRANCH] # [#tag-ts | TAG:timestamp] # Full artifact hash or hash prefix. # Any other type of symbolic name that Fossil extracts from | | | 286 287 288 289 290 291 292 293 294 295 | # [#timestamps | Timestamps], with preference to ISO8601 forms # [#tagpfx | tag:TAGNAME] # [#root | root:BRANCH] # [#merge-in | merge-in:BRANCH] # [#tag-ts | TAG:timestamp] # Full artifact hash or hash prefix. # Any other type of symbolic name that Fossil extracts from artifacts. <div style="height:40em" id="this-space-intentionally-left-blank"></div> |
Changes to www/fileedit-page.md.
︙ | ︙ | |||
54 55 56 57 58 59 60 | [referer]: https://en.wikipedia.org/wiki/HTTP_referer [csrf]: https://en.wikipedia.org/wiki/Cross-site_request_forgery [xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest ## `/fileedit` **Works by Creating Commits** Thus any edits made via that page become a normal part of the | | | 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 | [referer]: https://en.wikipedia.org/wiki/HTTP_referer [csrf]: https://en.wikipedia.org/wiki/Cross-site_request_forgery [xhr]: https://en.wikipedia.org/wiki/XMLHttpRequest ## `/fileedit` **Works by Creating Commits** Thus any edits made via that page become a normal part of the repository. ## `/fileedit` is *Intended* for use with Embedded Docs ... and similar text files, and is most certainly **not intended for editing code**. Editing files with unusual syntax requirements, e.g. hard tabs in |
︙ | ︙ |
Changes to www/fossil-v-git.wiki.
︙ | ︙ | |||
228 229 230 231 232 233 234 | <h3 id="durable" name="database">2.3 Durable</h3> The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage a [https://en.wikipedia.org/wiki/Directed_acyclic_graph | directed acyclic graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree | Merkle | | | 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 | <h3 id="durable" name="database">2.3 Durable</h3> The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage a [https://en.wikipedia.org/wiki/Directed_acyclic_graph | directed acyclic graph] (DAG) of [https://en.wikipedia.org/wiki/Merkle_tree | Merkle tree] structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via <i>its</i> hash. The difference is that Git stores its objects as individual files in the <tt>.git</tt> folder or compressed into bespoke [https://git-scm.com/book/en/v2/Git-Internals-Packfiles|pack-files], whereas Fossil stores its objects in a [https://www.sqlite.org/|SQLite] |
︙ | ︙ | |||
739 740 741 742 743 744 745 | The prime example in Git is rebasing: the change happens to the local repository immediately if successful, even though you haven't tested the change yet. It's possible to argue for such a design in a tool like Git which doesn't automatically push the change up to its parent, because you can still test the change before pushing local changes to the parent repo, but in the meantime you've made a durable change to your local Git | | | | 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 | The prime example in Git is rebasing: the change happens to the local repository immediately if successful, even though you haven't tested the change yet. It's possible to argue for such a design in a tool like Git which doesn't automatically push the change up to its parent, because you can still test the change before pushing local changes to the parent repo, but in the meantime you've made a durable change to your local Git repository. You must do something drastic like <tt>git reset --hard</tt> to revert that rebase if it causes a problem. If you push your rebased local repo up to the parent without testing first, you've now committed the error on a public branch, effectively a violation of [https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing | the golden rule of rebasing]. Lesser examples are the Git <tt>merge</tt>, <tt>cherry-pick</tt>, and <tt>revert</tt> commands, all of which apply work from one branch onto another, and all of which do their work immediately without giving you an opportunity to test the change first locally unless you give the <tt>--no-commit</tt> option. Fossil cannot sensibly work that way because of its default-enabled autosync feature. Instead of jumping straight to the commit step, Fossil applies the proposed merge to the local working directory only, requiring a separate check-in step before the change is committed to the repository. This gives you a chance to test the change first, either manually or by running your software's automatic tests. (Ideally, both!) Another difference is that because Fossil requires an explicit commit for a merge, it makes you give an explicit commit <i>message</i> for each merge, whereas Git writes that commit message itself by default unless you give the optional <tt>--edit</tt> flag to override it. |
︙ | ︙ |
Changes to www/mirrorlimitations.md.
︙ | ︙ | |||
12 13 14 15 16 17 18 | Git only supports version control. The additional features of Fossil such as Wiki, Tickets, Technotes, and the Forum are not supported in Git, so those features are not included in an export. Third-party Git based tooling may add some of these features (e.g. GitHub, GitLab) but because their data are not stored in the Git | | | | | | 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 | Git only supports version control. The additional features of Fossil such as Wiki, Tickets, Technotes, and the Forum are not supported in Git, so those features are not included in an export. Third-party Git based tooling may add some of these features (e.g. GitHub, GitLab) but because their data are not stored in the Git repository, there is no single destination for Fossil to convert its equivalent data *to*. For instance, Fossil tickets do not become GitHub issues, because that is a proprietary feature of GitHub separate from Git proper, stored outside the repository on the GitHub servers. You can also see the problem in its inverse case: you do not get a copy of your GitHub issues when cloning the Git repository. You *do* get the Fossil tickets, wiki, forum posts, etc. when cloning a remote Fossil repo. ## (2) Cherrypick Merges The Git client supports cherrypick merges but does not record the cherrypick parent(s). Fossil tracks cherrypick merges in its repository and displays cherrypicks in its timeline. (As an example, the dashed lines [here](/timeline?c=0a9f12ce6655b7a5) are cherrypicks.) Because Git does not have a way to represent this same information in its repository, the history of Fossil cherrypicks cannot be exported to Git, only their direct effects on the managed file data. ## (3) Named Branches Git has only limited support for named branches. Git identifies the head check-in of each branch. Depending on the check-in graph topology, this |
︙ | ︙ | |||
71 72 73 74 75 76 77 | [ghrtv]: https://github.com/drhsqlite/fossil-mirror/tree/release ## (5) Amendments To Check-ins Check-ins are immutable in both Fossil and Git. However, Fossil has a mechanism by which tags can be added to | | | 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | [ghrtv]: https://github.com/drhsqlite/fossil-mirror/tree/release ## (5) Amendments To Check-ins Check-ins are immutable in both Fossil and Git. However, Fossil has a mechanism by which tags can be added to its repository to provide after-the-fact corrections to prior check-ins. For example, tags can be added to check-ins that correct typos in the check-in comment. The original check-in is immutable and so the original comment is preserved in addition to the correction. But software that displays the check-ins knows to look for the comment-change tag and if present displays the corrected comment rather than the original. ([Example](/info/8ed91bbe44d0d383) changing the typo "os" into "so".) |
︙ | ︙ |
Changes to www/mkindex.tcl.
︙ | ︙ | |||
12 13 14 15 16 17 18 | adding_code.wiki {Adding New Features To Fossil} adding_code.wiki {Hacking Fossil} alerts.md {Email Alerts And Notifications} antibot.wiki {Defense against Spiders and Bots} backoffice.md {The "Backoffice" mechanism of Fossil} backup.md {Backing Up a Remote Fossil Repository} blame.wiki {The Annotate/Blame Algorithm Of Fossil} | | | 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | adding_code.wiki {Adding New Features To Fossil} adding_code.wiki {Hacking Fossil} alerts.md {Email Alerts And Notifications} antibot.wiki {Defense against Spiders and Bots} backoffice.md {The "Backoffice" mechanism of Fossil} backup.md {Backing Up a Remote Fossil Repository} blame.wiki {The Annotate/Blame Algorithm Of Fossil} blockchain.md {Is Fossil A Blockchain?} branching.wiki {Branching, Forking, Merging, and Tagging} bugtheory.wiki {Bug Tracking In Fossil} build.wiki {Compiling and Installing Fossil} cap-theorem.md {Fossil and the CAP Theorem} caps/ {Administering User Capabilities} caps/admin-v-setup.md {Differences Between Setup and Admin Users} caps/ref.html {User Capability Reference} |
︙ | ︙ |
Changes to www/permutedindex.html.
︙ | ︙ | |||
39 40 41 42 43 44 45 | <li><a href="password.wiki">Authentication — Password Management And</a></li> <li><a href="backup.md"><b>Backing Up a Remote Fossil Repository</b></a></li> <li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li> <li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li> <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li> <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li> <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li> | | | 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 | <li><a href="password.wiki">Authentication — Password Management And</a></li> <li><a href="backup.md"><b>Backing Up a Remote Fossil Repository</b></a></li> <li><a href="backoffice.md">Backoffice mechanism of Fossil — The</a></li> <li><a href="fossil_prompt.wiki">Bash Prompt — Fossilized</a></li> <li><a href="whyusefossil.wiki"><b>Benefits Of Version Control</b></a></li> <li><a href="caps/admin-v-setup.md">Between Setup and Admin Users — Differences</a></li> <li><a href="hashpolicy.wiki">Between SHA1 and SHA3-256 — Hash Policy: Choosing</a></li> <li><a href="blockchain.md">Blockchain? — Is Fossil A</a></li> <li><a href="antibot.wiki">Bots — Defense against Spiders and</a></li> <li><a href="private.wiki">Branches — Creating, Syncing, and Deleting Private</a></li> <li><a href="branching.wiki"><b>Branching, Forking, Merging, and Tagging</b></a></li> <li><a href="bugtheory.wiki"><b>Bug Tracking In Fossil</b></a></li> <li><a href="makefile.wiki">Build Process — The Fossil</a></li> <li><a href="cap-theorem.md">CAP Theorem — Fossil and the</a></li> <li><a href="caps/">Capabilities — Administering User</a></li> |
︙ | ︙ | |||
124 125 126 127 128 129 130 | <li><a href="delta_format.wiki">Format — Fossil Delta</a></li> <li><a href="fileformat.wiki">Format — Fossil File</a></li> <li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size — Image</a></li> <li><a href="../../../md_rules">Formatting Rules — Markdown</a></li> <li><a href="../../../wiki_rules">Formatting Rules — Wiki</a></li> <li><a href="forum.wiki">Forums — Fossil</a></li> <li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li> | < | 124 125 126 127 128 129 130 131 132 133 134 135 136 137 | <li><a href="delta_format.wiki">Format — Fossil Delta</a></li> <li><a href="fileformat.wiki">Format — Fossil File</a></li> <li><a href="image-format-vs-repo-size.md">Format vs Fossil Repo Size — Image</a></li> <li><a href="../../../md_rules">Formatting Rules — Markdown</a></li> <li><a href="../../../wiki_rules">Formatting Rules — Wiki</a></li> <li><a href="forum.wiki">Forums — Fossil</a></li> <li><a href="cap-theorem.md"><b>Fossil and the CAP Theorem</b></a></li> <li><a href="changes.wiki"><b>Fossil Changelog</b></a></li> <li><a href="concepts.wiki"><b>Fossil Core Concepts</b></a></li> <li><a href="css-tricks.md"><b>Fossil CSS Tips and Tricks</b></a></li> <li><a href="delta_encoder_algorithm.wiki"><b>Fossil Delta Encoding Algorithm</b></a></li> <li><a href="delta_format.wiki"><b>Fossil Delta Format</b></a></li> <li><a href="hacker-howto.wiki"><b>Fossil Developers Guide</b></a></li> <li><a href="fileformat.wiki"><b>Fossil File Format</b></a></li> |
︙ | ︙ | |||
186 187 188 189 190 191 192 193 194 195 196 197 198 199 | <li><a href="tech_overview.wiki">Implementation Of Fossil — A Technical Overview Of The Design And</a></li> <li><a href="inout.wiki"><b>Import And Export To And From Git</b></a></li> <li><a href="build.wiki">Installing Fossil — Compiling and</a></li> <li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li> <li><a href="selfcheck.wiki">Integrity Self Checks — Fossil Repository</a></li> <li><a href="webui.wiki">Interface — The Fossil Web</a></li> <li><a href="interwiki.md"><b>Interwiki Links</b></a></li> <li><a href="javascript.md">JavaScript in Fossil — Use of</a></li> <li><a href="th1.md">Language — The TH1 Scripting</a></li> <li><a href="copyright-release.html">License Agreement — Contributor</a></li> <li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li> <li><a href="interwiki.md">Links — Interwiki</a></li> <li><a href="../../../help"><b>Lists of Commands and Webpages</b></a></li> <li><a href="password.wiki">Management And Authentication — Password</a></li> | > | 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 | <li><a href="tech_overview.wiki">Implementation Of Fossil — A Technical Overview Of The Design And</a></li> <li><a href="inout.wiki"><b>Import And Export To And From Git</b></a></li> <li><a href="build.wiki">Installing Fossil — Compiling and</a></li> <li><a href="fossil-from-msvc.wiki"><b>Integrating Fossil in the Microsoft Express 2010 IDE</b></a></li> <li><a href="selfcheck.wiki">Integrity Self Checks — Fossil Repository</a></li> <li><a href="webui.wiki">Interface — The Fossil Web</a></li> <li><a href="interwiki.md"><b>Interwiki Links</b></a></li> <li><a href="blockchain.md"><b>Is Fossil A Blockchain?</b></a></li> <li><a href="javascript.md">JavaScript in Fossil — Use of</a></li> <li><a href="th1.md">Language — The TH1 Scripting</a></li> <li><a href="copyright-release.html">License Agreement — Contributor</a></li> <li><a href="mirrorlimitations.md"><b>Limitations On Git Mirrors</b></a></li> <li><a href="interwiki.md">Links — Interwiki</a></li> <li><a href="../../../help"><b>Lists of Commands and Webpages</b></a></li> <li><a href="password.wiki">Management And Authentication — Password</a></li> |
︙ | ︙ |
Changes to www/shunning.wiki.
︙ | ︙ | |||
30 31 32 33 34 35 36 | Fossil to insert bad control artifacts. Therefore, before we get to methods of permanently deleting content from a Fossil repos, let's give some alternatives that usually suffice, which don't damage the project's fossil record: <ul> <li><p>When a forum post or wiki article is "deleted," what actually | | | | 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 | Fossil to insert bad control artifacts. Therefore, before we get to methods of permanently deleting content from a Fossil repos, let's give some alternatives that usually suffice, which don't damage the project's fossil record: <ul> <li><p>When a forum post or wiki article is "deleted," what actually happens is that a new empty version is added to the Fossil repository. The web interface interprets this as "deleted," but the prior version remains available if you go digging for it.</p></li> <li><p>When you close a ticket, it's marked in a way that causes it to not show up in the normal ticket reports. You usually want to give it a Resolution such as "Rejected" when this happens, plus possibly a comment explaining why you're closing it. This is all new |
︙ | ︙ |