Nelson B Bolyard wrote:
On 2009-07-30 19:04 PDT, Howard Chu wrote:
As far as I can see, CERT_VerifyCertName() is still vulnerable to the
embedded NUL hack that was recently published here
http://www.wired.com/threatlevel/2009/07/kaminsky/ and on slashdot. Yet
some comments in the discussion
tificates. The
root CA module (libnssckbi.so or nssckbi.dll) is version
1.75.
Wan-Teh Chang
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
dev-tech-crypt
First you should respond to Kyle's reply to you there.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
__
OpenSSL mailing lists are
certainly a better forum for this question...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
n libldap and the SSL library), and
another sockbuf layer below the SSL layer (between the SSL library and the
network).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architec
Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-17 22:21:
>>
> I think you're saying that you expect every library to have its own set of
> trusted certs, as if libraries -- and not true human users -- get to decide
> what certs are trusted and what are not. A hu
. I suggested an approach in my previous post in this thread, but
while it maintains a measure of compatibility it's still not fool-proof.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-16 17:03:
>> What software is that? The docs say NSS_Init must only be called once; this
>> would only be a problem if a piece of code called NSS_Init multiple times and
>> still only called NSS_Shutdown once. Code writte
n with other callers.
I think you can solve the majority of cases by making the exported
NSS_Shutdown decrement a counter as Wan-Teh suggested, but also install an
atexit handler to invoke an NSS_RealShutdown function when the current app
exits. Not sure if it needs to be an actual atexit slot
Rich Megginson wrote:
> Howard Chu wrote:
>> At any rate, I've committed the preliminary code to CVS so you can
>> tinker with it if you want. It will take a lot more beating on before
>> it's actually usable.
> Some Red Hat folks have been working on adding
reasonably efficient and it would also solve a lot of certificate
sharing/distribution issues.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_
> which NSS version works with which DB version. I remember a serious
> problem with cert7.db used by a 3rd-party product and different media
> releases of NSS.
And PEM has been around since 1992 or so, without any real changes. (Which
isn't surprising since it's mostly dead...)
trust that is read is the union of all the trusts from
> each DB, by slot priority.
>
> When you call CERT_GetCertTrust you only get one trust object no matter
> how many slots the cert may appear in, and whether the trust between
> those DBs agrees or not. It's not possible to
Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-10 14:13:
>> It would make it impossible to use in e.g. OpenLDAP/nss_ldap because
>> applications would be unable to load their own configuration settings
>> after nss_ldap/libldap/nss initialized.
>
> Nothing pre
dules. Before NSS
> 3.12, you needed to use a separate cert/keydb for each application as
> the underlying database format didn't support multiple access if any one
> process had it open writable, but NSS 3.12 now supports a shareable
> format but it is not enabled by default which
Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-10 14:13:
>
>> The issue isn't about a specific file format, it's about overall
>> usability. Ignoring the issue of hiding things in a fragile DB the
>> problem is that it's a one-shot monolithic co
Nelson B Bolyard wrote:
> Howard Chu wrote, On 2008-08-10 03:30:
> When one considers all the important reasons to choose a crypto
> implementation, support for one file format which is not used in any
> standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie.
The is
n be freely used
anywhere in the world.
While there appears to be a function for enumerating the available cipher
suites and their names, it would also be convenient to have a function that
returns the cipher number for a given name, to make it easier to work with
settings read from a configura
18 matches
Mail list logo