Closed Bug 1405522 Opened 3 years ago Closed 3 years ago

sqldb will drop imported certificate trust settings if a non-empty password is changed

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: keeler, Assigned: keeler)

References

()

Details

Attachments

(1 file)

STR:

certutil -N -d sql:.
certutil -S -d sql:. -n "ca" -x -t "CT,," -s "CN=ca"

(this just makes a sql db with a certificate in it trusted for webauth)

Then, (in a c file or something):

int
main(int argc, char* argv[])
{
  if (NSS_Initialize("sql:.", "", "", SECMOD_DB, NSS_INIT_NOROOTINIT) != SECSuccess) {
    return 1;
  }
  PK11SlotInfo* slot = PK11_GetInternalKeySlot();
  if (PK11_ChangePW(slot, "", "password") != SECSuccess) {
    return 1;
  }
  if (PK11_ChangePW(slot, "password", "") != SECSuccess) {
    return 1;
  }
  PK11_FreeSlot(slot);
  if (NSS_Shutdown() != SECSuccess) {
    return 1;
  }
  return 0;
}

This changes the empty password to "password" and back to an empty password.

`certutil -d sql:. -L` should result in:

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

ca                                                           CTu,u,u


but the last line is instead:

ca                                                           u,u,u
Priority: -- → P2
Interestingly, if the password is changed to a different non-empty password, the trust settings will be unavailable for the duration of that run of NSS, but certutil will print out the correct trust if run after the fact.
Summary: sqldb will drop imported certificate trust settings if a non-empty password is changed to an empty password → sqldb will drop imported certificate trust settings if a non-empty password is changed
Assignee: nobody → dkeeler
Tim, any chance you could pick up this review while Franziskus is on vacation?
Flags: needinfo?(ttaubert)
Comment on attachment 8915384 [details]
bug 1405522 - fix authenticated attribute migration under password changes in the sql DBs r?franziskus

Tim Taubert [:ttaubert] has approved the revision.

https://phabricator.services.mozilla.com/D100#2339
Attachment #8915384 - Flags: review+
Flags: needinfo?(ttaubert)
Try looks good - the gtest failure looks like an intermittent, and the mac builds are failing for every push, so ¯\_(ツ)_/¯
Tim - would you mind checking this in? Thanks!
Flags: needinfo?(ttaubert)
(In reply to David Keeler [:keeler] (use needinfo?) from comment #5)
> Try looks good - the gtest failure looks like an intermittent, and the mac
> builds are failing for every push, so ¯\_(ツ)_/¯

Yeah, it's a known issue. We're looking into it :)

> Tim - would you mind checking this in? Thanks!

Wanted to do that yesterday already, sorry!

https://hg.mozilla.org/projects/nss/rev/f3766809817b
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(ttaubert)
Resolution: --- → FIXED
Target Milestone: --- → 3.34
(To make up for the delay I just pushed the latest NSS revision to inbound.)
You need to log in before you can comment on or make changes to this bug.