Hi all:

I am running fossil version: afb4f74808

The Security Audit page shows the developer "user" has write access to tickets. However the permissions for the develop user are: 4bdei. This should turn off access to tickets for the developer right?

Can anybody explain this?

Thanks,

-- rouilj

Possibly now fixed on trunk due to a check-in I just made.

I updated and reinstalled. Using [ba56f5e5cc] I still see the problem.

Other ideas?

-- rouilj

The summary now looks like:

	Code	Forum	Tickets	Wiki	Unversioned Content
"nobody"	read	read	off	read	read
"anonymous"	read	write	off	write	read
"reader"	read	write	off	write	read
"developer"	write	write	off	write	read
New User Default	read	write	off	write	read
Adminstrator	write	write	write	write	read

with [3941824d85].

One thing I don't get is why the admin has read access to unversioned. Shouldn't that be write?

Also congrats on getting back a free letter for the permissions strings.

I assume that deleting a ticket or wiki is done by shunning the artifact. Is this correct?

-- rouilj

One thing I don't get is why the admin has read access to unversioned. Shouldn't that be write?

No, it should not, on purpose.

Also congrats on getting back a free letter for the permissions strings.

I'm not sure cap letter "d" can be considered liberated for quite some time to come. It's stored as a string in each new repo, so whatever reuses this letter in the future will automatically be granted to the Developer user category by default. Therefore, either:

1. Users will have to be warned to remove "d" from the default "dei" user cap set before upgrading to any version that uses "d" for something else. (And many Fossil users will ignore whatever advance warning we do give!)

2. Any future actually-useful capability assigned "d" will have to be appropriate for Developer class users to have, broadly speaking.

Apparently, I never removed the 'd' capability, even though it no longer makes any sense.

A possible re-interpretation of 'd' would be to hide/unhide tickets and wiki pages.

Also, I didn't think tickets or wiki pages were part of "the blockchain". I thought each ticket/wiki page was its own blockchain, independent of the DAG revision tree that tracks file (including embedded docs) revisions.

If that's the case, then a ticket or wiki page could be deleted by removing by removing the blockchain for that ticket or wiki page.

(Though, I think hide/unhide is a better idea. If a ticket/wiki page truly needs to be removed, its artifacts can be shunned.)

Also, I didn't think tickets or wiki pages were part of "the blockchain". I thought each ticket/wiki page was its own blockchain, independent of the DAG revision tree that tracks file (including embedded docs) revisions.

That's effectively true, but tickets and wikis may contain links to arbitrary other elements in the repo, and in turn can be linked to by other elements, so they're kind of "indirectly" part of the blockchain.

However, if a wiki's whole existence were wiped out via deletion of its own private strip of the chain, any links to that page would be invalidated or (worse) perhaps point to different content than intended if the wiki page's name were later reused for a different purpose. (That's analogous to re-using a free()d-then-re-allocated pointer in C, in that the pointer itself is valid, but very probably doesn't point to what it initially pointed to.) It would become impossible to distinguish between a link which points to a now-deleted page amd a link to a page which never existed. Whether that distinction is significant or not is of course debatable, but the current method of simply emptying out a wiki page to signal it as "deleted" doesn't have that property.

I never removed the 'd' capability, even though it no longer makes any sense.

I made a more extensive removal here.

Is there any good reason not to merge it to trunk?

If you could, please first add a comment some place (or places) obvious to warn future maintainers that reusing the 'd' capability is dangerous. There might be many repos in circulation that have users with the 'd' capability already.

The comment should be in some spot that a future maintainer would have to edit in order to be able to reuse the 'd' capability. In other words, the comment should be in a place where it will be difficult to overlook.

please first add a comment some place (or places)

Done.

There might be many repos in circulation that have users with the 'd' capability already.

It should be all of them, to a first approximation, since it was assigned to Developer by default. I'd guess that the percentage of extant repos that have either removed "d" from Developer category or who have moved it elsewhere is in the single digits.

The latest checkin on that branch therefore repurposes the check for "d" cap in the Security Audit to warn that it should be removed from current repos.