On Dec 17, 2017, at 1:44 PM, Kevin <kyou...@gmail.com> wrote:
>
> I believe deception and impersonation are important.
I agree. One of the core tenets of Fossil is durable accountability, and here
we have a case where it allows the who-did-what history to be muddied.
What Fossil allowed in the case that started this thread is fine: I reassigned
some of my own commits under an incorrect user name to the one I prefer that
fossil-scm.org know me by.
What I hope we get to in this thread are the further implications of the power
which drh has granted me on fossil-scm.org, and whether we wish to limit that
power.
> I would recommend the study of block chain or blockchain technologies,
> such as Bitcoin. These technologies use signed hashes.
I don’t see how that gets you anything but pseudonymity within the system.
That may be useful, and we’ll get to that below, but I don’t think that’s good
enough for fossil-scm.org.
As I understand them, cryptocurrencies only give you accountability at the
borders of the system when the pseudonymous identity gets transformed to a real
identity. In the case of Bitcoin, it happens when you cash out.
Case in point: we don’t know who Satoshi Nakamoto is, because he has never
cashed out any of his/their Bitcoins.
If anything about Fossil changes as a result of this discussion, I want to
allow it to work *within* a DVCS trust relationship tree. There is no
analogous “border” in Fossil for users to cross.
> someone added a copyright comment in several pre-existing open source
> program sources, as if they were the author.
Fossil already protects against that.
If I change the program text as you say, we have the version-controlled history
to fall back on.
If I reassign one of drh’s commits to myself, Fossil still remembers the
original committer name. Fossil is just *showing* something different in the
UI now.
What I want is an option that allows a repo admin to insist that the identity
on the checkins match the logged-in user name.
This should be optional, and maybe fossil-scm.org doesn’t end up enabling it.
I think I might do so on my public repos, though.
The larger the project, the less likely you will probably want to enable such
features because trust becomes more complicated:
Alice -> Bob -> Charlize -> Donny
Donny “owns” the main project repo, and he has given login rights to Charlize.
She in turn publishes her repository publicly, and has given Bob the right to
log into it, and he in turn has done the same for Alice. If Charlize syncs
with Donny, her repo may push artifacts originally checked in by Alice or Bob.
That sort of thing is much rarer in the Fossil world than in the Git world. If
I, as the repo maintainer, decide that trust should not be transitive in this
way, I should be able to insist that checkins from Charlize be tagged as “from
Charlize” only.
Whether that means rewriting authorship during sync or denying non-matching
artifacts is a separate matter, one I don’t feel qualified to opine on, since
it probably impacts the very operation of Fossil at a deep level.
The only other way I see to go is to depend on some outside identity provider.
GitHub does it by being centralized, but part of the problem is that Fossil
doesn’t currently get that same benefit even when you do use it as a
centralized DVCS.
Git does it by using email addresses for identity instead of user names, which
lets Git leverage the uniqueness of email addresses, enforced by DNS, domain
name registrars, and such. Coupled with GPG, you can assert identity even in
the face of transitive trust relationships, which is why the world’s Linux
contributors don’t all need to coordinate with Linus Torvalds to get a login on
his central repo. I don’t think we want to complicate Fossil in this same way.
Another path may be to use protocols like OAUTH. The identity provider makes
an assertion, and the Fossil repo can then choose what to do about that
assertion.
The central repo’s admin could choose one trusted OAUTH provider, so that in my
distributed trust relationship example above, Donny could trust Alice because
he trusts the OAUTH provider. Donny’s repo could run in three modes:
a) I trust anyone that my OAUTH provider trusts
b) I trust anyone on this whitelist, which my OAUTH provider also trusts; that
trust is transitive
c) I trust only those on this whitelist
In mode c, Alice gets to push to Donny only if she gets her identity approved
by Charlize and Donny, in addition to Bob, who already trusts her. Until then,
commits from her get stripped at the Bob->Charlize barrier.
In mode b, Alice gets to push to Donny because Donny trusts Charlize to
whitelist people wisely. This is how some clubs operate: anyone may invite any
other person, transitively, but membership is always sponsored.
In mode a, everyone just coordinates directly with the OAUTH provider. Donny
trusts the OAUTH provider to make sensible assertions. In this mode, the
Fossil repo’s contents could be near-pseudonymous, with commits traceable back
to real-world identities only when law enforcement gets involved.
That then leads to the possibility of trusting *all* OAUTH providers. This
might be of use in a wiki-only project, where any contribution is welcome. All
that is wanted is a strong pseudonymous identity proof. All we care about in
this mode is that you are unspoofably you.
This in turn gets you to true pseudonymous identity protocols like SQRL, which
only prevent identity spoofing, but prove nothing about real-world identity
unless someone manages to seize the user’s private keys. (On purpose.)
> Another example is where the original author is over written, or not
> mentioned or barely mentioned.
Technical means are generally poor solutions to social problems.
I don’t think the problems I’m advocating for a fix to are primarily social
problems. They’re more “How do I *x* in the face of *y*?” problems.
The social aspect of the problem is already reasonably well solved in Fossil
already: If I were to impersonate drh on the fossil-scm.org repo, I would lose
my login privileges, and all my fraudulent checkins would get pushed off onto a
branch, backed out, and/or relabeled. In this hypothetical, I violated
Wheaton’s Law and that problem got solved.
I want to restrict this thread to the technical issues: preventing
wyoung/tangent confusions, or helping Donny trust Alice, or or giving Donny the
tools to *not* trust Alice just because Bob trusts Alice.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
