I found this write up that might explain some issues I have seen. I'm
about to try this on a certificate provided to me that should be
trusted. In think this might be inlne with what Eddy is saying about
intermediates, and explain further why when using intermediates it
does not work as
On 29.3.11 20:21, Mark Mentovai wrote:
Wan-Teh and I discussed adding a new header to handle this problem,
security/nss/lib/freebl/blconfig.h, that could be #included as needed
where definitions of macros like NSS_X86 and NSS_USE_64 are
significant. This could be structured like
#ifdef
On 30.3.11 02:52, Wan-Teh Chang wrote:
Mandating Apple compilers is fine. Until one or two years ago,
NSPR and NSS were using the -Wmost flag, which is an Apple
extension. I was the one who noticed the problem. That's
strong evidence that no one else had tried to compile NSPR
or NSS on the
On 30.3.11 14:56, Ridley wrote:
In think this might be inlne with what Eddy is saying about
intermediates, and explain further why when using intermediates it
does not work as expected.
I guess that he root cause of your problems is again the one described in
On Wed, Mar 30, 2011 at 6:45 AM, Kaspar Brand m...@velox.ch wrote:
Sounds good. security/nss/lib/jar is currently the other place which
also depends on the NSS_X* macros, i.e. it should be a header file which
can be used by files outside freebl, too.
I see. security/nss/lib/util/secport.h is
I have to be honest and say I don't know. The PFX was exports with the entire
chain, and the XPI was signed using XPISigner (also tried Key Manager plugin)
and in both cases the XPI only installed on the signing machine. Other machines
received the -260 error.
Interestingly, the XPI installed
On 30.03.2011 19:19, Wan-Teh Chang wrote:
Another option is to fix security/nss/lib/jar so that it doesn't
use the NSS_X86_OR_X64 macro. lib/jar is only used by
the NSS command-line tools modutil and signutil, so it isn't
important to rely on x86/x86_64 processors' ability to do
unaligned
7 matches
Mail list logo
