Closed Bug 19119 Opened 25 years ago Closed 24 years ago

No Cartman on mac yet...

Categories

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

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: chofmann, Assigned: beard)

References

Details

(Keywords: relnote, smoketest, Whiteboard: [dogfood+][nsbeta2-] Code Checked In) 

need a status update on how this is coming..
definitely pdt+ material.
Group: netscapeconfidential?
Whiteboard: [PDT+]
Bob -- please give us an idea of when this will land.
Component: Browser-General → Security
Assignee: lord → mwelch
Assigning to myself, since I'm working on it.

Current status update:

- Ported libnls to the Mac. Still some rough edges, but enough to get a basic,
faceless SSL connection going.

- I have server sockets and blocking TCP I/O working in my Mac NSPR tree -- will
need to get reviewed by wtc, larryh and gordon before checking in. (There are
enough pending changes that I want three people to review them.)

- I have the Cartman client library working for export-grade encryption.  So,
what this means is that I have built a console test app on the Mac which
connects to a Cartman module running on another machine (e.g. a Solaris box) and
sets up an SSL connection.

- I am currently porting the policy patcher to the Mac, so that I can make Mac
Cartman work with domestic-grade encryption. Should be done with this by the end
of today.

- After the patcher is complete, I will test the Cartman module itself. Not sure
what I'll run into, but should be able to get an SSL connection going on my
machine this week.

There are additional things I will need to do to make this eligible for landing
(build scripts, etc).

I'll report any additional progress here.
QA Contact: leger → junruh
Setting QA Contact.
Status: NEW → ASSIGNED
Shipped preliminary version of Mac PSM client library to dougt for Seamonkey
integration.
I have SSL connections working in Cartman now. The console test client shows raw
HTML from web pages.

I have a couple of side problems to track down, but I'll be submitting changes
for review within the next day or so.
Depends on: 4318, 4320
Adding dependency on Mac NSPR changes. Waiting for code review from gordon +
beard + wtc before checking in those changes (see 4318 and 4320 for details).
Bob: can we get an update on this bug please?
Mark's changes to Mac NSPR, have been reviewed and checked in.
This will not be fixed for M12 or Dogfood.
OS: Windows 95 → Mac System 8.5
Hardware: PC → Macintosh
what is the status of this bug?  I have a lot of Christmas shopping to do and
need cartman on Mac...

changing platform/os so this bug can be found more easily
In order to properly test Mac Cartman, I need a working Mac Seamonkey build,
which neither Doug nor I have been able to get. We can each build the browser,
but we cannot load pages with it. (I've been asking for help on IRC and getting
some, but I haven't yet managed to get Mac Seamonkey to work.)

In addition, I ran into some build problems with Mac Cartman this week and have
been working on those.

For now, I've checked client libraries into ns/sdk/psm, and have been taking
care of the aforementioned Mac Cartman build issues. Once that is done, I intend
to check in those changes as well as changes to the BuildCommercial* scripts, so
that daily builds will incorporate the Cartman client libraries. After this is
done,  we could try dropping in Mac Cartman along with a daily Seamonkey build,
and it may Just Work[tm].

Having said all this, I don't believe that we will get to a proper end-to-end
test this week, so the current ETA for Mac Cartman integration is next week
(early in M14, since M13 tree closure is tomorrow iirc).
I checked in some modifications to the Mac commercial build:
- added manifest files
- updated the client libraries
- a change to CommercialBuildList.pm to properly incorporate the client libs
(reviewed by dougt).

I am currently trying to diagnose a crashing problem in Mac Cartman which seems
to happen only when I scoop up the libnls binaries into the PSM daemon. I think
we're very close here, but there aren't enough minutes between now and midnight
to diagnose and fix the problem.

I'm not sure what the protocol is for how you want this bug sorted, so since I'm
missing tonight's deadline I will assign the bug to M14. However, I am still
working solely and intensely on this problem, and I will report progress here.
Setting milestone to M14.
Target Milestone: M14
cc self. go bez go!

I now have Mac Mozilla loading SSL pages using PSM, specifically https://omen. 

I had to make a change in Mac NSPR to wake up some additional threads on
disconnect events. I'm not comfortable that I've fixed every potential wedge
case, just the read case. I'll send the diffs to wtc/gordon as soon as is
practical, and hopefully we can figure out in the next day or two what the Right
Thing[tm] is to do here. 

In the meantime, I have to track down a shutdown bug in Mac Cartman, make sure
everything works after I scoop the various shared libraries into the PSM
application, and check everything else in. 

Putting dogfood in the keyword field.
Keywords: dogfood
Setting swag date (remember, it's a swag) to 2/18:

- Turns out my original NSPR fix caused lockups, so I'm trying to put together a 
better fix. wtc says he can wait for me until noon on Thursday 2/17.
- Need to get Mozilla to start up Mac Cartman on demand.
Whiteboard: [PDT+] → [PDT+] 2/18
Depends on: 28271
Depends on: 28486
Current status:

- sfraser is almost done with bug 28271. He has made Seamonkey launch PSM, but
he needs to do more testing prior to checkin. (Changes also need to be made to
the PSM component in Seamonkey.)

- Simon also performed considerable cleanup on the projects I had been working
on in libnls/NSS/PSM, and I asked him to check those changes in to my branch
when he is able.

- Added two bugs for subtasks involving the builds: bug 28486 and bug 28503.
Need leaf and/or jj to help me make the correct module(s) and reconfigure the
Mac build to build PSM. I need to generate a static tag for NSS just before this
happens, in order to freeze any pending NSS changes.

- Still trying to determine what is causing pictures to fail to load in SSL.
sfraser says I may be aggravating a pre-existing bug here, and that I should
talk to Pam Nunn. Adding her to this bug.

Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
adding beta1 keyword so this shows up on beta stopper lists.
Keywords: beta1
Depends on: 28906
per PDT, Mark, can we get a new ETA on this?
Depends on: 29044
I created and attached bug 29044. That, along with the NSPR re-tag, are the only
two pending issues of which I am aware. I cannot give a good ETA on 29044,
because I am not familiar with the Necko code. I'll write in 2/25 for now, but I
don't expect that date to be accurate.
Whiteboard: [PDT+] 2/18 → [PDT+] 2/25
Moving to PDT-.  Did not make the 02/25 deadline for beta1.  Putting on the 
relnote keyword.  No mac cartman for beta1.  if you want to state your case, 
come see PDT at 4pm any weekday.
Keywords: relnote
Whiteboard: [PDT+] 2/25 → [PDT-] 2/25
I'm very astonished that you have made this decision. There are two minor issues
that need to be fixed to make this ready for beta 1 (29044 and 29129). Is PDT
comfortable with this decision?


If this is ready, check it in, get Mac Cartman in the builds tonight.  Moving to 
PDT+. QA will test with tomorrows build.
Whiteboard: [PDT-] 2/25 → [PDT+] 2/29
The Mac builds are already turned on, so Cartman is building.

I have to talk to sfraser re the menu item removal, and need to coordinate with
rpotts on the Necko fix. In addition, we need to bump up the period with which
the browser waits for PSM to start up, in order to accommodate slower Macs.

I'll keep you all posted.

Last change (for 29572) expected to be in tomorrow, for a bug which John filed 
today. Moving to 3/1 because I expect sfraser's fix for 29572 to be in tomorrow, 
based on our conversations earlier.
Group: netscapeconfidential?
Whiteboard: [PDT+] 2/29 → [PDT+] 3/1
All the dependent bugs are closed... so.... are we there?  Can we close this, or
should the status whiteboard be updated?
Thanks,
Jim (real happy to see this in!!!!) Roskind ;-)

Yes, I'd say it's done. I wanted to wait and see if there were any other pending 
issues that came up from testing today, but there are none.

So, it's fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
How can this be verified when bug 29572 was reopened?

Reopening. Cartman on mac is still non-functional.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Fix milestone
Target Milestone: M14 → M15
Putting on [dogfood+] radar.
Whiteboard: [PDT+] 3/1 → [dogfood+] 3/1
*** Bug 35747 has been marked as a duplicate of this bug. ***
Whiteboard: [dogfood+] 3/1 → [dogfood+] 3/1 [from mwelch@netscape.com]
I'm leaving Netscape, so I'm reassigning all my pending bugs to David Drinan.
I've added "[from mwelch@netscape.com]" to the status whiteboard for each of
these bugs for easier searching.
Assignee: mwelch → ddrinan
Status: REOPENED → NEW
How come this is still M15? M15 is already out!
This a very problematic "bug" (feature), and it is dogfood :-(.
Ddrian: Do you think you'll be able to make progress here?  Do you have a plan?

Thanks in advance for status update,
Jim (dogfood chaser) Roskind
It is my not very humble opinion that Mac cartman is at serious risk for beta2. 
It has never really worked well, broke after security code was moved to mozilla, 
and some portions (e.g. the Security Advisor) have never worked. We need someone 
full time of this if we are serious about shipping a Mac browser with security.

Making P1.
Priority: P3 → P1
The basic reason for the lack of working SSL on the Mac is because there have
been two parallel lines of development occurring in PSM -- one line for the Mac,
and one for all other platforms. In the long run, these development lines need
to be merged into one.

Before going into detail, let me describe the trees affected by, and affecting,
SSL in Seamonkey:

- The Seamonkey tree itself, internally at ns/netwerk/security, and externally
at mozilla/extensions/psm-glue.

- The PSM client library tree: internally at ns/security/ssm/lib, and externally
at mozilla/security/psm/lib.

- The PSM server tree: internally at ns/security/ssm/server (and other places),
and externally at mozilla/security/psm/server.


In addition, there are multiple releases of PSM to track, along with
corresponding protocol versions:

- 1.0.1

- Pre-release 1.1, made specially for M14 on Windows and Linux (which I'll just
call "M14 PSM" for now)

- Final 1.1 (there was a bug reported against M14 PSM which required us to make
a protocol change)

- 1.2 (1.1 + SDR/wallet work)


The tip of the Seamonkey tree, as of this writing, works with M14 PSM
on Windows and Linux. The Mac Seamonkey tree had worked with 1.0.1
prior to the move of the psm-glue and PSM client library source to the
external tree, but now does not work with anything.  (The external
tree cannot have a dependency on the internal tree.) When Doug and/or
Pavlov moved the Seamonkey PSM glue code from the internal to the
external tree, and when I landed the initial PSM client library code
into the Mozilla tree, we were working with the Windows/Unix
development line. Up to now, the Mac development line has yet to be
merged into the main line of development.

The tip of the PSM client library tree, as far as I have been able to
tell, will work with PSM 1.1, but not with the Seamonkey tip in its
current state. (See below for information on what I have coded and
checked into branches.)

The tip of the internal PSM tree is PSM 1.1. The tip of the external
PSM tree will become PSM 1.2 when work is complete.

As I understand it, the following choices exist to make Mac SSL work:

- Generate a Mac build of the pre-release PSM 1.1 build used with M14, and check
in a Mac project file (with a few changes) on the M14 branch of the PSM client
library.

- Change the Seamonkey build to use PSM 1.1.

- Change the Seamonkey build to use PSM 1.2.


I contend that choice #1, while allowing the least amount of change to
the Seamonkey code base, will still not accomplish the goal of truly
unifying the code bases.

I think the best long-term strategy for preserving Mac stability is to
truly unify the codebases (change the Seamonkey build to use either
PSM 1.1 or PSM 1.2). In those two cases, the following steps need to
be performed simultaneously:

- In mozilla/extensions/psm-glue, merge PSM11ProtocolMac_BRANCH to the tip.

- PSM team generates a static tag for the current tip of
mozilla/security/psm/lib.

- CPD release engineering (or PSM team with leaf's permission) changes the
client build to begin using the abovementioned static tag.

For PSM 1.1, the pre-existing PSM 1.1 packages for Windows and Linux
need to be converted into .xpi files, and there needs to be a Mac
build generated from the tip of the internal PSM tree
(ns/security/ssm). For PSM 1.2, the following will have to be done:

- Make NSS 3.0 (mozilla/security/nss) build on the Mac.

- Generate new builds for all platforms from the tip (or suitable tag) of
mozilla/security/psm/server.

The tradeoff here is that PSM 1.1 can probably be made to work sooner,
but PSM 1.2 will provide a security advisor on the Mac, and therefore
might be worth the wait if the development effort can be put in to
make it work.

What I have done to these trees to prepare for future Mac work:

- In the PSM client library tree: I have built (on the Mac) and
checked in changes to the PSM client library tree to accommodate both
the Mac and the PSM 1.1 protocol. David Drinan informs me that this
code builds on Windows.

- In the Seamonkey tree: I have checked in (on a branch) a number of
changes to mozilla/extensions/psm-glue to get Seamonkey to work with
both the Mac (launching/event handling issues) and with PSM 1.1
(incorporating protocol changes). These changes live on
PSM11ProtocolMac_BRANCH. (I am somewhat limited in my ability to test
on the Mac, because of recent instability in the Mac tree and an
additional recent change in the Mac development environment.)

- In the internal PSM tree: I have merged all pending Mac changes
from PSM101Mac_BRANCH with the tip, creating
PSM11ProtocolMac_BRANCH. This is theoretically a unified version of
PSM 1.1, though a QA run would need to be applied if builds for all
platforms were generated from this branch.

- In the external mozilla/security tree: I have merged the same set of
patches I applied to the internal tip to the external tip. I have left
those changes on the tip.


The following changes need to be made to the tip of mozilla/security:

- MacPerl scripts need to be written to build NSS and/or PSM, as is
done for Seamonkey.

- The NSS project file needs to be changed so that the new sources will build
properly. I am not familiar with how the NSS team wants to do crypto library
selection, so if a MacPerl script is to be written to compile NSS, the choice of
core crypto component will have to be reflected in the build process.

- There were changes made by Simon Fraser to NSS 2.8 to fix some compile errors.
It is unclear to me how these changes can/should be applied to NSS 3.0.

- The PSM project file needs to incorporate the mozilla I18N libraries, and
their dependencies. David Drinan has been incorporating these into PSM 1.2 on
other platforms.


I hope I haven't confused everyone here. I'll be around on IRC in the
coming weeks and months in case additional help is needed sorting
through this.

Speaking to Simon's point above, I concur that someone should
be assigned full-time to make Mac SSL work -- there is probably enough
work here to keep someone occupied for a while.

Clarification: The last section that starts with "The following changes need to
be made to the tip of mozilla/security" applies only to NSS 3.0 and PSM 1.2.

bumped up the sev, added kw's...pardon the spam, but since this wasn't fixed for
m15, do we have a new target milestone? i've set it to m16 --change it as needed
("would be nice if it were nsbeta2").
Severity: normal → blocker
Keywords: beta1 → nsbeta2, smoketest
Target Milestone: M15 → M16
this isn't a recent regression and doesn't look like it's getting fixed any time 
soon, so I'm not holding the tree for this.
reducing severity to major. This should not be blocking any development work, 
if you think it is, please not specifically what that work is. We don't need 
this bug as a constant fixture on the smoketest blocker radar. removing 
extraneous [dogfood] from summary, and ancient tfd from whiteboard.
Severity: blocker → major
Summary: [dogfood] no cartman on mac yet... → No Cartman on mac yet...
Whiteboard: [dogfood+] 3/1 [from mwelch@netscape.com] → [dogfood+]
I am the doomed one working on this.  assigning to myself.
Assignee: ddrinan → dougt
Whiteboard: [dogfood+] → [dogfood+] 4d
Whiteboard: [dogfood+] 4d → [dogfood+][nsbeta2-] 4d
I don't remember saying this was going to take four days.  removing 4d from the 
status
Whiteboard: [dogfood+][nsbeta2-] 4d → [dogfood+][nsbeta2-]
reassigning to Bob Lord.  I am going on vacation in a few days.  I can't make 
much more progress on these Mac Cartman bugs.
Assignee: dougt → lord
Adding Phli to CC list to help get his focus.  This is a Big Problem.  We really 
need some out-of-the-box suggestions about how to make this happen :-(
I suggest that we hire a contractor.
After seeing email from Patrick Beard stepping up to take a shot at this, I'm 
moving this bug over to him. 
Patrick: As you form a plan, please update the status whiteboard.
Thanks,
Jim
Assignee: lord → beard
No longer blocks: 33531
No longer depends on: 4318, 4320, 28271, 28486
I'm working with Terry Hayes on designing a solution that takes Cartman in-
process.
Status: NEW → ASSIGNED
Whiteboard: [dogfood+][nsbeta2-] → [dogfood+][nsbeta2-] Investigation Ongoing
Whiteboard: [dogfood+][nsbeta2-] Investigation Ongoing → [dogfood+][nsbeta2-] No ETA Yet
Blocks: 41048
Blocks: 39678
Blocks: 39905
I've checked in code to take PSM in-process. PSM has been converted to a shared 
library that starts up threads within the Mozilla process. The code to implement 
this has been checked in, and build system issues will be resolved early next 
week.

The only remainging issue revolves around PSM's locking up when an SSL connection 
can't be established. (See bug #42896)
Whiteboard: [dogfood+][nsbeta2-] No ETA Yet → [dogfood+][nsbeta2-] Code Checked In
Changing milestone.
Component: Security: General → Security: Crypto
Target Milestone: M16 → M17
Reassigning to gordon to close when build system changes are in.
Assignee: beard → gordon
Status: ASSIGNED → NEW
Depends on: 42896
cc'ing beard
Who is the right person to get these build changes in?
*** Bug 32783 has been marked as a duplicate of this bug. ***
*** Bug 45379 has been marked as a duplicate of this bug. ***
Build changes were in by the end of June, but there were still some crashes a 
certain https pages.  It's possible we might be able to close this bug, if there 
are open bugs that cover the crashes.

*** Bug 25670 has been marked as a duplicate of this bug. ***
If its turned on in the latest release team build mark this one fixed 
and open bugs for crashes not fixed yet....
Agree with chofmann. I'm worried that this bug will attract illegitimate dups.
Assigning to beard...gordon is out.  beard, any ETA on this?
Assignee: gordon → beard
This is now fixed.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Verified
Status: RESOLVED → VERIFIED
Blocks: 45379
Blocks: 22561
Blocks: 83395
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Target Milestone: M17 → ---
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.