In the nss SPEC, there is: # recreate certificates %{__perl} ./certdata.perl < /etc/pki/tls/mozilla/certdata.txt which in nss 3.27.2, does nothing but spit a bunch of output to the screen, but doesn't change any files. Apparently at one point in time, it used to create or update a file or files. What I'm guessing this means is that the nss package isn't building with the system rootcerts as it's supposed to be, it's just using the bundled certdata.txt in the nss source instead. In nss 3.28, the certdata.perl script has been changed to where it takes its input and output files as arguments, so we need to figure out what the output file was supposed to be. From the format of its output in 3.27.2, it's not apparent what that was supposed to be.
Assigning to all packagers collectively, since there is no registered maintainer for this package. (In reply to David Walser from comment #0) > In the nss SPEC, there is: > > # recreate certificates > %{__perl} ./certdata.perl < /etc/pki/tls/mozilla/certdata.txt > > > which in nss 3.27.2, does nothing but spit a bunch of output to the screen, > but doesn't change any files. Apparently at one point in time, it used to > create or update a file or files. > > What I'm guessing this means is that the nss package isn't building with the > system rootcerts as it's supposed to be, it's just using the bundled > certdata.txt in the nss source instead. > > In nss 3.28, the certdata.perl script has been changed to where it takes its > input and output files as arguments, so we need to figure out what the > output file was supposed to be. From the format of its output in 3.27.2, > it's not apparent what that was supposed to be. CC'ing tv, because he committed nss in the past and Perl is as good as his first language (apart from Breton) ;-)
Assignee: bugsquad => pkg-bugsCC: (none) => marja11, thierry.vignaud
(In reply to Marja van Waes from comment #1) > > (In reply to David Walser from comment #0) > > In the nss SPEC, there is: > > > > # recreate certificates > > %{__perl} ./certdata.perl < /etc/pki/tls/mozilla/certdata.txt > > > > > > which in nss 3.27.2, does nothing but spit a bunch of output to the screen, > > but doesn't change any files. Apparently at one point in time, it used to > > create or update a file or files. > > I forgot to ask to attach that output.
Oden, I don't know if you're still watching these e-mails, but you're the person most likely to know the answer to this.
CC: (none) => oe
CC: (none) => cooker
(In reply to David Walser from comment #0) > In the nss SPEC, there is: > > # recreate certificates > %{__perl} ./certdata.perl < /etc/pki/tls/mozilla/certdata.txt > > > which in nss 3.27.2, does nothing but spit a bunch of output to the screen, > but doesn't change any files. Apparently at one point in time, it used to > create or update a file or files. > > What I'm guessing this means is that the nss package isn't building with the > system rootcerts as it's supposed to be, it's just using the bundled > certdata.txt in the nss source instead. > > In nss 3.28, the certdata.perl script has been changed to where it takes its > input and output files as arguments, so we need to figure out what the > output file was supposed to be. From the format of its output in 3.27.2, > it's not apparent what that was supposed to be. I built nss 3.28 while working on firefox-beta. One of the changes needed in the spec was to remove the < in the line you cited above. While researching that I ran across a mozilla bug on the subject. https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1294417 In comment 3 he refers to creating a certdata.c file from certdata.txt. When I checked my 3.28 build I found nss/BUILD/nss-3.28.1/nss/lib/ckfw/builtins/Linux4.9_x86_64_cc_glibc_PTH_64_OPT.OBJ/certdata.c was created in the course of the build. That file did not exist in freshly unpacked source. It doesn't look like we do anything with certdata.c in the spec but is this the file you are looking for?
CC: (none) => mrambo
(In reply to Mike Rambo from comment #4) > https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1294417 > > In comment 3 he refers to creating a certdata.c file from certdata.txt. When > I checked my 3.28 build I found > nss/BUILD/nss-3.28.1/nss/lib/ckfw/builtins/Linux4. > 9_x86_64_cc_glibc_PTH_64_OPT.OBJ/certdata.c was created in the course of the > build. That file did not exist in freshly unpacked source. > > It doesn't look like we do anything with certdata.c in the spec but is this > the file you are looking for? If the output is a C source file, it very well may be that that's the output file that we're supposed to specify. That doesn't look like a very portable path name though :o(
(In reply to David Walser from comment #5) > (In reply to Mike Rambo from comment #4) > > https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1294417 > > > > In comment 3 he refers to creating a certdata.c file from certdata.txt. > > When I checked my 3.28 build I found > > nss/BUILD/nss-3.28.1/nss/lib/ckfw/builtins/Linux4. > > 9_x86_64_cc_glibc_PTH_64_OPT.OBJ/certdata.c was created in the course > > of the build. That file did not exist in freshly unpacked source. > > > > It doesn't look like we do anything with certdata.c in the spec but is > > this the file you are looking for? > > If the output is a C source file, it very well may be that that's the output > file that we're supposed to specify. That doesn't look like a very portable > path name though :o( If I'm reading the build log correctly nss is indeed using a built in certdata.txt file during build. But the line in comment #1 has nothing to do with the issue and appears to me to be a noop so far as affecting anything during the build is concerned. The library built using in the internal certdata.txt is already long done by the time that command is ran. I have patched the Makefile to use what I have assumed is the system rootcerts at /etc/pki/tls/mozilla/certdata.txt and have confirmed that that file is used during build. Looks like certdata.txt is built into certdata.c which turns into certdata.o which is used to build libnssckbi.so. If this sounds correct then I think I have the fix you're looking for.
Mike, it sounds like you got it. Go for it (and please commit the fix in the Mageia 5 branch as well). Thanks!
Updated to version 3.28.3 plus a fix for this bug was uploaded for cauldron and a freeze push was requested. Patched package uploaded for Mageia 5. Advisory: ======================== Updated nss package fixes a root certificate bug: * force the use of the system rootcerts instead of those bundled with nss Updated packages in core/updates_testing: ======================== nss-doc-3.27.2-1.1.mga5 lib64nss3-3.27.2-1.1.mga5 lib64nss-devel-3.27.2-1.1.mga5 lib64nss-static-devel-3.27.2-1.1.mga5 nss-3.27.2-1.1.mga5 nss-debuginfo-3.27.2-1.1.mga5 from nss-3.27.2-1.1.mga5.src.rpm Test procedure would be to use web browsers for https web sites as described in https://bugs.mageia.org/show_bug.cgi?id=14168#c2.
Whiteboard: (none) => has_procedureVersion: Cauldron => 5Assignee: pkg-bugs => qa-bugs
Mike, let's go with 3.28.3 for Mageia 5 and include it with the next Firefox update. Make sure rootcerts gets built and uploaded first (including in Cauldron, I recently updated rootcerts in SVN, so you'll need to amend your freeze push request and should probably tell Akien on IRC before he pushes it).
Reassigning to myself until all the updates are figured out. No need for QA to deal with this more than once.
Assignee: qa-bugs => mrambo
New rootcerts packages have been submitted for both cauldron and 5. A new sqlite3 package has been submitted for 5 (needed for nss). The nss package supporting the new rootcerts is done for cauldron but we need updates for both rootcerts and sqlite before I can push the new nss package for mageia 5. Both of those have built but are sitting in updates/testing.
All three of rootcerts-20170209, sqlite3-3.10.2, and nss-3.28.3 have been built for mga5 core/updates_testing (a necessity to do the nss update). The three packages are related in this context. As web browsers are dependent upon nss and rootcerts, and nss requires sqlite3, all three are probably ok if browser tests using secure web sites are successful. Advisory: ======================== Updated nss package fixes a root certificate bug: * force the use of the system rootcerts instead of those bundled with nss Updated packages in core/updates_testing: ======================== nss-doc-3.28.3-1.mga5 lib64nss3-3.28.3-1.mga5 lib64nss-devel-3.28.3-1.mga5 lib64nss-static-devel-3.28.3-1.mga5 nss-3.28.3-1.mga5 nss-debuginfo-3.28.3-1.mga5 from nss-3.28.2-1.mga5.src.rpm Advisory: ======================== Updated rootcerts package to 20090209. Updated packages in core/updates_testing: ======================== rootcerts-20090209.00-1.mga5 rootcerts-java-20090209.00-1.mga5 from rootcerts-20090209.00-1.mga5.src.rpm Advisory: ======================== Updated sqlite3 package fixes bugs and is needed for nss 3.28.3. Updated packages in core/updates_testing: ======================== lemon-3.10.2-1.mga5 lib64sqlite3_0-3.10.2-1.mga5 lib64sqlite3-devel-3.10.2-1.mga5 lib64sqlite3-static-devel-3.10.2-1.mga5 sqlite3-debuginfo-3.10.2-1.mga5 sqlite3-tcl-3.10.2-1.mga5 sqlite3-tools-3.10.2-1.mga5 from sqlite3-3.10.2-1.mga5.src.rpm
Assignee: mrambo => qa-bugs
(In reply to Mike Rambo from comment #12) > Advisory: > ======================== > > Updated rootcerts package to 20090209. > > > Updated packages in core/updates_testing: > ======================== > rootcerts-20090209.00-1.mga5 > rootcerts-java-20090209.00-1.mga5 > > from rootcerts-20090209.00-1.mga5.src.rpm This must be a typo, right? I really do hope you're not shipping an 8 year old cert package in place of the current one. :-)
These need to be included as part of the Firefox update, so moving this there. Note that we can't have multiple advisories for the same bug (unless they're for different distro versions). For multiple packages where the updates are related, they're generally combined into one advisory. If they're separate enough, in some cases one update can block another (which depends on the first one).
CC: (none) => qa-bugsDepends on: (none) => 20419Assignee: qa-bugs => mrambo
Fixed: http://advisories.mageia.org/MGASA-2017-0081.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED