Closed Bug 744952 Opened 12 years ago Closed 10 months ago

TB: Modern MIME parser

Categories

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

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: curtisk, Unassigned)

References

(
URL
)

Details

(Whiteboard: [pending secreview][score:0::Low][Tb]) 

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/ckoenig@mozilla.com/Security%20Review.html) and whom to invite.
Assignee: nobody → dveditz
Status: NEW → ASSIGNED
(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/ckoenig@mozilla.com/Security%20Review.html)
> and whom to invite.

I do not expect this to be ready before May at the earliest.
(In reply to Joshua Cranmer [:jcranmer] from comment #1)
> The work is being implemented in bug 740652.
Make that bug 746052 (dyslexia strikes again).
Blocks: 746052
(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/ckoenig@mozilla.com/Security%20Review.html)
> > and whom to invite.

Would it be possible to schedule a review for sometime in June?
(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/ckoenig@mozilla.com/Security%20Review.html

Could I schedule one on Thursday, June 21?
(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/ckoenig@mozilla.com/Security%20Review.html
> 
> Could I schedule one on Thursday, June 21?

Ping?
: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?
Would this Thursday be a doable opportunity, or is it too soon?
I will ask dveditz what he thinks, and see if we need a full review.
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.
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).
(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.
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
Whiteboard: [pending secreview] → [pending secreview][score:0::Low]
Whiteboard: [pending secreview][score:0::Low] → [pending secreview][score:0::Low][Tb]
Assignee: dveditz → nobody
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.