Closed Bug 122961 Opened 19 years ago Closed 19 years ago

NSS 3.4 / can't send encrypted mail

Categories

(MailNews Core :: Security: S/MIME, defect, P1)

1.0 Branch
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: KaiE, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

New profile.
Imported internal CA dual key cert from p12 file.
Both encryption and signing cert show up as verified in cert manager.

Trying to send encrypted mail to myself fails.
Mozilla says, recipient encryption certificate can not be found.
Well, I realize that we not yet resolved the issue, that has been discussed in
bug 116334, comments 21-27.

#ifdef NSS_3_4
// fix this... rjr
certList = nsnull;
#else
certList = CERT_CreateEmailAddrCertList(nsnull, CERT_GetDefaultCertDB(),
            (char*)aEmailAddress, PR_Now(), PR_TRUE);
#endif

I'm adding this as a blocker for 116334, please remove it if you think it is not.

My understanding is, if we land 116334 without this bug being fixed, nobody will
be able to send encrypted email.

I see function CERT_CreateEmailAddrCertList is not available in 3.4. I found
CERT_FindCertByNicknameOrEmailAddr. I wonder whether we can use that temporarily.
Blocks: 116334
Attached patch Suggested fix (obsolete) — Splinter Review
This works for me, at least for sending to myself.
->me
cc'ing NSS people, as this is a potential 3.4 landing blocker.
Assignee: ssaux → kaie
this is not 3.4 specific. This will happen to a 3.3 build as well. The reason is
that one must have one's own encryption certificate in the Others database in
order for the s/mime code to find it.

The problem was first reported in bug 114893

If you agree, then this should not block 116334.

No longer blocks: 116334
Stephane, the problem is actually some else. PSM has a code section that is
different for NSS 3.3 and 3.4, controlled by #idef.

While there is working code in the path for 3.3, there is currently no code at
all  that could find a recipient's cert. The reason for code absence is, that is
has not yet been implemented, as 3.4 requires different logic.
Attached patch Updated fixSplinter Review
The previous fix did not care for the case that the found certificate has the
wrong usage. This new patch tries to solve that.

Bob, you can please review? I had to export one more function from NSS.
Attachment #67421 - Attachment is obsolete: true

patch (included exported function) looks good.
r=relyea

Alec, can you please sr= ?
Status: NEW → ASSIGNED
Comment on attachment 67512 [details] [diff] [review]
Updated fix

you should return NS_ERROR_OUT_OF_MEMORY if new fails, other than that sr=alecf
Attachment #67512 - Flags: superreview+
Comment on attachment 67512 [details] [diff] [review]
Updated fix

As per Bob Relyea's comment.
Attachment #67512 - Flags: review+
Comment on attachment 67512 [details] [diff] [review]
Updated fix

The change to mozilla/security/nss/lib/nss/nss.def
has been checked into the NSS main trunk.
Does this need 3.4?
Otherwise it's ready to go in.
Priority: -- → P1
Target Milestone: --- → 2.2
Version: 1.01 → 2.2
Checked in including Alec's request, marking fixed.
Blocks: 74157
You've forgot to actually mark it fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
QA Contact: alam → junruh
Product: PSM → Core
Version: psm2.2 → 1.0 Branch
Product: Core → MailNews Core
QA Contact: junruh → s.mime
You need to log in before you can comment on or make changes to this bug.