Closed Bug 123964 Opened 23 years ago Closed 23 years ago

PSM missing in Mac OS X nightly

Categories

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

Other Branch
PowerPC
macOS
defect

Tracking

(Not tracked)

VERIFIED FIXED
psm2.2

People

(Reporter: pbaker, Assigned: KaiE)

References

Details

(Keywords: smoketest)

Attachments

(2 files)

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.
Confirming. Netscape 6 and Mozilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P1
Target Milestone: --- → 2.2
Javi, Jonathan?
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.
The cert manager opens, but I cannot visit a secure web site.
Do any certs show up in the Authorities tab?
The CA tab is blank.
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
$ 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.
*** Bug 124267 has been marked as a duplicate of this bug. ***
Samething under MacOS 8.6

OS -> All
this is a smoketest blocker.

perhaps this is related to the issues which caused bug 123918
Severity: major → blocker
Keywords: smoketest
cc Simon Fraser.  Simon do you have any idea what needs to be done?
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://].
We need mac/packaging expertise here. It builds fine on dev machines.
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)
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.
Attached patch Suggested fixSplinter Review
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?
problem still exists in 2002020710 Mac OS X build.
Paul, does that mean, my patch doesn't work for you?
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.
Attachment #68441 - Flags: review+
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 on attachment 68441 [details] [diff] [review]
Suggested fix

sr=sfraser

What jj said.
Attachment #68441 - Flags: superreview+
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.
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.
I'll check the patch in once tinderbox goes green.
Assignee: ssaux → kaie
JJ, Simon, this is my fault.
checked in, fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
https works in 2002020803 on Mac OS X now. Should I mark this bug as VERIFIED
since I'm the reporter?
It's usually up to the QA contact (junruh@netscape.com 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.
Verified on Mac OSX and 9.1.
Status: RESOLVED → VERIFIED
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 on attachment 68643 [details] [diff] [review]
adding "SSL3" fragment name to optimized target

r=javi
Attachment #68643 - Flags: review+
Are the other fragment names unique?
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.
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).


I've updated ssl.xml with a patch jj sent me and updated the NSS_CLIENT_TAG
accordingly.
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: