need a status update on how this is coming.. definitely pdt+ material.
Bob -- please give us an idea of when this will land.
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.
Setting QA Contact.
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.
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.
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.
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.
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.
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.
adding beta1 keyword so this shows up on beta stopper lists.
per PDT, Mark, can we get a new ETA on this?
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.
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.
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.
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.
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.
How can this be verified when bug 29572 was reopened?
Reopening. Cartman on mac is still non-functional.
Putting on [dogfood+] radar.
*** Bug 35747 has been marked as a duplicate of this bug. ***
I'm leaving Netscape, so I'm reassigning all my pending bugs to David Drinan. I've added "[from firstname.lastname@example.org]" to the status whiteboard for each of these bugs for easier searching.
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.
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").
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.
I am the doomed one working on this. assigning to myself.
I don't remember saying this was going to take four days. removing 4d from the status
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.
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
I'm working with Terry Hayes on designing a solution that takes Cartman in- process.
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)
Reassigning to gordon to close when build system changes are in.
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?
This is now fixed.
Mass changing Security:Crypto to PSM
Mass changing Security:Crypto to PSM