1209565 - Phishing Issue - raise a flag if Sender Name uses @, and does not match sender email address

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[info]

Attachment: CVE-Submission.txt

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150826023504

Steps to reproduce:

The full write up is in the attached CVE-Submission.txt file.

Comment 1

[info]

This is being publicly presented on Nov. 14th at a security conference.  It affects more than just Thunderbird, but this is my step to ensure you know about this issue.

Comment 2

[Kent James (:rkent)]

Since the From field of an email is so easily spoofed, I'm not sure how serious this should be considered. It's pretty easy to send an email with a FROM header of "Bank of America" <[e-mail]> and have it show up that way in the From field of the message header. The typical exploit then would be to have the user click on a link in that email. Hard to stop that without using sender authentication, which has never caught on.

But this is a little different, and I can see how could be confusing. Should not be hard to fix.

Adding Jorkg since he has looked at some of these in the past.

Comment 3

[info]

Yes!  You "get it"!...  That's what we're trying to do, just have a flag thrown if Sender Name uses @ and does not match sender email

Comment 4

[Jorg K (CEST = GMT+2)]

Why don't you explain it, so a simple mind can understand it.

I created an e-mail with the From header
From: "[e-mail]" <[e-mail]>
That shows up as such.

When replying to it, an entry is placed into the address book with
Display: [e-mail] and e-mail: [e-mail].

When this happens, the display now only shows the "[e-mail]", and you need to hover over it to see the e-mail.

Another e-mail now created with
From: "[e-mail]" <[e-mail]>
will now be displayed as coming from [e-mail].

So once the attacker address got into the address book, they can send more e-mail that appears coming from a different source.

Comment 5

[Al Billings [:abillings - ex-MoCo]]

But the sending address is unathenticated in email in general and has been for decades. You can't *ever* trust the sending address is actually the person, which is why I get spam messages seemingly from myself or my mother.

Comment 6

[Kent James (:rkent)]

(In reply to Al Billings [:abillings] from comment #5)
> But the sending address is unathenticated in email in general and has been
> for decades. You can't *ever* trust the sending address is actually the
> person, which is why I get spam messages seemingly from myself or my mother.

Right, I agree, so sec-low is appropriate. This is a little different in that it gets added to the address book, and it would probably be easy to fix, at least with better visibility of the actual email address.

Comment 7

[Kent James (:rkent)]

aceman, would you have any interest in trying to change the header UI a little so that we would not display a bare username that resembles an email address? Or Jorgk?

Comment 8

[:aceman]

How should it look like? Also we have the phishing bar coming up if urls or an anything is suspicious. If there is a way to trigger it, maybe we could use it?

Comment 9

[Kent James (:rkent)]

At the very least, instead of showing the address for "[e-mail]" <[e-mail]> as simply "[e-mail]" in the header, maybe we could who the full address:

"[e-mail]" <[e-mail]>

Comment 10

[Magnus Melin [:mkmelin]]

Yeah you could probably just force the effect of mail.showCondensedAddresses off when the displayname is a mail address != the real address.

Comment 11

[info]

Hi,

Sorry I haven't been in this conversation; been working all day.  So, here is the gist:

Attacker sends a convincing email that will elicit a reply.  No obfuscation takes place at this point, its simply an email from [e-mail] sent to [e-mail]. (Hook)

Victim sends reply to [e-mail] asking who he is or whatnot.  In doing so, the victim has unknowingly added the email address of [e-mail] to their address book. (Line)

Attack, now having a confirmation of address book modification, sends another email to the victim.  However, this time they do two things; they change the "Sender Name" to a convincing email address, and they change the Reply-To line to match it.  The Reply-to line is done in addition so that if the victim clicks reply; the desired email is shown. (Sinker)

So that's it.  In a nutshell what we believe would be a proper patch, is that any email client, upon receiving an email where the "Sender Name" makes use of the @ character, that the client will compare the string against the "Sender Email Address"; if there is no match, then a warning flag of sorts is shown, thereby alerting the user to a possible phish attempt

Comment 12

[Joshua Cranmer [:jcranmer]]

(In reply to info from comment #11)
> So that's it.  In a nutshell what we believe would be a proper patch, is
> that any email client, upon receiving an email where the "Sender Name" makes
> use of the @ character, that the client will compare the string against the
> "Sender Email Address"; if there is no match, then a warning flag of sorts
> is shown, thereby alerting the user to a possible phish attempt

I disagree with a possible phish attempt prompt. There are valid use cases where an email address, even one that mismatches the actual addr-spec, would be present in the display name of an address production. The two that most readily come to mind are downgraded EAI addresses (where there is simply no way to spell the real address in the addr-spec), and mailing list From-munging as a result of Yahoo!'s DMARC debacle.

I actually do have legitimate email on the latter form: I'm subscribed to the llvm-dev mailing list, where a recent message has From: "[e-mail] via llvm-dev" <[e-mail]>.

From prior experience with the phishing bar, an overly aggressive detection mechanism that produces too many false positives strongly motivates users to bypass phishing altogether, worsening security rather than improving it. Quite frankly, since most MUAs display the display address in place of the addr-spec, providing a plausibly misleading From display name is a much easier path to social engineering than going through the rigmarole of trying to specifically display a plausible email address. I suspect that the true positives of displaying a phishing indicator in this scenario would be outweighed by at least an order of magnitude or two by false positives.

Comment 13

[info]

(In reply to Joshua Cranmer [:jcranmer] from comment #12)
> (In reply to info from comment #11)
> > So that's it.  In a nutshell what we believe would be a proper patch, is
> > that any email client, upon receiving an email where the "Sender Name" makes
> > use of the @ character, that the client will compare the string against the
> > "Sender Email Address"; if there is no match, then a warning flag of sorts
> > is shown, thereby alerting the user to a possible phish attempt
> 
> I disagree with a possible phish attempt prompt. There are valid use cases
> where an email address, even one that mismatches the actual addr-spec, would
> be present in the display name of an address production. The two that most
> readily come to mind are downgraded EAI addresses (where there is simply no
> way to spell the real address in the addr-spec), and mailing list
> From-munging as a result of Yahoo!'s DMARC debacle.
> 
> I actually do have legitimate email on the latter form: I'm subscribed to
> the llvm-dev mailing list, where a recent message has From: "[e-mail] via
> llvm-dev" <[e-mail]>.
> 
> From prior experience with the phishing bar, an overly aggressive detection
> mechanism that produces too many false positives strongly motivates users to
> bypass phishing altogether, worsening security rather than improving it.
> Quite frankly, since most MUAs display the display address in place of the
> addr-spec, providing a plausibly misleading From display name is a much
> easier path to social engineering than going through the rigmarole of trying
> to specifically display a plausible email address. I suspect that the true
> positives of displaying a phishing indicator in this scenario would be
> outweighed by at least an order of magnitude or two by false positives.

Hi Joshua,

I'll agree with you in that there might be certain instances where the cases in point you brought up should NOT trigger a flag.  However, to the average user; this is not the case.  When Grandma Betty opens her Thunderbird to find an email from [e-mail], she's going to drop her Cigar and do what John from the FBI instructed her to do, period, point blank.  You're going to counter with Grandma Betty doesn't use Thunderbird.  She does, Johnny Nephew set it up for her...

We're not asking for a "Phishing Alert" banner of sorts like gMail does.  All we're asking is that when Thunderbird detects the "Sender Name" does not match the "Sender Email", that the Sender Email is shown instead of the "Sender Name" --OR--  The Address Book default addition is removed.

This fix doesn't have to be flashy to work, but a fix should be created.  At a minimum, remove the ability to add an email by default upon sending an email, make this a choice, rather than a default.  Right now, as it stands, this method can be used to Phish an easy 40% of your userbase.  Remember, we're not after the savvy users here; we're out to fix the common user.  This method DOES work.  It's not just Thunderbird that is affected either; iPad, iPhone and Android all suffer the same, Yet, Microsoft Outlook and Evolution do not.

Comment 14

[Jim Porter (:squib)]

(In reply to info from comment #13)
> Right now, as it stands, this method can be used to Phish an easy 40% of your userbase.

Where are you getting this number?

> This method DOES work.

How do you know?

--------------------

As Joshua says, I don't think we can rely on some heuristic to show the full email address if the display name looks email-ish. It fails in too many cases.

However, it *would* be reasonable for automatically-added address book contacts to be flagged somehow to say "don't hide the email address in the header for messages from this person". It would just be a matter of changing the "Always prefer display name over message header" boolean into a tri-state: 1) show the address book display name, 2) show the message header display name, 3) show the full message header.

Since I added this feature originally, I could probably whip up a patch once we agree on the correct behavior here. Here's a quick UX proposal:

  In the address book dialog for a contact, replace "Always prefer display name over message header"
  with:

  "When displaying messages, show: [ This display name         | v ]
                                   | The sender's display name |
                                   | The sender's full address |
                                   +---------------------------+

  Then make automatically-added addresses default to the last option.

Any ideas on wording, behavior, etc?

Comment 15

[info]

(In reply to Jim Porter (:squib) from comment #14)
> (In reply to info from comment #13)
> > Right now, as it stands, this method can be used to Phish an easy 40% of your userbase.
> 
> Where are you getting this number?
> 
> > This method DOES work.
> 
> How do you know?
> 
> --------------------
> 
> As Joshua says, I don't think we can rely on some heuristic to show the full
> email address if the display name looks email-ish. It fails in too many
> cases.
> 
> However, it *would* be reasonable for automatically-added address book
> contacts to be flagged somehow to say "don't hide the email address in the
> header for messages from this person". It would just be a matter of changing
> the "Always prefer display name over message header" boolean into a
> tri-state: 1) show the address book display name, 2) show the message header
> display name, 3) show the full message header.
> 
> Since I added this feature originally, I could probably whip up a patch once
> we agree on the correct behavior here. Here's a quick UX proposal:
> 
>   In the address book dialog for a contact, replace "Always prefer display
> name over message header"
>   with:
> 
>   "When displaying messages, show: [ This display name         | v ]
>                                    | The sender's display name |
>                                    | The sender's full address |
>                                    +---------------------------+
> 
>   Then make automatically-added addresses default to the last option.
> 
> Any ideas on wording, behavior, etc?

Hi Jim,

As far as the number goes, I don't have true percentages, but I know people; and people are stupid.  Remember, it's not the savvy I'm concerned with, it is the untrained user to be worried about.  40% was a light estimate in my opinion.  If you want an example, use my provided Python code and Phish a relative; I'll bet you a beer it'll work.

Regarding how I know it works, pick a friend and try it out; I promise you it does.  Social Engineering works.

I know I seem brazen and to the point, but my worries are justified.  With Thunderbird, unless a user takes extra steps (and they won't...), they have no idea who the email was sent from, they're going to trust the software.  How many users do you know, who don't work for Mozilla, who only care about who's liking them on Facebook and such, actually view Email Headers?

You folks at Thunderbird do a lot of coding that I don't do, so some of the terminologies used went over my head.  I believe the simplest patch would be something like this:

If the Sender Email != Sender Name, then 
   Verify if the Sender Name contains the @ character
   If not:
      Display the Sender Name as intended by the Sender
   If so:
      Verify if the Sender Name string matches the Sender email
         If so:
            Display the Sender Name as intended by the Sender
         If not:
            Only display the Sender email

Comment 16

[Jim Porter (:squib)]

(In reply to info from comment #15)
> 40% was a light estimate in my opinion.

An estimate based on no actual data isn't a very good estimate, I'm afraid. If you had actual user studies about this, it would be a lot easier to make an informed choice about what strategy best protects the user.

For instance, if this specific issue didn't increase the likelihood of a user being fooled by very much compared to other strategies that *don't* rely on this issue, then we'd want to address phishing in a broader way. However, if this issue made users, say, twice as likely to be fooled, then a narrower focus would be better.

Sadly, the users who get targeted by scams are the ones who'll fall for even the most obvious fakery. In fact, the common "419 scams" intentionally make themselves look bogus by following the same old format, complete with spelling errors, in order to weed out all but the biggest rubes. Since these are the kinds of users who need the most protection, I'm not convinced that we can solve this problem for them without trying out multiple things to see what works. It would be great if we could do these sorts of user studies ourselves, but I'm not sure the Thunderbird team has the resources at the moment.

> You folks at Thunderbird do a lot of coding that I don't do, so some of the
> terminologies used went over my head.  I believe the simplest patch would be
> something like this: [snip]

As mentioned above, this doesn't account for legitimate cases where an @ appears in the display name in the message header. (It also ignores that the display name can come from the address book too, but that's not a showstopper.) The solution I posted solves the problem somewhat more thoroughly: merely replying to a message can *never* result in the email address of the original sender to get hidden in the message header. This would also cover cases where the display name didn't have an @, such as "Facebook".

However, as I said, I'm still not convinced that any of these solutions is the right one because we don't have any data. Without data, the best we can do is guess at what a user might do, which is notoriously difficult when dealing with extremely-inexperienced users.

Comment 17

[Jorg K (CEST = GMT+2)]

(In reply to Kent James (:rkent) from comment #9)
> At the very least, instead of showing the address for "[e-mail]"
> <[e-mail]> as simply "[e-mail]" in the header, maybe we
> could show the full address: "[e-mail]" <[e-mail]>
What's wrong with this approach?

Comment 18

[:aceman]

Yes, I also agree with comment 9 and comment 10. That seems simple and clean.

Is is a problem if we do not condense (show in full) the username and also email of that legitimate use of @ in username?

Comment 19

[Richard Marti (:Paenglab)]

This is no problem. What would be a legitimate use case where the name has a email address which is different to the email address?

Comment 20

[:aceman]

Maybe the example in comment 12.

Comment 21

[Richard Marti (:Paenglab)]

Yes, correct. But I think it's better to show name and address in this case. This doesn't disturb the user like a phishing bar because it's in the header area and needs no action from user.

Comment 22

[:aceman]

squib, do you have enough specs now?

Comment 23

[Jim Porter (:squib)]

As I already mentioned, only doing this for message header display names with an "@" in them probably won't help inexperienced users in all cases. Once you reply to a user, it would be possible for them to change their display name to *anything* official-sounding like "Facebook" or "The President of the United States", and you wouldn't see that their email address is [e-mail]. The solution I proposed in comment 14 addresses that, and also lets us avoid using a heuristic to decide when to show the email address.

Heck, we could simplify it even further and say "if prefer-address-book-name is false, always show the entire address as though that contact weren't in the address book".

Comment 24

[:aceman]

You say that once we have the email in the AB, we do not display the username stored with it in the AB, but anything that comes in the new message?

Comment 25

[Jim Porter (:squib)]

If "Always prefer display name over message header" is unchecked, yes. Contacts added automatically when you send a message to them should have that unchecked, I believe.

Comment 26

[:aceman]

Yeah, I see. For manually created contacts it is checked by default.
Then proposal in comment 14 looks sane to me. However, why do we actually need to show the username from the message and not the AB? Why is that option there? Are there some cases where the username contains important information? E.g. some automatically generated always unique usernames (on the same emai)?

Comment 27

[Jim Porter (:squib)]

(In reply to :aceman from comment #26)
> Are there some cases where the username contains important
> information? E.g. some automatically generated always unique usernames (on
> the same emai)?

Frequently. Consider GitHub issue emails that all have the same address, but whose display name is the name of the user who commented on the issue. See bug 474721 for more rationale.

Comment 28

[Magnus Melin [:mkmelin]]

So what's wrong with the simple approach just to force full display for all addresses with displayname containing @ (and different from what we know)?

Comment 29

[Jim Porter (:squib)]

I've already explained my reasoning in comments 16 and 23.

Comment 30

[Magnus Melin [:mkmelin]]

Ah, right. I'm all for simple, the "if prefer-address-book-name is false, always show the entire address as though that contact weren't in the address book" approach from comment 23 sounds good to me.

Comment 31

[Jim Porter (:squib)]

Yeah, I think I'd be ok with that too. I might throw a heads-up on the newsgroups though to see if anyone gets really grumpy. However, anyone who hates it *should* be able to override FormatDisplayName() in an add-on to do what they like (it's one of the main reasons I made that function).

Comment 32

[info]

Out of curiosity... Has a decision been made?

Comment 33

[Wayne Mery (:wsmwk)]

(In reply to info from comment #32)
> Out of curiosity... Has a decision been made?

I think comment 30 decides it

Comment 34

[Magnus Melin [:mkmelin]]

Yep. squib: did you want to take this?

Comment 35

[info]

I'm definitely looking forward to a fix being issued.  I saw this the other day:
http://thehackernews.com/2015/11/gmail-spoofing.html

Before others start poking my friend and I are very close to going public.  It would be very cool to see Thunderbird fix this though!

Comment 36

[Jim Porter (:squib)]

I'm unlikely to work on this before the new year, since I'm busy with fixing blockers for Firefox OS, and will soon be busy with holiday-related things. That doesn't mean I *definitely* won't get to it this year, but don't hold your breath. :)

If anyone else wants to take this, I'll happily review the patch.

Comment 37

[Jorg K (CEST = GMT+2)]

Attachment: Proposed dead-simple solution.

There's been so much action in this bug, and the end it resulted to nothing.

Apparently we currently have 22 security bugs, maybe this is one of them, so I'm making a start.

With this solution, the name and the e-mail address are always displayed in the message pane. Magnus wanted simple, so this is simple.

Comment 38

[Jim Porter (:squib)]

The correct way for FormatDisplayName to indicate that the full address (display name + email) should be shown is to return `null`, not to reconstruct the full address in-place.

Arguably, this API should be changed, but that's a larger issue than this.

Comment 39

[Jorg K (CEST = GMT+2)]

(In reply to Jim Porter (:squib) from comment #38)
> The correct way for FormatDisplayName to indicate that the full address
> (display name + email) should be shown is to return `null`, not to
> reconstruct the full address in-place.
Well, when returning null, the display name from the card is displayed, and that's what we don't want.
We want the name from the header + the e-mail from the header, right?
So despite knowing very little about this, I have to contradict ;-)

Comment 40

[Jorg K (CEST = GMT+2)]

I'm happy for someone else to do something, so far more than four months have passed waiting for a simple change of a couple of lines.

Comment 41

[Jim Porter (:squib)]

(In reply to Jorg K (GMT+1) from comment #39)
> (In reply to Jim Porter (:squib) from comment #38)
> > The correct way for FormatDisplayName to indicate that the full address
> > (display name + email) should be shown is to return `null`, not to
> > reconstruct the full address in-place.
> Well, when returning null, the display name from the card is displayed, and
> that's what we don't want.

No, it uses the full address from the header: <http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1332>. This is ultimately retrieved by parsing the message header here: <http://mxr.mozilla.org/comm-central/source/mail/base/content/msgHdrViewOverlay.js#1230>.

You'll have to change the logic in FormatDisplayName to use the display name from the card if PreferDisplayName is true and to return null otherwise.

Comment 42

[Jorg K (CEST = GMT+2)]

Attachment: Proposed dead-simple solution (v2).

OK, Jim was right, here comes another patch.

Comment 43

[Magnus Melin [:mkmelin]]

Comment on attachment 8720556 [details] [diff] [review]
Proposed dead-simple solution (v2).

Review of attachment 8720556 [details] [diff] [review]:
-----------------------------------------------------------------

The aHeaderDisplayName param is not used anything anymore so you should remove that too.

Looks like also FormatDisplayNameList should fall back to raw value, not the name.

Other than that, looks good. Thx for taking it on!

Comment 44

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #43)
> The aHeaderDisplayName param is not used anything anymore so you should
> remove that too.
Will do.

> Looks like also FormatDisplayNameList should fall back to raw value, not the
> name.
Hmm, I will experiment with the raw value (aHeaderValue). If no good, I'll use "name <email>".

Comment 45

[Jim Porter (:squib)]

(In reply to Magnus Melin from comment #43)
> Comment on attachment 8720556 [details] [diff] [review]
> Proposed dead-simple solution (v2).
> 
> Review of attachment 8720556 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The aHeaderDisplayName param is not used anything anymore so you should
> remove that too.

No, please don't. This function is intended for add-on authors to replace, and the header display name would be useful for alternate forms of FormatDisplayName.

Comment 46

[Magnus Melin [:mkmelin]]

I don't think that kind of hook-logic is really used elsewhere in thunderbird. You can always think of some case, somewhere where someone would like a certain in-param, but bottom-line the functions should have only what they need in core.

Comment 47

[Jorg K (CEST = GMT+2)]

Attachment: Proposed simple solution (v3).

OK, as per Jim's comment, I left the unused parameter. If you guys can get an agreement, I can remove it. In fact, I already removed it and put it back.

FormatDisplayName() returns null to indicate that the default display should be used, so in FormatDisplayNameList() I construct it. I only use the raw header if no e-mail address was parsed.

For the record: The list name seems to appear in the message pane, when more than one message is selected in the list and a summary is displayed.

I hope you like it, otherwise, we do another round ;-(

Comment 48

[Jorg K (CEST = GMT+2)]

Looks like Jim worked in this area in bug 474721 and bug 563062, so perhaps he wants to review it?

Comment 49

[Magnus Melin [:mkmelin]]

I guess I'm ok with preserving aHeaderDisplayName in this case.

Comment 50

[Jorg K (CEST = GMT+2)]

Well, the patch preserves aHeaderDisplayName, so it's ready for review.

Comment 51

[Magnus Melin [:mkmelin]]

Comment on attachment 8720964 [details] [diff] [review]
Proposed simple solution (v3).

Review of attachment 8720964 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, r=mkmelin

::: mail/base/modules/displayNameUtils.js
@@ +97,1 @@
>        displayName = card.displayName || null;

might want to add a commentary here that
// If PreferDisplayName is not set, don't fallback to aHeaderDisplayName as it could
// lead to address confusion in case someone in collected addresses use an email for display name.

@@ +128,5 @@
>    }
>    else {
>      // Something strange happened, just return the raw header value.
>      return aHeaderValue;
>    }

please instead of having a return in the else, remove the else and you can have just a return aHeaderValue at the end for both cases.

Comment 52

[Jorg K (CEST = GMT+2)]

Attachment: Proposed simple solution (v4).

Thanks for the review. I've added the comment add straightened out the else case.

This needs a try run since in bug 474721 comment #77 there were test failures when changing the format of the display:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=38a21c84cdfb

Comment 53

[Kent James (:rkent)]

(In reply to Magnus Melin from comment #46)
> I don't think that kind of hook-logic is really used elsewhere in
> thunderbird. You can always think of some case, somewhere where someone
> would like a certain in-param, but bottom-line the functions should have
> only what they need in core.

I don't agree with this comment on principle. Addon authors frequently need the ability to override behavior, and we should support that in core. Generally a test should exist though, plus a comment making clear that this is an addon hook. (This is a general comment, I did not actually look at the patch).

Comment 54

[Jorg K (CEST = GMT+2)]

Kent, don't worry, we maintained the parameters as they were and there is a comment explaining it. It's all good.

Comment 55

[Jorg K (CEST = GMT+2)]

http://archive.mozilla.org/pub/thunderbird/try-builds/[e-mail]-38a21c84cdfb/try-comm-central-linux64/try-comm-central_ubuntu64_vm_test-mozmill-bm121-tests1-linux64-build6.txt.gz

OK, four test failures:
INFO -  SUMMARY-UNEXPECTED-FAIL | test-summarization.js | test-summarization.js::test_display_name_no_abook
INFO -    EXCEPTION: Expected to find sender named 'Sarah Davol', found 'Sarah Davol <[e-mail]>'
INFO -      at: test-summarization.js line 324
INFO -         check_address_name test-summarization.js:324 11
INFO -         test_display_name_no_abook test-summarization.js:338 3

INFO -  SUMMARY-UNEXPECTED-FAIL | test-summarization.js | test-summarization.js::test_display_name_abook_no_pdn
INFO -    EXCEPTION: Expected to find sender named 'Sarah Davol', found 'Sarah Davol <[e-mail]>'
INFO -      at: test-summarization.js line 324
INFO -         test_display_name_abook_no_pdn test-summarization.js:364 3

INFO -  SUMMARY-UNEXPECTED-FAIL | test-display-names.js | test-display-names.js::test_no_header_name_in_abook_no_pdn
INFO -    EXCEPTION: got '[e-mail]' but expected 'My Buddy'
INFO -      at: test-display-names.js line 97
INFO -         help_test_display_name test-display-names.js:97 11
INFO -         test_no_header_name_in_abook_no_pdn test-display-names.js:157 3

INFO -  SUMMARY-UNEXPECTED-FAIL | test-display-names.js | test-display-names.js::test_header_name_in_abook_no_pdn
INFO -    EXCEPTION: got 'Carl Sagan <[e-mail]>' but expected 'Carl Sagan'
INFO -      at: test-display-names.js line 97
INFO -         help_test_display_name test-display-names.js:97 11
INFO -         test_header_name_in_abook_no_pdn test-display-names.js:177 3

They need to be fixed before this is ready to go.

Comment 56

[Jorg K (CEST = GMT+2)]

Attachment: Proposed simple solution (v4) with tests fixed.

Comment 57

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/comm-central/rev/cafcf1e5e13f

Comment 58

[Jorg K (CEST = GMT+2)]

Comment on attachment 8721444 [details] [diff] [review]
Proposed simple solution (v4) with tests fixed.

[Approval Request Comment]
Regression caused by (bug #): No regression.
User impact if declined: Security bug, should be uplifted.
Testing completed (on c-c, etc.): Manual and in test suite.
Risk to taking this patch (and alternatives if risky):
Low, due to automated tests.

Comment 59

[Jorg K (CEST = GMT+2)]

Aurora (TB 46):
https://hg.mozilla.org/releases/comm-aurora/rev/bb8e56cb1ea8

Comment 60

[Kent James (:rkent)]

Comment on attachment 8721444 [details] [diff] [review]
Proposed simple solution (v4) with tests fixed.

[Approval Request Comment]
security uplift.

Comment 61

[info]

I don't follow all the stuff.  Is it patched? =)

Comment 62

[Jorg K (CEST = GMT+2)]

Yes, in versions 46 and 47. Version 45 will be patched before the release in March and we're considering porting it back to version 38 in case we do a 38.7 release.

Comment 63

[Kent James (:rkent)]

The short answer to "is it patched" is that it is in process, but no official release has the patch yet. The next official releases, 38.7.0 and 45.0, will be released in the middle of March. It has only been patched in the current development versions.

Comment 64

[info]

Thank you for your work =)  Look forward to the release.  Once it releases, we will release our findings for htpau.

Comment 65

[Kent James (:rkent)]

Comment on attachment 8721444 [details] [diff] [review]
Proposed simple solution (v4) with tests fixed.

https://hg.mozilla.org/releases/comm-esr38/rev/9024b08bdd48
http://hg.mozilla.org/releases/comm-esr45/rev/a0ce7bc3da49

Comment 66

[Jorg K (CEST = GMT+2)]

Comment on attachment 8721444 [details] [diff] [review]
Proposed simple solution (v4) with tests fixed.

[Triage Comment]