Roundup Tracker - Issues

Issue 2550954

Title: History display breaks on removed properties
Type: behavior Severity: critical
Components: Web interface, API Versions: devel
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: schlatterbeck Nosy List: ber, rouilj, schlatterbeck
Priority: urgent Keywords: Blocker

Created on 2017-09-25 23:44 by rouilj, last changed 2018-04-19 11:01 by schlatterbeck.

msg6022 Author: [hidden] (rouilj) Date: 2017-09-25 23:44
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>

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


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


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

------- End of Forwarded Messages
msg6067 Author: [hidden] (ber) Date: 2018-02-28 08:05
On the mailinglist this has been marked as release critical.
Any news?
msg6069 Author: [hidden] (schlatterbeck) Date: 2018-04-19 11:01
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
Date User Action Args
2018-04-19 11:01:47schlatterbecksetstatus: open -> closed
messages: + msg6069
components: + API
2018-02-28 08:05:08bersetnosy: + ber
messages: + msg6067
severity: major -> critical
2017-10-27 22:01:48rouiljsetkeywords: + Blocker
2017-10-15 02:08:15rouiljsetpriority: high -> urgent
2017-09-26 01:18:52rouiljsetstatus: new -> open
2017-09-26 01:16:19rouiljsetstatus: open -> new
2017-09-26 01:01:43rouiljsetnosy: + schlatterbeck
2017-09-25 23:46:07rouiljsetstatus: new -> open
priority: high
assignee: schlatterbeck
severity: normal -> major
components: + Web interface
versions: + devel
title: History Problem (fwd) -> History display breaks on removed properties
type: behavior
2017-09-25 23:44:55rouiljcreate