Closed Bug 60909 Opened 24 years ago Closed 24 years ago

PSM must build on windows for Mozilla users

Categories

(Core :: Security: PSM, defect, P3)

1.0 Branch
x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ddrinan0264, Assigned: ddrinan0264)

Details

Attachments

(5 files)

PSM must build as part of the regular mozilla build for windows.
Attached patch Javi, please review my changes. (deleted) — Splinter Review
Changes look good to me. r=javi@netscape.com
whoa, tiger! why are we adding security to LINCS in netwerk/protocol/http/src?
> ! #// Figure out how to pull NSS and PSM libs. > ! #// If no NSS_CO_TAG or PSM_CO_TAG is specified, use the default static tag What happens, if I manually pulled a different version of e.g. a single NSS file and then use client.mk to update? Will it be overridden with the version client.mk wants to pull?
if you pull with a sticky tag (that is, any tag but the cvs default, or latest, revision), the checkout would leave it on that sticky tag. (unless the -A option is given to cvs, which i don't think is the case right now).
OK, tnx. (Yes, pulling with the sticky tag is the default, if you pull by specific date or version.)
Leaf, The reason we have to add security to LINCS in netwerk/protocol/http/src is because the HTTPS handler includes the nsIPSMComponent.h file which includes PSM header files. Prior to these changes, mozilla would build the PSM protocol and client libraries and the header files would be exported into dist/include. However, with these changes we are using the coreconf gmake makefiles to build these libraries (because we now build NSS and the PSM daemon and it needs to link with these) and the header files are placed into dist/security.
ok, so this doesn't mean that we wouldn't be able to build netwerk without psm/nss, right?
Can you build netwerk/protocol/http/src today without the PSM header files? The HTTPS handler uses the nsIPSMComponent.idl interface which includes the main PSM header file cmtcmn.h.
Javi, Please review the latest patch.
I thought one of the reasons for adding the forward declares of CMTControl and CMTSocket to the idl file was to get rid of the dependency on security in http/protocol/src, yet that the protocol/src directory still adds the security to its include line. Should it still be there?
Javi, Good catch. I'll change that and update the patch.
Why is a .idl file #including ctccmn.h? Is anyone actually using those native types yet? IDL should not couple to implementations. Cc'ing bryner for his two cents. I also would like leaf to help me review here, I'm not a Windows build guru. We need to keep modules decoupled at compile-time as much as possible. There is too much bad precedent for *requiring* extensions/... from netwerk/... and elsewhere. Can we move away from that? /be
Latest patch looks good. r=javi
As of a change I made a few days ago, nsHTTPSHandler.cpp no longer includes nsIPSMComponent.h, it includes nsISecurityManagerComponent.h (a generic interface exported from network). So: - no need to descend into extensions/psm-glue if ENABLE_CRYPTO isn't set - no problems arise include psm client lib headers in nsIPSMComponent.idl, although I'm still not sure it's a great idea. I might recommend a rename of ENABLE_CRYPTO to BUILD_PSM or something similar, in case someone wants to check in some other crypto implementation at some point. It's also more to the point.
In this section: + !if "$(NSS_CO_TAG)" != "" + NSS_CO_FLAGS=-r $(PSM_CO_TAG) + !else + NSS_CO_FLAGS= -r NSS_CLIENT_TAG + !endif It seems to me like it should read: !if "$(NSS_CO_TAG)" != "" NSS_CO_FLAGS=-r $(NSS_CO_TAG) !else NSS_CO_FLAGS= -r NSS_CLIENT_TAG !endif
Thanks bryner for catching that one. I'll submit an updated patch right away.
r=bryner, except I notice a patch to psm/server/ctrlconn.c that wasn't part of the previous patches, I'm assuming that just got in there accidentely.
The ctrlconn.c is not part of the patch. It's something I was testing for Javier.
bryner, that's the change we were chatting about yesterday for finding the path to the loadable roots module on Linux. It worked great on Linux and I just wanted ddrinan to test if that still worked on Win32.
why the removal of the autoreg stuff in nlslayer?
Leaf, With these changes PSM will run in the same directory as mozilla and will use mozilla's components and registry. PSM does not need to register components since mozilla has already registered them.
hmm... people are going to have to whack their existing security directories, but such is life. sr=leaf
I've noticed that PSM doesn't seem to be included in the win32 Installer builds (atleast build 2000121204). when you go to https://www.fortify.net/cgi-bin/ssl_2 it says "connection was refused when attempting to contact www.fortify.ney". If I then install PSM from http://docs.iplanet.com/docs/manuals/psm/psm-mozilla/index.html it then works properly.
It will need to be added to the packages file (xpinstall/packager/packages-*). I'd suggest that the psm files go in their own package.
This appears to be fixed in the 12/18 builds.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I still get connection refused when trying to connect to the site I mentioned using the Win32 Installer build from 2000121804
Can you open up the security advisor? If so, then it most likely is the case that you're talking to a server that does not properly implement TLS.
Clicking on the lock or going tasks->Provacy and securty->personal Security Manager didn't do anyhting. I went to https://digitalid.verisign.com/ (From the smoketests) and it gave the same error (Connection was refused..) with a stock install. It workes after installing PSM. After re reading Brian Ryner's comment dated 2000-12-12 19:52, I looked thorugh http://lxr.mozilla.org/mozilla/source/xpinstall/packager/packages-win It appears that psm.exe is not in there. (As far as I know it only affects the Win32 Installer build)
Following bug has been opened for the packages problem. http://bugzilla.mozilla.org/show_bug.cgi?id=63307
Verified fixed.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm1.4 → 1.0 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: