As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 679677 - Add more app.update.certs.* possibilities to SeaMonkey
: Add more app.update.certs.* possibilities to SeaMonkey
Product: SeaMonkey
Classification: Client Software
Component: Security (show other bugs)
: Trunk
: All All
: -- normal (vote)
: seamonkey2.5
Assigned To: Justin Wood (:Callek)
Depends on:
  Show dependency treegraph
Reported: 2011-08-17 05:55 PDT by Robert Kaiser
Modified: 2011-08-23 05:21 PDT (History)
3 users (show)
bugspam.Callek: in‑testsuite-
bugspam.Callek: blocking‑seamonkey2.0.15-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

comm-release (906 bytes, patch)
2011-08-17 07:54 PDT, Justin Wood (:Callek)
no flags Details | Diff | Splinter Review
v1.1 comm-release (917 bytes, patch)
2011-08-17 07:56 PDT, Justin Wood (:Callek)
kairo: review+
smani: feedback+
philip.chee: approval‑comm‑aurora+
philip.chee: approval‑comm‑beta+
bugspam.Callek: approval‑seamonkey2.0.15-
Details | Diff | Splinter Review

Description User image Robert Kaiser 2011-08-17 05:55:07 PDT
SeaMonkey currently only has one CA possibility for update:

Firefox has two:,139-140#124

We should add one or two in addition, so we have more freedom of where to get our certs from. Restricting them is good for security, but only one choice is bad again, giving us no possibilities to switch if one CA has a problem.

fox2mike: Which CA(s) would Mozilla prefer us to add there?

(Note that it will take quite some time until we have a so high audience on new versions that we could abandon the current one, but the sooner we introduce other pref values, the sooner we'll be actually able to have a choice.)
Comment 1 User image Justin Wood (:Callek) 2011-08-17 07:54:08 PDT
Created attachment 553768 [details] [diff] [review]

Patch against comm-release (will check shortly if it applies elsewhere)
Comment 2 User image Justin Wood (:Callek) 2011-08-17 07:56:18 PDT
Created attachment 553771 [details] [diff] [review]
v1.1 comm-release

Whops, missed a save point before refressing.
Comment 3 User image Shyam Mani [:fox2mike] 2011-08-17 09:22:24 PDT
Comment on attachment 553771 [details] [diff] [review]
v1.1 comm-release

Yes, that seems fine. Can we build a test build with this setting, and test? I can switch the certs out, we can test and switch back. Would be a shame to put this in the code and ship without testing.
Comment 4 User image Robert Kaiser 2011-08-17 09:42:35 PDT
Comment on attachment 553771 [details] [diff] [review]
v1.1 comm-release

>+pref("app.update.certs.2.issuerName", 'CN=GeoTrust SSL CA,O="GeoTrust, Inc.",C=US');

Given the way we quote Thawte:

>+pref("app.update.certs.3.issuerName", "CN=Thawte SSL CA,O=\"Thawte, Inc.\",C=US");

can you please go for the same style for GeoTrust?

With that, let's land this on trunk, kick off nightlies with it and test them with the old and new certificates. Please also go through testing with and older build with manually adding those. Once that's done, please request approval for aurora/beta/release (I see that comm doesn't have a release approval tag, btw).
Comment 5 User image Justin Wood (:Callek) 2011-08-17 19:28:03 PDT

We'll test this tomorrow.

Pre-requesting approvals.
Comment 6 User image Philip Chee 2011-08-17 21:04:42 PDT
Comment on attachment 553771 [details] [diff] [review]
v1.1 comm-release

rs=me assuming this tests out successfully.
Comment 7 User image Justin Wood (:Callek) 2011-08-20 10:01:57 PDT

Turns out we don't need this for 2.0.x (we don't actually check the cert this way there) I'll plan an extra aus test with the non-modified 2.0.x just to be safe.

Note You need to log in before you can comment on or make changes to this bug.