70217 - Todo: Get PSM(2) working under BeOS

Status: VERIFIED FIXED

(NSS :: Libraries, defect, P2)

Description

[Gregor Rosenauer]

My bank-account is not reachable with Mozilla/BeOS 2001021912.
Go to http://www.bawag.at then click on "Internet Banking" in the icon-bar at
the bottom (the URL specified above).
This should bring you to a login-page, but instead a new window is opened and
nothing happens.

Comment 1

[Gregor Rosenauer]

This is what the terminal outputs when trying to load the URL:
Error loading URL https://eb03.bawag.com/webbank/bawag/webbank.htm: 804b0033 

Comment 2

[Darin Fisher]

Can you verify that you have PSM installed?

Comment 3

[Gregor Rosenauer]

Sorry, just read that in BeOS SSL does not work yet :-(
I did not find this bug on bugzilla, so it may still be useful as a reminder:)

Comment 4

[Darin Fisher]

Reassigning to owner of Security:Crypto

Comment 5

[Darin Fisher]

Let me try that again...

Comment 6

[kurros (Wade Majors)]

I made a futile attempt at getting psm2 building under BeOS. I got up to thelinking of mozilla/security/nss/lib/ before I hit another roadblock. Was anundefined ref to main().Here are the diffs on the files I modified to get compiling so I could get tothat point.How I built:added to ~/.mozconfig---export MOZ_NSS_AUTOCONF=1ac_add_options --enable-cryptomk_add_options MOZ_NSS_AUTOCONF=1---did ./configure, make -f client.mk checkout, then make -f client.mk buildThis of course requires you have GUI autoconf installed which is not part of thedefault BeOS distribution. Getting the archive from ftp.gnu.org and changing/usr/local to /boot/beos in the configure script got it to compile and install fine.If anyone else has ideas I'd appreciate the help.

Comment 7

[kurros (Wade Majors)]

Attachment: diff -u mozilla/security/coreconf/nsinstall/nsinstall.c

Comment 8

[kurros (Wade Majors)]

Attachment: diff -u mozilla/security/nss/lib/util/*

Comment 9

[kurros (Wade Majors)]

Ugh. NetPostive screwed up my last post. Here are the comments again:

I made a futile attempt at getting psm2 building under BeOS. I got up to
thelinking of mozilla/security/nss/lib/ before I hit another roadblock. Was
anundefined ref to main().

Here are the diffs on the files I modified to get compiling so I could get
tothat point.

How I built:
added to ~/.mozconfig
---
export MOZ_NSS_AUTOCONF=1
ac_add_options --enable-crypto
mk_add_options MOZ_NSS_AUTOCONF=1
---
did ./configure, make -f client.mk checkout, then make -f client.mk build

This of course requires you have GNU autoconf installed which is not part of the
default BeOS distribution. Getting the archive from ftp.gnu.org and
changing/usr/local to /boot/beos in the configure script got it to compile and
install fine

.If anyone else has ideas I'd appreciate the help. 

Comment 10

[Gregor Rosenauer]

Maybe, until PSM is available on BeOS, Mozilla should display an error "PSM not
installed / available" so the user is not confused why the page stops loading?

Comment 11

[cls]

This should actually be assigned to the NSS team.

Comment 12

[cls]

Oops, forgot to click 'reassign bug'

Comment 13

[cls]

Attachment: Get NSS to compile on BeOS. The patch is against the NSS_CLIENT_BRANCH

Comment 14

[kurros (Wade Majors)]

building, but we aren't in the clear yet.

https://despot.mozilla.org and https://www.verisign.com produce:
- http://ezri.org/nss.jpeg

https://www.sourceforge.net produces a blank white page.

Comment 15

[cls]

My guess is that we're hitting what bryner thinks is a classic blocking problem.  I ran a build while logging nsSocketTransport and the logfile seems to indicate that we are being blocked when we try to write the GET request to the socket.

Comment 16

[cls]

Attachment: nsSocketTransport logfile

Comment 17

[Wan-Teh Chang]

If you generate a patch for NSS against NSS_CLIENT_TAG
(which requires you to build Mozilla with MOZ_NSS_AUTOCONF
unset), I'll be happy to review your patch and check
it in.

Comment 18

[cls]

Attachment: coreconf .mk for BeOS 5.0

Comment 19

[cls]

Attachment: Updated beos patch to get NSS from NSS_CLIENT_TAG to compile

Comment 20

[cls]

Here's the updated BeOS changes against the NSS_CLIENT_TAG.  They allow NSS to
compile but Mozilla still cannot establish a secure connection.  The changes
really need to be closely reviewed by both someone intimately familiar with BeOS
as well as someone intimately familiar with NSS. 

Comment 21

[Makoto Hamanaka]

Chris, I want to try your patches but I have one question.
Maybe a beginner question but, where should I place coreconf.mk at?

Comment 22

[cls]

Copy attach 39999 to mozilla/security/coreconf/BeOS5.0.mk 

Comment 23

[Makoto Hamanaka]

Thanks. So I tried to make NSS.
I applied your 40000 patch and placed BeOS5.0.mk. Then, 
make -f client.mk build
on /mozilla/. But errors occured.

>make[2]: Entering directory `/MOZILLA/bezillaA1/mozilla/security/nss'

>cd lib; /bin/make install

>make[3]: Entering directory `/MOZILLA/bezillaA1/mozilla/security/nss/lib'

>cd crmf; /bin/make install

>make[4]: Entering directory `/MOZILLA/bezillaA1/mozilla/security/nss/lib/crmf'

>/bin/sh: ../../../coreconf/nsinstall/BeOS5.0_DBG.OBJ/nsinstall: No such file or directory

>make[4]: *** [BeOS5.0_DBG.OBJ/crmfenc.o] Error 127

>make[4]: Leaving directory `/MOZILLA/bezillaA1/mozilla/security/nss/lib/crmf'


... and so on. It then compiled some .cpp files on security/manager/ssl/src 
but end up link error. And the make process was terminated.

Then, I "cd" to security/coreconf and did "make".
Then, coreconf/nsinstall/BeOS5.0_DBG.OBJ/nsinstall was created.
I returned to /mozilla/. again and did "make".
Then another errors occured,

>make[3]: Entering directory `/MOZILLA/bezillaA1/mozilla/security/nss/lib/crmf'

>gcc -o BeOS5.0_DBG.OBJ/crmfenc.o -c -g -fPIC -Di386 -Wall -pipe
> -DXP_BEOS -DDEBUG -UNDEBUG -DDEBUG_baron -DBEOS 
>-I../../../../dist/BeOS5.0_DBG.OBJ/include  -I../../../../dist/public/security 
>-I../../../../dist/private/security -I../../../../dist/public/dbm  crmfenc.c

>In file included from /MOZILLA/bezillaA1/mozilla/security/nss/lib/crmf/crmf.h:39,

>                 from /MOZILLA/bezillaA1/mozilla/security/nss/lib/crmf/crmfenc.c:36:

>/MOZILLA/bezillaA1/mozilla/dist/public/security/seccomon.h:47: prtypes.h: No
> such file or directory

and so on.

I picked the gcc sentense and added "-I../../../../dist/include/nspr" manually, 
and tried to execute. Then it compiled crmfenc.c without an error.
Can you guess which file is wrong?

Comment 24

[Makoto Hamanaka]

It seems that the choice of whether debug/optimized build is not recognozed correctly.
I was doing optimized build, but NSS want to do debug build, as it seems.
Can NSS detect "ac_add_options --enable-optimize" in .mozconfig?
Though, I did "export BUILD_OPT=1" .

I added these lines and it can compile source files.
INCLUDES += -I$(CORE_DEPTH)/../dist/include/nspr
INCLUDES += -I$(CORE_DEPTH)/../dist/include

Then, error occured during linking and I had to create 
  mozilla/dist/BeOS5.0_OPT.OBJ/lib/libdbm.a
by hand.

Also copying mozilla/dist/BeOS5.0_OPT.OBJ/lib/* to mozilla/dist/lib/ was needed to 
make security/manager .

Though, finally, NSS libraries were made.
The results of accessing https sites are the same as the screenshot Wade Majors got.
(My source tree is several days old)

Comment 25

[cls]

If you want to build NSS standalone, you must follow the directions on the NSS
build page, http://www.mozilla.org/projects/security/pki/nss/buildnss_31.html (I
haven't tested that on BeOS).  I just built NSS as part of mozilla by passing
--enable-crypto to configure.  

Comment 26

[Makoto Hamanaka]

Ah, I tried again with just --enable-crypto and it builds ok ;-)

It seems that what was wrong is I added 
>export MOZ_NSS_AUTOCONF=1
>ac_add_options --enable-crypto
>mk_add_options MOZ_NSS_AUTOCONF=1
to .mozconfig .

Comment 27

[Paul]

Attachment: Updated patch to get compiling again

This patch will get mozilla to compile again with --enable-crypto.
I did this, because I thought we might have fixed some of the previous problems

fixed by Bug#71697.  Well, upon the first trial after compiling, going to
https://despot.mozilla.org, I get the following:

HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.6
Date: Thu, 10 Jan 2002 03:58:45 GMT
Content-type: text/html
Last-modified: Sat, 29 Aug 1998 00:49:36 GMT
Content-length: 374
Accept-ranges: bytes
Connection: keep-alive

HTTP/1.1 200 OK
Server: Netscape-Enterprise/3.6
Date: Thu, 10 Jan 2002 03:58:45 GMT
Content-type: text/html
Last-modified: Sat, 29 Aug 1998 00:


So, at least we get something now.  Anyone have any ideas of where I should
start looking?	It seems we are loading the header, maybe?  I do not know much 

about the security branch, so any help, what so ever, would be greatly
appreciated!

Comment 28

[Paul]

Attachment: coreconf .mk file for BeOS BONE (BeOS5.0.4.mk)

Coreconf file required to compile under BONE.

Comment 29

[Paul]

Attachment: console output with SSLDEBUG & SSLTRACE set to 99

This is the console's standard output captured when SSLDEBUG and SSLTRACE are
set each to 99, to get the most info.  This is what is produced when
going to https://despot.mozilla.org

Thought it might be helpful.

Comment 30

[hacker formerly known as [e-mail]]

Attachment: Working SSL support at cost of stabiilty

The good news is that I managed to get SSL connections working on BeOS
net_server builds.  That's what the patch does.  The bad news is that the patch
causes the browser to crash on the 3rd or so pageload.

A key part of the patch is the change to _MD_connect.  Without that change, the
browser doesn't crash but of course, SSL connections fail too.	 After calling
connect(...),  printfs show that rv=-1 and errno is EINPROGRESS (Operation in
progress).  Looking at nonblocking && (EINPROGRESS || EAGAIN) checks, I'm
guessing that we are currently being bitten by BeOS' lack of support for
nonblocking sockets.  I thought that there was a way to use blocking sockets
with NSS?

Comment 31

[Wan-Teh Chang]

Chris wrote:
> I thought that there was a way to use blocking sockets
> with NSS?

Yes, you need to modify nsNSSIOLayerConnect() in nsNSSIOLayer.cpp.
See bug 106188, my patch (attachment 66652 [details] [diff] [review]) for nsNSSIOLayer.cpp.
Adjust it for BeOS.

Comment 32

[hacker formerly known as [e-mail]]

Attachment: use blocking connect code for SSL on beos

Thanks Wan-Teh!  By adding XP_BEOS to the XP_MAC ifdefs and removing the
previous NSPR hack, we have stable support for SSL on BeOS now.

Comment 33

[Paul]

Did part of the patch for Bug#106188 not get applied properly?  I just did a
cvs update of nsNSSIOLayer.cpp, and still needed to apply part of the
attachment 66652 [details] [diff] [review].  Just curious.  I manually applied the latest patch and
am building now.  Thanks for this Chris! It is GREATLY appreciated!

Comment 34

[hacker formerly known as [e-mail]]

The patch for 106188 was already applied when I created the 2nd patch.  It looks
like sfraser backed out 106188 when he got non-blocking connects working for the
mac.  So I'll have to roll another patch. :-/

Comment 35

[hacker formerly known as [e-mail]]

Attachment: updated patch after bug 106188 changes

Comment 36

[Gregor Rosenauer]

Any chance to get this working on BONE (7a) ?I had no luck with any version of BONE+SSL yet...This is a huge step for BeZilla - big thanks and congrats to all involved!Hugh

Comment 37

[Wan-Teh Chang]

Chris,

In comment #32 you said you removed "the previous NSPR hack".
But in fact you did not remove but rather start to use the NSPR
hack that previously was only used for BONE.  Did I miss
something?

Comment 38

[hacker formerly known as [e-mail]]

Sorry, I meant that I removed the NSPR hack that I was using in the previous
patch.  I removed the extra EINPROGRESS check that I added to bnet.c which was
causing the instability.

Comment 39

[hacker formerly known as [e-mail]]

I don't know of any reason why it wouldn't work on BONE atm but I don't have
BONE to check.  The net_server & BONE builds are now using the same workaround
for the nonblocking sockets problem and there were no bits of the NSS port that
used any BeOS specific features besides the mutexes.

Comment 40

[Paul]

I plan on trying a BONE build tonight, and will post the results.

Comment 41

[Paul]

Well, my BONE build just completed.  Trying to go to any secure site gives me a
dialog with the message "connection refused".  I was hoping this would just
work, so I did not have debug enabled, so, I will build it again over night,
with debug enabled, and let you know what I find out.  Thanks for the great
work, Chris!

Comment 42

[Dennis Jakobsen]

Compiles and works for me, but i have a beef with the .mk files. They both have 
OS_REL_CFLAGS   = -Di386. Either this should be removed or changed to -Di586. BeOS does not 
run on anything below a Pentium (1).

Comment 43

[Paul]

Attachment: Patch to bnet.c for BONE builds

This patch along with the previous patch gets SSL/PSM working under
net_server and BONE.  I have not run into any other issues, except for
some focus issues under secure sites, but I will address that in another
bug.

Comment 44

[Paul]

The tree is closed for 0.9.9.  Will this be able to make it into the tree for
the next release? 

Comment 45

[hacker formerly known as [e-mail]]

Paul, the tree is not completely closed for 0.9.9.  It's in lockdown mode.  The
changes would have to be approved by [e-mail] in addition to the
usual level of r/sr.  I think we have a fairly strong case for getting this in. :) 

Wan-Teh, assuming that you can review this changes, who would be the appropriate
person to sr them?  The changes are mostly inside BeOS ifdefs so I'm not sure if
the additional sr is really needed.  Can we get these changes checked in and the
static tags bumped before 0.9.9 branches (presumably on Friday or Monday)?

Dennis, -Di386 it used to signifiy that we are compiling for an Intel processor
(-D_X86_ would be more appropriate), not that it actually runs on a 386.  Since
we don't actually use that define, it can probably go away (not verified).

Comment 46

[Paul]

Since there is no BeOS PPC port at this point for mozilla, the i386/i586 thing is kind ofirrelavant.

Comment 47

[Wan-Teh Chang]

Comment on attachment 70252 [details] [diff] [review]
updated patch after bug 106188 changes

I have some questions about the NSS changes in this patch.

1. security/coreconf/nsinstall/nsinstall.c

>+#ifdef HAVE_FCHMOD
> 	    if (fchmod(tofd, mode) < 0)
>+#else
>+	    if (chmod(tofd, mode) < 0)
>+#endif

The first argument of fchmod is an int (fd) whereas the first
argument of chmod is a char* (path), so I believe we need to
say:
	    if (chmod(toname, mode) < 0)

2. security/nss/lib/freebl/Makefile

>+ifeq ($(OS_TARGET),BeOS)
>+ifeq ($(CPU_ARCH),x86)
>+    ASFILES  = mpi_x86.s
>+    DEFINES += 
>+#-DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQUARE -DMP_ASSEMBLY_DIV_2DX1D
>+endif
>+endif

Should I simply delete the whole DEFINES += thing?

Are you using mpi_x86.s on BeOS?

3. security/nss/lib/freebl/unix_rand.c

>+#ifdef BEOS
>+    char *files[] = {
>+	"/boot/var/swap",
>+	"/boot/var/log/syslog",
>+	"/boot/var/tmp",
>+	"/boot/home/config/settings",
>+	"/boot/home",
>+	0
>+    };
>+#else
>     static const char * const files[] = {
> 	"/etc/passwd",
> 	"/etc/utmp",
>@@ -743,6 +786,7 @@
> 	"/usr/tmp",
> 	0
>     };
>+#endif

I will declare 'files' as
      static const char * const files[] = {
same as the other platforms.

By the way, your changes to this file are good!

4. security/nss/lib/freebl/mpi/Makefile

>+ifeq ($(TARGET),x86BEOS)
>+#BeOS
>+AS_OBJS = mpi_x86.o
>+#MPICMN += -DMP_ASSEMBLY_MULTIPLY -DMP_ASSEMBLY_SQUARE -DMP_ASSEMBLY_DIV_2DX1D
>+#MPICMN += -DMP_MONT_USE_MP_MUL
>+CFLAGS= -O2 -fPIC -Di386 -ansi -Wall \
>+ -pipe -DBEOS -Dbeos -DXP_BEOS -DHAVE_STRERROR \
>+ -UDEBUG -DNDEBUG -D_REENTRANT $(MPICMN)
>+endif

Should I delete the commented-out MPICMN += lines?

5. security/nss/lib/ssl/sslmutex.c

>+#ifdef XP_BEOS
>+    if ((pMutex->u.sem = create_sem(1, "sslMutex sem")) < B_OK)
>+	rv = -1;
>+#else

You may be using rv uninitialized here.  I changed this to
      rv = (pMutex->u.sem = create_sem(1, "sslMutex sem")) < B_OK ? -1 : 0;

>     if (rv < 0) {
>+#ifndef XP_BEOS
>         nss_MD_unix_map_default_error(errno);
>+#endif
>         return SECFailure;
>     }

Is this because nss_MD_unix_map_default_error() is not defined
for BEOS?

6. security/nss/lib/ssl/sslsecur.c

>+#if defined(BEOS)
>+    gs->readOffset += amount;
>+#else
>     if (!(flags & MSG_PEEK)) {
> 	gs->readOffset += amount;
>     }
>+#endif

Is this because BEOS doesn't have MSG_PEEK?

Comment 48

[Wan-Teh Chang]

There are two attachments (attachment 39999 [details] and attachment 64462 [details])
that look like the coreconf .mk file for BeOS.  Which one should
I add and what should the file name be?

Comment 49

[hacker formerly known as [e-mail]]

Wan-Teh wrote:

> 
> 1. security/coreconf/nsinstall/nsinstall.c
> 3. security/nss/lib/freebl/unix_rand.c

Fine by me.  The build still works with those changes.

> 2. security/nss/lib/freebl/Makefile

> Should I simply delete the whole DEFINES += thing?
> 
> Are you using mpi_x86.s on BeOS?

Well, we're compiling the file but I don't know if we're actually using it if
the ifdefs aren't there.  We crash trying to access a https page if the defines
are uncommented so they can be removed.

> 4. security/nss/lib/freebl/mpi/Makefile
> Should I delete the commented-out MPICMN += lines?

Same as above.

Actually, it turns out that we run fine w/o the BeOS changes to both of those
Makefiles so I believe the changes can be safely ignored.  I'm sure that we're
missing out on some optimization but we're happy with that. ;)

> 5. security/nss/lib/ssl/sslmutex.c
> 

> You may be using rv uninitialized here.  I changed this to
>       rv = (pMutex->u.sem = create_sem(1, "sslMutex sem")) < B_OK ? -1 : 0;

Oops.  Good catch.

> Is this because nss_MD_unix_map_default_error() is not defined
> for BEOS?

Actually, it was because "The Be Book 5" API guide made no indication that those
functions set errno on failure.


> 6. security/nss/lib/ssl/sslsecur.c

> Is this because BEOS doesn't have MSG_PEEK?
> 
Correct.


I have attachment 39999 [details] in my tree as security/coreconf/BeOS5.0.mk since that's
what `uname``uname -r` returns.  BONE builds may identify themselves differently
, hence Paul's need for a BeOS5.0.4.mk. I think we can safely make BeOS5.0.4.mk
just include BeOS5.0.mk.

Comment 50

[Dennis Jakobsen]

>Since there is no BeOS PPC port at this point for mozilla, the i386/i586 thing is kind ofirrelavant.my bad then, i just thought the -Dixxx was passed to gcc to tell it what kind of processor to optimize for. can you tell me why they make i686 builds for linux then if it makes no difference?And on another note, the succesful SSL/PSM build i did on net_server worked fine on BONE.

Comment 51

[hacker formerly known as [e-mail]]

mozilla.org makes "i686" builds for linux because `config.guess` returns i686 as
the processor type.  Nothing in the build config scripts optimizes for processor
type.  If someone else is distributing i686 optimized builds, then they are
supplying the extra compiler options themselves.

Comment 52

[Paul]

All net_server builds do "sort-of" run under BONE, as BONE has some wrapper
classes to the new network stack for backwards compatability.  The net_server
builds are not "optimized" to run under BONE, however.  If you have a "pure" 
BONE build running, it will run faster than the net_server build.

Thanks Chris, for clarifying the coreconf make file differences.  They are
just copies of eachother, so, having the 5.0.4 file include the 5.0 file should
work.

Thank you everyone for your work on this.  You have all made a lot of people very
happy in the BeOS community! :)

Comment 53

[Wan-Teh Chang]

Chris Seawood wrote, referring to securiy/nss/lib/freebl/Makefile
and security/nss/lib/freebl/mpi/Makefile:
>
> Actually, it turns out that we run fine w/o the BeOS changes to
> both of those Makefiles so I believe the changes can be safely
> ignored.  I'm sure that we're missing out on some optimization
> but we're happy with that. ;)

In that case, I will omit the BeOS changes to both of those
Makefiles.  I am not qualified to review them and I don't think
I can have them reviewed before the mozilla 0.9.9 deadline.

> > Is this because nss_MD_unix_map_default_error() is not defined
> > for BEOS?
>
> Actually, it was because "The Be Book 5" API guide made no indication
> that those functions set errno on failure.

So how do those functions report error codes on failure?

Comment 54

[Paul]

> So how do those functions report error codes on failure?

BeOS is partially posix compliant, which is where the create_sem comes from,
IIRC.  It does return error codes, even though it may not be documented.  I am
not at my
Be machine at the moment, so I cannot test this, but you should be able to call
nss_MD_unix_map_default_error(errno).

Comment 55

[Wan-Teh Chang]

I just noticed another potential problem with the patch
(attachment 70252 [details] [diff] [review]).

Does create_sem(1, "sslMutex sem") create a process-shared
semaphore (i.e., a semaphore that can be shared by multiple
processes)?  If not, then the BeOS changes to
security/nss/lib/ssl/sslmutex.{c,h} are wrong.

If BeOS has the POSIX pipe() system call and if the
file descriptors of a pipe are inherited by a child
process, BeOS can use the same sslMutex implementation
as Linux, AIX, and OpenVMS.

Comment 56

[Wan-Teh Chang]

Attachment: Patch for NSS (security/coreconf and security/nss), including new file security/coreconf/BeOS.mk

This patch is the NSS subset of attachment 70252 [details] [diff] [review], with my
modifications, and includes the new coreconf .mk file for
BeOS (which replaces the BeOS5.0.mk and BeOS5.0.4.mk files
submitted earlier).

The only open issue is the changes to the sslmutex.{h,c}
files, which I described in comment #55.

Please apply this patch to security/coreconf and security/nss
and let me know if it works.

Comment 57

[hacker formerly known as [e-mail]]

> So how do those functions report error codes on failure?

In the return value. Errno's never mentioned on the page so I wasn't going to
make that assumption.

> Does create_sem(1, "sslMutex sem") create a process-shared
> semaphore (i.e., a semaphore that can be shared by multiple
> processes)?

Yes.  

"The sem_id number that identifies a semaphore is a system-wide token葉he sem_id
values that you create in your application will identify your semaphores in all
other applications as well."

http://www.bebox.nu/bebooks/BeBookR5/The%20Kernel%20Kit/SemaphoreConcepts.html

> If BeOS has the POSIX pipe() system call and if the
> file descriptors of a pipe are inherited by a child
> process, BeOS can use the same sslMutex implementation
> as Linux, AIX, and OpenVMS.

Ah. That's much simplier.  And since it works, it renders previous discussions
moot. :)

Comment 58

[hacker formerly known as [e-mail]]

Comment on attachment 70763 [details] [diff] [review]
Patch for NSS (security/coreconf and security/nss), including new file security/coreconf/BeOS.mk

r=cls works for me!

Comment 59

[Wan-Teh Chang]

Chris,

I have a question about your comment #57.  Do you want to implement
sslMutex with create_sem() or pipe()?  If using the pipe() implementation,
could you send me the diffs for sslmutex.{h,c}?  Thanks.

Once this is done, I am ready to check in the NSS changes.

Can you take care of getting the approval from [e-mail]?

Comment 60

[hacker formerly known as [e-mail]]

Attachment: Use pipe() impl for sslmutex

I have no strong preference either way.  Both seem to work fine (not a lot of
extensive testing though)  The pipe patch is significantly less invasive than
the create_sem patch so I guess I'd go with the pipe patch.  We'll need another
round of BONE testing from Paul though.

Comment 61

[hacker formerly known as [e-mail]]

Attachment: Blocking connect patch for PSM

Comment 62

[Wan-Teh Chang]

Attachment: Patch for NSS (security/coreconf and security/nss), including new file security/coreconf/BeOS.mk

This new NSS patch uses pipe() implementation for sslmutex.

Chris, sslMutex is only used in SSL server-side code, so it
is not used by the Mozilla client.

Comment 63

[hacker formerly known as [e-mail]]

Comment on attachment 70834 [details] [diff] [review]
Patch for NSS (security/coreconf and security/nss), including new file security/coreconf/BeOS.mk

Ah, that explains it. r=cls

Comment 64

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 70834 [details] [diff] [review]
Patch for NSS (security/coreconf and security/nss), including new file security/coreconf/BeOS.mk

a=shaver for 0.9.9.

Comment 65

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 70602 [details] [diff] [review]
Patch to bnet.c for BONE builds

a=shaver for 0.9.9

Comment 66

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 70823 [details] [diff] [review]
Blocking connect patch for PSM

a=shaver for 0.9.9.

Comment 67

[Wan-Teh Chang]

Chris,

After reading "The Be Book 5", I agree with you that the
return codes of the semaphore functions double as error
codes, and there is no indication in the documentation
that these functions set errno on failure.

I now think that it is better to implement sslMutex with
sem_id, but since sslMutex is not used by the Mozilla
client, I suggest we use the simpler pipe implementation
and worry about this later when you want to port an
NSS-based SSL server to BeOS. ;-)

Comment 68

[Paul]

I just tested the latest patch on net_server and BONE.  Everything seems to work
just fine.  r=arougthopher

Also, as for the errno, I will ask some of the other developers in the BeOS
land, and will hopefully have a diffinitive answer for you soon.

Comment 69

[hacker formerly known as [e-mail]]

All of the patches have been checked in.  We're now just waiting for the
NSS_CLIENT_TAG to be updated. :-)

Comment 70

[Wan-Teh Chang]

The deed is done.  Marked the bug fixed.  Have fun!

Comment 71

[Paul]

Chris,
is crypto going to be enabled for the nightly and tinderbox builds now?

Comment 72

[hacker formerly known as [e-mail]]

Yes.

Comment 73

[hacker formerly known as [e-mail]]

verified.