Closed
Bug 503515
Opened 15 years ago
Closed 8 years ago
exporting certificates lack an extension
Categories
(Core Graveyard :: Security: UI, defect)
Core Graveyard
Security: UI
Tracking
(firefox47 fixed)
RESOLVED
FIXED
mozilla47
Tracking | Status | |
---|---|---|
firefox47 | --- | fixed |
People
(Reporter: kbrosnan, Assigned: Cykesiopka)
References
Details
(Whiteboard: [securitytestday])
Attachments
(3 files, 1 obsolete file)
Export a cert via options/prefs > advanced > encryption > view certificates > servers > export don't have a file extension. This makes importing the file via the certificate manger harder as it is not detected by the file picker. If you don't have an exception listed you can add one by visiting https://verisign.com
Reporter | ||
Updated•15 years ago
|
Whiteboard: [securitytestday]
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
in-litmus+ https://litmus.mozilla.org/show_test.cgi?id=6017 This is the actual test case that discovered the bug.
Flags: in-litmus+
Version: unspecified → 1.9.1 Branch
Assignee | ||
Comment 4•8 years ago
|
||
Note that on Windows, a .crt extension *is* in fact appended. On my Linux setup, there is no extension appended, as noted in comment 0.
Assignee: nobody → cykesiopka.bmo
Severity: normal → minor
Status: NEW → ASSIGNED
Component: Security → Security: UI
Product: Toolkit → Core
Version: 1.9.1 Branch → unspecified
Assignee | ||
Comment 6•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/33959/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/33959/
Attachment #8716853 -
Flags: review?(dkeeler)
Comment on attachment 8716853 [details] MozReview Request: Bug 503515 - Try and ensure exported certificates include an extension by default. https://reviewboard.mozilla.org/r/33959/#review30727 Sounds good. Just the one question. ::: security/manager/pki/resources/content/pippki.js:93 (Diff revision 1) > + fp.init(parent, bundle.getString("SaveCertAs"), nsIFilePicker.modeSave); My one concern with moving this line is the documentation says the file picker isn't valid until init is called. Should it occur before setting defaultString/Extension?
Attachment #8716853 -
Flags: review?(dkeeler) → review+
Assignee | ||
Comment 8•8 years ago
|
||
https://reviewboard.mozilla.org/r/33959/#review30727 Thanks for the review! > My one concern with moving this line is the documentation says the file picker isn't valid until init is called. Should it occur before setting defaultString/Extension? Good catch - the call to init() should stay where it is. I was reading https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFilePicker concerning defaultString, and somehow misread "This should be set before calling open() or show()" as "[...] init()"...
Assignee | ||
Comment 9•8 years ago
|
||
- Revert move of init() call.
Attachment #8716853 -
Attachment is obsolete: true
Attachment #8717339 -
Flags: review+
Assignee | ||
Comment 10•8 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ee91b67bcf6e The tc[Tier-2](B) failure looks unrelated.
Keywords: checkin-needed
Comment 11•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/3b0ec072cd21
Keywords: checkin-needed
Comment 12•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/3b0ec072cd21
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox47:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•