Discussion:
tangent vs. wyoung on recent commti
(too old to reply)
jungle Boogie
2017-12-14 17:19:11 UTC
Permalink
Hi All,

This commit caught my eye:
http://fossil-scm.org/index.html/info/ec059849f5c73a43

User & Date:wyoung on 2017-12-13 21:37:20
Original User & Date:tangent on 2017-12-13 21:37:20

So Warren edited a file at the same exact time as tangent?

Clicking on tangent, I see this:
http://fossil-scm.org/index.html/timeline?c=2017-12-13+21:37:20&u=tangent

But those both show Warren's name.

I don't mean to call out you, Warren, directly and I certainly am not
pointing a proverbial finger at you.
--
-------
inum: 883510009027723
sip: ***@sip2sip.info
Richard Hipp
2017-12-14 18:07:36 UTC
Permalink
Post by jungle Boogie
Hi All,
http://fossil-scm.org/index.html/info/ec059849f5c73a43
User & Date:wyoung on 2017-12-13 21:37:20
Original User & Date:tangent on 2017-12-13 21:37:20
So Warren edited a file at the same exact time as tangent?
No. The commit was originally by a user named "tangent" at the time
shown. Then a tag was added
(http://fossil-scm.org/index.html/info/80f1e8a521518104) that changed
the username to "wyoung".

I'm guessing that "tangent" is some local username on Warren's
desktop. After he committed, he noticed that the commit picked up the
wrong username and so he changed it to his "public" username "wyoung".
I don't have any issues with this. In fact, I think it was the right
thing to do.
--
D. Richard Hipp
***@sqlite.org
jungle Boogie
2017-12-14 18:27:40 UTC
Permalink
Post by Richard Hipp
Post by jungle Boogie
Hi All,
http://fossil-scm.org/index.html/info/ec059849f5c73a43
User & Date:wyoung on 2017-12-13 21:37:20
Original User & Date:tangent on 2017-12-13 21:37:20
So Warren edited a file at the same exact time as tangent?
No. The commit was originally by a user named "tangent" at the time
shown. Then a tag was added
(http://fossil-scm.org/index.html/info/80f1e8a521518104) that changed
the username to "wyoung".
I'm guessing that "tangent" is some local username on Warren's
desktop. After he committed, he noticed that the commit picked up the
wrong username and so he changed it to his "public" username "wyoung".
I don't have any issues with this. In fact, I think it was the right
thing to do.
Ah, that's probably what it is. I don't see a notation of an edit. Am
I missing that, or are username changes no recorded?
Post by Richard Hipp
--
D. Richard Hipp
--
-------
inum: 883510009027723
sip: ***@sip2sip.info
Warren Young
2017-12-14 19:13:18 UTC
Permalink
Post by jungle Boogie
So Warren edited a file at the same exact time as tangent?
Fossil arguably has a bug here, where if you check a change in as local user name “tangent”, as I do here, then *later* do a “fossil sync” to a URL with a user name, some bit of the local on-disk state remembers that you originally cloned the repo as tangent and makes your changes under that name. Then when you go to push to the remote repo, it uses your remote user name and password credentials, but the changes are tagged with your local user name.

I think Fossil ought to catch this kind of thing and either silently rewrite the user name or force some local fix-up it can’t be done automatically for some reason.

This kind of thing happens when a previous outsider to a project is later granted privileges, but under a different name.

I assume Fossil is the way it currently is because:

a) many people use the same user name everywhere
b) it’s a rare occurrence; and
c) it’s easy to fix when it happens

But even knowing all of this, it’s happened to me twice with the fossil-scm.org repository, once from two different machines. The first was a pure surprise to me on my first checkin to fossil-scm.org, and the second happened to me yesterday because I missed one client machine when I went around and closed, re-cloned and re-opened the fossil-scm.org repository to make each one forget about user tangent.

I classify this as a bug because it could be used for an impersonation attack. I expect that it would not allow me to check changes in as drh simply by creating a local drh user, since that’s a known user and I cannot produce drh’s password, but it certainly will let me check changes in as billgates.
Scott Robison
2017-12-14 19:31:21 UTC
Permalink
I'd bet that you can commit as anyone and push it if you have that access.
You probably wouldn't keep that access for long, though.
Post by Warren Young
Post by jungle Boogie
So Warren edited a file at the same exact time as tangent?
Fossil arguably has a bug here, where if you check a change in as local
user name “tangent”, as I do here, then *later* do a “fossil sync” to a URL
with a user name, some bit of the local on-disk state remembers that you
originally cloned the repo as tangent and makes your changes under that
name. Then when you go to push to the remote repo, it uses your remote
user name and password credentials, but the changes are tagged with your
local user name.
I think Fossil ought to catch this kind of thing and either silently
rewrite the user name or force some local fix-up it can’t be done
automatically for some reason.
This kind of thing happens when a previous outsider to a project is later
granted privileges, but under a different name.
a) many people use the same user name everywhere
b) it’s a rare occurrence; and
c) it’s easy to fix when it happens
But even knowing all of this, it’s happened to me twice with the
fossil-scm.org repository, once from two different machines. The first
was a pure surprise to me on my first checkin to fossil-scm.org, and the
second happened to me yesterday because I missed one client machine when I
went around and closed, re-cloned and re-opened the fossil-scm.org
repository to make each one forget about user tangent.
I classify this as a bug because it could be used for an impersonation
attack. I expect that it would not allow me to check changes in as drh
simply by creating a local drh user, since that’s a known user and I cannot
produce drh’s password, but it certainly will let me check changes in as
billgates.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andy Bradford
2017-12-15 18:33:50 UTC
Permalink
Fossil arguably has a bug here, where if you check a change in as
local user name ``tangent'', as I do here, then *later* do a ``fossil
sync'' to a URL with a user name, some bit of the local on-disk state
remembers that you originally cloned the repo as tangent and makes
your changes under that name.
I disagree that this is a bug. I consider it useful flexibility.
I classify this as a bug because it could be used for an impersonation
attack.
Fossil records which user synchronized the content in the recvfrom table
so the owner of the remote repository knows who did it if he cares.

As stated in the past, Fossil is meant for a tighter group of
developers---perhaps this perception has changed---one in which
impersonation is unlikely.

Andy
--
TAI64 timestamp: 400000005a3415b3
Richard Hipp
2017-12-15 18:52:55 UTC
Permalink
Post by Andy Bradford
Fossil arguably has a bug here, where if you check a change in as
local user name ``tangent'', as I do here, then *later* do a ``fossil
sync'' to a URL with a user name, some bit of the local on-disk state
remembers that you originally cloned the repo as tangent and makes
your changes under that name.
I disagree that this is a bug. I consider it useful flexibility.
I classify this as a bug because it could be used for an impersonation
attack.
Fossil records which user synchronized the content in the recvfrom table
so the owner of the remote repository knows who did it if he cares.
As stated in the past, Fossil is meant for a tighter group of
developers---perhaps this perception has changed---one in which
impersonation is unlikely.
I was very aware of all of these factors when I designed Fossil, 10
years ago. Impersonation was a concern. But in a DVCS, there really
is no way around it.

Defenses include:

(1) The rcvfrom table that shows clearly where all artifacts
originated, thus allowing the originator of a deception to be tracked
down and dealt with administratively.

(2) Check-ins can be signed using GPG or PGP. (I do this on TH3, fwiw.)
--
D. Richard Hipp
***@sqlite.org
Ron W
2017-12-14 20:38:15 UTC
Permalink
Date: Thu, 14 Dec 2017 12:31:21 -0700
Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
I'd bet that you can commit as anyone and push it if you have that access.
You probably wouldn't keep that access for long, though.
As I understand it, Fossil's "check in" permission really means "push"
permission. That is, whether a repo will accept a push from another repo
under that user name.

Local, command line usage seems to grant the command line user full
permissions as long as the user has RW access to the repo file, itself.

Right now, I can't test this to confirm this behavior.
Stephan Beal
2017-12-14 21:30:43 UTC
Permalink
Post by Ron W
Local, command line usage seems to grant the command line user full
permissions as long as the user has RW access to the repo file, itself.
Right now, I can't test this to confirm this behavior.
That's correct: all CLI commands simply bypass (i.e. don't check)
permissions. Only client/server commands check permissions.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Ron W
2017-12-17 17:11:06 UTC
Permalink
Date: Sun, 17 Dec 2017 09:56:57 +0000
Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
<CADJpCb=AJUXV-zx6jZ6NJXB63MUZnNXPT4cQ5GUr=O5
Content-Type: text/plain; charset="utf-8"
Unless I am misunderstanding what you mean by permanent record, I don't
think this is possible in a DVCS. In a DVCS the remote can be different and
even change between pull/syncs
I was referring to the difference between "artifacts" and entries in a
table in the database.

Fossil only sync's artifacts between repositories. Anything in the db that
isn't an artifact is local metadata.

Besides tags added when a commit is made, Fossil allows additional tags to
be created. It does this by creating "control artifacts", therefore making
these additional tags sync-able between repos.

By adding "rcvfrom" tags to commits received from the other repos, any
given commit would then be trace-able to its originating repo - even if any
of the intermediate repos is no longer available.
Mark Janssen
2017-12-17 18:13:17 UTC
Permalink
Then what is the point of recvfrom? It will then just reduce to the repo
where the artifact was created. This might be useful, but it is not what
recvfrom means.
On Sun, Dec 17, 2017 at 7:00 AM, <
Date: Sun, 17 Dec 2017 09:56:57 +0000
Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
<CADJpCb=AJUXV-zx6jZ6NJXB63MUZnNXPT4cQ5GUr=
Content-Type: text/plain; charset="utf-8"
Unless I am misunderstanding what you mean by permanent record, I don't
think this is possible in a DVCS. In a DVCS the remote can be different and
even change between pull/syncs
I was referring to the difference between "artifacts" and entries in a
table in the database.
Fossil only sync's artifacts between repositories. Anything in the db that
isn't an artifact is local metadata.
Besides tags added when a commit is made, Fossil allows additional tags to
be created. It does this by creating "control artifacts", therefore making
these additional tags sync-able between repos.
By adding "rcvfrom" tags to commits received from the other repos, any
given commit would then be trace-able to its originating repo - even if any
of the intermediate repos is no longer available.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Kevin
2017-12-17 20:44:35 UTC
Permalink
Post by Richard Hipp
Fossil arguably  has a  bug here, where  if you check  a change  in as
local user name ``tangent'', as I  do here, then *later* do a ``fossil
sync'' to a URL with a user  name, some bit of the local on-disk state
remembers that  you originally  cloned the repo  as tangent  and makes
your changes under that name.
I disagree that this is a bug.  I consider it useful flexibility.
I classify this as a bug because it could be used for an impersonation
attack.
Fossil records which user synchronized the content in the recvfrom
table
Post by Richard Hipp
so the owner of the remote repository knows who did it if he cares.
As  stated  in  the  past,  Fossil  is
meant  for  a  tighter  group  of
Post by Richard Hipp
developers---perhaps   this  perception   has  changed---
one   in  which
Post by Richard Hipp
impersonation is unlikely.
I was very aware of all of these factors when I designed Fossil, 10
years ago.  Impersonation was a concern.  But in a DVCS, there really
is no way around it.
(1) The rcvfrom table that shows clearly where all artifacts
originated, thus allowing the originator of a deception to be tracked
down and dealt with administratively.
(2) Check-ins can be signed using GPG or PGP.  (I do this on TH3, fwiw.)
-- 
I believe deception and impersonation are important.

I would recommend the study of block chain or blockchain technologies,
such as Bitcoin. These technologies use signed hashes. 

I have found they have a significant perspective on when an event occurs,
in what order events occur and who is the originator of the event.

An interesting, and annoying, deception I found a few years ago was where
someone added a copyright comment in several pre-existing open source
program sources, as if they were the author.

Another example is where the original author is over written, or not
mentioned or barely mentioned. 

I was working at a bank in 2001, where a programmer got an award for
installing a major fix very quickly. The designer had a big smile on his
face, because the programmer simply copied the exact code from the
designer and implemented it. The designer was never mentioned.

Most of us have similar stories.
Warren Young
2017-12-19 00:55:16 UTC
Permalink
Post by Kevin
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.
Post by Kevin
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.
Post by Kevin
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.)
Post by Kevin
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.
Warren Young
2017-12-19 02:35:42 UTC
Permalink
Post by Warren Young
Git does it by using email addresses for identity instead of user names
It also occurs to me that Git typically inverts the push/pull relationship as compared to Fossil. I can’t get random checkins into Linus’ git tree merely because one of his trusted lieutenants trusts me because Linus must *pull* from the lieutenant’s tree, which lets him decide whether he trusts each checkin individually.

Fossil’s model says, “Whatever you say about the ownership of these commits, I trust, because you can log into me.”

That’s one of Fossil’s advantages of course: In a small organization with high trust levels, the owner of the central repo doesn’t need to spend time acting as a gatekeeper for each commit. Most problems can be dealt with adequately post-facto.

If any changes are made, they should be done with this philosophical difference in mind. I do not intend that Fossil turn into Git.

It is also the case that unlimited transitive trust probably isn’t the best plan for all Fossil users.
jungle boogie
2017-12-19 03:22:06 UTC
Permalink
Thus said Warren Young on Mon, 18 Dec 2017 17:55:16 -0700
Post by Warren Young
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.
I can't remember the repo drh mentioned, but he signs commits with a GPG
key, maybe Th1 repo?. W.r.t. signing commits, I think this information
is only shown in the manifest link:
https://www.fossil-scm.org/skins/original/artifact/a6c5a4620a5388fd

I think I asked something to the effect of, can this information be
shown in the overview section of a commit, but since that hasn't really
been asked for, it was assumed it wasn't really a needed feature.

And honestly, it would have only provided some assurance if you had
signed the commit with a gpg key.

So if you committed something as drh with an improved overview section
showing gpg keys, would this has prevented confusion? Would we have
easily seen wyoung attempted to commit as drh, because of a missing gpg
key? I don't even know what happens if the drh has gpg keys setup and
wyoung attempts a commit. Would the commit work and not be signed?
Warren Young
2017-12-19 04:43:21 UTC
Permalink
Post by jungle boogie
I can't remember the repo drh mentioned
TH3, the paid-for test harness for SQLite:

https://sqlite.org/th3.html
Post by jungle boogie
So if you committed something as drh with an improved overview section showing gpg keys, would this has prevented confusion?
As far as I can tell from my brief scan of the docs on this plus some grepping of the code, it looks like signatures just let you *later* prove that you created the manifest by handing over the public half of the key used to sign it. They aren’t used by “fossil sync” to deny the sync if the signatures don’t match known, trusted public keys.

For that to be of any use to what I’m talking about, the remote Fossil instance would need some way to retrieve those public keys during the sync process so that it can decide whether to accept the provided artifacts.

If this future Fossil stores that as part of the user record, then this effectively prevents transitive trust. To reuse my earlier post’s example, because Alice does not have a login on Donny’s repo, checkins made by Alice on Bob’s repo and then sync’d to Charlize’s repo won’t be accepted by Donny’s repo because it cannot look up her public key and thereby verify that the checkins signed by Alice are legitimate.

If future Fossil gets that from somewhere else, you then have the familiar trust problem that has made PGP-signed email completely fail to catch on widely.

That’s why I suggested OAUTH or SQRL, if you only need pseudonymous identity proofs.

All of this is far more complicated than where we started out, though, which is why fossil-scm.org accepted checkins from “tangent” in the first place. I’d have thought it would say, “Who the heck is tangent? No. You can’t send me that.”

I’d have gotten an error, and I’d have figured out the problem and fixed it before it became part of the public record on fossil-scm.org. Twice.
Post by jungle boogie
what happens if the drh has gpg keys setup and wyoung attempts a commit. Would the commit work and not be signed?
I believe it would currently be accepted, but then if anyone goes and *checks* those signatures, the fraudulent ones would be detected.

Signature based systems buy you other problems, too, like key revocation, multiple keys per user, etc.
Ron W
2017-12-18 04:58:45 UTC
Permalink
Date: Sun, 17 Dec 2017 18:13:17 +0000
Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
Then what is the point of recvfrom? It will then just reduce to the repo
where the artifact was created. This might be useful, but it is not what
recvfrom means.
All I'm suggesting is that the information already being put in the
"rcvfrom" table (that DRH mentioned) also be saved as tags to the commits
they refer to. Therefore, the tags will have the same meaning as the
entries in the existing "rcvfrom" table.
Jan Nijtmans
2017-12-18 09:12:16 UTC
Permalink
Post by Ron W
All I'm suggesting is that the information already being put in the
"rcvfrom" table (that DRH mentioned) also be saved as tags to the commits
they refer to. Therefore, the tags will have the same meaning as the entries
in the existing "rcvfrom" table.
Well, I don't think this is even possible, neither does it help accomplishing
what you want. Tags can easily forged as well. Another problem: tags, when
created in one repository will later synchronized to other repositories
(even back to the original one), so I'm really not sure what the
value of the information in it really is ..... I wouldn't go this path.

My suggestion would be: try to come up with a patch, which does what
you suggest. I don't think it would help anything, but feel free to prove
me wrong!

Thanks!
Jan Nijtmans
Stephan Beal
2017-12-18 11:13:08 UTC
Permalink
Fwiw, i agree completely, plus suspect (without knowing for certain) that
including a user's IP (and thus, indirectly, location) in the permanent
record _might_ run afoul of privacy laws in some jurisdictions.

----- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.
Post by Ron W
Post by Ron W
All I'm suggesting is that the information already being put in the
"rcvfrom" table (that DRH mentioned) also be saved as tags to the commits
they refer to. Therefore, the tags will have the same meaning as the
entries
Post by Ron W
in the existing "rcvfrom" table.
Well, I don't think this is even possible, neither does it help accomplishing
what you want. Tags can easily forged as well. Another problem: tags, when
created in one repository will later synchronized to other repositories
(even back to the original one), so I'm really not sure what the
value of the information in it really is ..... I wouldn't go this path.
My suggestion would be: try to come up with a patch, which does what
you suggest. I don't think it would help anything, but feel free to prove
me wrong!
Thanks!
Jan Nijtmans
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Loading...