Re: [fossil-users] tangent vs. wyoung on recent commti

[Warren Young]

On Dec 18, 2017, at 8:22 PM, jungle boogie  wrote:
> 
> I can't remember the repo drh mentioned

TH3, the paid-for test harness for SQLite:

   https://sqlite.org/th3.html

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

> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[jungle boogie]

Thus said Warren Young on Mon, 18 Dec 2017 17:55:16 -0700

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?



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Warren Young]

On Dec 18, 2017, at 5:55 PM, Warren Young  wrote:
> 
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Warren Young]

On Dec 17, 2017, at 1:44 PM, Kevin  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 

Re: [fossil-users] tangent vs. wyoung on recent commti

[Stephan Beal]

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.

On Dec 18, 2017 10:12, "Jan Nijtmans"  wrote:

> 2017-12-18 5:58 GMT+01:00 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
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Jan Nijtmans]

2017-12-18 5:58 GMT+01:00 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Ron W]

On Sun, Dec 17, 2017 at 9:11 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Sun, 17 Dec 2017 18:13:17 +
> From: Mark Janssen <mpc.jans...@gmail.com>
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Kevin]

On Fri, 15 Dec 2017 13:52:55 -0500, D. Richard Hipp 
wrote:
>On 12/15/17, Andy Bradford  wrote:
>> Thus said Warren Young on Thu, 14 Dec 2017 12:13:18 -0700:
>>
>>> 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.)
>-- 
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.





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Mark Janssen]

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.

Op zo 17 dec. 2017 18:11 schreef Ron W :

> On Sun, Dec 17, 2017 at 7:00 AM, <
> fossil-users-requ...@lists.fossil-scm.org> wrote:
>>
>> Date: Sun, 17 Dec 2017 09:56:57 +
>> From: Mark Janssen 
>> Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
>> Message-ID:
>> 

Re: [fossil-users] tangent vs. wyoung on recent commti

[Ron W]

On Sun, Dec 17, 2017 at 7:00 AM, 
wrote:
>
> Date: Sun, 17 Dec 2017 09:56:57 +
> From: Mark Janssen 
> Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
> Message-ID:
> 

Re: [fossil-users] tangent vs. wyoung on recent commti

[Richard Hipp]

On 12/15/17, Andy Bradford  wrote:
> Thus said Warren Young on Thu, 14 Dec 2017 12:13:18 -0700:
>
>> 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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Andy Bradford]

Thus said Warren Young on Thu, 14 Dec 2017 12:13:18 -0700:

> 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: 40005a3415b3


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Stephan Beal]

On Thu, Dec 14, 2017 at 9:38 PM, Ron W  wrote:

> 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Ron W]

On Thu, Dec 14, 2017 at 2:31 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Thu, 14 Dec 2017 12:31:21 -0700
> From: Scott Robison <sc...@casaderobison.com>
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Scott Robison]

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.

On Dec 14, 2017 12:13 PM, "Warren Young"  wrote:

> On Dec 14, 2017, at 10:19 AM, jungle Boogie 
> wrote:
> >
> > 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.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Warren Young]

On Dec 14, 2017, at 10:19 AM, jungle Boogie  wrote:
> 
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[jungle Boogie]

On 14 December 2017 at 10:07, Richard Hipp  wrote:
> On 12/14/17, jungle Boogie  wrote:
>> 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?
>>
>
> 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?

> --
> D. Richard Hipp
> d...@sqlite.org


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] tangent vs. wyoung on recent commti

[Richard Hipp]

On 12/14/17, jungle Boogie  wrote:
> 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?
>

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
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] tangent vs. wyoung on recent commti

[jungle Boogie]

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=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: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users