checkin to mozilla/security/manager/Makefile.in also contains the fix
for bug 288647 to allow building NSS with system nspr. a=kengert for
branch-1.8.1.
Tag: MOZILLA_1_8_BRANCH
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@188902 18797224-902f-48f8-a5cc-f745e15eee43
use it have evaporated, r=cls+dougt. Patch written by bsmedberg.
a=bsmedberg for branch-1.8.1+
Tag: MOZILLA_1_8_BRANCH
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@188871 18797224-902f-48f8-a5cc-f745e15eee43
r=wtc/bsmedberg, a=bsmedberg
Note: patches for bugs 288647 and 317620 might be required before enabling this build feature works.
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@188554 18797224-902f-48f8-a5cc-f745e15eee43
NSS 3.10.2 Beta 2, which we expect will be the same as NSS 3.10.2 final.
a=asa for mozilla1.8rc1.
Tag: MOZILLA_1_8_BRANCH
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@181941 18797224-902f-48f8-a5cc-f745e15eee43
NSS 3.10.2 Beta 2, which we expect will be the same as NSS 3.10.2 final.
a=asa for mozilla1.8rc1.
Tag: MOZILLA_1_8_BRANCH
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@181938 18797224-902f-48f8-a5cc-f745e15eee43
the user to trust the root most CA (instead of the leaf most CA) in the
package. Also make sure that the cert is indeed a CA cert. r=kaie,relyea.
sr=sfraser. a=asa for mozilla1.8b5.
Tag: MOZILLA_1_8_BRANCH
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@181212 18797224-902f-48f8-a5cc-f745e15eee43
access to the dom window
patch by Christian Persch <chpe@gnome.org> r=jgmyers sr=roc a=asa
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@177944 18797224-902f-48f8-a5cc-f745e15eee43
sr=brendan r=wtc a=dbaron
The issue is the use of the PL_DHash* functions. It's possible that a given call to PL_DHashOperate which adds a new entry may cause the hash table to expand, and all the existing entries to be reallocated. PL_DHash does this by allocating new memory, then copying the entries. getCacheEntry() returns one of these hash entries. CmpBy() makes two consecutive calls to getCacheEntry, then uses the returned entries for it's comparisons. If the second entry call causes a new entry to be added to the table, and causes the hash table to expand, the pointer to the first entry we retrieved will point to freed memory. The fix is to make the usable entry a pointer in the hashtable entry, and return that pointer. When the hashtable rebuilds it's entries, the pointer will be copied to the new entry and not be disturbed.
git-svn-id: svn://10.0.0.236/branches/MOZILLA_1_8_BRANCH@177796 18797224-902f-48f8-a5cc-f745e15eee43
#/********************************************************************/
#/* The VERSION Strings should be updated in the following */
#/* files everytime a new release of JSS is generated: */
#/* */
#/* org/mozilla/jss/CryptoManager.java */
#/* org/mozilla/jss/CryptoManager.c */
#/* org/mozilla/jss/util/jssver.h */
#/* lib/manifest.mn */
#/* */
#/********************************************************************/
git-svn-id: svn://10.0.0.236/trunk@177648 18797224-902f-48f8-a5cc-f745e15eee43
r=wtc.
Delay loading the S/MIME records on upgrade until the cert is loaded
git-svn-id: svn://10.0.0.236/trunk@177646 18797224-902f-48f8-a5cc-f745e15eee43
transfering large files (> 10MB). In order to test this in current and future
release, there needs to be a test client that can read a file and transfer it to
a server (remote or local) via JSS socket. The server should report the number
of bytes read and the time it took to read these bytes. There should not no
degradation in read time if there is no leak of any sort.
This is not part of all.pl, but is a client/server that uses JSS to transfer
files securely. The main purpose of this test would be to test the performance
of large file transfer using JSS.
NOTE: If bufferedStream.mark(Integer.MAX_VALUE); method is invoked then fill
method of BufferedInputStream class copies lot of data using System.arraycopy
(which in-turn use memcpy). This causes very high CPU usage. This is one of
the reasons secure large file transfer can become slow over time.
git-svn-id: svn://10.0.0.236/trunk@177558 18797224-902f-48f8-a5cc-f745e15eee43
buffer. We access this buffer using indices from 0 to orderBitSize.
r=douglas.stebila.
git-svn-id: svn://10.0.0.236/trunk@177513 18797224-902f-48f8-a5cc-f745e15eee43
