From the devel mailing list. I wanted to get a ticket on this so its
not forgotten before release.

The plan also includes a config.ini option to allow access to deleted
properties or deny access to deleted properties. There is no way to
determine what the access rights were for the deleted link property.

This may be related to issue1169513 - History breaks when props are
inaccessible. There isn't a lot of detail on this ticket, so when this
ticket closes we should close 1169513 as well.

------- Forwarded Messages

Date: Fri, 18 Aug 2017 16:05:05 +0200
From: Ralf Schlatterbeck <rsc>
To: roundup-devel
Subject: History Problem
Message-ID: <20170818140505.7psjtkskhalgk52z at runtux.com>

Commit 462b0f76fce8
"issue2550864 - Potential information leakage via journal/history"

breaks roundup databases where a history change removes a link
attribute. Roundup used to deal with schema changes gracefully. Now we
get a traceback in a tracker that had a schema change that removed a
link attribute.

The reason is that the checks in Class.history (for link/unlink but
possibly others) access cls.properties[key] without checking that the
given key still exists in the database.

I'd volunteer to fix this but have a question: What do we want to do for
the security-related problem that displaying the given schema entry
might expose information? Add a new config-item that tells us to:
- - display anyway
- - never display 
- - some heuristics to display?

John, I'm sending this also directly to you because you did many of the
recent security-related changes...

Thanks
Ralf

------- Message 2

Date: Sun, 27 Aug 2017 11:06:27 +0200
From: Ralf Schlatterbeck <rsc>
Subject: Re: Update of journal security filtering

On Sun, Aug 27, 2017 at 12:43:52AM -0400, John P. Rouillard wrote:
> Hi Ralf:
> 
> I just pushed a couple of changes to the journal filtering code.  It
> shouldn't have any effect on your fixes, but you will want to
> 
>    hg pull -u
[...]

Thanks!

> Also I had a thought about how to fix the problem you found as a
> result of my journal filtering. It seems the preferred python way to
> handle this is to capture the exception raised when the retired/invalid
> property is accessed. 

Yes, that was my plan. And then depending on a config setting either
proceed (and show the property anyway) or stop.

Ralf
------- End of Forwarded Messages

On the mailinglist this has been marked as release critical.
Any news?

Now changes to removed properties, and link/unlink events from
non-existing properties or classes no longer trigger a traceback.
Concerning the visibility: We have a new config-item
obsolete_history_roles in the main section that defines which roles may
see removed properties. By default only role Admin is allowed to see
these.