Neil wrote:
Neil wrote:
I also notice that checkPassword(); logs out if there was a
password. Can this behaviour be relied on, or should I call
logoutSimple() too?
To answer my own question, nsPK11Token::CheckPassword calls
PK11_CheckUserPassword which is documented as logging out
Robert Relyea wrote:
On 10/15/2009 02:39 AM, Neil wrote:
Robert Relyea wrote:
If you have no master password set, you have a token that doesn't have 'need login' set
in it. NSS will treat such a token as always logged in. No matter how many
times you log out, the token and it's keys
Nelson B Bolyard wrote:
By the way, I REALLY REALLY wish that the password manager would use that when
you click the button to reveal the passwords, instead of doing what it does
now, which forces you to re-enter the master password, even if you've JUST
entered it.
I think this is a
Robert Relyea wrote:
If you have no master password set, you have a token that doesn't have 'need login' set
in it. NSS will treat such a token as always logged in. No matter how many
times you log out, the token and it's keys are still available.
What exactly are you seeing?
What I'm
Nelson Bolyard wrote:
I'll add these thoughts. I don't know of any way to log in to a token that has no
password. IINM, such a token just comes up in a state that is similar to being already
logged in. It's not surprising to me that forcefully logging it out leaves it in a state where it
in when there is no password
c) there's a bug in PSM and/or NSS?
Thanks,
Neil.
--
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
Nelson Bolyard wrote:
NSS certainly supports AES. NSS offers a C API.
PSM is the primary provider of XPCOM wrappers for NSS. I'm not aware of what
raw symmetric encryption capabilities PSM offers to the users of its XPCOM
interfaces. Sadly, few PSM developers hang out here.
For those
Polly wrote:
Neil wrote:
Polly wrote:
Tom, you asked what third party DLLs I'm using -- it's the openssl DLLs
ssleay32.dll and libeay32.dll.
One possible alternative might be to rewrite your code to use NSS?
Thanks for the suggestion. As it happens, my requirements were
Some users of SeaMonkey 2.0b1 who have migrated from SeaMonkey 1.1.17
have been complaining that the resulting profile claims to have a master
password. As I understand it, NSS uses the key3.db to tell whether or
not a master password exists, and we do nothing more than copy the file
during
Nelson Bolyard wrote:
Neil, if your code to do this is in a patch or checked in somewhere, a pointer
to that code would be appreciated.
I was going to email you a diff, but it turns out that there's an error
in my methodology and I wasn't catching people misusing PL_strfree
Nelson Bolyard wrote:
If you have public redistributable header files that declare the MSVCRT memory
guards, please send a pointer to them. Thanks.
I can't actually find the documentation I originally read about it; this
is the nearest that I get from a search:
Nelson Bolyard wrote:
Benjamin Smedberg wrote, On 2009-03-31 08:35:
In the other cases, we should just fix the bug, which is (I think) why Neil
posted originally.
I wish him Godspeed in fixing (or even filing) those bugs.
I filed bugs 486404/5 yesterday, and have a possible patch
Nelson B Bolyard wrote:
The problem is in the way that Mozilla builds JEMalloc for FF on Windows. They
build a replacement for the Microsoft C RunTime Library.
Ah, but I'm hoping that any solution that they manage to implement for
the Mac will be portable to VC Express, since it will only
Nelson B Bolyard wrote:
Neil wrote, On 2009-03-29 17:01:
Firefox may want to switch to using the jemalloc allocator on the Mac.
Well, I hope it won't mean for the Mac what it has meant on Windows.
On Windows, the JEMalloc code can ONLY be built with the non-free
professional version
Firefox may want to switch to using the jemalloc allocator on the Mac.
As I understand it, this is tricky because you can't globally replace
malloc/free. While in theory it would be possible to replace NS_Free
and/or PR_Free, this runs into problems when the code doesn't match its
allocators.
Kai Engert wrote:
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).
Ah, I had overlooked that version; I thought it was all done via the
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
Wan-Teh Chang wrote:
I'm not sure if it's still worth implementing the real fix now -- it is easier
to ask the affected people to blow away their dist/public/nss directory in
their build trees.
Even in depend builds, Mozilla's root makefile still automatically blows
away all of
Wan-Teh Chang wrote:
On Sun, Feb 24, 2008 at 3:15 AM, Neil [EMAIL PROTECTED] wrote:
Even in depend builds, Mozilla's root makefile still automatically blows away
all of dist/include to avoid such problems... do dist/public and dist/private
need to be added to that list too?
Yes, just
Nelson Bolyard wrote:
I'd like to get a dependency tools for Windows again. I guess there's one as
part of Mozilla, but I don't want to have to build the whole browser to get a
dependency tool.
While the Mozilla build system can build its own, I'm not sure NSS is up
to the task,
import.
Nelson Bolyard wrote:
Neil wrote, On 2008-02-22 17:05:
On second thoughts the problem seems to be that someone is including
pkix_pl_oscpcertid.h before pkixt.h
Doesn't the compiler name the .c file that it's trying to compile when this
error occurs?
pkix_pl_ldapcertstore.c
Nelson Bolyard wrote:
In any case, I'd guess the right fix is for pkix_pl_oscpcertid.h to include
pkixt.h, since it depends on types defined there.
The build still didn't succeed. This is also now with a normal MSYS
VC7.1 SeaMonkey build, which produces this (partial) output:
make[6]:
Nelson Bolyard wrote:
Neil, here's what I find strange about all this.
The code you cite builds and runs, without error, continuously, on a whole
bunch of tinderbox systems
That's because a number of factors are required to trigger this bug:
1. The bug does not affect clobber builds
Nelson Bolyard wrote:
That user cert you created doesn't have an email address in it.
Sorry, my bad; I couldn't cut and paste and I overlooked the
[EMAIL PROTECTED], in the command line for the email cert.
I suggest you try both (in separate certs).
They both seem to work, but I like the
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error *pkix_pl_OcspCertID_RegisterSelf(void *plContext);
PKIX_Error *
PKIX_PL_OcspCertID_Create(
Wan-Teh Chang wrote:
On Fri, Feb 22, 2008 at 4:35 PM, Neil [EMAIL PROTECTED] wrote:
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation */
PKIX_Error
Neil wrote:
Wan-Teh Chang wrote:
On Fri, Feb 22, 2008 at 4:35 PM, Neil [EMAIL PROTECTED] wrote:
pkix_pl_oscpcertid.h contains:
struct PKIX_PL_OcspCertIDStruct {
CERTOCSPCertID *certID;
PRBool certIDWasConsumed;
};
/* see source file for function documentation
Nelson B Bolyard wrote:
Neil wrote, On 2008-02-20 16:33:
It seems that building SeaMonkey will include certutil
Do SM builds build all the NSS commands? That seems like a big waste.
Sorry, I hadn't looked closely enough, I see that I have the source, but
the first step would
(with the test email address [EMAIL PROTECTED])!
Thanks in advance,
Neil.
--
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
Wan-Teh Chang wrote:
NSS uses LD on Unix (including Linux and Mac OS X), and LINK on
Windows, to refer to the linker.
It also uses $LINK_DLL on Windows and $MKSHLIB everywhere else. How
inconsistent :-(
--
Warning: May contain traces of nuts.
___
Wan-Teh Chang wrote:
None of the NSS developers cross-compiles NSS. (The closest thing we
do to cross-compilation is to build the Windows CE binaries on Windows
2000/XP.) So we're not familiar with how the Mozilla developers
cross-compile NSS.
I don't think many Mozilla developers
Nelson B wrote:
I suggest that you first try to get NSS to build for you in its
stand-alone configuration, using only NSS's makefiles and not any of
the other mozilla products' makefiles.
Where would this be documented, with specific reference to cross
compilation?
--
Warning: May contain
Myself using Interix and Mook using Wine have both tried to
cross-compile Mozilla using MSVC as a cross compiler. Generally I would
like to think that NSS has been the easiest part to cross compile, but
here are the issues we ran into:
1. Because we're not using GCC or MSYS, rules.mk tries
Steve Mitchell wrote:
It is confusing deploying JSS on Windows XP. The library jss4.dll depends
on libnspr4.dll, not nspr4.dll as is installed with Firefox. Other
dependent libraries such as nss3.dll depend on nspr4.dll. Should I copy and
rename nspr4.dll to libnspr4.dll, or are these
34 matches
Mail list logo
