Closed Bug 1018259 Opened 10 years ago Closed 10 years ago

Thunderbird should stop using SHA-1 when signing email messages

Categories

(Thunderbird :: Security, enhancement)

enhancement
Not set
normal

Tracking

(thunderbird36 fixed)

RESOLVED FIXED
Thunderbird 36.0
Tracking Status
thunderbird36 --- fixed

People

(Reporter: dcooper16, Assigned: dcooper16)

References

Details

Attachments

(2 files, 7 obsolete files)

Thunderbird is currently hardcoded to always use SHA-1 when signing email messages. However, there is a growing consensus that it is time to move away from using SHA-1 for digital signatures.

For the U.S. Federal government, the National Institute of Standards and Technology states that SHA-1 can no longer be used to create digital signatures: http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf.

Bruce Schneier wrote a blog post a couple of years ago saying that "we in the community need to start the migration away from SHA-1 and to SHA-2/SHA-3 now." (https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html)

Microsoft has announced a policy deprecating the use of SHA-1 when signing certificates: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx. Based on this decision, it has been recommended that in the near future Mozilla also stop accepting some certificates that have been signed using SHA-1 (bug 942515). It has similarly been suggested to move from SHA-1 to SHA-2 for other purposes in order to reduce reliance on SHA-1 (bug 917510).

For these reasons I believe that Thunderbird should also strongly consider moving away from using SHA-1 when signing email messages.

The attached patch addresses this by choosing the most appropriate hash function based on the size and type of the key being used to sign the email, using the hash function whose strength most closely matches that of the key.

Note that in order to work, this patch must be used in conjunction with Patch 1 that was submitted for bug 222179 (https://bugzilla.mozilla.org/attachment.cgi?id=8431595&action=edit). Bug 222179 addresses the move away from SHA-1 by allowing the user to select the hash function, as opposed to this patch, which automatically selects the most appropriate hash function without user involvement.
Attachment #8431629 - Flags: review?(mkmelin+mozilla)
Attachment #8431629 - Flags: review?(Pidgeot18)
Comment on attachment 8431629 [details] [diff] [review]
Select hash function to sign email based on key type and size

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

I've not had the time to look at the substance of this patch yet. There are several minor style issues that should be addressed before the next patch.

While I would normally insist on tests for this sort of change, unfortunately the framework for testing this sort of stuff is still sitting on a patch in my hard drive. :-(

::: mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
@@ +11,2 @@
>  #include "msgCore.h"
> +#include "nsIX509Cert3.h"

Nit: please sort this before nsIX509CertDB.h in the header list.

@@ +49,5 @@
>                                                void *closure);
>  static nsresult make_multipart_signed_header_string(bool outer_p,
>                    char **header_return,
> +                  char **boundary_return,
> +                  int16_t hash_type);

Nit: the indentation here is incorrect; you probably want to align with the open paren like (almost) everyone else here.

@@ +312,5 @@
>    }
>    return NS_OK;
>  }
>  
> +// Select a hash algorithm to sign message based on subject public key type and size. //

Nit: No trailing '//' on comments.

@@ +314,5 @@
>  }
>  
> +// Select a hash algorithm to sign message based on subject public key type and size. //
> +static nsresult
> +getSigningHashFunction(/*out*/ PRInt16 *mHashType, nsIX509Cert *aSigningCert)

Nits:
1. Function name should be GetSigningHashFunction.
2. Use int16_t instead of PRint16.
3. Outparams should be sorted after inparams.
4. Never call an argument mHashType. The 'm' prefix is for 'member'
5. We generally don't comment /*out*/ for outparams.

@@ +338,5 @@
> +  }
> +
> +  unsigned keylen;
> +  if ((subjectPublicKeyType == rsaKey) ||
> +      (subjectPublicKeyType == rsaPssKey)) {

Nit: too many parentheses.

@@ +340,5 @@
> +  unsigned keylen;
> +  if ((subjectPublicKeyType == rsaKey) ||
> +      (subjectPublicKeyType == rsaPssKey)) {
> +    keylen = 8 * siglen;
> +    

Nit: trailing whitspace.

@@ +1018,5 @@
>  static nsresult
>  make_multipart_signed_header_string(bool outer_p,
>  									char **header_return,
> +									char **boundary_return,
> +									int16_t hash_type)

Nit: the indentation here is way off-kilter. (Looks like the original file used tabs?) I know it's not your fault, but please fix this anyways.

@@ +1023,2 @@
>  {
> +  char hash_str[20];

char *hashStr = nullptr;

...

@@ +1029,5 @@
>  	return NS_ERROR_OUT_OF_MEMORY;
>  
> +  switch (hash_type) {
> +  case nsICryptoHash::SHA1:
> +    sprintf(hash_str, PARAM_MICALG_SHA1);

... and hashStr = PARAM_MICALG_SHA1. These are string literals, copying them is completely unnecessary.
Joshua,

Thanks for the quick feedback. I went ahead and fixed the style issues that you raised.

I also just fixed a nit that David Keeler raised on the related patch in bug 222179 (https://bugzilla.mozilla.org/attachment.cgi?id=8431818&action=edit).

David
Attachment #8431629 - Attachment is obsolete: true
Attachment #8431629 - Flags: review?(mkmelin+mozilla)
Attachment #8431629 - Flags: review?(Pidgeot18)
Attachment #8431822 - Flags: review?(mkmelin+mozilla)
Attachment #8431822 - Flags: review?(Pidgeot18)
Comment on attachment 8431822 [details] [diff] [review]
Select hash function to sign email based on key type and size

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

::: mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
@@ +312,5 @@
>    }
>    return NS_OK;
>  }
>  
> +// Select a hash algorithm to sign message based on subject public key type and size.

Nit: break at 80 characters.

@@ +319,5 @@
> +{
> +  // Get the signing certificate
> +  nsCOMPtr<nsIX509Cert2> aSigningCert2 = do_QueryInterface(aSigningCert);
> +  CERTCertificate *scert = nullptr;
> +  if (aSigningCert2) {

Some more nits: these one line if statements don't need bracing. (Wasn't sure if that was prevailing style in this file without checking).

@@ +414,5 @@
>    if (NS_FAILED(rv)) {
>      goto FAIL;
>    }
>  
> +  if (signMessage && (mSelfSigningCert != nullptr)) {

Nit: if (signMessage && !mSelfSigningCert)

@@ +418,5 @@
> +  if (signMessage && (mSelfSigningCert != nullptr)) {
> +    rv = GetSigningHashFunction(mSelfSigningCert, &mHashType);
> +    if (NS_FAILED(rv)) {
> +      goto FAIL;
> +    }

Please use NS_ENSURE_SUCCESS(rv, rv); instead of the if (NS_FAILED(rv)) goto FAIL;

@@ +489,5 @@
>    char *header = 0;
>    uint32_t L;
>  
>    rv = make_multipart_signed_header_string(aOuter, &header,
> +                    &mMultipartSignedBoundary, mHashType);

Nit: this should only be indented two spaces.

@@ -636,5 @@
>  
>    /* Create the signature...
>     */
>  
> -  PR_ASSERT(mHashType == nsICryptoHash::SHA1);

You're removing the check that the hash type is valid here. I think I'd like to see mHashType initialized to 0 in the constructor and then add an NS_ASSERTION(mHashType != 0, "Should not be signing a certificate without a hash type"); or something similar.

@@ +716,5 @@
>    PR_ASSERT (mSelfSigningCert);
>    PR_SetError(0,0);
>  
> +  rv = cinfo->CreateSigned(mSelfSigningCert, mSelfEncryptionCert,
> +              (unsigned char*)hashString.get(), hashString.Length(), mHashType);

Nit: indent only two spaces
In addition to all of the above nits, there is one concern I have:

Why go through all the trouble of trying to derive the hash algorithm from the strength of the key? If the concern is that SHA-1 is too weak, why emit it at all?

The valid reasons I can see to not use SHA-256 or stronger is if there's a deployment which doesn't support SHA-256. Outlook supports verifying SHA-256 signed messages starting on Outlook 2003 with at least Vista, but not XP, even support XP SP3, according to <http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx>. This suggests that there is a potential need to force sha1 support, but I'm also wary of putting this in a hidden preference because people will tend to set-and-forget these kinds of things. Given that XP is now end-of-life and the kind of people who are likely to use S/MIME messages, maybe it isn't a big deal. But I don't have an install of Outlook handy to shove into my XP VM for testing. :-(

Looking at some other documentation, it seems very unlikely that we'll come across a client that can't support SHA-256-signed messages (even Thunderbird 2 ought to support that).
(In reply to Joshua Cranmer [:jcranmer] from comment #4)
> Looking at some other documentation, it seems very unlikely that we'll come
> across a client that can't support SHA-256-signed messages (even Thunderbird
> 2 ought to support that).

For the case of detached signatures (i.e. the prevalent one), it was Tb 5, released in June 2011, which added support for SHA-2 hashes - see bug 541334.
(In reply to Joshua Cranmer [:jcranmer] from comment #3)
> > +  if (signMessage && (mSelfSigningCert != nullptr)) {
> 
> Nit: if (signMessage && !mSelfSigningCert)

if (signMessage && mSelfSigningCert) he meant of course


Given this would probably not go into a general release until tb38 in when ? ... beginning of 2015? I would not bother supporting XP installations of EOL:d software at that point in time. Anyone who is at all concerned about safety would switched by then, and that is not the people setting up S/MIME for them selves. TB5 is also long ago EOL:d and people should just upgrade.
Joshua,

I tried to address all of the nits that you pointed out. I checked the file and there was no consistency on whether to include braces around one-line if statements, so I left in. It provides a bit of safety in case the code is later modified to add another line within the if statement, and in bug 222179 comment 33 I was specifically asked to include braces single line if statements.

I followed your suggestion to get mHashType to 0 and then include the NS_ASSERTION in MimeFinishMultipartSigned. I discovered, however, that the NS_ASSERTION isn't really necessary as there are two checks in MimeInitMultipartSigned that will fail is mHashType = 0, so the call to MimeFinishMultipartSigned will never be made in that case.

For the indentation issues, I tried to adjust the indentation to match the formatting used elsewhere when a function call can't fit on a single line.

(In reply to Joshua Cranmer [:jcranmer] from comment #4)
> Why go through all of the trouble of trying to derive the hash algorithm
> from the strength of the key? If the concern is that SHA-1 is too weak, why
> emit it al all?

In the case of DSA and ECC there is no choice. For DSA, NSS will refuse to sign the message if the length of the hash if longer than the length of the q parameter. Similarly for ECC, NSS will refuse to sign the message if the length of the hash is longer than the field size. So, for DSA and ECC, GetSigningHashFunction returns the strongest hash function that NSS will accept. This also results in the strength of the hash matching the strength of the key, which is generally considered best practice.

In the case of RSA, GetSigningHashFunction could just ignore the key length and always use SHA-256. No one would use an RSA key with a modulus so short that a SHA-256 hash couldn't be used, and no one uses RSA keys that are long enough to justify using SHA-384 or SHA-512. Rather than just always using SHA-256, though, I went with the approach of selecting the hash function that most closely aligned with the strength of the key, with the result being that if one uses a weak key then a comparably weak hash algorithm is used.

Either way is okay with me for RSA, though. For my use case, any RSA keys would be at least 2048 bits in length.
Attachment #8431822 - Attachment is obsolete: true
Attachment #8431822 - Flags: review?(mkmelin+mozilla)
Attachment #8431822 - Flags: review?(Pidgeot18)
Attachment #8432608 - Flags: review?(mkmelin+mozilla)
Attachment #8432608 - Flags: review?(Pidgeot18)
(In reply to David Cooper from comment #7)
> For the indentation issues, I tried to adjust the indentation to match the
> formatting used elsewhere when a function call can't fit on a single line.

The general formatting used in comm-central code is to indent two spaces in almost all circumstances. Some of the older code is the victim of several automated whitespace conversion patches (mostly delete-tabs) that ended up leaving indentation in the wrong amounts.

> In the case of DSA and ECC there is no choice. For DSA, NSS will refuse to
> sign the message if the length of the hash if longer than the length of the
> q parameter. Similarly for ECC, NSS will refuse to sign the message if the
> length of the hash is longer than the field size. So, for DSA and ECC,
> GetSigningHashFunction returns the strongest hash function that NSS will
> accept. This also results in the strength of the hash matching the strength
> of the key, which is generally considered best practice.

This is the sort of information I like seeing in comments in the code. The way the code is currently proposed, it reads to me like a giant block of magic code with no explanation of what's going on or why it is like that.

Seeing the constant assigning to a temporary keylen variable raises the question: why are you using the signature length instead of using the key length directly?

Some other notes:
1. NSS appears to not really support rsaPssKey or fortezzaKey, at least for SECKEY_*Len functions. I don't think they're useful here.
2. Add an NS_WARNING when we hit the unknown key type.
3. Wouldn't it make more sense to default to SHA-256 or something stronger for an unknown key? An unknown key to me implies that NSS added some new public key algorithm, and I can't see any new algorithm needing or wanting to default to the weakest SHA algorithm. There's also no backwards compatibility concern in that situation, either.
4. I'd like to see tests here. There's a start to an S/MIME suite in bug 1011625, but it clearly needs a lot of work (I only support RSA certificates, e.g., and it depends on another bug to even apply correctly). I'd be happy to work with you to build a testsuite, but my ability to do any helping is severely curtailed for the next week.
(In reply to Joshua Cranmer [:jcranmer] (away June 7-12) from comment #8)
> (In reply to David Cooper from comment #7)
> > For the indentation issues, I tried to adjust the indentation to match the
> > formatting used elsewhere when a function call can't fit on a single line.
> 
> The general formatting used in comm-central code is to indent two spaces in
> almost all circumstances. Some of the older code is the victim of several
> automated whitespace conversion patches (mostly delete-tabs) that ended up
> leaving indentation in the wrong amounts.

I tried again to set the indentation in the two places that you mentioned, but I don't know if this is what you want, as I cannot find any other place in which the second line in a function call is only indented two spaces.

> > In the case of DSA and ECC there is no choice. For DSA, NSS will refuse to
> > sign the message if the length of the hash if longer than the length of the
> > q parameter. Similarly for ECC, NSS will refuse to sign the message if the
> > length of the hash is longer than the field size. So, for DSA and ECC,
> > GetSigningHashFunction returns the strongest hash function that NSS will
> > accept. This also results in the strength of the hash matching the strength
> > of the key, which is generally considered best practice.
> 
> This is the sort of information I like seeing in comments in the code. The
> way the code is currently proposed, it reads to me like a giant block of
> magic code with no explanation of what's going on or why it is like that.
> 
> Seeing the constant assigning to a temporary keylen variable raises the
> question: why are you using the signature length instead of using the key
> length directly?

Okay, I've added a lot more comments to the code in order to try to explain the basis for the selection process. I got rid of the conversion from siglen to keylen and just select the hash based on siglen. I think this makes the code harder to read, but hopefully I made up for that with comments that specify the key length (in bits) that corresponds to each signature length (in bytes).

The reason that the code can't just use key length instead of signature length is because of DSA. For RSA signature length and key length are the same, and the code previously just converted from bytes to bits since people are used to thinking of key lengths in bits. For ECDSA, I believe I could have used either key length or signature length, since the signature length is generally twice the length of the key, but I think the hash is supposed to be based on the signature length.

DSA, however, has two components to its "key length." FIPS 186-4 describes it as follows:

    This Standard [FIPS 186-4] specifies the following choices for the pair
    L and N (the bit lengths of p and q, respectively):

        L = 1024, N = 160
        L = 2048, N = 224
        L = 2048, N = 256
        L = 3072, N = 256

(p and q are parameters.) The length of the public key is L, whereas the length of the signature is 2N. The hash function selected for the signature has to have a length of at most N (and ideally has a length of exactly N).

If I asked NSS for the length of the public key it would give me L, whereas asking for the length of the signature gives me 2N. (Note that it's not possible to convert from key length to signature length since, even with the restricted options in FIPS 186-4, a key length of L = 2048 could correspond to either N = 224 or N = 256.) So, in order to know which hash algorithm to select I need to ask for the signature length.

> Some other notes:
> 1. NSS appears to not really support rsaPssKey or fortezzaKey, at least for
> SECKEY_*Len functions. I don't think they're useful here.

Okay, I removed these two key types.

> 2. Add an NS_WARNING when we hit the unknown key type.

Done.

> 3. Wouldn't it make more sense to default to SHA-256 or something stronger
> for an unknown key? An unknown key to me implies that NSS added some new
> public key algorithm, and I can't see any new algorithm needing or wanting
> to default to the weakest SHA algorithm. There's also no backwards
> compatibility concern in that situation, either.

Okay, I changed it to SHA-256.

> 4. I'd like to see tests here. There's a start to an S/MIME suite in bug
> 1011625, but it clearly needs a lot of work (I only support RSA
> certificates, e.g., and it depends on another bug to even apply correctly).
> I'd be happy to work with you to build a testsuite, but my ability to do any
> helping is severely curtailed for the next week.

I can try to contribute to the tests you're developing in bug 1011625. My ability to help may be limited, though, given that I am not familiar with either JavaScript or Python.
Attachment #8432608 - Attachment is obsolete: true
Attachment #8432608 - Flags: review?(mkmelin+mozilla)
Attachment #8432608 - Flags: review?(Pidgeot18)
Attachment #8437726 - Flags: review?(mkmelin+mozilla)
Attachment #8437726 - Flags: review?(Pidgeot18)
Comment on attachment 8437726 [details] [diff] [review]
Select hash function to sign email based on key type and size

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

Very, very close!

::: mailnews/extensions/smime/src/nsMsgComposeSecure.cpp
@@ +333,5 @@
> +  if (!scertPublicKey) {
> +    return mozilla::MapSECStatus(SECFailure);
> +  }
> +  KeyType subjectPublicKeyType = SECKEY_GetPublicKeyType(scertPublicKey);
> +  unsigned siglen = SECKEY_SignatureLen(scertPublicKey);

It looks like you want to use bits here whereas the method returns bytes, so you probably ought to say

// Get the length of the signature hash in bits
unsigned siglen = SECKEY_SignatureLen(scertPublicKey) * 8;

@@ +341,5 @@
> +
> +  // Select a hash function for signature generation whose security strength
> +  // meets or exceeds the security strength of the public key, using NIST
> +  // Special Publication SP 800-57, Recommendation for Key Management - Part 1:
> +  // General (Revision 3), where Table 3 specifies the security strength of

Nit: this is Table 2, not Table 3. :-)

@@ +344,5 @@
> +  // Special Publication SP 800-57, Recommendation for Key Management - Part 1:
> +  // General (Revision 3), where Table 3 specifies the security strength of
> +  // the public key and Table 3 lists acceptable hash functions. (The security
> +  // strength of the hash (for digital signatures) is half the length of the
> +  // output.)

An http link to the document referenced here would be useful.
Attachment #8437726 - Flags: review?(Pidgeot18) → review-
(In reply to David Cooper from comment #9)
> The reason that the code can't just use key length instead of signature
> length is because of DSA. For RSA signature length and key length are the
> same, and the code previously just converted from bytes to bits since people
> are used to thinking of key lengths in bits. For ECDSA, I believe I could
> have used either key length or signature length, since the signature length
> is generally twice the length of the key, but I think the hash is supposed
> to be based on the signature length.

After reading the NIST documentation and the NSS source code in closer detail, I've come to the conclusion that this is information that somehow ought to be exposed in NSS. Given that it's not in NSS, though, I'm generally fine with the code as written in the latest patch, with the caveat that you measure in bits instead of bytes.

> I can try to contribute to the tests you're developing in bug 1011625. My
> ability to help may be limited, though, given that I am not familiar with
> either JavaScript or Python.

I won't insist on tests in this bug. Hopefully, I can start with one test and that would be sufficient to let you copy-paste your way to success. :-)
This should address the remaining issues that were raised in comment #10.
Attachment #8437726 - Attachment is obsolete: true
Attachment #8437726 - Flags: review?(mkmelin+mozilla)
Attachment #8440916 - Flags: review?(mkmelin+mozilla)
Attachment #8440916 - Flags: review?(Pidgeot18)
In working on making the suggested changes to the patch for bug 222179 I discovered that since I began working on that patch NSS has been modified so that it now will create DSA and ECDSA signatures using a hash that is longer than the key size. [This is permitted by the standard, which specifies that the hash value be truncated to the length of the key.] So, I updated this patch to reflect that. The update does not involve any changes to the code, just changes to a couple of the comments within GetSigningHashFunction.
Attachment #8440916 - Attachment is obsolete: true
Attachment #8440916 - Flags: review?(mkmelin+mozilla)
Attachment #8440916 - Flags: review?(Pidgeot18)
Attachment #8442170 - Flags: review?(mkmelin+mozilla)
Attachment #8442170 - Flags: review?(Pidgeot18)
Comment on attachment 8442170 [details] [diff] [review]
Select hash function to sign email based on key type and size

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

Sorry for the extended delay in reviewing this, but your review request happened to land at a bad time for me.

Unfortunately, thanks to mozilla-central kicking out the S/MIME code to comm-central and other changes to interfaces (most notably the consolidation of nsIX509Cert interfaces), this patch no longer applies and works. That said, based on prior discussions and changes, I think I'm happy with this patch modulo the inability to apply issues.
Attachment #8442170 - Flags: review?(Pidgeot18) → feedback+
Okay, here is a revised patch that works with the current code and that incorporates the patch that I previously submittted for mozilla-central (in bug 222179).
Attachment #8442170 - Attachment is obsolete: true
Attachment #8442170 - Flags: review?(mkmelin+mozilla)
Attachment #8462639 - Flags: review?(mkmelin+mozilla)
Attachment #8462639 - Flags: review?(Pidgeot18)
Attachment #8462639 - Flags: review?(Pidgeot18) → review+
Assignee: nobody → dcooper16
Status: NEW → ASSIGNED
Comment on attachment 8462639 [details] [diff] [review]
Select hash function to sign email based on key type and size

Looks ok to me, though I don't know that much about this code.
There's a slight bitrot, I'll attach an updated patch for checkin.
Attachment #8462639 - Flags: review?(mkmelin+mozilla) → review+
https://hg.mozilla.org/comm-central/rev/dcc6a567b46e
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 35.0
I just had to back this out due to linker bustage on windows:

https://hg.mozilla.org/comm-central/rev/1575d08812cb

nsMsgComposeSecure.obj : error LNK2019: unresolved external symbol _SECKEY_SignatureLen referenced in function "enum tag_nsresult __cdecl GetSigningHashFunction(class nsIX509Cert *,short *)" (?GetSigningHashFunction@@YA?AW4tag_nsresult@@PAVnsIX509Cert@@PAF@Z)

nsMsgComposeSecure.obj : error LNK2019: unresolved external symbol _SECKEY_GetPublicKeyType referenced in function "enum tag_nsresult __cdecl GetSigningHashFunction(class nsIX509Cert *,short *)" (?GetSigningHashFunction@@YA?AW4tag_nsresult@@PAVnsIX509Cert@@PAF@Z)

xul.dll : fatal error LNK1120: 2 unresolved externals
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Mark Banner (:standard8) from comment #19)
> I just had to back this out due to linker bustage on windows:

The two symbols need to be added to m-c's config/external/nss/nss.def. Not sure whom to ask for review, so feel free to redirect... (and I deliberately included David as the author, no need for mentioning my name in the commit).
Attachment #8485382 - Flags: review?(standard8)
Attachment #8485382 - Flags: review?(standard8) → review?(dkeeler)
Attachment #8485382 - Flags: review?(dkeeler) → review+
(Attachment 8485382 [details] [diff] should first land on m-c)
Keywords: checkin-needed
(Temporarily) changing product to Core, in the hope that it will show up in the relevant checkin-needed search.
Product: Thunderbird → Core
Whiteboard: Attachment 8485382 needs checkin on m-c, see comment 21
Target Milestone: Thunderbird 35.0 → ---
https://hg.mozilla.org/mozilla-central/rev/90f8728118e8
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Thanks, Carsten. Reopening and changing product back to Thunderbird. Attachment 8482391 [details] [diff] now needs checkin on comm-central.
Status: RESOLVED → REOPENED
Keywords: checkin-needed
Product: Core → Thunderbird
Resolution: FIXED → ---
Whiteboard: Attachment 8485382 needs checkin on m-c, see comment 21 → Attachment 8482391 needs checkin on c-c, see comment 25
Target Milestone: mozilla35 → Thunderbird 35.0
Comment on attachment 8485382 [details] [diff] [review]
Windows build adjustments (m-c) [checked in]

Marking m-c part as [checked in]
Attachment #8485382 - Attachment description: Windows build adjustments (m-c) → Windows build adjustments (m-c) [checked in]
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: Thunderbird 35.0 → Thunderbird 36.0
Whiteboard: Attachment 8482391 needs checkin on c-c, see comment 25
Depends on: 1111578
Depends on: 1167857
You need to log in before you can comment on or make changes to this bug.