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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: ddrinan0264, Assigned: ddrinan0264)
Details
Attachments
(5 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
PSM must build as part of the regular mozilla build for windows.
Assignee | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
Changes look good to me. r=javi@netscape.com
Comment 3•24 years ago
|
||
whoa, tiger! why are we adding security to LINCS in netwerk/protocol/http/src?
Comment 4•24 years ago
|
||
> ! #// 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?
Comment 5•24 years ago
|
||
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).
Comment 6•24 years ago
|
||
OK, tnx. (Yes, pulling with the sticky tag is the default, if you pull by
specific date or version.)
Assignee | ||
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
ok, so this doesn't mean that we wouldn't be able to build netwerk without
psm/nss, right?
Assignee | ||
Comment 9•24 years ago
|
||
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.
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
Javi,
Please review the latest patch.
Comment 12•24 years ago
|
||
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?
Assignee | ||
Comment 13•24 years ago
|
||
Javi,
Good catch. I'll change that and update the patch.
Assignee | ||
Comment 14•24 years ago
|
||
Comment 15•24 years ago
|
||
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
Comment 16•24 years ago
|
||
Latest patch looks good. r=javi
Comment 17•24 years ago
|
||
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.
Assignee | ||
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
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
Assignee | ||
Comment 20•24 years ago
|
||
Thanks bryner for catching that one. I'll submit an updated patch right away.
Assignee | ||
Comment 21•24 years ago
|
||
Comment 22•24 years ago
|
||
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.
Assignee | ||
Comment 23•24 years ago
|
||
The ctrlconn.c is not part of the patch. It's something I was testing for
Javier.
Comment 24•24 years ago
|
||
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.
Comment 25•24 years ago
|
||
why the removal of the autoreg stuff in nlslayer?
Assignee | ||
Comment 26•24 years ago
|
||
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.
Comment 27•24 years ago
|
||
hmm... people are going to have to whack their existing security directories,
but such is life. sr=leaf
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
This appears to be fixed in the 12/18 builds.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 31•24 years ago
|
||
I still get connection refused when trying to connect to the site I mentioned
using the Win32 Installer build from 2000121804
Comment 32•24 years ago
|
||
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.
Comment 33•24 years ago
|
||
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)
Comment 34•24 years ago
|
||
Following bug has been opened for the packages problem.
http://bugzilla.mozilla.org/show_bug.cgi?id=63307
You need to log in
before you can comment on or make changes to this bug.
Description
•