123964 - PSM missing in Mac OS X nightly

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P1)

Description

[Paul Baker]

I can't visit any https sites in the 2002020608 build for Mac OS X (carbon, not
macho). Dialog reports that PSM is not installed.

Steps to reproduce:
1. Download and install the 2002020608 build for Mac OS X.
2. Try to visit an SSL encrypted site such as: https://www.amazon.com/
3. Notice the dialog box asking you to install Personal Security Manager.
4. File this bug.

Reproducible:
Everytime I tried.

Additional Information:
Works fine in at least 2002020408 on Mac OS X. I didn't try the build from the 5th.

Comment 1

[John Unruh]

Confirming. Netscape 6 and Mozilla.

Comment 2

[Stephane Saux]

Javi, Jonathan?

Comment 3

[Javier Delgadillo]

huh?  Does MacOS X packaging use a different file than Mac OS 9?  Perhaps the
MacOS X packaging file is out of date?  Other than that, I'm not sure why this
would be.

Can you view the Certificate Manager under Preferences->Privacy &
Security->Certificates->Manager Certificates?

If so, then this is not a packaging issue, but some other bug.

Comment 4

[John Unruh]

The cert manager opens, but I cannot visit a secure web site.

Comment 5

[Javier Delgadillo]

Do any certs show up in the Authorities tab?

Comment 6

[John Unruh]

The CA tab is blank.

Comment 7

[Javier Delgadillo]

Can you see if the MacOS X build you downloaded has these 3 files in Components?

PIPNSS.shlb
PIPboot.shlb
PIPPKI.shlb

User Essential Files:
NSSckbi.shlb

If this build came after 2/6/02, the these files should also be in "Essential
Files":

NSS3.shlb
SSL3.shlb
SMIME3.shlb
Softoken3.shlb

Comment 8

[Paul Baker]

$ find . -name PIP*             
./Mozilla.app/Contents/MacOS/Components/PIPBOOT.shlb
./Mozilla.app/Contents/MacOS/Components/PIPNSS.shlb
./Mozilla.app/Contents/MacOS/Components/PIPPKI.shlb

$ find . -name NSS*
./Mozilla.app/Contents/MacOS/Essential Files/NSSckbi.shlb
./Mozilla.app/Contents/MacOS/Essential Files/NSStdLib.shlb

The other 4 files you listed were not found. As of this writing there is no
20020207 build for OS X yet. As soon as there is one, I will try it out.

Comment 9

[Stephane Saux]

*** Bug 124267 has been marked as a duplicate of this bug. ***

Comment 10

[Benjamin Mucci]

Samething under MacOS 8.6

OS -> All

Comment 11

[Tracy Walker [:tracy]]

this is a smoketest blocker.

perhaps this is related to the issues which caused bug 123918

Comment 12

[Stephane Saux]

cc Simon Fraser.  Simon do you have any idea what needs to be done?

Comment 13

[sairuh (rarely reading bugmail)]

side note: the security-related pref panels are there, but as john sez in
comment 4, i'm unable to open a page to a secure site [https://].

Comment 14

[Stephane Saux]

We need mac/packaging expertise here. It builds fine on dev machines.

Comment 15

[J.J. Enser]

For MacOS packaging expertise, just cc me!!!! I've owned theses 2 processes (OS9
and X) long enough for people to remember me now :-/
I'm only jumping in because twalker just stopped by to ask me if I knew about
this bug...

This said, the 4 files "*3.shlb" should be listed packages-mac for them to be
included in the release builds. They're not. "Update packages-*" is a golden
rule when you add new files to the build. (in bold on the Tinderbox page)

Comment 16

[J.J. Enser]

I actually notice that packages-win and packages-unix were updated as part of
the NSS landing yesterday early morning.
Only packages-mac was left out. Dunno why.

Comment 17

[Kai Engert [:KaiE:]]

Attachment: Suggested fix

I have never used a Mac and do not understand the file naming, but from the
information posted in this bug, I guess this patch could fix it.

Can you please review?

Comment 18

[Paul Baker]

problem still exists in 2002020710 Mac OS X build.

Comment 19

[Kai Engert [:KaiE:]]

Paul, does that mean, my patch doesn't work for you?

Comment 20

[J.J. Enser]

Comment on attachment 68441 [details] [diff] [review]
Suggested fix

if you don't understand something about a platform, then please ask someone who
knows, or refrain from checking in XP code.
This is clearly documented here: http://mozilla.org/build/making-additions.html

in this case, since you already had the additions taken care for packages-win
and packages-unix, dealing with packages-mac shouldn't have been too big of a
problem, and shouldn't have been left out.

Comment 21

[J.J. Enser]

Paul, Kai's fix has just been submitted and is not checked in yet, so no wonder
2002020710 still shows this bug.
You'll probably have to wait for tomorrow's build to verify the fix, assuming
the patch goes in by 3am tonight.

Comment 22

[Simon Fraser [no longer active]]

Comment on attachment 68441 [details] [diff] [review]
Suggested fix

sr=sfraser

What jj said.

Comment 23

[Javier Delgadillo]

sorry about that.  I should've caught that kaie's original patch didn't add the
new files to the packages-mac file.  The attached patch is fine.

Comment 24

[Kai Engert [:KaiE:]]

I have to apologize, too, because I was responsible for doing the landing and
didn't re-assure that everything had been addressed. Promised, the next time
will be better.

Comment 25

[Kai Engert [:KaiE:]]

I'll check the patch in once tinderbox goes green.

Comment 26

[Wan-Teh Chang]

JJ, Simon, this is my fault.

Comment 27

[Kai Engert [:KaiE:]]

checked in, fixed.

Comment 28

[Paul Baker]

https works in 2002020803 on Mac OS X now. Should I mark this bug as VERIFIED
since I'm the reporter?

Comment 29

[J.J. Enser]

It's usually up to the QA contact ([e-mail] for this bug)
to mark it verified, but it's always good to get feedback from others too,
especially the reporter!
Thanks.

junruh, please verify OS9 too.

Comment 30

[John Unruh]

Verified on Mac OSX and 9.1.

Comment 31

[J.J. Enser]

I'd like to add one comment regarding the landing of NSS 3.4 on Mac since all
the involved parties are on this list:

For talkback purposes, we collect all symbol files generated by the build and
rename them according to the corresponding fagment name, set in the target prefs.

However, among the 4 new projects added, SSL3 doesn't have a fragment name set
(neither targets), which would probably cause crashes in this library to
generate reports without symbols.

Following is a 1-line patch to ssl.xml to fix that, assuming "SSL3" is the right
fragment name to use.

Comment 32

[J.J. Enser]

Attachment: adding "SSL3" fragment name to optimized target

please review

Comment 33

[Javier Delgadillo]

Comment on attachment 68643 [details] [diff] [review]
adding "SSL3" fragment name to optimized target

r=javi

Comment 34

[Simon Fraser [no longer active]]

Are the other fragment names unique?

Comment 35

[Javier Delgadillo]

I must've missed the SSL3 fragment name.  IIRC, I gave each target the name of
the shlb minus the '.shlb' ending.  Should be unique, but I didn't check against
all fragment names in the tree.

Comment 36

[J.J. Enser]

Simon: Yes, other fragment names are unique and straightforward : NSS3, SMIME3
and Softoken3

Janier will check in the patch for me since this lives on a separate branch.
patch will actually name the code fragments for _both_ target (my patch was only
naming optimized).

Comment 37

[Javier Delgadillo]

I've updated ssl.xml with a patch jj sent me and updated the NSS_CLIENT_TAG
accordingly.