This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla features

Apologies for not participating in the gcc-bugs mailing list myself :) 
I'm subscribed to many, many mailing lists.  I also am replying as my
mozilla-webtools normal account holder -- didn't mean to send the
previous mail from my talk2 address.

On Mon, 2001-11-19 at 09:23, Joseph S. Myers wrote:
> The main point is that, when someone sends a follow-up by mail, and that 
> is QP-encoded (say), it appears cleanly in the bug logs (rather than, as 
> at present with GNATS, as raw quoted-printable).  I've explained in my 
> other reply
> that we *do* want attachments to go out in mail.

  OK, then, it would definitely involve a volunteer hacking
to allow this functionality, and preferably providing the patches back
as a parameter-izable option.  Not in there right now, it only sends a
link to the attachment ID in the database.

> gcc-gnats is the current address for submissions to GNATS, not a mailing
> list - so, for replies for existing bug reports converted into Bugzilla,
> we'd need a converter sitting there that sends replies onto
> bugzilla-daemon.  New messages sent out about bugs to people and the lists
> can include bugzilla-daemon somewhere in their header addresses so that
> replies will go there and get properly filed.

  OK, you can just modify the header via our administration interface in
the "editparams.cgi" script.  There's an option there for the "To:" and
"From:" headers so you can chop them up how you'd like -- change "From:"
to "", then set up your Bugzilla procmail filters on
that alias.  Trivial, really.
  There's this little part of me that cringes at seeing Bugzilla being
called gnats, but that's just me :)

> Experience shows this not to be a problem with the GNATS setup.  When spam
> goes to the gcc-gnats address, it gets filed as a "pending" PR since it
> isn't properly formatted as a bug submission, and doesn't get sent to the
> lists, so few people see it.
  Understood.  You'd definitely have some kind of converter front-end to which converts it into a format understands
(or, alternately, modify to accept gccbugs format).  You
configure to stick submissions which don't specify any
defaults into some working queue.  It works the same.  As long as you
have someone who doesn't mind sifting through the spam in that queue
from time to time : )

> Having a converter that converts current gccbug output (received by
> gcc-gnats) into whatever format Bugzilla would expect for emailed bug
> submission, and if appropriate a more Bugzilla-tailored new gccbug script
> as well, is I think essential.  The detail of whether it then creates
> Bugzilla accounts for the people who submit bugs this way I don't care
> about.

  Right, it's as irrelevant to you as it was to me when I used this
system.  Another option is to strip out sender headers entirely in, and make it so that anything coming into the script is
sent in as a certain currently existing user.  Six of one, half a dozen
of the other.
  An important part, too, is setting up procmail filters to filter out
bounces.  Otherwise you can get nasty mailstorms from Bugzilla
auto-replying to an auto-reply address.  That causes database issues,

> Spam will not be properly formatted as a bug report from a bug reporting
> script.  I don't know the best treatment of such mails that can't be
> parsed as bug reports or follow-ups to existing ones, but perhaps they
> should go to a moderator who discards them if spam or enters them manually
> if relevant.

  Yep, that's a problem that has a wetware solution :)

> OK, so the system could daily lock the database, do an XML dump and make
> that available for rsync so we keep the bulk anonymous access to the whole
> database, and back it up as documented?  (The FSF machines have reasonable
> backup procedures, but I don't know about sourceware.)  Is the database of
> bugs cleanly separated from other information such as user passwords (so
> there are no security issues with having it available for anon rsync)?

  Yes, that's almost exactly what I did the last place I adminned
Bugzilla.  The user information table is separate from the bugs table,
but you will get some nasty errors if a bug doesn't have matching user
information when you run a query.  Passwords are encrypted in the
database, but any diligent hacker can eventually pry passwords out of a
hash, particularly if they have offline access.
  Exporting all the bugs in the database as XML, while
processor-intensive, would allow decent replicatability without the
above issue.  Or something which exports everything via mysqldump, then
replaces all the password information with some hash, and also doesn't
export the session table.  However you do it, it would have to be done
with care that you don't expose the sessions and user data.
  So, umm, I guess the answer is "yes and no".  There are security
issues with simply doing a raw dump of the database on a nightly basis
and allowing anon access to it.  They can be worked around with some
diligence on the part of the backup maintainer.


Matthew P. Barnson
Bugzilla Documentation Guru

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]