350921 - [email_in] Create an email interface that can create a bug in Bugzilla

Status: RESOLVED FIXED

(Bugzilla :: Incoming Email, enhancement)

Description

[Max Kanat-Alexander]

This is the first part of bug 94850--making email_in.pl able to call post_bug.cgi and create a bug.

Comment 1

[Max Kanat-Alexander]

Attachment: v1

Okay, here's a version of email_in.pl that can post a bug to Bugzilla.

If you have any questions, feel free to ask.

You'll notice one unrelated change in Bugzilla::Install::Requirements--that's just me doing some cleanup as module owner.

Comment 2

[Colin Ogilvie [:cso]]

I've just tried to test this using the following sample email (from the perldoc):

From: my_username@my_domain.co.uk
Subject: Bug Summary

@product = TestProduct
@component = TestComponent
@version = 1.0

This is a bug description. It will be entered into the bug exactly as
written here.

It can be multiple paragraphs.


and I get the following at the end of the very verbose output:

[colin@omicron bugzilla-trunk]$ ./email_in.pl < email_in.txt
return error - 


I wonder if there's something up with one of my module installs?

Comment 3

[Max Kanat-Alexander]

(In reply to comment #2)
> and I get the following at the end of the very verbose output:

  There shouldn't be very verbose output, if you didn't specify -v.

> return error - 

  That's odd. Never seen that error.

> I wonder if there's something up with one of my module installs?

  What's the output of your ./checksetup.pl with the patch applied?

Comment 4

[Colin Ogilvie [:cso]]

Attachment: Checksetup Output

Comment 5

[Colin Ogilvie [:cso]]

Comment on attachment 236310 [details] [diff] [review]
v1

Denying review for the errors, but I'm still getting the return error - with the sample email from the perldoc...


>Index: email_in.pl
>===================================================================

>+use Bugzilla;
>+use Bugzilla::Bug qw(ValidateBugID);
>+use Bugzilla::Constants qw(USAGE_MODE_EMAIL);
>+use Bugzilla::Mailer;
>+use Bugzilla::User;
>+use Bugzilla::Util;

You need to use Bugzilla::BugMail here as well as Bugzilla::Error, as it fails on landfill with "Undefined subroutine &Bugzilla::BugMail::MessageToMTA called at ./email_in.pl line 282, <STDIN> line 15."

Comment 6

[Max Kanat-Alexander]

Attachment: v2

Okay. Well, I fixed the errors, but I'm also getting the "return error -" message, and I have NO idea where it's coming from. It happens somewhere inside the die_handler, because everything seems to work fine if I die($msg) instead of "print STDERR $msg" there.

Comment 7

[Max Kanat-Alexander]

Attachment: v3

Okay, I finally figured it out. :-) That was quite a bug hunt.

You can see the line of code that I added to die_handler, and the comment there that explains it.

Basically, it turns out that [% RETURN %] is actually implemented as a call to Template::Context->throw(), which throws an error. (In other words, it calls "die"). Dumb.

Comment 8

[Colin Ogilvie [:cso]]

Comment on attachment 238945 [details] [diff] [review]
v3

Looks good to me, and appears to work with all the mail I threw at it.

One nit is that it would be nice, since it doesn't post attachments, is that it emails back the user to say "Bug posted but your attachment wasn't".

Probably requires a second review though.

Comment 9

[Colin Ogilvie [:cso]]

Noting here in case I don't get the chance tonight: Enhancements from this bug which should be filed;

1) Allow it to do some verification that $email is actually from $user - bounce-back check, GPG etc.
2) Post attachments to the bug if there are any.

Comment 10

[Max Kanat-Alexander]

Comment on attachment 238945 [details] [diff] [review]
v3

I think ghendricks would be an appropriate reviewer, since he's already dealt a bit with inbound email in importxml.pl.

Comment 11

[Greg Hendricks]

Comment on attachment 238945 [details] [diff] [review]
v3


>+=item C<set_user>
>+
>+Allows you to directly set what L</user> will return. You can use this
>+if you want to bypass L</login> for some reason and directly "log in"
>+a specific L<Bugzilla::User>. Be careful with it, though!
>+

This has me very nervous. This seems like there would be opportunities to spoof users and get away with nasty things. 

Everything else looks good. If you can explain how this cannot be done I will r+ it.

Comment 12

[Max Kanat-Alexander]

(In reply to comment #11)
> This has me very nervous. This seems like there would be opportunities to spoof
> users and get away with nasty things. 
> 
> Everything else looks good. If you can explain how this cannot be done I will
> r+ it.

  It's part of the code--it's not accessible to users.

  It's true that you can pretend to be somebod you're not, using the email interface. That's something that has to be fixed in a future bug. The old email interface was the same way.

Comment 13

[Greg Hendricks]

Comment on attachment 238945 [details] [diff] [review]
v3

I suppose that since all this lets you do is add bugs, the potential for harm is mitigated somewhat. Only other thing to watch out for is DoS attacks from email bug entry.

Comment 14

[Max Kanat-Alexander]

Cha. We can address some of the various issues in future bugs.

Comment 15

[Frédéric Buclin]

Comment on attachment 238945 [details] [diff] [review]
v3

>Index: Bugzilla.pm

>+    return Bugzilla->user if Bugzilla->usage_mode eq USAGE_MODE_EMAIL;


>Index: post_bug.cgi

>+if (Bugzilla->usage_mode eq USAGE_MODE_EMAIL) {


USAGE_MODE_EMAIL is an integer and so == should be used as a comparator instead of eq. Please fix that on checkin.

Comment 16

[Max Kanat-Alexander]

Checking in Bugzilla.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla.pm,v  <--  Bugzilla.pm
new revision: 1.51; previous revision: 1.50
done
RCS file: /cvsroot/mozilla/webtools/bugzilla/email_in.pl,v
done
Checking in email_in.pl;
/cvsroot/mozilla/webtools/bugzilla/email_in.pl,v  <--  email_in.pl
initial revision: 1.1
done
Checking in post_bug.cgi;
/cvsroot/mozilla/webtools/bugzilla/post_bug.cgi,v  <--  post_bug.cgi
new revision: 1.180; previous revision: 1.179
done
Checking in Bugzilla/Constants.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Constants.pm,v  <--  Constants.pm
new revision: 1.57; previous revision: 1.56
done
Checking in Bugzilla/Install/Filesystem.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Filesystem.pm,v  <--  Filesystem.pm
new revision: 1.17; previous revision: 1.16
done
Checking in Bugzilla/Install/Requirements.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Install/Requirements.pm,v  <--  Requirements.pm
new revision: 1.24; previous revision: 1.23
done
Checking in template/en/default/global/user-error.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/global/user-error.html.tmpl,v  <--  user-error.html.tmpl
new revision: 1.193; previous revision: 1.192
done

Comment 17

[Max Kanat-Alexander]

I also noticed that docs/makedocs.pl wasn't including email_in.pl in the index.html page for docs/html/api/, so I fixed that right after checkin:

Checking in docs/lib/Pod/Simple/HTMLBatch/Bugzilla.pm;
/cvsroot/mozilla/webtools/bugzilla/docs/lib/Pod/Simple/HTMLBatch/Bugzilla.pm,v <--  Bugzilla.pm
new revision: 1.2; previous revision: 1.1
done

Comment 18

[Frédéric Buclin]

Documentation is needed to explain how to configure your PC to get incoming emails and pass them to email_in.pl. There is currently no doc at all about this script (and to be honest, I have no idea myself on how to configure my PC to do this).

Comment 19

[Frédéric Buclin]

Attachment: HOWTO config the mail server to redirect emails to email_in.pl

I'm putting this here for the record (comes from justdave on IRC). We can either attach the patch here, or file a separate bug. Also, we have to decide if it should go into email_in.pl itself, or in docs/.