Closed Bug 62085 Opened 25 years ago Closed 25 years ago

cannot open secure site

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: tracy, Assigned: javi)

References

(
URL
)

Details

(Keywords: smoketest)

seen on commercial build 2000-12-06-05-Mtrunk -attempt to open above URL expected results: site opens. tested results: throbber flashes briefly. status say connecting, but the page never opens
Keywords: smoketest
Assignee: mstoltz → javi
Component: Security: General → Security: Crypto
Priority: P3 → P1
QA Contact: ckritzer → junruh
Summary: cannot open secure site → Mac-cannot open secure site
Component > Crypto
The build team needs to add the following line to the Mozilla Build Prefs file for Commercial Builds only: options psm 1 We're still ivestigating the possibility of turning PSM on for Mozilla daily builds, but aren't sure if we can do this just yet. I wouldn't hold the tree closed for this. Who's in charge of the Mac builds? I'd need to talk to him/her.
a little head's up when these kinds of changes go in would be nice, cc'ing jj (mac build meister). I'll flip this option on in the commercial config file, and respin commercial bits, reducing severity, opening tree.
ok, this needs to be flipped on in the *mozilla* config file, which would enable crypto in the builds that go to ftp.mozilla.org, the legality of which is still being determined. so leaving disabled for now... javi is hacking the commercial build scripts to build in the mozilla tree as part of the commercial build... this will taint mozilla release builds, so that a clobber will be necessary before doing respins of mac mozilla. hopefully the legalities will be worked out soon, so we don't have to worry about it anymore.
leaf: Javier actually posted an announcement on macdev, n.p.m.crypto and n.p.m.mac yesterday afternoon. :-) Javier: don't we want psm to build by default ? (setting the flag in MozillaBuildFlags.txt instead of Mozilla Opt build Prefs)
If we build SSL by default for Mozilla, then mozilla can all of a sudden become export controlled. I'm in no position to say whether or not Mozilla builds are suited for the export control world. Until lord and mitchell figure out what's the best way to proceed with Mozilla, we don't want to enable crypto for the mozilla builds. Basically, until lord and mitchell say it's OK to enable crypto in Mozilla builds, we need to err on the side of not enabling to avoid getting Mozilla in trouble with the BXA.
seen today on Windows commercial build 2000-12-07-06-Mtrunk changed platform and OS to all
OS: Mac System 9.x → All
Hardware: Macintosh → All
this is most likely a different bug since it's windows instead of mac. twalker, do you see this bug on the mac still, or on linux? I installed the 2000120706 win32 blob from the 'sea' directory and have the same problem. Any attempted access of an https:// site just sit there and does not connect.
Summary: Mac-cannot open secure site → cannot open secure site
Jon, it is still happening on Mac. It doesn't happen on Linux.
It doesn't work on my Debian Linux
*** Bug 62193 has been marked as a duplicate of this bug. ***
For windows this is caused by a change we made to mozilla last night that allows PSM to be built as part of the Mozilla build. By default, this is switched off for export control reasons. For our commercial builds, PSM *must* be built. This is done by setting BUILD_PSM=1 before doing the nmake -f client.mak build_all. Also, the packaging step for seamonkey should *not* include the PSM xpi file that the security team delivered to CPD since the build will already have PSM.
leaf and jj are aware of the problem and working on it. since this is just an automation change, I'm not holding the tree closed for this.
*** Bug 62284 has been marked as a duplicate of this bug. ***
downgrading
Severity: blocker → critical
*** Bug 62261 has been marked as a duplicate of this bug. ***
*** Bug 62281 has been marked as a duplicate of this bug. ***
None of these comments say why PSM will not work ion Windows even if it is installed from the designated site. The manager just will not come up, even if one follows all of the install instructions.
*** Bug 62334 has been marked as a duplicate of this bug. ***
*** Bug 62349 has been marked as a duplicate of this bug. ***
Can we upgrade this? I think it's pretty important to *a lot* of people. For me, at least, it makes the browser unusable. I know it's just an automation problem, but in my view, this leads to a lack of basic functionality. and should be a tree blocker just my $.02
I agree about this being a blocker. I also do not see how the commercial version (Netscape 6) is viable now either since PSM does not work in it either. I have regressed to Netscape 4.76.
uh... psm in Netscape 6 is not affected by this bug, it was shipped over two weeks ago. i'll be turning on security for mac and windows tonight to shake out any bugs in the new stuff.
I downloaded Netscape 6 on Friday (after I told it not to do Java-- the file was not there). And PSM would not work at all!. Now maybe the Mozilla PSM has screwed up the Netscape one, but I now have to use Netscape 4.76 to do anything. I also feel the .6 release should be killed because it regressed so much and does not even allow the user to send e-mail. People cannot find bugs if they cannot use the #$%^ thing
works fine on commercial builds windows 2000-12-11-06-Mtrunk mac 2000-12-11-04-Mtrunk
I built from CVS this morning with BUILD_PSM=1, yet I still get connection refused when trying to contact https sites. What am I missing?
you also need to pull with client.mk after setting that variable... if it's *still* not working, then we have further issues. As to this bug affectiong 0.6, it doesn't. At all; neither does it affect Netscape 6. Those two releases are unrelated to this bug. Note, as well, that the linux build functionality isn't there yet in the mozilla trunk, so the iPlanet version of psm is still usable for linux nightly builds. Crypto is building in windows and mac mozilla trunk, but we have another bug, 62524.
What I'm doing is: export BUILD_PSM=1 cvs checkout mozilla/client.mk cd mozilla make -f client.mk checkout ./configure --enable-optimize --disable-tests \ --disable-debug --enable-strip-libs make -f client.mk build_all and it doesn't work.
That is bug 60912 which is still open and hasn't been checked in. Only Win32 and Mac currently have support for building SSL.
right... see what i said about linux not being there yet? =) there's another bug tracking the linux building status.
so this seems to be working for me in today's builds. Tested 121508 mac and win32 mozilla builds. visited https://digitalid.verisign.com/ and https://sourceforge.net and successfully loaded the pages. The lock was locked, PSM identified the sites as secure and the layout of the actual page looked fine.
thanks to ddrinan for tracking down the linker problem on the windows build machine. marking fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified fixed for mac and win.
Status: RESOLVED → VERIFIED
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.1
Mass changing Security:Crypto to PSM
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.