744952 - TB: Modern MIME parser

Status: RESOLVED WORKSFORME

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Who is/are the point of contact(s) for this review?
    
Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):
    
Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:
    
Does this request block another bug? If so, please indicate the bug number This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?

Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)

Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?

Are there any portions of the project that interact with 3rd party services?

Will your application/service collect user data? If so, please describe 

If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):

Desired Date of review (if known from https://mail.mozilla.com/home/[e-mail]/Security%20Review.html) and whom to invite.

Comment 1

[Joshua Cranmer [:jcranmer]]

(In reply to Curtis Koenig [:curtisk] from comment #0)
> Who is/are the point of contact(s) for this review?

I guess that would be me.

> Please provide a short description of the feature / application (e.g.
> problem solved, use cases, etc.):

Providing a new API for an internal parsing component of Thunderbird, with the expectation that the current implementation will be replaced with the new one in the future.

> Please provide links to additional information (e.g. feature page, wiki) if
> available and not yet included in feature description:

<http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_frm/thread/cf8c349907d129d1/c0c96c6df6abc68f> is the original proposal,
<https://mail.mozilla.org/pipermail/tb-planning/2012-January/001522.html> has some more notes.

> Does this request block another bug? If so, please indicate the bug number
> This review will be scheduled amongst other requested reviews. What is the
> urgency or needed completion date of this review?

The work is being implemented in bug 740652. It's not particularly urgent, and I'm also not sure how much of a security review it needs.

> Does this feature or code change affect Firefox, Thunderbird or any product
> or service the Mozilla ships to end users?

It will not have an immediate effect on Thunderbird/SeaMonkey instances, but it adds an API which will be made available to extension authors and which internal usage is intended to eventually use.

> Are there any portions of the project that interact with 3rd party services?

No. The closest it comes is handling input that will have been generated by 3rd party products/services and which has a potential for being malicious.

> Will your application/service collect user data? If so, please describe 

No.

> Desired Date of review (if known from
> https://mail.mozilla.com/home/[e-mail]/Security%20Review.html)
> and whom to invite.

I do not expect this to be ready before May at the earliest.

Comment 2

[Joshua Cranmer [:jcranmer]]

(In reply to Joshua Cranmer [:jcranmer] from comment #1)
> The work is being implemented in bug 740652.
Make that bug 746052 (dyslexia strikes again).

Comment 3

[Joshua Cranmer [:jcranmer]]

(In reply to Joshua Cranmer [:jcranmer] from comment #1)
> > Does this request block another bug? If so, please indicate the bug number
> > This review will be scheduled amongst other requested reviews. What is the
> > urgency or needed completion date of this review?
> 
> > Desired Date of review (if known from
> > https://mail.mozilla.com/home/[e-mail]/Security%20Review.html)
> > and whom to invite.

Would it be possible to schedule a review for sometime in June?

Comment 4

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

What date would you like? Available dates can be found here: https://mail.mozilla.com/home/[e-mail]/Security%20Review.html

Comment 5

[Joshua Cranmer [:jcranmer]]

(In reply to Curtis Koenig [:curtisk] from comment #4)
> What date would you like? Available dates can be found here:
> https://mail.mozilla.com/home/[e-mail]/Security%20Review.html

Could I schedule one on Thursday, June 21?

Comment 6

[Joshua Cranmer [:jcranmer]]

(In reply to Joshua Cranmer [:jcranmer] from comment #5)
> (In reply to Curtis Koenig [:curtisk] from comment #4)
> > What date would you like? Available dates can be found here:
> > https://mail.mozilla.com/home/[e-mail]/Security%20Review.html
> 
> Could I schedule one on Thursday, June 21?

Ping?

Comment 7

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

:jcranmer - sorry, due to lots of people on PTO last week we did not have a triage so here is what I think we need to do. Ping :dveditz and check next course of action...

:dveditz - this bug is assigned to you, did we decide if you were going to do a solo review of this or are you leading a team review?

Comment 8

[Joshua Cranmer [:jcranmer]]

Would this Thursday be a doable opportunity, or is it too soon?

Comment 9

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I will ask dveditz what he thinks, and see if we need a full review.

Comment 10

[Daniel Veditz [:dveditz]]

We don't need a high-level group review on this. I did a quick scan over the code and we probably want a deeper look at some point when it's ready to be integrated with existing code (at the moment it appears pretty much standalone and uncalled). The primary win for security would be in taking out some scary and mostly unmaintainanble C-code parsing and replacing it with a memory-safe language, and well-documented at that (although the trade-off is scary, equally-hard to maintain, regexp parsing -- "now you have two problems"). But that's generally going to lead to correctness bugs, not security problems. At least until you get around to implementing S/MIME or PGP where correctness problems can easily be security problems.

Comment 11

[Joshua Cranmer [:jcranmer]]

Just so I'm clear: this means that we don't need to have a security review meeting then?

I'll definitely keep you in the loop if/when I get to the possibly sec-sensitive stuff (S/MIME, PGP, maybe TNEF if it has some security stuff in there).

Comment 12

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Joshua Cranmer [:jcranmer] from comment #11)
> Just so I'm clear: this means that we don't need to have a security review
> meeting then?
> 
Correct.

> I'll definitely keep you in the loop if/when I get to the possibly
> sec-sensitive stuff (S/MIME, PGP, maybe TNEF if it has some security stuff
> in there).
Yes, please work directly with Dan to get this work done and closed out.

Comment 13

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Risk/Priority Ranking Exercise https://wiki.mozilla.org/Security/RiskRatings

Priority: N/A

Operational: 0 - N/A
User: 0 - N/A
Privacy: 0 - N/A
Engineering: 2 - Normal
Reputational: 0 - N/A

Priority Score: 0