Workaround for Add-Certificate-Exception for (mail) ports blocked by Necko

RESOLVED FIXED

Status

()

--
major
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: kaie, Assigned: kaie)

Tracking

({regression})

Trunk
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
Please see bug 387480 comment 74 to 77
for the discussion that lead to the creation of this bug.

In short:
- the new add-exception dialog that got added with bug 387480 currently uses
  xmlhttprequest to obtain the cert
- necko blocks access to many ports, including all standard mail server ports,
  so currently it's impossible to add exceptions for mail servers.

I'm proposing a workaround, that will make the add-exception dialog work,
as soon as you've visited the broken site.


The "real" solution (do not require to visit bad server first)
will be more difficult to implement.

(But in my opinion, even the "real" solution will benefit from
the code I'm proposing for this workaround.
The major problem for the real solution is sites like STARTTLS,
that use a protocol dependent plaintext communication.
Therefore, the real solution will most likely involve changes to 
protocol dependent configuration UI (like SMTP server configuration).
In that context, a button could initiate a protocol connection
to the server, in order to obtain the server certificate.
With the code I'm proposing, it will be sufficient to open a connection.
The protocol specific code won't have to deal with obtaining and storing the cert)

I'll attach the patch that I had initially attached to bug 387480 comment 73.
(Assignee)

Comment 1

11 years ago
Created attachment 284016 [details] [diff] [review]
Patch v1
Attachment #284016 - Flags: review?(rrelyea)
(Assignee)

Comment 2

11 years ago
This should block 1.9, because without it, we make life really difficult for mail users.

We have a patch already.
Flags: blocking1.9?

Updated

11 years ago
Duplicate of this bug: 399174

Comment 4

11 years ago
Comment on attachment 284016 [details] [diff] [review]
Patch v1

r+ I've reviewed this once already;).
Attachment #284016 - Flags: review?(rrelyea) → review+
(Assignee)

Comment 5

11 years ago
Comment on attachment 284016 [details] [diff] [review]
Patch v1

Requesting approval for this patch to make mail users happy (both Thunderbird / SeaMonkey)
Attachment #284016 - Flags: approval1.9?

Updated

11 years ago
Attachment #284016 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 6

11 years ago
checked in, marking fixed.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
V.Fixed between
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101503 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)
and
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007101611 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

The U.I. now lets me add <imap/ssl>:993 and <smtp/ssl>:465 entries.
(See (duplicate) bug 398534.)
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
Blocks: 327181
No longer blocks: 398534
Duplicate of this bug: 398534
Severity: normal → major
Keywords: mail4, regression
(Assignee)

Comment 9

11 years ago
Reopening bug. All patches that got checked in to trunk yesterday are being backed out, because it's unclear which patch has caused a performance regression.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 10

11 years ago
checked in again, marking fixed.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.