Closed Bug 1974505 Opened 9 months ago Closed 8 months ago

Creating a new login with SDR mechanism set to AES overrides old DES3 key instead of creating a new one

Categories

(NSS :: Libraries, defect, P3)

Product:
NSS
Component:
Libraries
Type:
defect

Tracking

(firefox-esr128 unaffected, firefox-esr140 unaffected, firefox140 unaffected, firefox141 wontfix, firefox142 wontfix, firefox143 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr128 --- unaffected
firefox-esr140 --- unaffected
firefox140 --- unaffected
firefox141 --- wontfix
firefox142 --- wontfix
firefox143 --- fixed

People

(Reporter: maltejur, Assigned: maltejur)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

Bug 1974505 - Key private/public/secret keys by key type in softoken keydb r?rrelyea
48 bytes, text/x-phabricator-request
Details | Review

I've found that the changes from Bug 198090 currently have a rather big bug. To reproduce:

  1. Set security.sdr.mechanism to 0
  2. Create a login
  3. Set security.sdr.mechanism to 1
  4. Create another login
  5. Observe the login list

Only the second login will appear. That is due to a new AES key being generated with the same key ID as the old DES3 key. This results in the old key just being overwritten when the second login gets created. That is because, contrary to what I believed when I wrote the original patch, the keys are only keyed by their ID, not by the key type. The fix would probably be to either key the keys by their type as well, or to use a distinct key ID for each mechanism.

Flags: behind-pref+
Blocks: 1974184
Attachment #9497412 - Attachment description: WIP: Bug 1974505 - Key private/public/secret keys by key type in softoken keydb r?rrelyea → Bug 1974505 - Key private/public/secret keys by key type in softoken keydb r?rrelyea

Set release status flags based on info from the regressing bug 198090

status-firefox140: --- → unaffected
status-firefox141: --- → affected
status-firefox142: --- → affected
status-firefox-esr128: --- → unaffected
status-firefox-esr140: --- → unaffected

We are in our last week of beta for 141, is that a bug we need a fix for in 141? Thanks

Flags: needinfo?(maltejur)

Also could we get a severity set on this bug? Thanks

This would only affect users who have manually flipped the security.sdr.mechanism pref. We don't need a fix in 141.

Severity: -- → S3
Flags: needinfo?(maltejur)
Priority: -- → P3
Attachment #9497412 - Attachment is obsolete: true
Attachment #9497412 - Attachment is obsolete: false

https://hg-edge.mozilla.org/projects/nss/rev/a1566b5ff895720caead584d64366885cc702656

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED

It looks like the windows build doesn't like the syntax for the gtest changes. I think we can just remove the cast.

Regressions: 1981518

(In reply to Robert Relyea from comment #8)

It looks like the windows build doesn't like the syntax for the gtest changes. I think we can just remove the cast.

Looking at it in Bug 1981518.

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

Attachment

General

Creator:
Created:
Updated:
Size: