Closed
Bug 968334
(CVE-2015-2707)
Opened 10 years ago
Closed 8 years ago
Unsafe Imap/Pop url protocol handling could lead to RCE
Categories
(MailNews Core :: Security, defect)
Tracking
(firefox38 fixed, firefox38.0.5 fixed, firefox39 fixed, thunderbird38+ fixed, thunderbird39 fixed, thunderbird40 fixed, thunderbird_esr31+ affected)
People
(Reporter: l.pontorieri, Assigned: neil)
References
Details
(Keywords: sec-high, Whiteboard: [reporter-external][adv-main38-])
Attachments
(6 files, 2 obsolete files)
5.04 MB,
video/ogg
|
Details | |
1.75 KB,
patch
|
smaug
:
review-
|
Details | Diff | Splinter Review |
6.39 KB,
patch
|
smaug
:
review+
Sylvestre
:
approval-mozilla-beta-
|
Details | Diff | Splinter Review |
1.00 KB,
patch
|
standard8
:
review+
standard8
:
feedback+
rkent
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
8.65 KB,
patch
|
smaug
:
review+
Sylvestre
:
approval-mozilla-release+
|
Details | Diff | Splinter Review |
1.27 KB,
patch
|
rkent
:
review+
rkent
:
approval-comm-aurora+
rkent
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20130911160237 Steps to reproduce: Mozilla Thunderbird handles imap procol unsafely. An attacker can force victim's client to do imap requests on his mail server. It's possible to take advantage of this condition to force a target to download any kind of file on its computer spoofing its mime type and in the worst scenario to be directly opened/executed without user interaction. An attacker can force an user to do an IMAP request sending a malicious HTML mail. For example we could force him to FETCH his first email and to display it in iframe sending him: <html> <iframe src="imap://[email]@[ImapServer]:[Port]/fetch%3EUID%3E/INBOX%3E1"></iframe> </html> Username and ImapServer Port are not mandatory, we could simply send an html like this to obtain the same result: <html> <iframe src="imap:///fetch%3EUID%3E/INBOX%3E1"></iframe> </html> The most interesting scenario is that we can force the victim to download a malicious attached file *without interacting*. *Furthermore if the user has selected in the past which program to use to open those files, this will make him execute the program as soon as he opens the mail.* <html> <iframe src="imap:///fetch%3EUID%3E/INBOX%3E[EMAIL_ID]?part=[Part]&filename=[Arbitrary Filename]&type=[Arbitrary Mime Type] </html> If the user has not selected any program in the past, a download prompt will appear, asking to save or open the file. In this case it could be useful to set up filename and type fields in the forced imap request. Filename doesn't stand for the actual filename of the attached file, but an arbitrary string we can set. This is useful to bypass every SMPTD filters (like Googlemail; it forbids to send files with extensions like "exe"). Even more useful is "type". It stands for file mime type, it can be used to force to load the file with a program despite its extension. By the way we need to set [EMAIL_ID] correctly without knowing it. From RFC 3501: Also note that a UID range of 559:* always includes the UID of the last message in the mailbox, even if 559 is higher than any assigned UID value. This is because the contents of a range are independent of the order of the range endpoints. Thus, any UID range with * as one of the endpoints indicates at least one message (the message with the highest numbered UID), unless the mailbox is empty. So we can set email id as [Extremely large Number]:* to reach last email (our mail) attachment. Another approach would be to "bruteforce" with a large number of iframes our email. This issue also affects POP3. In that scenario, because of the fact POP3 saves mail on the local disk, we have to bruteforce/guess maildir, or to try to create a "fake temporary file". For example, on linux, Thunderbird creates tmp files when an attachment is opened: it's possible to send two different emails, the first one with the "email file" (with another safe ext) and the second one with attack code like <html> <iframe src="mailbox:///tmp/faketmpfile.pdf?part=1.2&filename=[FILENAME]&type=[Type]"> </iframe> </html> Actual results: It's possible to take advantage of Thunderbird Imap/Pop urls to force a victim to do actions without interacting (victim just opens the mail). Expected results: It's not possibile to force an execution/download or imap requests without user authorization.
![]() |
||
Updated•10 years ago
|
Flags: sec-bounty?
Whiteboard: [reporter-external]
Reporter | ||
Comment 1•10 years ago
|
||
Comment 2•9 years ago
|
||
Why is Linux not treating shell scripts as "executable" files that can't be opened by default? That aside, though, a more likely attack scenario would be mail with MS office formats or PDF attachments using well known exploits and figuring lots of users haven't upgraded. Those are also formats most users probably check the "do this every time" box on.
Keywords: sec-high,
sec-vector
Product: Thunderbird → MailNews Core
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Daniel Veditz [:dveditz] from comment #2) > Why is Linux not treating shell scripts as "executable" files that can't be > opened by default? I'm investigating this, I understand this is an unexpected behaviour. I just opened an .sh file and checked the box to open that file-type automatically. > That aside, though, a more likely attack scenario would > be mail with MS office formats or PDF attachments using well known exploits > and figuring lots of users haven't upgraded. Those are also formats most > users probably check the "do this every time" box on. Yes, probably this is the most common attack scenario without user interaction. Obviously an attacker could use social engineering to trick the user to open a fake "Thunderbird update". Average user probably would open something TB shows "by itself". Another idea is to trigger firefox/other browser to open a file and execute javascript on file:// protocol (I think this leads to local file disclosure, but I didn't test this).
Assignee | ||
Comment 4•9 years ago
|
||
On trunk we might be able to leverage bug 906276 to disable all undisplayable content. Unfortunately saving attachments currently relies on content retargeting, so some tweaking might be required.
Updated•9 years ago
|
Group: mail-core-security
Comment 5•9 years ago
|
||
Hi Mark, any idea what the issue is here?
Assignee: nobody → standard8
Flags: needinfo?(standard8)
Comment 6•9 years ago
|
||
The "issue" here is that Thunderbird uses the imap/pop uris to access attachments. If you outright block those, then things like displaying attached images/downloading attachments will just stop working. The solution that Neil comments on in comment 4 is potentially possible, but I don't think I'm the right person to do that. Neil would you be able to look at this?
Assignee: standard8 → nobody
Flags: needinfo?(standard8)
Updated•9 years ago
|
Keywords: sec-vector
Comment 8•9 years ago
|
||
neil?
Assignee | ||
Comment 9•9 years ago
|
||
Sorry I haven't had time to look at this, but I should have more time next month.
Updated•9 years ago
|
Group: mail-core-security
Comment 10•9 years ago
|
||
There was a websec issue with attackers using the view-source URL scheme in object tags (bug 973837) and iframes (bug 624883) to harm users. Could we leverage these pieces of code to fix this bug, or do we need iframe/objects pointing to imap and mailbox URL schemes for HTML emails?
Flags: needinfo?(standard8)
Comment 11•9 years ago
|
||
(In reply to Frederik Braun [:freddyb] from comment #10) > There was a websec issue with attackers using the view-source URL scheme in > object tags (bug 973837) and iframes (bug 624883) to harm users. Could we > leverage these pieces of code to fix this bug, or do we need iframe/objects > pointing to imap and mailbox URL schemes for HTML emails? We need them pointing to imap and mailbox schemes so that we can e.g. display in-line attachments like pictures etc. It might be conceivable just to block for iframes, not sure if this would cause issues with existing email use cases already out there (Joshua might know), or if that alone would be enough to fix this bug.
Flags: needinfo?(standard8) → needinfo?(Pidgeot18)
Comment 12•9 years ago
|
||
The main use of cid URLs is for <img src="cid:"> stuff. Conceivably you could also add in <audio> or <video> but I'm not sure how many email clients support those tags. Use of cid: in <link href=""> and in CSS url(cid:) values is also conceivable, but those are likely to be less well supported anyways. I can't think of any usecase for an <iframe src="">. I am offhand worried, though, that the issue of the message rewriting URLs is larger than just iframes and equally applicable to <img src="">.
Flags: needinfo?(Pidgeot18)
![]() |
||
Comment 13•9 years ago
|
||
Shouldn't our checkMayLoad checks prevent load of any imap:, pop3: schemes? Isn't there any protocol flag to set/drop to achieve that?
Comment 14•9 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #13) > Shouldn't our checkMayLoad checks prevent load of any imap:, pop3: schemes? > Isn't there any protocol flag to set/drop to achieve that? It's a somewhat complicated situation. When we get a mime message that says <img src="cid:foobar">, we rewrite that in the MIME backend to say <img src="message URL?part=1.2.1&type=image/png"> so we can load the cid: reference properly. The message URLs that we use for IMAP messages are imap://imap.google.com:993/fetch%3EUID%3E/INBOX%3E224350.
Assignee | ||
Comment 15•9 years ago
|
||
Thank you for your patience. I have investigated my potential solution that I referred to in comment #4. The attached patch prevents attachments from opening automatically but still allows them to be opened manually. Possible issues: * nsDocShell.cpp part of patch may not be acceptable * Potential side-effects on RSS pages (this could perhaps be mitigated by toggling the retargeting in the content policy instead) * Did not test detached attachments
Flags: needinfo?(neil)
Reporter | ||
Comment 16•9 years ago
|
||
Hello Mozilla Team, Any news about this report?
Comment 17•9 years ago
|
||
Neil, is there someone who can review the patch or do we want to get a different patch for this issue?
Flags: needinfo?(neil)
Assignee | ||
Comment 18•9 years ago
|
||
(In reply to Al Billings from comment #17) > Neil, is there someone who can review the patch or do we want to get a > different patch for this issue? You would need to start by finding a docshell peer to review the second half of the patch. Should that be accepted, a Thunderbird peer would then review the first half.
Flags: needinfo?(neil)
Comment 19•9 years ago
|
||
Comment on attachment 8466827 [details] [diff] [review] Potential approach Olli, could you take a look at this? Thanks.
Attachment #8466827 -
Flags: review?(bugs)
Comment 20•9 years ago
|
||
The docshell part looks odd. Why we want the 'else'? That means we don't always honor mAllowContentRetargeting, and such special case is just error prone.
Comment 21•9 years ago
|
||
And DocShell code is so complicated that I really wouldn't want to add any new special cases there. Features need to work consistently. Maybe we need some other flag there to handle this case, but it is not quite clear to me what the requirements are.
Updated•9 years ago
|
Attachment #8466827 -
Flags: review?(bugs) → review-
Assignee | ||
Comment 22•9 years ago
|
||
(In reply to Olli Pettay from comment #20) > The docshell part looks odd. Why we want the 'else'? That means we don't > always honor mAllowContentRetargeting, and such special case is just error prone. Disallowing content retargeting fixes the Thunderbird bug, but breaks certain cases involving LOAD_LINK (sorry I don't remember the exact details offhand). Making LOAD_LINK bypass that fixes those cases. The one existing consumer doesn't use LOAD_LINK so they aren't affected.
Comment 24•9 years ago
|
||
Boris, did you say recently that you might be able to help on some Thunderbird security bugs? Can you look at this one?
Flags: needinfo?(bzbarsky)
![]() |
||
Comment 25•9 years ago
|
||
Why can thunderbird not have a content policy that blocks TYPE_SUBDOCUMENT loads for such URIs?
Flags: needinfo?(bzbarsky)
Assignee | ||
Comment 26•9 years ago
|
||
(In reply to Boris Zbarsky from comment #25) > Why can thunderbird not have a content policy that blocks TYPE_SUBDOCUMENT > loads for such URIs? We can't readily tell the content type of the URI so we'd basically have to indiscriminately block all frames in messages. (This would be a problem if seamless iframes ever became a thing because we want to use them for displaying inline message parts.)
Flags: needinfo?(neil)
![]() |
||
Comment 27•9 years ago
|
||
I'm not sure I follow. Why is the content type (of the thing that will load from the URI?) relevant? I thought the issue was that simply running the imap:// URL caused problems?
Updated•9 years ago
|
Flags: needinfo?(bugs)
Assignee | ||
Comment 28•9 years ago
|
||
(In reply to Boris Zbarsky from comment #27) > I'm not sure I follow. Why is the content type (of the thing that will load > from the URI?) relevant? I thought the issue was that simply running the > imap:// URL caused problems? What do you mean be "the imap:// URL"? The message and all attachments and embedded objects have imap URLs, and I don't know how to tell which ones are safe just from the URL alone. (Maybe someone else does.)
![]() |
||
Comment 29•9 years ago
|
||
OK, that matches my understanding. So we'd need to block iframes pointing to imap:// urls, but you could still have a data: iframe. Let's posit that we want a better solution, fine. I'd like to be clearer on why DONT_RETARGET helps. Is the issue that we end up with a MIME type we can't handle and then start looking for a different handler for it and that handler is what does the undesirable IMAP accesses?
Assignee | ||
Comment 30•9 years ago
|
||
(In reply to Boris Zbarsky from comment #29) > OK, that matches my understanding. So we'd need to block iframes pointing > to imap:// urls, but you could still have a data: iframe. No; as I understand it, some imap:// urls are safe (ones with a type parameter are more likely to be unsafe). > I'd like to be clearer on why DONT_RETARGET helps. Is the issue that we end > up with a MIME type we can't handle and then start looking for a different > handler for it and that handler is what does the undesirable IMAP accesses? My understanding is that the potential to execute the handler is what is undesirable.
![]() |
||
Comment 31•9 years ago
|
||
> No; as I understand it, some imap:// urls are safe Right, but we can't tell up front. > My understanding is that the potential to execute the handler is what is undesirable. OK. So this is not about something the protocol handler does, but about some nsIContentHandler or nsIURIContentListener? The earlier patch in this bug is not making sense to me; won't an <a href="imap://whatever-dangerous-url"> be just as bad?
Assignee | ||
Comment 32•9 years ago
|
||
(In reply to Boris Zbarsky from comment #31) > The earlier patch in this bug is not making sense to me; won't an <a > href="imap://whatever-dangerous-url"> be just as bad? You might as well use <a href="http://whatever-dangerous-url"> - nothing will happen until the user clicks on it. This isn't true of an iframe.
![]() |
||
Comment 33•9 years ago
|
||
Getting users to click a link is trivial.
Assignee | ||
Comment 34•9 years ago
|
||
(In reply to Boris Zbarsky from comment #33) > Getting users to click a link is trivial. Unfortunately getting users to open an executable attachment is quite easy too.
![]() |
||
Comment 35•9 years ago
|
||
OK, fair. But that said, are there actual use cases for <a href="imap://whatever">? Comment 22 seems to claim there are, but I'd like to understand what they are, exactly.
Assignee | ||
Comment 36•9 years ago
|
||
(In reply to Boris Zbarsky from comment #35) > But that said, are there actual use cases for <a href="imap://whatever">? > Comment 22 seems to claim there are, but I'd like to understand what they > are, exactly. Currently we simulate a link click to open an attachment which then uses the normal handler mechanism (this is application-dependent e.g. in SeaMonkey it opens a text attachment in the browser).
![]() |
||
Comment 37•9 years ago
|
||
Simulate a link click in a subframe, though? Or simulate a link click in the main mail docshell? I guess your patch was setting retargeting to false on the messagepane itself. Can we just set it to false on descendant docshells of the messagepane?
Assignee | ||
Comment 38•9 years ago
|
||
(In reply to Boris Zbarsky from comment #37) > Simulate a link click in a subframe, though? Or simulate a link click in > the main mail docshell? > > I guess your patch was setting retargeting to false on the messagepane > itself. Can we just set it to false on descendant docshells of the > messagepane? Sounds reasonable; I'd have to be able to set it early on in the frame's creation, so where would the best place be to handle that, back in the content policy again?
![]() |
||
Comment 39•9 years ago
|
||
Do you have a custom treeowner here by any chance?
Assignee | ||
Comment 40•9 years ago
|
||
(In reply to Boris Zbarsky from comment #39) > Do you have a custom treeowner here by any chance? I didn't even know that was possible... I think we have the default content tree owner.
![]() |
||
Comment 41•9 years ago
|
||
OK. So we could add some sort of "hey, a docshell got created" notification. Or we could add a new setter on docshell that doesn't set its retargeting stuff to false, but causes it to set retargeting stuff to false on all its kids. The latter is probably simpler.
Assignee | ||
Comment 42•9 years ago
|
||
(In reply to Boris Zbarsky from comment #41) > OK. So we could add some sort of "hey, a docshell got created" > notification. Or we could add a new setter on docshell that doesn't set its > retargeting stuff to false, but causes it to set retargeting stuff to false > on all its kids. > > The latter is probably simpler. OK I'll work on the latter.
Assignee | ||
Comment 43•9 years ago
|
||
Reporter | ||
Comment 44•8 years ago
|
||
Hello mozilla security team, I've reported this issue one year and one month ago to your bug bounty program. Could you please tell me when this will be patched (I want to publish an article about this) and when the reward will be assigned? Thank you, LP
Comment 45•8 years ago
|
||
The patch is already over a month old. Did you forget to set a review flag, Neil? I'm not sure who to ask for a review, can you figure this out?
Assignee: nobody → neil
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(neil)
Comment 46•8 years ago
|
||
(In reply to l.pontorieri from comment #44) > Hello mozilla security team, > I've reported this issue one year and one month ago to your bug bounty > program. > Could you please tell me when this will be patched (I want to publish an > article about this) and when the reward will be assigned? > > Thank you, > LP I'm terribly sorry, that this bug has been in limbo for so long :( Thunderbird is maintained by community, so we can't really force this work upon someone specific ;-) But I'll try to take this responsibility and poke a few more people about this.
Comment 47•8 years ago
|
||
Comment on attachment 8554272 [details] [diff] [review] Patch as per comment #41 Olli said he can take a look.
Flags: needinfo?(neil)
Attachment #8554272 -
Flags: review?(bugs)
Comment 48•8 years ago
|
||
Comment on attachment 8554272 [details] [diff] [review] Patch as per comment #41 > nsDocShell::SetAllowContentRetargeting(bool aAllowContentRetargeting) > { >+ mAllowContentRetargetingOnChildren = > mAllowContentRetargeting = aAllowContentRetargeting; mAllowContentRetargetingOnChildren = aAllowContentRetargeting; mAllowContentRetargeting = aAllowContentRetargeting; Would be a tad easier to read. And Docshell uses Mozilla coding style these days, so 2 spaces only. >@@ -285,16 +285,22 @@ interface nsIDocShell : nsIDocShellTreeI update uuid This of course misses the TB specific part.
Attachment #8554272 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 49•8 years ago
|
||
Attachment #8554272 -
Attachment is obsolete: true
Attachment #8574381 -
Flags: review?(bugs)
Updated•8 years ago
|
Attachment #8574381 -
Flags: review?(bugs) → review+
Assignee | ||
Comment 50•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/f1bdb836d0c5
Keywords: leave-open
Comment 51•8 years ago
|
||
sorry had to back this out in https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=202f81536f5e since one of this changes caused https://treeherder.mozilla.org/logviewer.html#?job_id=7522355&repo=mozilla-inbound
Updated•8 years ago
|
Flags: sec-bounty? → sec-bounty+
Comment 52•8 years ago
|
||
Any chance at a second checkin attempt soon? This thing is an ancient sec-high that comes up in Critsmash meetings.
Flags: needinfo?(neil)
Assignee | ||
Comment 53•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2232d2bce241 Sorry for the delay (combination of multiple tree closures and hard disk failure).
Flags: needinfo?(neil)
Comment 54•8 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/2232d2bce241
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 55•8 years ago
|
||
Bah, I forgot to set leave-open for the comm-central part of the patch.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 56•8 years ago
|
||
(Haven't been able to find a reviewer for this patch yet.)
Comment 57•8 years ago
|
||
Comment on attachment 8584875 [details] [diff] [review] comm-central part of patch Review of attachment 8584875 [details] [diff] [review]: ----------------------------------------------------------------- ::: mailnews/base/src/nsMessenger.cpp @@ +255,5 @@ > nullptr, nullptr, getter_AddRefs(childAsItem)); > > mDocShell = do_QueryInterface(childAsItem); > if (NS_SUCCEEDED(rv) && mDocShell) { > + mDocShell->SetAllowContentRetargetingOnChildren(false); Wouldn't this be better being set in nsMsgContentPolicy, e.g. in something like nsMsgContentPolicy::OnLocationChange ? This would mean it'll be set correctly on whatever docshell is used for displaying messages.
Assignee | ||
Comment 58•8 years ago
|
||
(In reply to Mark Banner from comment #57) > Wouldn't this be better being set in nsMsgContentPolicy, e.g. in something > like nsMsgContentPolicy::OnLocationChange ? > > This would mean it'll be set correctly on whatever docshell is used for > displaying messages. Good point, that would also stop it from affecting feed pages.
Assignee | ||
Comment 59•8 years ago
|
||
Attachment #8584875 -
Attachment is obsolete: true
Attachment #8586460 -
Flags: feedback?(standard8)
Comment 60•8 years ago
|
||
Comment on attachment 8586460 [details] [diff] [review] Updated comm-central part of patch I've not tested it, but I think this is the right place to set these, especially based on the other items there ;-)
Attachment #8586460 -
Flags: feedback?(standard8) → feedback+
Assignee | ||
Comment 61•8 years ago
|
||
So whom would you suggest to review attachment 8586460 [details] [diff] [review]?
Comment 63•8 years ago
|
||
Comment on attachment 8586460 [details] [diff] [review] Updated comm-central part of patch I tried reproducing the exploit to test this but wasn't able to, probably because I was missing something or on the wrong platform. However, Neil tells me he has tested this, so I'm therefore giving this r+ based on his testing, and this looks like the right thing to do in the right place.
Flags: needinfo?(standard8)
Attachment #8586460 -
Flags: review+
Assignee | ||
Comment 64•8 years ago
|
||
Pushed comm-central changeset 6bd8cda9d3e3.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 40.0
Reporter | ||
Comment 65•8 years ago
|
||
Could you assign a CVE id to this issue? Thank you
Updated•8 years ago
|
OS: Linux → All
Hardware: x86 → All
Comment 66•8 years ago
|
||
What is the uplift plan for this to 38 and esr31?
Updated•8 years ago
|
tracking-thunderbird38:
--- → +
tracking-thunderbird_esr31:
--- → +
Comment 68•8 years ago
|
||
(In reply to Kent James (:rkent) from comment #66) > What is the uplift plan for this to 38 and esr31? Someone needs to request approvals for both patches. I don't see an issue with uplifting to 38, especially as there's still a couple of weeks left in beta. Not sure about 31. Someone needs to check the patches will apply & work correctly (I suspect they will, they seemed quite simple in code that's unlikely to have changed much), and then get approvals.
Updated•8 years ago
|
status-firefox38:
--- → affected
status-firefox39:
--- → fixed
status-firefox40:
--- → fixed
status-thunderbird38:
--- → affected
status-thunderbird39:
--- → affected
status-thunderbird40:
--- → fixed
status-thunderbird_esr31:
--- → affected
Comment 69•8 years ago
|
||
Neil, would you be able to request approval-mozilla-beta (along with the risk assessment) so that we can try to get this into gecko 38? I can handle the comm-beta part after the mozilla-beta part lands.
Flags: needinfo?(neil)
Assignee | ||
Comment 70•8 years ago
|
||
Comment on attachment 8574381 [details] [diff] [review] Updated for review comments and bitrot Approval Request Comment [Risks and why]: Desired for Thunderbird ESR [String/UUID change made/needed]: UUID change
Flags: needinfo?(neil)
Attachment #8574381 -
Flags: approval-mozilla-beta?
Assignee | ||
Comment 71•8 years ago
|
||
(In reply to Kent James from comment #69) > the risk assessment Oh, I forgot that bit, sorry.
Comment 72•8 years ago
|
||
I had not noticed the interface change. What has been the approach to this in that past? That is, can we avoid the binary compatibility problem by creating a second interface that only includes the one added attribute? Or are changes like this typically accepted so late in beta?
Assignee | ||
Comment 73•8 years ago
|
||
(In reply to Kent James from comment #72) > I had not noticed the interface change. > > What has been the approach to this in that past? That is, can we avoid the > binary compatibility problem by creating a second interface that only > includes the one added attribute? Or are changes like this typically > accepted so late in beta? Yeah, I might be able to implement it as an nth interface,
Assignee | ||
Comment 74•8 years ago
|
||
Attachment #8596137 -
Flags: review?(bugs)
Updated•8 years ago
|
Attachment #8596137 -
Flags: review?(bugs) → review+
Comment 75•8 years ago
|
||
Comment on attachment 8574381 [details] [diff] [review] Updated for review comments and bitrot As noticed, we cannot take it because of the uuid change. Please resubmit for uplift the new patch with the uplift template filled. Thanks
Attachment #8574381 -
Flags: approval-mozilla-beta? → approval-mozilla-beta-
Assignee | ||
Comment 76•8 years ago
|
||
Comment on attachment 8596137 [details] [diff] [review] Branch-safe version of attachment 8574381 [details] [diff] [review] Approval Request Comment [Feature/regressing bug #]: N/A [User impact if declined]: N/A [Describe test coverage new/current, TreeHerder]: Not used by Firefox (Trunk patch has baked for a month on central/aurora without issues) [Risks and why]: Needed by Thunderbird [String/UUID change made/needed]: None
Attachment #8596137 -
Flags: approval-mozilla-beta?
Comment 77•8 years ago
|
||
Comment on attachment 8596137 [details] [diff] [review] Branch-safe version of attachment 8574381 [details] [diff] [review] Taking it because 38 is an ESR, it is a sec high and it is the base of TB.
Attachment #8596137 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 78•8 years ago
|
||
Comment on attachment 8596137 [details] [diff] [review] Branch-safe version of attachment 8574381 [details] [diff] [review] [Triage Comment] 38 is now in m-r.
Attachment #8596137 -
Flags: approval-mozilla-beta+ → approval-mozilla-release+
Comment 79•8 years ago
|
||
https://hg.mozilla.org/releases/mozilla-release/rev/38ff61772a2e
status-firefox40:
fixed → ---
status-thunderbird40:
fixed → ---
status-thunderbird_esr38:
--- → fixed
Target Milestone: Thunderbird 40.0 → Thunderbird 39.0
Comment 81•8 years ago
|
||
Shouldn't this also go to mozilla-esr31?
Assignee | ||
Updated•8 years ago
|
status-thunderbird40:
--- → fixed
Target Milestone: Thunderbird 39.0 → Thunderbird 40.0
Assignee | ||
Comment 82•8 years ago
|
||
Attachment #8597597 -
Flags: review?(rkent)
Updated•8 years ago
|
Attachment #8597597 -
Flags: review?(rkent) → review+
Updated•8 years ago
|
Assignee | ||
Updated•8 years ago
|
Comment 83•8 years ago
|
||
Comment on attachment 8597597 [details] [diff] [review] Branch version of attachment 8586460 [details] [diff] [review] [Triage Comment]
Attachment #8597597 -
Flags: approval-comm-beta+
Attachment #8597597 -
Flags: approval-comm-aurora+
Comment 84•8 years ago
|
||
Comment on attachment 8597597 [details] [diff] [review] Branch version of attachment 8586460 [details] [diff] [review] http://hg.mozilla.org/releases/comm-beta/rev/67a24915fc34 http://hg.mozilla.org/releases/comm-aurora/rev/16c1af11167f (with wrong user, sorry)
Updated•8 years ago
|
Comment 85•8 years ago
|
||
Backed out from comm-aurora due to bustage https://hg.mozilla.org/releases/comm-aurora/rev/6e8da969cd36 https://hg.mozilla.org/releases/comm-aurora/rev/c4fdea68607a
Comment 86•8 years ago
|
||
It looks like the mozilla branch patch did not land in mozilla-aurora, so the status-firefox39 is incorrect?
Assignee | ||
Comment 87•8 years ago
|
||
Comment on attachment 8586460 [details] [diff] [review] Updated comm-central part of patch (In reply to Kent James from comment #86) > It looks like the mozilla branch patch did not land in mozilla-aurora, so > the status-firefox39 is incorrect? The mozilla trunk patch landed last month, so it got automatically uplifted to mozilla-aurora*. This means that it is this patch that you would need for comm-aurora. * http://hg.mozilla.org/releases/mozilla-aurora/rev/2232d2bce241
Attachment #8586460 -
Flags: approval-comm-aurora?
Comment 88•8 years ago
|
||
I assume that this isn't fixed in the upcoming Thunderbird release since that is built off of ESR31 and we didn't fix this there. So, effectively this didn't get fixed in Thunderbird. Do I misunderstand?
Flags: needinfo?(neil)
Updated•8 years ago
|
Flags: needinfo?(ludovic)
Assignee | ||
Comment 89•8 years ago
|
||
(In reply to Al Billings from comment #88) > I assume that this isn't fixed in the upcoming Thunderbird release since > that is built off of ESR31 and we didn't fix this there. So, effectively > this didn't get fixed in Thunderbird. Do I misunderstand? ESR31 is affected because neither has attachment 8596137 [details] [diff] [review] been uplifted to mozilla-esr31 nor attachment 8597597 [details] [diff] [review] to comm-esr31. 39 is affected because attachment 8586460 [details] [diff] [review] has not been uplifted to comm-aurora. ESR38, 38 and 40 should be fixed.
Flags: needinfo?(neil)
Comment 90•8 years ago
|
||
(In reply to neil@parkwaycc.co.uk from comment #89) > ESR31 is affected because neither has attachment 8596137 [details] [diff] [review] > [review] been uplifted to mozilla-esr31 nor attachment 8597597 [details] [diff] [review] > [diff] [review] to comm-esr31. > 39 is affected because attachment 8586460 [details] [diff] [review] has not > been uplifted to comm-aurora. > ESR38, 38 and 40 should be fixed. Well, that means shipping Thunderbird is affected because we don't ship TB 38 (or 39 or 40). Public TB builds are all based on ESR31. So, basically, we didn't fix it for TB in the one branch we ship...
Updated•8 years ago
|
Flags: needinfo?(ludovic)
Updated•8 years ago
|
Whiteboard: [reporter-external] → [reporter-external][adv-main38-]
Comment 91•8 years ago
|
||
Comment on attachment 8586460 [details] [diff] [review] Updated comm-central part of patch [Triage Comment] http://hg.mozilla.org/releases/comm-beta/rev/ae46efbe3a5b
Attachment #8586460 -
Flags: approval-comm-aurora? → approval-comm-beta+
Updated•8 years ago
|
Updated•8 years ago
|
Group: core-security → core-security-release
Updated•7 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•