Fossil SCM
Added the "Anonymity" section to the new blockchain doc.
Commit
b357dc2b03b66096abb03aeb6c047aa4d682b042e44ee7b494da17dc6aabd12c
Parent
154d848d2ecb500…
1 file changed
+93
-12
+93
-12
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -34,10 +34,11 @@ | ||
| 34 | 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| 36 | 36 | |
| 37 | 37 | |
| 38 | 38 | |
| 39 | +<a id="currency"></a> | |
| 39 | 40 | ## Cryptocurrency |
| 40 | 41 | |
| 41 | 42 | Because blockchain technology was first popularized as Bitcoin, many |
| 42 | 43 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 43 | 44 | with cryptocurrency, so a claim that “Fossil is a blockchain” may fail |
| @@ -187,31 +188,32 @@ | ||
| 187 | 188 | Fossil. |
| 188 | 189 | |
| 189 | 190 | This much is certain: Fossil is definitely not a cryptocurrency. Whether |
| 190 | 191 | this makes it “not a blockchain” is a subjective matter. |
| 191 | 192 | |
| 192 | -[arh]: https://fossil-scm.org/fossil/doc/trunk/www/hooks.md | |
| 193 | +[arh]: ./hooks.md | |
| 193 | 194 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 194 | 195 | [caps]: ./caps/ |
| 195 | -[cs]: https://fossil-scm.org/home/help?cmd=clearsign | |
| 196 | +[cs]: /help?cmd=clearsign | |
| 196 | 197 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 197 | 198 | [dsig]: https://en.wikipedia.org/wiki/Digital_signature |
| 198 | -[fb]: https://fossil-scm.org/home/doc/trunk/www/branching.wiki | |
| 199 | +[fb]: ./branching.wiki | |
| 199 | 200 | [GPG]: https://gnupg.org/ |
| 200 | 201 | [PGP]: https://www.openpgp.org/ |
| 201 | 202 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 202 | 203 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 203 | 204 | [pow]: https://en.wikipedia.org/wiki/Proof_of_work |
| 204 | 205 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 205 | 206 | |
| 206 | 207 | |
| 207 | 208 | |
| 209 | +<a id="dlt"></a> | |
| 208 | 210 | ## Distributed Ledgers |
| 209 | 211 | |
| 210 | 212 | Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If |
| 211 | 213 | we can convince ourselves that Fossil is also a distributed |
| 212 | -ledger, then we might think of Fossil as at least a peer technology, | |
| 214 | +ledger, then we might think of Fossil as a peer technology, | |
| 213 | 215 | having at least some qualifications toward being considered a blockchain. |
| 214 | 216 | |
| 215 | 217 | A key tenet of DLT is that records be unmodifiable after they’re |
| 216 | 218 | committed to the ledger, which matches quite well with Fossil’s design |
| 217 | 219 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| @@ -234,12 +236,12 @@ | ||
| 234 | 236 | there can be no guaranteed consensus on the content of the ledger at any |
| 235 | 237 | given time. If you had an AP-mode accounts receivable system, it could |
| 236 | 238 | have different bottom-line totals at different sites, because you’ve |
| 237 | 239 | cast away “C” to get AP-mode operation. |
| 238 | 240 | |
| 239 | -Because of this, you could still not guarantee that the command “`fossil | |
| 240 | -info tip`” gives the same result everywhere. A CA or CP-mode Fossil | |
| 241 | +Because of this, you could still not guarantee that the command | |
| 242 | +“`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil | |
| 241 | 243 | variant would guarantee that everyone got the same result. (Everyone not |
| 242 | 244 | partitioned away from the majority of the network at any rate, in the CP |
| 243 | 245 | case.) |
| 244 | 246 | |
| 245 | 247 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| @@ -260,10 +262,11 @@ | ||
| 260 | 262 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 261 | 263 | [purge]: /help?cmd=purge |
| 262 | 264 | [shun]: ./shunning.wiki |
| 263 | 265 | |
| 264 | 266 | |
| 267 | +<a id="dpc"></a> | |
| 265 | 268 | ## Distributed Partial Consensus |
| 266 | 269 | |
| 267 | 270 | If we can’t get DLT, can we at least get some kind of distributed |
| 268 | 271 | consensus at the level of individual Fossil’s commits? |
| 269 | 272 | |
| @@ -272,11 +275,11 @@ | ||
| 272 | 275 | a legitimate part of the whole blockchain, or it is not. |
| 273 | 276 | |
| 274 | 277 | Unfortunately, this author doesn’t see a way to do that with Fossil. |
| 275 | 278 | Given only one “block” in Fossil’s putative “blockchain” — a commit, in |
| 276 | 279 | Fossil terminology — all you can prove is whether it is internally |
| 277 | -consistent, not corrupt. That then points you at the parent(s) of that | |
| 280 | +consistent, that it is not corrupt. That then points you at the parent(s) of that | |
| 278 | 281 | commit, which you can repeat the exercise on, back to the root of the |
| 279 | 282 | DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks] |
| 280 | 283 | does. |
| 281 | 284 | |
| 282 | 285 | If cryptocurrencies worked this way, you wouldn’t be able to prove that |
| @@ -302,21 +305,99 @@ | ||
| 302 | 305 | Solving that problem basically requires solving the [PKI] problem first, |
| 303 | 306 | since you can’t verify the proofs of these signatures if you can’t first |
| 304 | 307 | prove that the provided signatures belong to people you trust. This is a |
| 305 | 308 | notoriously hard problem in its own right. |
| 306 | 309 | |
| 307 | -A future version of Fossil could instead provide consensus [in the CAP | |
| 308 | -sense][cacp]. For instance, you could say that if a quorum of servers | |
| 310 | +A future version of Fossil could instead provide [consensus in the CAP | |
| 311 | +sense][ctcp]. For instance, you could say that if a quorum of servers | |
| 309 | 312 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 310 | 313 | would mean that querying whether a given commit is part of the |
| 311 | 314 | “blockchain” would be as simple as going down the list of servers and |
| 312 | -sending it an HTTP GET `/info` query for the artifact ID, returning | |
| 313 | -“Yes” once you get enough HTTP 200 status codes back. All of this is | |
| 315 | +sending each an HTTP GET `/info` query for the artifact ID, concluding | |
| 316 | +that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is | |
| 314 | 317 | hypothetical, because Fossil doesn’t do this today. |
| 315 | 318 | |
| 316 | 319 | [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence |
| 317 | -[rcks]: https://fossil-scm.org/home/help?cmd=repo-cksum | |
| 320 | +[rcks]: /help?cmd=repo-cksum | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | +<a id="anon"></a> | |
| 325 | +## Anonymity | |
| 326 | + | |
| 327 | +Many blockchain based technologies go to extraordinary lengths to | |
| 328 | +allow anonymous use of their service. | |
| 329 | + | |
| 330 | +As typically configured, Fossil does not: commits synced between servers | |
| 331 | +always at least have a user name associated with them, which the remote | |
| 332 | +system must accept through its [RBAC system][caps]. That system can run | |
| 333 | +without having the user’s email address, but it’s needed if [email | |
| 334 | +alerts][alert] are enabled on the server. The remote server logs the IP | |
| 335 | +address of the commit for security reasons. That coupled with the | |
| 336 | +timestamp on the commit could sufficiently deanonymize users in many | |
| 337 | +common situations. | |
| 338 | + | |
| 339 | +It is possible to configure Fossil so it doesn’t do this: | |
| 340 | + | |
| 341 | +* You can give [Write capability][capi] to user category “nobody,” so | |
| 342 | + that anyone that can reach your server can push commits into its | |
| 343 | + repository. | |
| 344 | + | |
| 345 | +* You could give that capability to user category “anonymous” instead, | |
| 346 | + which requires that the user log in with a CAPTCHA, but which doesn’t | |
| 347 | + require that the user otherwise identify themselves. | |
| 348 | + | |
| 349 | +* You could enable [the `self-register` setting][sreg] and choose not to | |
| 350 | + enable [commit clear-signing][cs] so that anonymous users could push | |
| 351 | + commits into your repository under any name they want. | |
| 352 | + | |
| 353 | +On the server side, you can also [scrub] the logging that remembers | |
| 354 | +where each commit came from. | |
| 355 | + | |
| 356 | +That info isn’t transmitted from the remote server on clone or pull. | |
| 357 | +Instead, the size of the `rcvfrom` table after initial clone is 1: it | |
| 358 | +contains the remote server’s IP address. On each pull containing new | |
| 359 | +artifacts, your local `fossil` instance adds another entry to this | |
| 360 | +table, likely with the same IP address unless the server has moved or | |
| 361 | +you’re using [multiple remotes][mrep]. This table is far more | |
| 362 | +interesting on the server side, containing the IP addresses of all | |
| 363 | +contentful pushes; thus [the `scrub` command][scrub]. | |
| 364 | + | |
| 365 | +Some people say that private, permissioned blockchains (as you may | |
| 366 | +imagine Fossil to be) are inherently problematic by the very reason that | |
| 367 | +they don’t bake anonymous contribution into their core. The very | |
| 368 | +existence of an RBAC is a moving piece that can break. Isn’t it better, | |
| 369 | +the argument goes, to have a system that works even in the face of | |
| 370 | +anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies | |
| 371 | +do this, for example: anyone can “mine” a new coin and push it into the | |
| 372 | +blockchain, and there is no central authority restricting the transfer | |
| 373 | +of cryptocurrency from one user to another. | |
| 374 | + | |
| 375 | +A similar analogy can be made to encryption, where an algorithm is | |
| 376 | +considered inherently insecure if it depends on keeping any information | |
| 377 | +from an attacker other than the key. Encryption schemes that do | |
| 378 | +otherwise are derided as “security through obscurity.” | |
| 379 | + | |
| 380 | +You may be wondering what any of this has to do with whether Fossil is a | |
| 381 | +blockchain, but that is exactly the point: all of this is outside | |
| 382 | +Fossil’s core hash-chained repository data structure. If you take the | |
| 383 | +position that you don’t have a “blockchain” unless it allows anonymous | |
| 384 | +contribution, with any needed restrictions provided only by the very | |
| 385 | +structure of the managed data, then Fossil does not qualify. | |
| 386 | + | |
| 387 | +You can make a good inverse argument, however: because Fossil doesn’t | |
| 388 | +remember IP addresses in commit manifests or require commit signing, it | |
| 389 | +allows at least *pseudonymous* commits. When someone clones a remote | |
| 390 | +repository, they don’t learn email address, IP address, or any other | |
| 391 | +sort of [PII] of prior committers, on purpose. | |
| 392 | + | |
| 393 | + | |
| 394 | +[alert]: ./alerts.md | |
| 395 | +[capi]: ./caps/ref.html#i | |
| 396 | +[mrep]: /help?cmd=remote | |
| 397 | +[scrub]: /help?cmd=scrub | |
| 398 | +[sreg]: /help?cmd=self-register | |
| 318 | 399 | |
| 319 | 400 | |
| 320 | 401 | # Conclusion |
| 321 | 402 | |
| 322 | 403 | This author believes it is technologically indefensible to call Fossil a |
| 323 | 404 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -34,10 +34,11 @@ | |
| 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| 36 | |
| 37 | |
| 38 | |
| 39 | ## Cryptocurrency |
| 40 | |
| 41 | Because blockchain technology was first popularized as Bitcoin, many |
| 42 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 43 | with cryptocurrency, so a claim that “Fossil is a blockchain” may fail |
| @@ -187,31 +188,32 @@ | |
| 187 | Fossil. |
| 188 | |
| 189 | This much is certain: Fossil is definitely not a cryptocurrency. Whether |
| 190 | this makes it “not a blockchain” is a subjective matter. |
| 191 | |
| 192 | [arh]: https://fossil-scm.org/fossil/doc/trunk/www/hooks.md |
| 193 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 194 | [caps]: ./caps/ |
| 195 | [cs]: https://fossil-scm.org/home/help?cmd=clearsign |
| 196 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 197 | [dsig]: https://en.wikipedia.org/wiki/Digital_signature |
| 198 | [fb]: https://fossil-scm.org/home/doc/trunk/www/branching.wiki |
| 199 | [GPG]: https://gnupg.org/ |
| 200 | [PGP]: https://www.openpgp.org/ |
| 201 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 202 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 203 | [pow]: https://en.wikipedia.org/wiki/Proof_of_work |
| 204 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 205 | |
| 206 | |
| 207 | |
| 208 | ## Distributed Ledgers |
| 209 | |
| 210 | Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If |
| 211 | we can convince ourselves that Fossil is also a distributed |
| 212 | ledger, then we might think of Fossil as at least a peer technology, |
| 213 | having at least some qualifications toward being considered a blockchain. |
| 214 | |
| 215 | A key tenet of DLT is that records be unmodifiable after they’re |
| 216 | committed to the ledger, which matches quite well with Fossil’s design |
| 217 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| @@ -234,12 +236,12 @@ | |
| 234 | there can be no guaranteed consensus on the content of the ledger at any |
| 235 | given time. If you had an AP-mode accounts receivable system, it could |
| 236 | have different bottom-line totals at different sites, because you’ve |
| 237 | cast away “C” to get AP-mode operation. |
| 238 | |
| 239 | Because of this, you could still not guarantee that the command “`fossil |
| 240 | info tip`” gives the same result everywhere. A CA or CP-mode Fossil |
| 241 | variant would guarantee that everyone got the same result. (Everyone not |
| 242 | partitioned away from the majority of the network at any rate, in the CP |
| 243 | case.) |
| 244 | |
| 245 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| @@ -260,10 +262,11 @@ | |
| 260 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 261 | [purge]: /help?cmd=purge |
| 262 | [shun]: ./shunning.wiki |
| 263 | |
| 264 | |
| 265 | ## Distributed Partial Consensus |
| 266 | |
| 267 | If we can’t get DLT, can we at least get some kind of distributed |
| 268 | consensus at the level of individual Fossil’s commits? |
| 269 | |
| @@ -272,11 +275,11 @@ | |
| 272 | a legitimate part of the whole blockchain, or it is not. |
| 273 | |
| 274 | Unfortunately, this author doesn’t see a way to do that with Fossil. |
| 275 | Given only one “block” in Fossil’s putative “blockchain” — a commit, in |
| 276 | Fossil terminology — all you can prove is whether it is internally |
| 277 | consistent, not corrupt. That then points you at the parent(s) of that |
| 278 | commit, which you can repeat the exercise on, back to the root of the |
| 279 | DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks] |
| 280 | does. |
| 281 | |
| 282 | If cryptocurrencies worked this way, you wouldn’t be able to prove that |
| @@ -302,21 +305,99 @@ | |
| 302 | Solving that problem basically requires solving the [PKI] problem first, |
| 303 | since you can’t verify the proofs of these signatures if you can’t first |
| 304 | prove that the provided signatures belong to people you trust. This is a |
| 305 | notoriously hard problem in its own right. |
| 306 | |
| 307 | A future version of Fossil could instead provide consensus [in the CAP |
| 308 | sense][cacp]. For instance, you could say that if a quorum of servers |
| 309 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 310 | would mean that querying whether a given commit is part of the |
| 311 | “blockchain” would be as simple as going down the list of servers and |
| 312 | sending it an HTTP GET `/info` query for the artifact ID, returning |
| 313 | “Yes” once you get enough HTTP 200 status codes back. All of this is |
| 314 | hypothetical, because Fossil doesn’t do this today. |
| 315 | |
| 316 | [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence |
| 317 | [rcks]: https://fossil-scm.org/home/help?cmd=repo-cksum |
| 318 | |
| 319 | |
| 320 | # Conclusion |
| 321 | |
| 322 | This author believes it is technologically indefensible to call Fossil a |
| 323 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -34,10 +34,11 @@ | |
| 34 | [SHA-1]: https://en.wikipedia.org/wiki/SHA-1 |
| 35 | [SHA-3]: https://en.wikipedia.org/wiki/SHA-3 |
| 36 | |
| 37 | |
| 38 | |
| 39 | <a id="currency"></a> |
| 40 | ## Cryptocurrency |
| 41 | |
| 42 | Because blockchain technology was first popularized as Bitcoin, many |
| 43 | people associate the term with cryptocurrency. Fossil has nothing to do |
| 44 | with cryptocurrency, so a claim that “Fossil is a blockchain” may fail |
| @@ -187,31 +188,32 @@ | |
| 188 | Fossil. |
| 189 | |
| 190 | This much is certain: Fossil is definitely not a cryptocurrency. Whether |
| 191 | this makes it “not a blockchain” is a subjective matter. |
| 192 | |
| 193 | [arh]: ./hooks.md |
| 194 | [bse]: https://www.researchgate.net/publication/311572122_What_is_Blockchain_a_Gentle_Introduction |
| 195 | [caps]: ./caps/ |
| 196 | [cs]: /help?cmd=clearsign |
| 197 | [dboc]: https://en.wikipedia.org/wiki/Debasement |
| 198 | [dsig]: https://en.wikipedia.org/wiki/Digital_signature |
| 199 | [fb]: ./branching.wiki |
| 200 | [GPG]: https://gnupg.org/ |
| 201 | [PGP]: https://www.openpgp.org/ |
| 202 | [PII]: https://en.wikipedia.org/wiki/Personal_data |
| 203 | [PKI]: https://en.wikipedia.org/wiki/Public_key_infrastructure |
| 204 | [pow]: https://en.wikipedia.org/wiki/Proof_of_work |
| 205 | [prei]: https://en.wikipedia.org/wiki/Preimage_attack |
| 206 | |
| 207 | |
| 208 | |
| 209 | <a id="dlt"></a> |
| 210 | ## Distributed Ledgers |
| 211 | |
| 212 | Cryptocurrencies are an instance of [distributed ledger technology][dlt]. If |
| 213 | we can convince ourselves that Fossil is also a distributed |
| 214 | ledger, then we might think of Fossil as a peer technology, |
| 215 | having at least some qualifications toward being considered a blockchain. |
| 216 | |
| 217 | A key tenet of DLT is that records be unmodifiable after they’re |
| 218 | committed to the ledger, which matches quite well with Fossil’s design |
| 219 | and everyday use cases. Fossil puts up multiple barriers to prevent |
| @@ -234,12 +236,12 @@ | |
| 236 | there can be no guaranteed consensus on the content of the ledger at any |
| 237 | given time. If you had an AP-mode accounts receivable system, it could |
| 238 | have different bottom-line totals at different sites, because you’ve |
| 239 | cast away “C” to get AP-mode operation. |
| 240 | |
| 241 | Because of this, you could still not guarantee that the command |
| 242 | “`fossil info tip`” gives the same result everywhere. A CA or CP-mode Fossil |
| 243 | variant would guarantee that everyone got the same result. (Everyone not |
| 244 | partitioned away from the majority of the network at any rate, in the CP |
| 245 | case.) |
| 246 | |
| 247 | What are the prospects for CA-mode or CP-mode Fossil? [We don’t want |
| @@ -260,10 +262,11 @@ | |
| 262 | [fc]: https://en.wikipedia.org/wiki/Fiat_money |
| 263 | [purge]: /help?cmd=purge |
| 264 | [shun]: ./shunning.wiki |
| 265 | |
| 266 | |
| 267 | <a id="dpc"></a> |
| 268 | ## Distributed Partial Consensus |
| 269 | |
| 270 | If we can’t get DLT, can we at least get some kind of distributed |
| 271 | consensus at the level of individual Fossil’s commits? |
| 272 | |
| @@ -272,11 +275,11 @@ | |
| 275 | a legitimate part of the whole blockchain, or it is not. |
| 276 | |
| 277 | Unfortunately, this author doesn’t see a way to do that with Fossil. |
| 278 | Given only one “block” in Fossil’s putative “blockchain” — a commit, in |
| 279 | Fossil terminology — all you can prove is whether it is internally |
| 280 | consistent, that it is not corrupt. That then points you at the parent(s) of that |
| 281 | commit, which you can repeat the exercise on, back to the root of the |
| 282 | DAG. This is what the enabled-by-default [`repo-cksum` setting][rcks] |
| 283 | does. |
| 284 | |
| 285 | If cryptocurrencies worked this way, you wouldn’t be able to prove that |
| @@ -302,21 +305,99 @@ | |
| 305 | Solving that problem basically requires solving the [PKI] problem first, |
| 306 | since you can’t verify the proofs of these signatures if you can’t first |
| 307 | prove that the provided signatures belong to people you trust. This is a |
| 308 | notoriously hard problem in its own right. |
| 309 | |
| 310 | A future version of Fossil could instead provide [consensus in the CAP |
| 311 | sense][ctcp]. For instance, you could say that if a quorum of servers |
| 312 | all have a given commit, it “belongs.” Fossil’s strong hashing tech |
| 313 | would mean that querying whether a given commit is part of the |
| 314 | “blockchain” would be as simple as going down the list of servers and |
| 315 | sending each an HTTP GET `/info` query for the artifact ID, concluding |
| 316 | that the commit is legitimate once you get enough HTTP 200 status codes back. All of this is |
| 317 | hypothetical, because Fossil doesn’t do this today. |
| 318 | |
| 319 | [AGI]: https://en.wikipedia.org/wiki/Artificial_general_intelligence |
| 320 | [rcks]: /help?cmd=repo-cksum |
| 321 | |
| 322 | |
| 323 | |
| 324 | <a id="anon"></a> |
| 325 | ## Anonymity |
| 326 | |
| 327 | Many blockchain based technologies go to extraordinary lengths to |
| 328 | allow anonymous use of their service. |
| 329 | |
| 330 | As typically configured, Fossil does not: commits synced between servers |
| 331 | always at least have a user name associated with them, which the remote |
| 332 | system must accept through its [RBAC system][caps]. That system can run |
| 333 | without having the user’s email address, but it’s needed if [email |
| 334 | alerts][alert] are enabled on the server. The remote server logs the IP |
| 335 | address of the commit for security reasons. That coupled with the |
| 336 | timestamp on the commit could sufficiently deanonymize users in many |
| 337 | common situations. |
| 338 | |
| 339 | It is possible to configure Fossil so it doesn’t do this: |
| 340 | |
| 341 | * You can give [Write capability][capi] to user category “nobody,” so |
| 342 | that anyone that can reach your server can push commits into its |
| 343 | repository. |
| 344 | |
| 345 | * You could give that capability to user category “anonymous” instead, |
| 346 | which requires that the user log in with a CAPTCHA, but which doesn’t |
| 347 | require that the user otherwise identify themselves. |
| 348 | |
| 349 | * You could enable [the `self-register` setting][sreg] and choose not to |
| 350 | enable [commit clear-signing][cs] so that anonymous users could push |
| 351 | commits into your repository under any name they want. |
| 352 | |
| 353 | On the server side, you can also [scrub] the logging that remembers |
| 354 | where each commit came from. |
| 355 | |
| 356 | That info isn’t transmitted from the remote server on clone or pull. |
| 357 | Instead, the size of the `rcvfrom` table after initial clone is 1: it |
| 358 | contains the remote server’s IP address. On each pull containing new |
| 359 | artifacts, your local `fossil` instance adds another entry to this |
| 360 | table, likely with the same IP address unless the server has moved or |
| 361 | you’re using [multiple remotes][mrep]. This table is far more |
| 362 | interesting on the server side, containing the IP addresses of all |
| 363 | contentful pushes; thus [the `scrub` command][scrub]. |
| 364 | |
| 365 | Some people say that private, permissioned blockchains (as you may |
| 366 | imagine Fossil to be) are inherently problematic by the very reason that |
| 367 | they don’t bake anonymous contribution into their core. The very |
| 368 | existence of an RBAC is a moving piece that can break. Isn’t it better, |
| 369 | the argument goes, to have a system that works even in the face of |
| 370 | anonymous contribution, so that you don’t need an RBAC? Cryptocurrencies |
| 371 | do this, for example: anyone can “mine” a new coin and push it into the |
| 372 | blockchain, and there is no central authority restricting the transfer |
| 373 | of cryptocurrency from one user to another. |
| 374 | |
| 375 | A similar analogy can be made to encryption, where an algorithm is |
| 376 | considered inherently insecure if it depends on keeping any information |
| 377 | from an attacker other than the key. Encryption schemes that do |
| 378 | otherwise are derided as “security through obscurity.” |
| 379 | |
| 380 | You may be wondering what any of this has to do with whether Fossil is a |
| 381 | blockchain, but that is exactly the point: all of this is outside |
| 382 | Fossil’s core hash-chained repository data structure. If you take the |
| 383 | position that you don’t have a “blockchain” unless it allows anonymous |
| 384 | contribution, with any needed restrictions provided only by the very |
| 385 | structure of the managed data, then Fossil does not qualify. |
| 386 | |
| 387 | You can make a good inverse argument, however: because Fossil doesn’t |
| 388 | remember IP addresses in commit manifests or require commit signing, it |
| 389 | allows at least *pseudonymous* commits. When someone clones a remote |
| 390 | repository, they don’t learn email address, IP address, or any other |
| 391 | sort of [PII] of prior committers, on purpose. |
| 392 | |
| 393 | |
| 394 | [alert]: ./alerts.md |
| 395 | [capi]: ./caps/ref.html#i |
| 396 | [mrep]: /help?cmd=remote |
| 397 | [scrub]: /help?cmd=scrub |
| 398 | [sreg]: /help?cmd=self-register |
| 399 | |
| 400 | |
| 401 | # Conclusion |
| 402 | |
| 403 | This author believes it is technologically indefensible to call Fossil a |
| 404 |