In message <20111017081202.GB22486@runtux.com>,
Ralf Schlatterbeck writes:

>On Sat, Oct 15, 2011 at 06:49:41PM -0400, John P. Rouillard wrote:
>> Hi all:
>> 
>> With the work going on with pgp signing of email messages, I thought
>> this may be a good time to bring up the idea of attaching an origin to
>> transactions that change the database.
>
>Nice. Can you put this idea into the issue tracker at
>http://issues.roundup-tracker.org/
>(as an "rfe" which translates to "request for enhancement" I think :-)
>
>I've had some usecases where it would be nice to find out the origin
>of a request from a detector... You're adding some interesting usecases.

The original use case was for secure tickets where only certain people
are allowed to view them. For my tutorial example, I am using the nosy
list as the access control list. If I allow email updates to tickets,
it is trivial to forge a from address and change the nosy list
(Subject: ... [nosy=+badguy]). So I have to add a caveat that you have
to disable email changes (or filter the emails in some way before they
hit roundup) in order for the security to be less soft.

Here is the original message as well.

============
Hi all:

With the work going on with pgp signing of email messages, I thought
this may be a good time to bring up the idea of attaching an origin to
transactions that change the database.

E.G. while you may want to allow new messages to be added to an issue
via email, changing the assignedto person may be done only via the web
or openpgpg signed emails.

I am specifically thinking of supplying the info to auditors so they
can make useful decisions on allowing/denying a database change, but
it may be useful for reactors as well.

Maybe adding a db.requestmode() similar to db.getuid(), or maybe a
generalized version of the request object available to the web
interface could be created. Then it could be set by the front end to:

   web
   xmlrpc
   email
   openpgp-email (for a validated signed email)
   cli
   program-<prog name>

via some function call and it would default to none if the program
didn't set its identifier. Then in the auditor/reactor you could use

   if not db.requestmode() in ['web', 'xmlrpc', 'openpgp-email', 'cli']:
        raise Reject, "Change did not arrive via autheticated channel"
====================

-- rouilj

Interesting, for a customer I have a similar setup: we have a
"confidential" flag (Boolean) that makes the issue readable only for
people on the nosy list if set.
I have made an additional check-method that allows visibility of
messages only if the issue to which the message is connected is visible
for the user -- this can be done with permission methods (in our setup
the most confidential information is in messages, so a user could
shoulder-surf or otherwise find out the message number to get access to
confidential information if messages were not protected by permissions).
I've also made an auditor that tests if someone attaches an already
existing message to an issue (e.g. via XMLRPC or a crafted web-request)
to get read-access to the message. But I failed to notice how easy it
would be to forge emails ... 

so it looks like there are several use-cases for your proposal.

Ralf Schlatterbeck in msg4450 said:

> I have made an additional check-method that allows
> visibility of messages only if the issue to which the
> message is connected is visible for the user

Yup did the same for my messages class. I left doing the
same for the file class as an exercise for the students 8-).

> I've also made an auditor that tests if someone attaches
> an already existing message to an issue (e.g. via XMLRPC
> or a crafted web-request) to get read-access to the
> message.

In my case I only allow adding a message to the issue's
messages multilink to be done by the owner of the message
being added. So if the user didn't originate the message,
s/he can't add it to any other issue.

> But I failed to notice how easy it would be to forge
> emails ...

Yup. It's a pretty big hole unfortunately. It can be mitigated
somewhat by forcing all changes to be sent to the nosy list (otherwise
a message with no body will result in an invisible change except in
the history of the issue). Hopefully with all changes being sent to
the nosy list, somebody will notice the nosy list change. But that is
more a detection method in absence of being able to limit the change
in the first place.

On Tue, Oct 18, 2011 at 08:29:06PM +0000, John Rouillard wrote:
> > I've also made an auditor that tests if someone attaches
> > an already existing message to an issue (e.g. via XMLRPC
> > or a crafted web-request) to get read-access to the
> > message.
> 
> In my case I only allow adding a message to the issue's
> messages multilink to be done by the owner of the message
> being added. So if the user didn't originate the message,
> s/he can't add it to any other issue.

Same here, seems we have invented the same wheel independently :-)

> > But I failed to notice how easy it would be to forge
> > emails ...
> 
> Yup. It's a pretty big hole unfortunately. It can be mitigated
> somewhat by forcing all changes to be sent to the nosy list (otherwise
> a message with no body will result in an invisible change except in
> the history of the issue).

Yes we have that and since this is a corporate setting where most people
working on an issue know each other it would be noticed with high
probability.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   http://www.runtux.com
Reichergasse 131, A-3411 Weidling       email: office@runtux.com
osAlliance member                       email: rsc@osalliance.com