Problematic Situation

[Cagdas]

We have a problem about the trust issues with Mozilla Firefox 3. Even
though there was a correct configuration on Apache2 web server,
Firefox 3 cannot recognize our root certificates. The error code is
"sec_error_unknown_issuer". The target web site is:
https://www.elele.org.tr/elele.php?id=101

Yet we are quite sure that server configuration is suitable with the
one that Firefox wants:

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:
+SSLv2:+EXP:+eNULL
SSLCACertificatePath /etc/apache2/ssl.crt SSLCACertificateFile /etc/
apache2/ssl.crt/kok_s2.crt SSLCertificateChainFile /etc/apache2/
ssl.crt/TURKTRUST_Elektronik_Sunucu_Sertifikasi_Hizmetleri_s2.crt
SSLCertificateFile /etc/apache2/ssl.crt/vakif1.crt
SSLCertificateKeyFile /etc/apache2/ssl.crt/vakif.key ...

Cagdas.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

signtool error

[johst]

Hi there,

I'm getting the following when trying to sign a directory with html
and javascript in:

$ signtool -d .   -k "Absolute Security's VeriSign, Inc. ID" -Z
download.jar download
Generating download/META-INF/manifest.mf file..
--> download.html
adding download/download.html to download.jar...(deflated 42%)
--> download.js
adding download/download.js to download.jar...(deflated 68%)
Generating zigbert.sf file..
signtool: can't generate digest context


I'm very new to this and i've followed the documentation as carefully
as can be done. I've got a Verisign certificate that has signing
rights but for some reason it doesn't work. When i try signtool -v i
get the following:

$ signtool -d . -v download.jar
NOTE -- "download.jar" archive DID NOT PASS crypto verification.
  (reported reason: Corrupt JAR file)

I've looked around for a few days now and can't find anywhere a
comment that says what "signtool: can't generate digest context"
means.

Any help would be greatly appreciated,
Johan
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Documenting default trusted CAs

[Daniel Veditz]

Wan-Teh Chang wrote:
>> which can be seen at
>> 
> 
> That URL is the latest version of the certdata.txt file, which is different 
> from
> the version in NSS 3.11.9.

The "CVS Blame" link can point at specific revisions including tag
names. The 3.11.9 version is:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ckfw/builtins/certdata.txt&rev=NSS_3_11_9_RTM
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: New documentation: NSPR functions required for using NSS

[Nelson B Bolyard]

Rob Crittenden wrote, On 2008-09-09 20:18:

> Does this mean than an explicit PR_Init() is not required?

Whenever you call a public PR_ function, if NSPR is not already initialized,
it will get initialized by that first call.  (*)

However, NSPR initialization should only be done on one thread.  It's bad
if multiple threads call NSPR Functions that all try to initialize NSPR
simultaneously.

PR_Init exists to provide a way to initialize NSPR at a point in the program
when the programmer is sure that no other thread can possibly be using NSPR.

Note: (*) I'm not sure this is correct for 100% of the public NSPR PR_
functions, but I believe it is true for the vast majority.  It may be that
some functions, such as those that operate on open PRFileDescriptors, may
not initialize NSPR, because they reasonably assume that the functions
that returned those newly opened PRFileDescriptors would have initialized
NSPR.  This is speculation.  Perhaps Wan-Teh will make an authoritative
statement about this.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Nelson B Bolyard]

Paul Hoffman wrote, On 2008-09-09 16:52:
> At 2:56 PM -0700 9/9/08, Nelson B Bolyard wrote:
>> Paul Hoffman wrote, On 2008-09-09 13:52:
>>>  Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow
>>>  the directions on
>>>
>>> 
>>>  and do the CVSing. 'gmake nss_build_all' ends with:
>>
>> Since you're trying to build NSS 3.12, hopefully you checked out NSS
>> with the cvs tag NSS_3_12_RTM and NSPR with the tag NSPR_4_7_RTM.
>>
>> NSS and NSPR are now defined cvs modules, which means that instead of
>> checking out by directory names, you can check out by module name.
>> Instead of the cvs commands shown on the page you cited above, you can
>> use
>> cvs co -r NSPR_4_7_RTM NSPR
>> cvs co -r NSS_3_12_RTM NSS
> 
>  Good call. Maybe it would be good to have a page for building 
> 3.12. 
> 
>  
> says that the instructions for "Build Instructions for NSS 3.11.4 and 
> above" is 
> ,
>  
> so I kind of assumed that it reall meant "and above".

I just added build instructions for 3.11.4 and 3.12.1 to the page



I see that you, Paul, were the last previous editor of that page. :)

We should edit the pages that point to those old 3.11.4 build instructions
to point to the new page instead.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: New documentation: NSPR functions required for using NSS

[Rob Crittenden]

Wan-Teh Chang wrote:
> As part of the work to include NSS in LSB 4.0, I created a list
> of NSPR functions required for using the NSS SSL functions at
> http://developer.mozilla.org/En/NSS_reference/NSPR_functions
> 
> I generated this list by inspecting the source code of libcurl,
> nss_compat_ossl, mod_nss, and the NSS test programs
> selfserv, tstclnt, strsclnt, vfyserv, and vfychain.
> 
> Note, in particular, that I documented the PR_ImportTCPSocket
> function, giving an official blessing to use this function "when
> you know what you're doing".  Please let me know if I have
> explained the caveats adequately without discouraging
> people from using this convenient function under the right
> circumstances.
> 
> Wan-Teh

Does this mean than an explicit PR_Init() is not required?

rob
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Validation (OCSP) Preferences

[Kai Engert]

Neil wrote:
Bug 110161 turned on OCSP by default. It also followed this up by 
changing the UI from a group of three radio buttons to a checkbox and a 
pair of radiobuttons. However these three controls fight over the same 
preference. This makes for some hairy preference code, but also I 
noticed that if you used to use a specific signer, then if you turn OCSP 
off and close preferences then it will forget that fact, so you can't 
just turn it back on again. (With the old triple radiobutton this was 
obvious behaviour.)


My suggestion is to create a new boolean security.OCSP.disabled pref 
that defaults to false and therefore does not affect existing behaviour 
but can be toggled through appropriate UI to override the 
security.OCSP.enabled pref.
  
Independently of our final decision, having both an "enabled" and 
"disabled" preference seems very ambiguos, so if we agreed to go that 
path, I'd vote for a stronger name for your new override preference.


It will also mean that at runtime, each time the browser verifies a web 
site cert, we'll have to query two preferences instead of just one (see 
implementation of and callers to function GetIsOcspOn).


This will mean that the current checkbox and 
radiobuttons can by updated to refer to the separate preferences and the 
linked preference updating code can be removed. Assuming that nobody has 
any objections I hope to work on the backend later this week.
  


I think you work primarily on SeaMonkey. Given that the backend code is 
shared amongst multiple apps, what are your plans wrt Firefox, 
Thunderbird, etc?


I think your intention is to simplify some (working) UI code, with the 
disadvantage of having to support an additional preference in the 
backend. My personal preference is to avoid the additional pref.


Thanks,
Kai



smime.p7s
Description: S/MIME Cryptographic Signature
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Nelson B Bolyard]

Paul Hoffman wrote, On 2008-09-09 16:52:
> At 2:56 PM -0700 9/9/08, Nelson B Bolyard wrote:
>> Paul Hoffman wrote, On 2008-09-09 13:52:

> I nuked mozilla/* and used the two cvs commands above. The make now ends with:
> 
> /usr/bin/ld: cannot find -lnssutil3

OK, so this time, it's failing to find a different library.
It's not finding libnssutil3.so (the library name implied by -lnssutil3).
That's not surprising, since your build built the file with a different
name, libnssutil3.so.1.0

>> See if the build actually built a .so whose name contains softokn3.
>> If so, then figure out why the link step for libnss3.so is using a
>> different name than the name of the .so that was actually built.

> phoffman-FreeBSD7.0:/home/phoffman/NSS-312/mozilla/security/nss# find 
> . -name "*\.so*" -print
> ./lib/sqlite/FreeBSD7.0_DBG.OBJ/libsqlite3.so.1.0
> ./lib/util/FreeBSD7.0_DBG.OBJ/libnssutil3.so.1.0

That output shows that your build built libnssutil3.so.1.0 but is then
subsequently looking for libnssutil3.so and not finding it.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Paul Hoffman]

At 5:28 PM -0700 9/9/08, Wan-Teh Chang wrote:
>On Tue, Sep 9, 2008 at 4:52 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote:
>>
>>  I nuked mozilla/* and used the two cvs commands above. The make 
>>now ends with:
>>
>>  /usr/bin/ld: cannot find -lnssutil3
>>  gmake[3]: ***
>>  [FreeBSD7.0_DBG.OBJ/FreeBSD_SINGLE_SHLIB/libfreebl3.so.1.0] Error 1
>>  gmake[3]: Leaving directory
>>  `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/freebl'
>
>This is the same problem.  We need to track this down.
>
>http://mxr.mozilla.org/security/source/security/coreconf/FreeBSD.mk#68
>
>68 MOZ_OBJFORMAT   := $(shell test -x /usr/bin/objformat &&
>/usr/bin/objformat || echo elf)
>69
>70 ifeq ($(MOZ_OBJFORMAT),elf)
>71 DLL_SUFFIX  = so
>72 else
>73 DLL_SUFFIX  = so.1.0
>74 endif
>
>Let's focus on line 68.  On your FreeBSD 7.0 system, /usr/bin/objformat
>doesn't exist.  So we expect that in line 68, "test -x /usr/bin/objformat"
>should fail, and therefore we short-circuit "&& /usr/bin/objformat" and
>execute "echo elf".  But this is not happening.

I'm not sure why the "echo elf" is not happening. However, changing 
line 68 to read "MOZ_OBJFORMAT := elf" causes everything to build 
just fine.

FWIW, the man page for objformat on FreeBSD 6.3 says:

==
DESCRIPTION
  This program is obsolete and is now just a compatibility stub.

  It reports the object file format as ``elf''.

HISTORY
  The objformat command appeared in FreeBSD 3.0.

  The objformat program was deprecated in FreeBSD 4.0 and reduced to a com-
  patibility stub in FreeBSD 5.0.  It will be completely removed before the
  next release.
==

That says to me that you can do the replacement I did above with 
complete impunity in a future version of NSS. Do you need me to 
submit a bug report for this or do you want to do it yourself?

>I don't have a FreeBSD system, so I tested this makefile fragment
>on Linux, and it works.

Let me know if you need access to one. OTOH, if you have a virtual 
server somewhere, FreeBSD installs just fine and is quite easy to set 
up.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Wan-Teh Chang]

On Tue, Sep 9, 2008 at 4:52 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote:
>
> I nuked mozilla/* and used the two cvs commands above. The make now ends with:
>
> /usr/bin/ld: cannot find -lnssutil3
> gmake[3]: ***
> [FreeBSD7.0_DBG.OBJ/FreeBSD_SINGLE_SHLIB/libfreebl3.so.1.0] Error 1
> gmake[3]: Leaving directory
> `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/freebl'

This is the same problem.  We need to track this down.

http://mxr.mozilla.org/security/source/security/coreconf/FreeBSD.mk#68

68 MOZ_OBJFORMAT   := $(shell test -x /usr/bin/objformat &&
/usr/bin/objformat || echo elf)
69
70 ifeq ($(MOZ_OBJFORMAT),elf)
71 DLL_SUFFIX  = so
72 else
73 DLL_SUFFIX  = so.1.0
74 endif

Let's focus on line 68.  On your FreeBSD 7.0 system, /usr/bin/objformat
doesn't exist.  So we expect that in line 68, "test -x /usr/bin/objformat"
should fail, and therefore we short-circuit "&& /usr/bin/objformat" and
execute "echo elf".  But this is not happening.

I don't have a FreeBSD system, so I tested this makefile fragment
on Linux, and it works.

Wan-Teh
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Paul Hoffman]

At 2:56 PM -0700 9/9/08, Nelson B Bolyard wrote:
>Paul Hoffman wrote, On 2008-09-09 13:52:
>>  Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow
>>  the directions on
>> 
>>
>>  and do the CVSing. 'gmake nss_build_all' ends with:
>
>Since you're trying to build NSS 3.12, hopefully you checked out NSS
>with the cvs tag NSS_3_12_RTM and NSPR with the tag NSPR_4_7_RTM.
>
>NSS and NSPR are now defined cvs modules, which means that instead of
>checking out by directory names, you can check out by module name.
>Instead of the cvs commands shown on the page you cited above, you can
>use
> cvs co -r NSPR_4_7_RTM NSPR
> cvs co -r NSS_3_12_RTM NSS

 Good call. Maybe it would be good to have a page for building 
3.12. 

 
says that the instructions for "Build Instructions for NSS 3.11.4 and 
above" is 
,
 
so I kind of assumed that it reall meant "and above".

I nuked mozilla/* and used the two cvs commands above. The make now ends with:

/usr/bin/ld: cannot find -lnssutil3
gmake[3]: *** 
[FreeBSD7.0_DBG.OBJ/FreeBSD_SINGLE_SHLIB/libfreebl3.so.1.0] Error 1
gmake[3]: Leaving directory 
`/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/freebl'
gmake[2]: *** [libs] Error 2
gmake[2]: Leaving directory 
`/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/freebl'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory 
`/usr/home/phoffman/NSS-312/mozilla/security/nss/lib'
gmake: *** [libs] Error 2

>There are two possible explanations that occur to me.
>1) your checked out source files/directories are missing the directory
>in which libsoftokn3 is built.  The make process just skips missing
>directories, so maybe the build didn't build it, and also didn't fail,
>because the directory was missing.

Well, the new checkout (for 3.12) shouldn't have done it twice

>2) From the output above, it appears that someone has changed the
>makefiles for BSD to use a different naming convention than NSS's
>usual naming convention for Unix shared libraries.  I say that because
>in the output above, I see libnss3.so.1.0 and that trailing .1.0 is
>simply not part of NSS's present naming scheme for shared libraries.
>Perhaps the problem is that your build built libsoftokn3.so.1.0 but
>this linker command to link libnss3 is looking for the library by its
>usual naming convention, which lacks the .1.0.
>
>Perhaps some changes are needed to the BSD makefiles to correct this.
>BSD is not directly supported by the NSS team.  None of us has BSD
>systems, so we depend on BSD aficionados to build on BSD, to report
>any make problems, and to contribute patches to fix those make problems.

I'm happy to make a FreeBSD system available to the team.

>  > Any clues how I can move forwards on this?
>
>See if the build actually built a .so whose name contains softokn3.
>If so, then figure out why the link step for libnss3.so is using a
>different name than the name of the .so that was actually built.

Nope.

phoffman-FreeBSD7.0:/home/phoffman/NSS-312/mozilla/security/nss# find 
. -name "*\.so*" -print
./lib/sqlite/FreeBSD7.0_DBG.OBJ/libsqlite3.so.1.0
./lib/util/FreeBSD7.0_DBG.OBJ/libnssutil3.so.1.0

At 3:07 PM -0700 9/9/08, Wan-Teh Chang wrote:
>The relevant makefile code that Nelson pointed out about
>the .so.1.0 suffix is:
>http://mxr.mozilla.org/security/source/security/coreconf/FreeBSD.mk#68
>
>
>68 MOZ_OBJFORMAT   := $(shell test -x /usr/bin/objformat &&
>/usr/bin/objformat || echo elf)
>69
>70 ifeq ($(MOZ_OBJFORMAT),elf)
>71 DLL_SUFFIX  = so
>72 else
>73 DLL_SUFFIX  = so.1.0
>74 endif
>
>What is the output of the command /usr/bin/objformat on your
>FreeBSD 7.0 system?

phoffman-FreeBSD7.0:/home/phoffman/NSS-312/mozilla/security/nss# 
/usr/bin/objformat
-bash: /usr/bin/objformat: No such file or directory

Maybe that is a hint. :-) FWIW, that command worked on FreeBSD 6. 
OTOH, the man page for objformat in FreeBSD 6 says that is was 
deprecated long ago and will be removed in 7.

>The intended code path for current versions of FreeBSD is line 71.

But that test seems to fail and go to line 73.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Wan-Teh Chang]

On Tue, Sep 9, 2008 at 1:52 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote:
> Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow
> the directions on
> 
> and do the CVSing. 'gmake nss_build_all' ends with:
>
> /usr/bin/ld: cannot find -lsoftokn3
> gmake[2]: *** [FreeBSD7.0_DBG.OBJ/libnss3.so.1.0] Error 1
> gmake[2]: Leaving directory
> `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/nss'
> gmake[1]: *** [libs] Error 2
> gmake[1]: Leaving directory
> `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib'
> gmake: *** [libs] Error 2

The relevant makefile code that Nelson pointed out about
the .so.1.0 suffix is:
http://mxr.mozilla.org/security/source/security/coreconf/FreeBSD.mk#68


68 MOZ_OBJFORMAT   := $(shell test -x /usr/bin/objformat &&
/usr/bin/objformat || echo elf)
69
70 ifeq ($(MOZ_OBJFORMAT),elf)
71 DLL_SUFFIX  = so
72 else
73 DLL_SUFFIX  = so.1.0
74 endif

What is the output of the command /usr/bin/objformat on your
FreeBSD 7.0 system?

The intended code path for current versions of FreeBSD is line 71.

Wan-Teh
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cannot make 3.12 on FreeBSD 7.0

[Nelson B Bolyard]

Paul Hoffman wrote, On 2008-09-09 13:52:
> Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow 
> the directions on 
> 
>  
> and do the CVSing. 'gmake nss_build_all' ends with:

Since you're trying to build NSS 3.12, hopefully you checked out NSS
with the cvs tag NSS_3_12_RTM and NSPR with the tag NSPR_4_7_RTM.

NSS and NSPR are now defined cvs modules, which means that instead of
checking out by directory names, you can check out by module name.
Instead of the cvs commands shown on the page you cited above, you can
use
cvs co -r NSPR_4_7_RTM NSPR
cvs co -r NSS_3_12_RTM NSS

> /usr/bin/ld: cannot find -lsoftokn3
> gmake[2]: *** [FreeBSD7.0_DBG.OBJ/libnss3.so.1.0] Error 1
> gmake[2]: Leaving directory 
> `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/nss'
> gmake[1]: *** [libs] Error 2
> gmake[1]: Leaving directory 
> `/usr/home/phoffman/NSS-312/mozilla/security/nss/lib'
> gmake: *** [libs] Error 2

The NSS build should have built libsoftokn3.so long before it came to
this step of trying to build libnss3.so.  If it failed to build
libsoftokn3, that should have stopped the build at that point, long
before it got to this point.

There are two possible explanations that occur to me.
1) your checked out source files/directories are missing the directory
in which libsoftokn3 is built.  The make process just skips missing
directories, so maybe the build didn't build it, and also didn't fail,
because the directory was missing.

2) From the output above, it appears that someone has changed the
makefiles for BSD to use a different naming convention than NSS's
usual naming convention for Unix shared libraries.  I say that because
in the output above, I see libnss3.so.1.0 and that trailing .1.0 is
simply not part of NSS's present naming scheme for shared libraries.
Perhaps the problem is that your build built libsoftokn3.so.1.0 but
this linker command to link libnss3 is looking for the library by its
usual naming convention, which lacks the .1.0.

Perhaps some changes are needed to the BSD makefiles to correct this.
BSD is not directly supported by the NSS team.  None of us has BSD
systems, so we depend on BSD aficionados to build on BSD, to report
any make problems, and to contribute patches to fix those make problems.

> Any clues how I can move forwards on this?

See if the build actually built a .so whose name contains softokn3.
If so, then figure out why the link step for libnss3.so is using a
different name than the name of the .so that was actually built.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Cannot make 3.12 on FreeBSD 7.0

[Paul Hoffman]

Greetings again. I'm trying to build 3.12 on FreeBSD 7.0. I follow 
the directions on 

 
and do the CVSing. 'gmake nss_build_all' ends with:

/usr/bin/ld: cannot find -lsoftokn3
gmake[2]: *** [FreeBSD7.0_DBG.OBJ/libnss3.so.1.0] Error 1
gmake[2]: Leaving directory 
`/usr/home/phoffman/NSS-312/mozilla/security/nss/lib/nss'
gmake[1]: *** [libs] Error 2
gmake[1]: Leaving directory 
`/usr/home/phoffman/NSS-312/mozilla/security/nss/lib'
gmake: *** [libs] Error 2

Looking in the library directory, we see:

phoffman-FreeBSD7.0:/home/phoffman/NSS-312/mozilla/security/nss# ls 
-la lib/nss/FreeBSD7.0_DBG.OBJ/
total 102
drwxr-xr-x  2 phoffman  phoffman512 Sep  9 13:51 .
drwxr-xr-x  4 phoffman  phoffman512 Sep  9 13:44 ..
-rw-r--r--  1 phoffman  phoffman  37094 Sep  9 13:44 libnss.a
-rw-r--r--  1 phoffman  phoffman  21196 Sep  9 13:44 nss.def
-rw-r--r--  1 phoffman  phoffman  33720 Sep  9 13:44 nssinit.o
-rw-r--r--  1 phoffman  phoffman   2876 Sep  9 13:44 nssver.o

Any clues how I can move forwards on this?

--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Validation (OCSP) Preferences

[Neil]

Bug 110161 turned on OCSP by default. It also followed this up by 
changing the UI from a group of three radio buttons to a checkbox and a 
pair of radiobuttons. However these three controls fight over the same 
preference. This makes for some hairy preference code, but also I 
noticed that if you used to use a specific signer, then if you turn OCSP 
off and close preferences then it will forget that fact, so you can't 
just turn it back on again. (With the old triple radiobutton this was 
obvious behaviour.)

My suggestion is to create a new boolean security.OCSP.disabled pref 
that defaults to false and therefore does not affect existing behaviour 
but can be toggled through appropriate UI to override the 
security.OCSP.enabled pref. This will mean that the current checkbox and 
radiobuttons can by updated to refer to the separate preferences and the 
linked preference updating code can be removed. Assuming that nobody has 
any objections I hope to work on the backend later this week.

-- 
Warning: May contain traces of nuts.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Including FNMT cert in Firefox 3 (Spanish government)

[Nukeador]

Hi again,

As I told Frank at the Summit, we should consider this bug as a hight
priority marketing issue in Spain. We are not going to gain more market
share if the Spanish citizens are unable to view a government site or
buy train tickets with Firefox.

Whatever is needed to speed up the process, contact us and we will help.

Regards.



signature.asc
Description: OpenPGP digital signature
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto