Closed Bug 106865 Opened 23 years ago Closed 22 years ago

Blank page instead of SSL error dialog visiting https server

Categories

(Core Graveyard :: Security: UI, defect, P2)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.4

People

(Reporter: nelson, Assigned: KaiE)

References

(
URL
)

Details

Attachments

(4 files, 3 obsolete files)

cert database for use with selfserv
16.00 KB, application/octet-stream
Details
key database for use with selfserv
16.00 KB, application/octet-stream
Details
Patch v4
10.41 KB, patch
rpotts
: review+
KaiE
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Patch as checked in
4.37 KB, patch
Details | Diff | Splinter Review 
I'm running N6.x BuildID: 2001091703
I'm attempting to reproduce a problem reported by a user with an older
version of Mozilla.  I should be getting SSL error dialogs, (like the ones
he reported) but instead I'm getting the infamous blank page, whose 
contents are:
           <html><body></body?</html>

That blank page phenomenon is EVIL!

Here's how I reproduced it.
1. Visit http://ca.in-berlin.de/cgi-bin/rootca and download the root CA
cert, but do not check any of the trust check boxes.
2. Visit http://ca.in-berlin.de/cgi-bin/serverca and download the 
intermediate CA cert, but do not check any of the trust check boxes.3. Visit
https://me.in-berlin.de/ or https://me.in-berlin.de/asdfkjh

You should get an error message about an untrusted CA cert.
Instead, I get a blank page.

4. Then use the Certificate Manager and edit the trust flags for the 
root CA,  trusting it to issue SSL server certs.  
5. Visit https://me.in-berlin.de/ or https://me.in-berlin.de/asdfkjh

You should get an error message about some other problem with the CA cert.
Instead, I get a blank page.
I think that
A) we should never see blank pages when there are SSL problems, and 
b) if we ever DO get this page, IT SHOULD NOT BE BLANK.

I propose that the page be changed to something like this:

   <html><body>If you can see this, PSM needs more work.</body?</html>
This was taken care of by the fix to bug 97997


*** This bug has been marked as a duplicate of 97997 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Priority: -- → P2
Resolution: --- → DUPLICATE
Target Milestone: --- → 2.2
Verified dupe.
Status: RESOLVED → VERIFIED
I've got news for ya.
I downloaded the 10-22 build from sweetlou, which identifies itself as
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 
(note it says 10-19)
And I get the same blank pages from it.
So this bug is NOT fixed.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Here is an update.  I see that what's actually happening is that no new page
is being loaded at all.  It's not a new blank page being loaded.  Whatever
page was being shown before is left showing.  
So, with this bugzilla page in my window, I visit the URL cited above,
and when the throbber stops, it says "document done", and no error dialogs
appeared, but I'm still looking at the same mozilla bug page.
With the 10/26 Win98 trunk build, I get "You cannot connect because of an 
unknown SSL error (-8101)"
Using nelsonb's TLS tests, I get:
/u/junruh/tls >./tstclnt -h me.in-berlin.de -d . < stdin.txt
tstclnt: connecting to me.in-berlin.de:443 (address=213.61.118.14)
tstclnt: connect: Operation is still in progress (probably a non-blocking 
connect).
tstclnt: about to call PR_Poll for connect completion!
tstclnt: PR_Poll returned 0x02 for socket out_flags.
tstclnt: ready...
tstclnt: about to call PR_Poll !
tstclnt: PR_Poll returned!
tstclnt: PR_Poll returned 0x01 for stdin out_flags.
tstclnt: stdin read 16 bytes
tstclnt: Writing 16 bytes to server
tstclnt: about to call PR_Poll on writable socket !
tstclnt: PR_Poll returned with writable socket !
tstclnt: about to call PR_Poll on writable socket !
tstclnt: PR_Poll returned with writable socket !
tstclnt: write to SSL socket failed: Certificate type not approved for 
application.
How 'bout a dialog box saying that in PSM?
Confirmed for 2001110703 on Win98SE.

This bug is very annoying (severity should be major) because no https site can
be browsed.
rangan
Assignee: ssaux → rangansen
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Something darn similar to this is happening in release 0.9.6, though it did not
happen in 0.9.5, on Linux.  With the 095 release, I was able to do my secure
banking and shopping with no problem at all.  With 096, hitting https:// pages
do nothing at all, or load a blank page if they were to open a new window
(either by javascript or by hitting the middle mouse button).  I reported it as
bug #111323, which will likely be marked a duplicate of this one.
This bug is really annoying. In fact, it's a "showstop" bug for any HTTPS user.

Please, update the "severity" field to reflect this important fact.

Mozilla is my only browser since last summer. Excellent work, guys.

Merry Christmas and happy 2002.
Blocks: 126944
Works for me. I cannot reproduce, and also haven't seen a blank page for a long 
time now.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Verified works for me.
Status: RESOLVED → VERIFIED
I got some bad news for you guys, this bug is still in 0.9.9, and it's still as 
much of a showstopper. Except now I have a test case.
It involves a bad SSL server configuration, but nonetheless mozilla should 
report an error, not a blank page .

See the attached cert and key databases.
They are for the server. Run selfserver from NSS the following way :

(strange)/u/jpierre/nss/34/mozilla/dist/SunOS5.8_DBG.OBJ/bin{72} !68
./selfserv -n Server-Cert -p 2000 -m -r -r -w enterprise

Then connect with Mozilla to the machine, in this case https://strange:2000 .

Then, mozilla will display the infamous blank page !

Meanwhile, selfserv will also report an error below :
selfserv: HDX PR_Read returned error -12199:
No certificate authority is trusted for SSL client authentication.

This is normal and is expected for this invalid SSL server configuration. But 
mozilla must deal with it. This is a showstopper.


Reproduced, reopening
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
You may want to take a look at 
http://bugzilla.mozilla.org/show_bug.cgi?id=134125
for other investigations about what led me to create this testcase .

Apparently the client side just gets an "end of file" right away from the 
misconfigured server, there is no SSL error reported. So there may also be a 
libssl bug at stake here.

Even if there is no SSL error reportd, mozilla should still report a problem 
with the site if it submits an HTTPS request and gets nothing back from the 
server. I discussed the HTTP/HTTPS aspects of this in another very similar bug, 
http://bugzilla.mozilla.org/show_bug.cgi?id=126944 .
OS: Windows NT → All
Hardware: PC → All
kai
Assignee: rangansen → kaie
Status: REOPENED → NEW
Target Milestone: 2.2 → Future
This problem seems related to "proxy" usage and SSL2+SSL3+TLS support. If you
have a proxy, TLS support and the remote server doesn´t support TLS but SSL3,
you see the problem. I haven't bug IDs at hand, but the problem seems reported
also in this context. Search the bugzilla database.

Since I can only navigate thru a proxy (squid), this is a showstop for me and a
big NO-NO for a inminent 1.0 release.
I believe that this bug and bug 126944 are duplicates.  I'll leave it 
to the assignee to decide which one to mark as a dup.

I believe that neither bug has anything to do with proxy handling.

This bug and bug 126944 appear to have the same cause, namely, 
a flaw in the logic that attempts to decide whether a given error 
should be displayed to the user by PSM or not.  Esentially, the 
error is that the code only displays errors for error codes that 
begin with SSL_, not ones that begin with PR_ or SEC_.  

The explanation for this bug is given in 
http://bugzilla.mozilla.org/show_bug.cgi?id=126944#c6

I have seen a similar problem.
The feature I realized is that https://
pages work only if disk cache is enabled.
If the disk cache size is set to 0 (or left blank)
a https:// page doesn't show up at all.
Really strange.
My comment was wrong.
I meant memory cache instead of disk cache.
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
Here's my findings:

- The original problem is no longer reproducable as it has been said already.
Trying steps 1-3 in the original report, I indeed see the error message. After
steps 4-5 the connection works, probably as the server configuration is
meanwhile correct.

- I can reproduce the problem that Julien reports in comment 14, using the
approach he suggested.


However, the symptoms are different. I don't see a blank page any longer.

However, when the failure occurs, no warning is shown at all.
The connection silently fails.
The content currently shown in the browser continues to be shown, and the user
has no idea what happened.
Status: NEW → ASSIGNED
Michael, I can not reproduce your problem. But it sounds different. If you still
can reproduce, please file a separate bug.
Attached patch Patch v1 (obsolete) — — Splinter Review 
When the connection fails in the given scenario, NSS does not return a specific
failure code. Instead we receive PR_END_OF_FILE_ERROR. Julien, Nelson, do you
think NSS should return a better error code?


Or is it reasonable to always inform the user if a connection to a remote site
fails with this error?

The attached patch will always show an error message to the user, if an attempt
is being made to load a top level document, and the socket transport thread
detects an EOF while expecting to be able to read or write to the socket.

Darin, do you think this makes sense?
If yes, is it ok to Mozilla's error code NS_ERROR_ABORT or should we define a
new one, like NS_ERROR_END_OF_FILE?
NS_ERROR_ABORT is probably too generic for this.  would it be useful to have
necko retry the connection?  if so, then you should map PR_END_OF_FILE_ERROR to
NS_ERROR_NET_RESET.  if 10 unsuccessful attempts go by, necko will finally error
out to docshell with NS_ERROR_NET_RESET, which will cause docshell to put up the
error message saying "the document contains no data."
Would an automatic retry have the chance to retransmit high level application
data, like the user's command to submit an order?

I wonder what happens if a buggy server accepts the order and sends us an EOF.

If you prefer an automatic retry and the same handling as in connection reset,
could we limit the automatic retry on EOF to those situations, where no high
level protocol data has yet been exchanged?

> Would an automatic retry have the chance to retransmit high level application
> data, like the user's command to submit an order?

yes, provided we have not yet read any data to satisfy the transaction.  i.e.,
necko already assumes that if there is no response from the server, then there
was never a complete transaction.  this is actually required given the way
TCP/IP works.  that is, writing may appear to succeed even though the other end
has closed the socket.  you'll only find out that it is closed after you get
done writing and try to read.

> I wonder what happens if a buggy server accepts the order and sends us an EOF.

ooh.. that'd be very bad.

> If you prefer an automatic retry and the same handling as in connection reset,
> could we limit the automatic retry on EOF to those situations, where no high
> level protocol data has yet been exchanged?

there's no way to determine if high level data has been exchanged.  sure, we
could say that we won't do this when issuing a HTTP POST, but what about a HTTP
GET?  it can have side-effects even though the standard says it should not.

when does the EOF occur?  were we able to successfully complete the SSL
handshake?  is it just that the server closed the connection after we issued the
HTTP request?
1) In this particular situation reported within this bug, the SSL handshake will
have failed, and no application data will have been exchanged. I would like to
find a way to report this failure to the user.

2) All we see is an EOF error code. This is a generic error that might occur in
many other situations, like generic networking for other protocols. Currently,
this error code is not specifically handled in necko.

3) When we try to do 1), I would like to avoid introducing new risks for 2),
like the "order submit example" for the http protocol.


I was asking about how Necko behaves, because I want to be careful. I think we
should do 1) without having to care for individual protocols like http.


The question is: Will a general new rule in Necko, that makes it retry on EOF,
have the risk to introduce new risks for 2)?


If there is the risk, I'd prefer to avoid it, and just display an error to the
user immediately.

This whole discussion might be obsolete, if Nelson thinks that NSS should give
us a better error message than just EOF, like SSL_HANDSHAKE_FAILED.

Nelson, what do you think?

The SSL protocol demands that an SSL "close notify alert" record be sent 
before a connection is closed.  If an SSL connection reads an EOF from the 
underlying socket without having already received a "close notify alert",
this is a violation of the SSL protocol.  In this case, the EOF is an
error, a protocol violation, rather than merely being an indication of
the normal end of the server's data stream.  So, libSSl returns -1 with 
PR_END_OF_FILE_ERROR rather than returning zero (EOF) in this case.  
AFAIK, this is the only circumstance under which PR_END_OF_FILE_ERROR
is generated (in libSSL).

So, PR_END_OF_FILE_ERROR means that the remote server (or an attacker) 
closed the connection without properly terminating the SSL protocol.

The application may wish to take a different action than it would for
the normal EOF case when it sees this error.  How the application  deals 
with this error is application dependent.  

Off the top of my head, I might suggest that the application could treat 
this error the same as an ordinary EOF if it has not received any response 
to its https request prior to the receipt of this error, and treat it as a 
security error if some portion of the http response has been received prior 
to the occurance of this error.
On second thought, I think the interpretation of the PR_END_OF_FILE_ERROR
has to depend on whether or not the http request was sent prior to the 
error occurance.  If the request was completely sent before the error 
occurs, then this error has to be regarded as a security violation,
a "truncation attack".  

This invalid-EOF-detection facility in SSL/TLS is there precisely to deal
with situations like the one where the server receives the request, 
honors it, and then the client is disconnected (e.g. by an attacker 
inserting a TCP FIN segment) before the client receive's the server's
response.  In this situation, the user should be notified that the 
connection was terminated in an insecure way, and perhaps the user
should be advised to check to see if the transaction was completed 
before resubmitting the transaction.

Let me summarize:

I conclude that Nelson
- does not think NSS should send us a better error, but PR_END_OF_FILE_ERROR is
sufficient.
- suggests we should NOT automatically retry if there is the chance the remote
site has already received our request.
- implicitly allows us to retry in certain situations, like knowing that we have
not yet sent any application data. (I'm generalizing from the http protocol
situation to a generic application protocol, since we probably don't want to add
http protocol dependent logic to the generic socket transport logic.)

In addition I see there is no other code in Mozilla which sets the
PR_END_OF_FILE_ERROR code, so our new behaviour is not likely to introduce side
effects.


To avoid risks and find a general solution I keep up my suggestion to:
- never retry
- always warn


As a result, we are back at comment 26/27, where I ask whether NS_ERROR_ABORT is
fine, or whether we should introduce a new one.

As Darin thinks the abort error code is too generic, I suggest to introduce a
new error code.

If nobody objects, I will attach a new patch, that is very similar to the
previous patch, but defines and uses the new error code NS_ERROR_END_OF_FILE
(directly defined in xpcom/base/nsError.h since this code sounds to be generic
enough).

1. Yes, I think PR_END_OF_FILE_ERROR is sufficient.  I see no need to create
another new error code (e.g. NS_END_OF_FILE_ERROR) with a 1:1 mapping.

2. The logic that decides whether or not to retry an http request should be the 
same with or without SSL.  It seems to me that the http client should not 
silently reissue the http request if/when it receives EOF __AFTER__ it has
completely sent the request.  

3. PR_END_OF_FILE_ERROR is different from a ZERO return (ordinary end of file)
in that the latter signifies an SSL protocol violation, a potential security 
attack.  I think that never retry & always warn is appropriate for this.
if you don't want the HTTP module to silently retry the request, then mapping
PR_END_OF_FILE_ERROR to NS_ERROR_NET_RESET is wrong.  if you map it to some
error like NS_ERROR_ABORT, then the user will see nothing but a blank page. 
what you probably want to do is map the error to some other error (perhaps
defined in netCore.h) and modify nsWebShell::EndPageLoad to check for that error
and display a message to the user indicating why they are seeing a blank page.
Nelson,

> 1. Yes, I think PR_END_OF_FILE_ERROR is sufficient.  I see no need to create
> another new error code (e.g. NS_END_OF_FILE_ERROR) with a 1:1 mapping.

My question was only related to what NSS gives out. Thanks, I'll react to that
code then.

The suggested 1:1 mapping to a new NS_END_OF_FILE_ERROR code has a different
reason: In Mozilla, the error code needs to transported through XPCom
components, which has a different error code namespace, and I can't pass the PR
code through as is, so I would like to introduce that new code.


> 2. The logic that decides whether or not to retry an http request should be the 
> same with or without SSL.  It seems to me that the http client should not 
> silently reissue the http request if/when it receives EOF __AFTER__ it has
> completely sent the request.  

I assume, in this paragraph, when you say EOF, you mean ordinary EOF, i.e. zero
byte return.

Agreed. I would even go one step further and not limit this proposal to HTTP,
but to any protocol.
With the new error code PR_END_OF_FILE_ERROR / NS_END_OF_FILE_ERROR, I think we
already agree to not retry.
However, for error codes PR_CONNECT_ABORTED_ERROR and PR_CONNECT_RESET_ERROR I
think we should move that handling to a separate bug. I would like to leave that
decision to Darin, whether to change the existing behaviour for those error
codes (which is unrelated to this bug).


> 3. PR_END_OF_FILE_ERROR is different from a ZERO return (ordinary end of file)
> in that the latter signifies an SSL protocol violation, a potential security 
> attack.  I think that never retry & always warn is appropriate for this.

Good. I think we all agree here. This is what this bug is about.

Darin,

> if you don't want the HTTP module to silently retry the request, then mapping
> PR_END_OF_FILE_ERROR to NS_ERROR_NET_RESET is wrong.  

Agreed. We don't want that.


> if you map it to some
> error like NS_ERROR_ABORT, then the user will see nothing but a blank page. 

Only because we don't handle that error code currently, but in my patch I
suggest to do so.
However, as you said, NS_ERROR_ABORT is generic, and I suggest to introduce
NS_END_OF_FILE_ERROR, and use that error code instead in my patch. Besides that
change, the patch should still be what we seem to agree on.


> what you probably want to do is map the error to some other error (perhaps
> defined in netCore.h) 

I suggested a global NS_END_OF_FILE_ERROR, but if you prefer a network code
local error code, that's fine with me, too.


> and modify nsWebShell::EndPageLoad to check for that error
> and display a message to the user indicating why they are seeing a blank page.

I believe that is what the attached patch is doing already?

I discussed with Sean Cotter, explaining the problem. He suggested the following
wording (where %S is the hostname). I like the wording.

"The connection to %S has terminated unexpectedly. Some data may have been
transferred."
Attached patch Patch v2 (obsolete) — — Splinter Review 
This new patch has the following changes:

- uses new XPCom error code NS_ERROR_SOCKET_EOF defined in netCore.h
  (instead of NS_ERROR_ABORT)

- maps PR_END_OF_FILE_ERROR to the new error code, no automatic retry

- extends nsWebShell::EndPageLoad to detect the error and calls an extended
version of nsDocShell::DisplayLoadError which will display the new error
message suggested by Sean


Darin, if you agree, can you please review?
Attachment #95348 - Attachment is obsolete: true
this message:

"The connection to %S has terminated unexpectedly. Some data may have been
transferred."

should almost be the default error message when a document fails to load
completely (not as a result of user action).  i've tried to introduce such a
dialog, but there are unfortunately some cases in which it erroneously fires.
iirc, imagelib terminates some otherwise valid image loads with
NS_ERROR_FAILURE, and javascript: URLs may even signal an error in some cases.

this is why we use a white-list to determine which errors should map to error
dialogs.

in this case, i think you could safely use NS_BASE_STREAM_CLOSED instead of
introducing a new error code.
If I understand you correctly, you want to use that generic code for this
specific situation in this bug, and are willing to accept that as a result, this
message will be shown in many situations, whenever the BASE_STREAM_CLOSED error
appears (at least for the top level document)?

New patch coming up.
Attached patch Patch v3 (obsolete) — — Splinter Review 
Same patch as v2, using NS_BASE_STREAM_CLOSED instead
Attachment #97228 - Attachment is obsolete: true
Comment on attachment 97234 [details] [diff] [review]
Patch v3

sr=darin
Attachment #97234 - Flags: superreview+
Comment on attachment 97234 [details] [diff] [review]
Patch v3

I should have tested this latest version of the patch, it does not work, and I
have already discussed with Darin. The problem is that we can't really use
NS_BASE_STREAM_CLOSED, as this code is occurring in standard situations and
will be mapped to NS_OK.
Attachment #97234 - Attachment is obsolete: true
I have discussed with Darin, the new error code should be named
NS_ERROR_NET_INTERRUPT.

The following is a summary of what I have discussed with Darin, and what I
believe is true for the PR_END_OF_FILE_ERROR.

This paragraph is actually long, and you might not want to read it completely.
It is rather the result of me trying to sort my thoughts and trying to
understand it better. After having written it, I'm more confident what we are
doing here is correct.



Assumption:
  When writing bytes over TCP/IP, it is not immediately known whether the write
succeeded or not.
  When doing the next read, and the read fails, it is unknown how many bytes
(none, some, all) were received by the remote site.

Desired Mozilla network behaviour (already in place):
  (1)
  If not even a single byte has been received from the remote site, and a read
error is detected, an automatic retry should happen.
  This is currently done when PR_CONNECT_ABORTED_ERROR or PR_CONNECT_RESET_ERROR
is seen (and communicated using NS_ERROR_NET_RESET).

Suggested additional behaviour:
  (2)
  If the application is sure that at least one single byte has already been
received from the remote site, 
    and an unexpected read error is detected, then we don't want to retry.
  This is communicated with the new proposed code NS_ERROR_NET_INTERRUPT.

Nelson said, if PR_END_OF_FILE_ERROR is set, it means the remote site did not
follow the protocol rules.
I assume SSL is a "client writes first" protocol.
There are two possibilites:
a) We have started with sending the initial handshake bytes, but the remote site
did not answer, we did not receive any bytes.
   I assume this is NOT treated as the PR_END_OF_FILE_ERROR case. It probably
does not make sense.
   If we are not yet sure the other site is speaking our protocol, since we have
not yet received any bytes,
     we can't really assume it's a protocol violation.
b) We have not yet exchanged application data, but we are still in the SSL
negotiation phase.
   We have already exchanged at least some SSL handshake bytes, so we are
assuming the remote site speaks SSL,
   and we are negotiating details.
   Once we have arrived in that state, we assume the protocols must be followed.
   If in that situation the remote site terminates the connection, without
having followed the fule to say "good bye",
     the situation is treated as a protocol violation, and PR_END_OF_FILE_ERROR
is reported.
c) We have completely finished the SSL handshake phase.
   We are now in the phase terminating the connection with sending "good bye"
messages first is a protocol violation.
   Therefore, any unexpected connection termination is communicated with
PR_END_OF_FILE_ERROR.


My assumption a) is probably correct. In this case, SSL is not different from
any other network logic.
An automatic retry would be reasonable and can not cause problems.
But even if my assumption were wrong, and PR_END_OF_FILE_ERROR is set anyway,
this isn't much of a problem.
The only consequence is: No automatic retry on initial SSL connection failure.

If PR_END_OF_FILE_ERROR is seen in b) or c), it is reasonable not to retry.
If we don't want to retry, we need to communicate that using NS_ERROR_NET_INTERRUPT.

By setting NS_ERROR_NET_INTERRUPT for both b) and c), the application code can't
distinguish whether application data was exchanged or not.
However, since it is known for sure that at least some bytes were exchanged, a
general connection was possible, and it is known for sure
  the actual transaction has been started. If that is known for sure, it is
reasonable to not automatically retry / repeat the transaction.
Attached patch Patch v4 — — Splinter Review 
This patch introduces the new error code as suggested.

Besides that I have made one additional change:

The previous patch only showed the error when the top level frame produced that
error.

However, I think it is reasonable to show that error even if the error occurs
in a sub frame.
This time I have actually tested the patch. It works for me.
Besides Julien's test case, it also fixes another behaviour.
Try to open https://www.mozilla.org:80/
It shows the same wrong behaviour (blank page, or rather, unchanged display,
without error message).
That's another situation this patch fixes.

Darin, are you ok with the numerical error code I assigned? It seems to fit into
the "net range", but that range was already full...
Target Milestone: Future → 2.4
Comment on attachment 97274 [details] [diff] [review]
Patch v4

Since you did not object to my previous comment, carrying forward sr=darin
Attachment #97274 - Flags: superreview+
Rick, could you please review, too?

Comment on attachment 97274 [details] [diff] [review]
Patch v4

a=asa for checkin to 1.2beta (on behalf of drivers)
Attachment #97274 - Flags: approval+
fixed on trunk
This is identical to patch v4 with two differences:
- previous patch did no longer apply because of context changes, fixed
- I did not check in the added PR_LOG statements, to save me some merging
trouble with other patches I'm working on
marking fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: