Re: Attachment spam: do we want to edit history?

Ralf Schlatterbeck <[email protected]>
Newsgroups gmane.comp.bug-tracking.roundup.user
Message-ID <[email protected]>
On Thu, Sep 06, 2012 at 10:39:40AM -0400, John P. Rouillard wrote:
> >I've just written a script to completely remove file spam:
> >http://roundup.hg.sourceforge.net/hgweb/roundup/roundup/rev/9f507a042c1b
> 
> By remove do you mean unlink? IIRC you can do unjournalled changes
> from the api, so I assume this unlink is not recorded? Or is it just
> deleted in the next step?

I'm editing the journal, i.e. this changes history.
I'm first removing the offending files if still attached to the issue,
this *will* generate a journal entry, but then I'm removing all journal
information that links to the file. If a journal record is empty after
this I'm removing it. So this doesn't leave any traces on the issue that
the file was there.

> >Do we really want to edit history in this way?
> >I'm for it (for spam only).
> 
> I am also for it, but I think it would be good to leave some sort of
> journal entry in the ticket to indicate that a file was removed due to
> spam.

The offending file object is still in the database and indicates that it
was once linked to the issue.

> I haven't worked with the journal api in a looong time. Is there a way
> to generate a journal entry that is just pure text and has no relation
> to any objects? Ideally if you look at the journal it should say
> something like:
> 
>    date user "file number so and so removed - attachment spam"
> 
> whithout any hyperlinks inside the " enclosed part for a web spider to
> crawl.

I don't know.

> This would provide the audit trail entry at least so if somebody
> really really wanted to, they could manually construct the uri for the
> file and get date and user who created the spam and other attachment
> info (maybe original size??) although not contents as they are zeroed
> out.

The file object is still in the DB.

> I agree with your caution of removing mistakes without noting the
> change, but I think this would be a suitable workaround if the code
> allows it.

Yes, lets hear what others think before taking any actions that can't be
undone.

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.