SSL cipher coverage test fails in backward compatibility testing

RESOLVED FIXED in 3.6

Status

NSS
Libraries
P1
blocker
RESOLVED FIXED
16 years ago
16 years ago

People

(Reporter: Wan-Teh Chang, Assigned: Robert Relyea)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

16 years ago
Today's daily build fails all SSL cipher coverage tests
in the backward compatibility testing on all platforms.

Three typical errors are:

tstclnt: write to SSL socket failed: SSL received a record with an incorrect
Message Authentication Code.
selfserv: HDX PR_Read returned error -5961:
TCP connection reset by peer.

selfserv: HDX PR_Read returned error -12273:
SSL received a record with an incorrect Message Authentication Code.
tstclnt: write to SSL socket failed: SSL peer reports incorrect Message
Authentication Code.

selfserv: HDX PR_Read returned error -12264:
SSL received a record with bad block padding.
tstclnt: write to SSL socket failed: SSL peer reports incorrect Message
Authentication Code.
(Reporter)

Comment 1

16 years ago
Created attachment 97787 [details]
results.html 20020904.1
(Reporter)

Comment 2

16 years ago
Created attachment 97789 [details]
output.log 20020904.1

Comment 3

16 years ago
I have been looking at this this morning. I think this has been happening since
last Friday.

Also, the SSl Cipher Coverage tests section in the regular testing (not BC) also
failed with this error:
9 Fatal - selfserv pid file
/share/builds/sbsrel2/nss/nsstip/builds/20020904.1/spd04_Solaris8/mozilla/tests_results/security/diffie.1/tests_pid.392034
does not exist

Just reporting it here since it looks similar, not verified yet if it is due to
the same cause.

Comment 4

16 years ago
Regarding the above comment by me:

The regular tests failed on Diffie, our DEC machine
Comment on attachment 97787 [details]
results.html 20020904.1

Changed mime type of attachment to text/html
Attachment #97787 - Attachment mime type: text/plain → text/html
I built NSS on the trunk yesterday afternoon, and it passed all.sh on my
NT system.  So, is this perhaps specific to the QA test environment?
(Reporter)

Comment 7

16 years ago
The daily QA passed on 8/27.

On 8/28, both the regular QA and backward compatibility test failed.
The failures are different from the ones reported in this bug.

On 8/29, regular QA passed but we started to see the backward
compatibility test failures reported in this bug.

Since our daily QA tests the snapshot at the end of the previous
day, this bug should be caused by a checkin on 8/27 or 8/28.

According to the crypto checkins newsgroup, it seems that all
the checkins on 8/27 and 8/28 were made by Bob.  So I am assigning
the bug to Bob.
Assignee: wtc → relyea
Severity: normal → blocker
Priority: -- → P1
Target Milestone: --- → 3.6

Comment 8

16 years ago
Nelson,

all.sh just tests the regular tests section, not the BC tests section. The
script 'nssqa' does the full suite of tests, the debug and opt regular tests,
and the debug and opt BC tests.

Comment 9

16 years ago
I was incorrect in my earlier statement.  all.sh does test the BC part, but some
environment variables need to be set. However, it gets somewhat cumbersome and
somewhat complicated.

Alternatively, all the right variables are set in the script 'nssqa'. Please
copy the script from /share/builds/sbstools/nsstools/nssqa/tests directory (it
is not the same as the checked in version in cvs) to your workspace tests
directory and run it thus:

./nssqa -y -d -fcron tip 0903 

or

./nssqa -y -d -fcron tip MMDD

This will first execute the debug and opt versions of all.sh, then set the
variables required for the BC testing, then execute the debug and opt BC test
suites.  The results can be viewed in the appropriate day's tests_results
directory, under the machine name.
(Assignee)

Comment 10

16 years ago
Created attachment 98052 [details] [diff] [review]
Keydb shouldn't use blob code.

The blob code uses certdb records to mark blob records. Certdb has a record
type for each of the records stored in the database. NSS code ignores
unrecognized records in the case of certs.

The key3.db code doesn't have records. The field that the certdb uses for a
record is a salt length. We could hack around the problem by making the blob
magic number quite large (255), under the theory that the record will be seen
as invalid by the key code, but it seems safest to assume we that we don't need
the blob code to handle keys.
(Reporter)

Comment 11

16 years ago
Comment on attachment 98052 [details] [diff] [review]
Keydb shouldn't use blob code.

r=wtc.
Attachment #98052 - Flags: review+
(Assignee)

Comment 12

16 years ago
patch fixed the problems.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.