Qt-interest Archive, October 2007
QSsl something not handling Time correctly
Message 1 in thread
Long-winded post, but lots of good detail. :) Unfortunately, it's
probably not going to format well.
Environment: WindowsXP Pro SP2, Qt 4.3.2 Commercial built from source,
VS2005 SP1, qt-vsintegration 1.3.2, openssl 0.9.7m.
Using "openssl req" I created a key + a self-signed certificate at local
time "Oct 16 17:06:43 2007", expiration 10,000 days. I'm in timezone
GMT-5, so that time is the same as "Oct 16 22:06:43 2007 GMT".
Using "openssl x509" I see the Validity fields for the certificate:
Not Before: Oct 16 22:06 43 2007 GMT
Not After : Mar 3 22:06:43 2035 GMT
Note that the first time matches the GMT creation time, so this
certificate is valid beginning -immediately-. According to OpenSSL,
everything is fine here.
I put the PEM-format string for the certificate into a QSslCertificate on
this same machine, and extract "effectiveDate()", and convert it several
ways:
QString cert = ...... // The PEM-encoded text of the certificate, with
header/footer/newlines.
QSslCertificate daCert(cert.toAscii());
QString certStartLocal = daCert.effectiveDate().toLocalTime().toString();
// returns "Tue Oct 16 22:06:43 2007" which is really the GMT/UTC
creation time!!!
QString certStartGMT = daCert.effectiveDate().toUTC().toString();
// returns "Wed Oct 17 03:06:43 2007" which is GMT+5 from creation time!
QString certStartGMT = daCert.effectiveDate().toUTC().toUTC().toString();
// returns same as single "toUTC()" conversion, which is good
QString certValid = daCert.isValid();
// Returns false, because time problem above makes it appear "not yet
valid"
That tells -me- that when QSslCertificate (or something deeper) pulls the
GMT/UTC time from the certificate and builds a QDateTime with it, it flags
it as "Local" time instead of GMT/UTC. When I ask for GMT, it adds +5
hours to what was already a GMT time.
The OpenSSL docs and newsgroups/etc all agree that the time inside the
certificate is always GMT/UTC, and the openssl commandline tool displays
the time as "GMT" correctly (see above). But Qt treats them as though
they were Local when they came from the certificate; it adds an extra 5
hours (in my case) to make them GMT even though they were -already- GMT.
It's now 20:49 local time. Qt says the certificate I created at 17:06:43
local today is still "not yet valid". If I were to stay another 1h18m and
run it again, I believe Qt would accept that certificate. But I really
want to go home and get some sleep rather than stay until 22:06!!! :)
So it will be valid tomorrow, but that doesn't actually get rid of the
problem.
So have I found a Qt bug??? Or is there some other explanation for
this?? :) I know I'm good, but I -can- make mistakes. :) :)
(If there were some way to tell OpenSSL to create a certificate with
YESTERDAY as start date, that would be kind of ugly, but a workaround
nonetheless.)
[[Also note that QSslCertificate doc pages in QtAssistant need to be
updated to replace references to non-existent methods "notValidBefore()"
and "notValidAfter()" with references to "effectiveDate()" and
"expiryDate()".]]
Mike
--
[ signature omitted ]
Message 2 in thread
Hi,
> So have I found a Qt bug??? Or is there some other explanation for
> this?? :) I know I'm good, but I -can- make mistakes. :) :)
It could be a Qt bug, although I wasn't able to find where it could hide by
reading your description and looking at the Qt source code.
If you have compiled Qt yourself or you have a debug version of Qt installed,
you might want to debug this a little bit:
* A start point could be QSslCertificatePrivate::QSslCertificate_from_X509()
in file qsslcertificate.cpp:
ASN1_TIME *nbef = q_X509_get_notBefore(x509);
ASN1_TIME *naft = q_X509_get_notAfter(x509);
certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
certificate.d->notValidAfter.setTime_t(q_getTimeFromASN1(naft));
* q_X509_get_notBefore() really is OpenSSl's X509_get_notBefore()
* q_getTimeFromASN1() is defined in file qsslsocket_openssl_symbols.cpp
I would suggest adding debug statements to print out "nbef" and
"q_getTimeFromASN1(nbef)".
To print the ASN1_TIME type, have a look at this thread:
http://www.mail-archive.com/openssl-users@xxxxxxxxxxx/msg43948.html
To print the time_t type, use for example C functions gmtime() followed by
asctime() - or equivalent Qt functions.
Otherwise, you could send a bug report here:
http://trolltech.com/bugreport-form
preferably with an example certificate and a small, compilable, complete
example that reproduces the problem.
You could also post the example here, I'll have a look at it time permitting.
--
[ signature omitted ]
Message 3 in thread
On Wed, 17 Oct 2007 01:05:23 -0500, Dimitri <dimitri@xxxxxxxxxxxxx> wrote:
> Hi,
>
>> So have I found a Qt bug??? Or is there some other explanation for
>> this?? :) I know I'm good, but I -can- make mistakes. :) :)
>
> It could be a Qt bug, although I wasn't able to find where it could hide
> by reading your description and looking at the Qt source code.
Sorry, I tried to give a lot of detail without dumping a lot of code to
the group. :) Of course, TODAY that certificate is seen as perfectly
valid since >5 hours has passed. I'll make a new certificate for further
testing.
> If you have compiled Qt yourself or you have a debug version of Qt
> installed, you might want to debug this a little bit:
>
> * A start point could be
> QSslCertificatePrivate::QSslCertificate_from_X509() in file
> qsslcertificate.cpp:
> ASN1_TIME *nbef = q_X509_get_notBefore(x509);
> ASN1_TIME *naft = q_X509_get_notAfter(x509);
> certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
> certificate.d->notValidAfter.setTime_t(q_getTimeFromASN1(naft));
>
> * q_X509_get_notBefore() really is OpenSSl's X509_get_notBefore()
>
> * q_getTimeFromASN1() is defined in file qsslsocket_openssl_symbols.cpp
I did debug into that area after tracking down the relevant datatypes.
(The ASN1_TIME format is either "ASN1_STRING" or "typedef asn1_string_st"
depending on a #ifdef.) The "nbef" and "naft" values are definitely the
GMT/UTC time values directly from the certificate: they match what
"openssl x509" shows me.
I tried following the conversion in "q_getTimeFromASN1()" and it -looked-
ok to me. (I don't know if it's updated for the new DaylightSavingsTime
rules, but that's a separate issue.) Maybe the problem is somewhere
between that function and "setTime_t".
I'll debug more completely and get back to you. I will gladly send a bug
report, but I first want to reduce the chances that it's my own stupid
error. :)
Thanks for the pointers/tips! :)
Mike
--
[ signature omitted ]
Message 4 in thread
I have a very simple testcase built that shows the discrepancy.
Using OpenSSL:
- You create a new certificate at local time XX in timezone GMT-YY.
- The UTC equivalent of that localtime XX is XX+YY.
- You examine the certificate and see "Not Before" as XX+YY : the correct
UTC time.
Using VisualStudio 2005 (or maybe another environment):
- Run the test case and note the output. Also commented for easy
debugging.
Analyze the output:
- QSslCertificate::effectiveDate().toLocalTime().toString() is XX+YY :
wrong.
- QSslCertificate::effectiveDate().toUTC().toString() is XX+YY+YY :
VERY wrong.
- Same discrepancies are visible in "Not After" / "expiryDate".
Shall I just post the code and a block of setup instructions here?? Or is
there some other convention for doing this??
Mike
On Thu, 18 Oct 2007 10:57:26 -0500, Mike Broida
<michaelb@xxxxxxxxxxxxxxxx> wrote:
> On Wed, 17 Oct 2007 01:05:23 -0500, Dimitri <dimitri@xxxxxxxxxxxxx>
> wrote:
>
>> Hi,
>>
>>> So have I found a Qt bug??? Or is there some other explanation for
>>> this?? :) I know I'm good, but I -can- make mistakes. :) :)
>>
>> It could be a Qt bug, although I wasn't able to find where it could
>> hide by reading your description and looking at the Qt source code.
>
> Sorry, I tried to give a lot of detail without dumping a lot of code to
> the group. :) Of course, TODAY that certificate is seen as perfectly
> valid since >5 hours has passed. I'll make a new certificate for
> further testing.
>
>> If you have compiled Qt yourself or you have a debug version of Qt
>> installed, you might want to debug this a little bit:
>>
>> * A start point could be
>> QSslCertificatePrivate::QSslCertificate_from_X509() in file
>> qsslcertificate.cpp:
>> ASN1_TIME *nbef = q_X509_get_notBefore(x509);
>> ASN1_TIME *naft = q_X509_get_notAfter(x509);
>> certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
>> certificate.d->notValidAfter.setTime_t(q_getTimeFromASN1(naft));
>>
>> * q_X509_get_notBefore() really is OpenSSl's X509_get_notBefore()
>>
>> * q_getTimeFromASN1() is defined in file qsslsocket_openssl_symbols.cpp
>
> I did debug into that area after tracking down the relevant datatypes.
> (The ASN1_TIME format is either "ASN1_STRING" or "typedef
> asn1_string_st" depending on a #ifdef.) The "nbef" and "naft" values
> are definitely the GMT/UTC time values directly from the certificate:
> they match what "openssl x509" shows me.
>
> I tried following the conversion in "q_getTimeFromASN1()" and it
> -looked- ok to me. (I don't know if it's updated for the new
> DaylightSavingsTime rules, but that's a separate issue.) Maybe the
> problem is somewhere between that function and "setTime_t".
>
> I'll debug more completely and get back to you. I will gladly send a
> bug report, but I first want to reduce the chances that it's my own
> stupid error. :)
>
> Thanks for the pointers/tips! :)
> Mike
--
[ signature omitted ]
Message 5 in thread
Hi,
> Shall I just post the code and a block of setup instructions here?? Or
> is there some other convention for doing this??
If you have found a bug in Qt, please do file a bug report here:
http://trolltech.com/bugreport-form
That's the only way to make sure the bug is known. This mailing list is not a
bug tracking tool. Bugs can be assigned to developers and fixes can be
scheduled only if they are referenced in Trolltech's bug tracking tool. The
entry point for Trolltech's bug tracking tool is the above URL.
Now if you post here an example that reproduces the issue you're facing,
myself or some other member of the mailing list may be able to have a look at
the issue, provide a workaroud, a patch for Qt, or maybe point to a bug in the
example itself.
--
[ signature omitted ]
Message 6 in thread
I definitely will post a bug report, but I want to debug deeper first;
maybe I can isolate the problem area.
Meanwhile, here's some instructions and a fairly short main() that
completely illustrates the problem and can be used to debug. I would have
made the test program do the setup steps listed below, but that's not easy
at all. So you have to do the setup yourself. Sorry. :)
BIG NOTE: I believe this problem will NOT be noticeable (though it does
exist) on systems set in any timezone that is UTC+XX hours, where XX is 0
or greater. Any certificate created there became valid XX hours BEFORE
creation. In timezones that are UTC-YY hours, the certificate will not be
valid until YY hours AFTER creation. This "limitation of the error" may
be why Trolltech has not encountered the problem during their own
testing. :) Aren't their offices in timezone GMT+1 or GMT+2?? I'm in
timezone GMT-5, so the problem is very noticeable here.
INSTRUCTIONS:
Before running the code below, you must:
1) Ensure your system is set to a timezone WEST of GMT: UTC-XX hours.
The bigger "XX" is, the more time you have to complete your
testing/debugging before the certificate becomes valid. You might be able
to track down the problem without this setup step, though.
2) Use the "openssl" commandline tool to create a new self-signed X509
certificate. I used this commandline:
openssl req -x509 -nodes -days 10000 -newkey rsa:1024 -out mycert.pem
You'll be asked to type-in several data items, but you can use a single
"." for each of them EXCEPT that you should use "localhost" to answer the
"Common Name (eg, YOUR name)" question. Notice the current localtime when
you finish this step.
**NOTE: IF not on a Unix-ish system or if config file "openssl.cnf" is not
in "/usr/local/ssl/", you may need to add another argument:
-config xxxxx
Substitute the correct path+name to that config file. On my Windows
system it is found in:
C:\openssl\openssl-0.9.7m\apps\
(I merely copied the file into my local directory and used only the
filename for "xxxxx" above.)
3) Examine the certificate "Not Before" and "Not After" values using the
same "openssl" commandline tool:
openssl x509 -startdate -enddate -noout -in mycert.pem
Notice that both values are shown as "GMT". The "Not Before" value should
match the localtime (converted to UTC) when you created the certificate
above. This shows that the times are stored in the certificate itself as
GMT/UTC times.
4) Record the "Not Before" datetime so you can compare it to the test
results later.
5) Copy the newly-created "mycert.pem" file to the directory you will
execute the test code from. You'll also need the "ssleay32.dll" and
"libeay32.dll" files (or equivalents on other platforms) in that same
directory or the system's "library-finding path". Those files are in the
"out32dll" or "out32dll.dbg" directories under the OpenSSL installation
directory: grab the right version (debug or not) for the buildmode you
will use for the code below.
6) Build/Run the test code below, redirecting STDOUT and STDERR to a
file. It will run very quickly if you don't debug it. :)
7) Examine the test results: Notice that the "Not Before time as Local:"
line shows the same value as the UTC "Not Before" time from the
certificate. This is BAD. Notice that the "Not Before time as UTC:" line
shows that same value increased (again) by your offset from GMT/UTC
timezone. This is BAD. Notice the "current time" lines as Local and
UTC. They should be correct and you can compare them to the other lines
to see the problem clearly": ALL those lines should indicate the same
timevalue, though some are converted to UTC.
CODE SAMPLE: (I've greatly reduced the comments; if you have questions,
ask me.)
------------
#include <QtCore/QCoreApplication>
#include <QtNetwork>
#include <QtDebug>
int main(int argc, char *argv[])
{
QCoreApplication ca(argc, argv); // Needed for this test?
// Load cert from file
QString path =
QDir::toNativeSeparators(QCoreApplication::applicationDirPath()) +
QDir::separator() +
"mycert.pem";
QFile certfile(path);
certfile.open(QIODevice::ReadOnly);
QSslCertificate daCert(&certfile); // Breakpoint here to debug how dates
are set
certfile.close();
// Now show the results.
qDebug() << "Loaded cert from file. Dates inside file are always UTC!";
qDebug() << " is null? " << daCert.isNull();
qDebug() << " is valid?" << daCert.isValid(); // Probably invalid due to
problem described!
qDebug() << " \"Not Before\" time as Local: " <<
daCert.effectiveDate().toLocalTime().toString();
qDebug() << " \"Not Before\" time as UTC: " <<
daCert.effectiveDate().toUTC().toString();
qDebug() << "For reference:";
qDebug() << " CURRENT time as Local: " <<
QDateTime::currentDateTime().toLocalTime().toString();
qDebug() << " CURRENT time as UTC: " <<
QDateTime::currentDateTime().toUTC().toString();
int a = 1; // Dummy: Place to set breakpoint at end.
}
--- END ---
--
[ signature omitted ]
Message 7 in thread
I believe I've found the true source of this problem.
Here's my analysis:
In QSslCertificatePrivate::QSslCertificate_from_X509(X509 *x509), look for
this line:
certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
Dimitri, that's in the block you pointed me to before. :)
At that point, nbef is a correct UTC value taken from the cert file.
Passing nbef into q_getTimeFromASN1(const ASN1_TIME *aTime), that function
recognizes it as UTC (aTime->type == V_ASN1_UTCTIME) and sets
"lSecondsFromUCT" = 0. It then correctly converts the datetime to a "tm"
structure holding correct sec, min, hour, mday, mon, and year values. It
calls mktime() to convert it to a "time_t" value (#secsSince1Jan1970UTC),
subtracts one hour if DaylightSavingsTime is in effect, then adds
lSecondsFromUCT (set above) to account for timezones. It returns this end
value, which I believe is fully correct. No problem to this point. :)
That value is passed into QDateTime::setTime_t(uint). This QDateTime
object is the "notValidBefore" part of the QSslCertificatePrivate object
("d") inside the QSslCertificate object. When it was created, the "spec"
item was set (or defaulted) to "LocalUnknown" and has not been changed.
setTime_t() saves that d->spec (which says "LocalUnknown") into local
variable "oldSpec", then converts the date and time into absolute QDate
and QTime values inside the QDateTimePrivate object. It then forces
d->spec to indicate "UTC". If "oldSpec" is not "UTC", this function calls
d->getLocal(QDate&, QTime&).
Let's look inside QDateTimePrivate::getLocal(QDate&, QTime&). This
function sets the output QDate and QTime to the QDateTimePrivate object's
values. If the QDateTimePrivate's "spec" (d->spec to caller) is UTC, it
calls "utcToLocal(QDate&, QTime&)" to convert to Local. That function
works correctly.
HOWEVER: setTime_t() --always-- sets d->spec to UTC -before- calling
d->getLocal(), so getLocal() will --always-- convert that value to
"Local", even if it was "Local" or "LocalUnknown" before getLocal() was
called. See "oldSpec" in QDateTime::setTime_t(). This is exactly what
I'm seeing!!
SO...... I believe that is the source of the problem. Moving this line:
d->spec = QDateTimePrivate::UTC;
in QDateTime::setTime_t() to --AFTER-- the "if" block would make it work
correctly. Callers of setTime_t() would have to ensure they set their
QDateTime object's "spec" value correctly before the call, but maybe the
default is correct for all cases. Of course, someone has to run a full
set of testcases and regression tests to make sure it doesn't mess up all
the other cases. :)
So, please look over the bits I've pointed out and let me know if I've
misanalysed something. I will post all of the above as a Bug at Trolltech
unless someone shows me an error I've made. :)
Thanks!
Mike
--
[ signature omitted ]
Message 8 in thread
I thought about this some more before bed last night. I think my analysis
was good, but my solution was incorrect: it could have had far too wide an
effect. So I've come up with TWO solutions, one general and one very
specific to this case.
QDateTime::setTime_t() is storing a passed-in value in the QDateTime
object. HOWEVER, it saves and later uses the -previous- spec (UTC vs
Local) of the QDateTime object to modify the passed in NEW value. WHY
does it care what (if anything) was formerly stored in this QDateTime
object?? The ONLY thing it's being asked to do is STORE the NEW value;
there is no relationship between the OLD and NEW values! The OLD value
and its spec are utterly irrelevant.
So unless there's a deeper reason it's setup that way, I believe that
QDateTime::setTime_t() should be modified by:
1) removing the first line that declares and sets "oldSpec", and
2) removing the final "if" block completely (two lines).
With those mods, setTime_t() will properly store a NEW date, time, and
"spec" in the QDateTime object without caring about any former value.
With those mods, setTime_t() becomes just a very specific constructor, so
maybe the function is correct but is being misused by QSslCertificate???
If QDateTime::setTime_t() has to be left "as-is" for other reasons, then
QSslCertificatePrivate::QSslCertificate_from_X509() (which KNOWS these
values are UTC because it pulls them from a certificate that always
contains UTC) must be modified to initialize the "NotBefore" and
"NotAfter" QDateTime objects to indicate "UTC" -before- calling
QDateTime::setTime_t().
So an alternate solution (much more specific to this single case) is to
modify QSslCertificatePrivate::QSslCertificate_from_X509() by inserting
these two lines:
certificate.d->notValidBefore.setTimeSpec(Qt::UTC);
certificate.d->notValidAfter.setTimeSpec(Qt::UTC);
immediately before these lines:
certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
certificate.d->notValidAfter.setTime_t(q_getTimeFromASN1(naft));
This ensures that QDateTime::setTime_t() will see "oldSpec" as UTC and
will not attempt to convert the value from LocalTime (which it is not) to
UTC.
If you see any flaws in this reasoning, or have suggestions/preferences
for the proposed solutions above, please let me know. I'm getting dizzy
trying to keep this straight in my head! :) I will submit the bug report
sometime this afternoon (GMT-5).
Mike
On Thu, 18 Oct 2007 17:13:09 -0500, Mike Broida
<michaelb@xxxxxxxxxxxxxxxx> wrote:
> I believe I've found the true source of this problem.
> Here's my analysis:
>
> In QSslCertificatePrivate::QSslCertificate_from_X509(X509 *x509), look
> for this line:
> certificate.d->notValidBefore.setTime_t(q_getTimeFromASN1(nbef));
> Dimitri, that's in the block you pointed me to before. :)
>
> At that point, nbef is a correct UTC value taken from the cert file.
> Passing nbef into q_getTimeFromASN1(const ASN1_TIME *aTime), that
> function recognizes it as UTC (aTime->type == V_ASN1_UTCTIME) and sets
> "lSecondsFromUCT" = 0. It then correctly converts the datetime to a
> "tm" structure holding correct sec, min, hour, mday, mon, and year
> values. It calls mktime() to convert it to a "time_t" value
> (#secsSince1Jan1970UTC), subtracts one hour if DaylightSavingsTime is in
> effect, then adds lSecondsFromUCT (set above) to account for timezones.
> It returns this end value, which I believe is fully correct. No problem
> to this point. :)
>
> That value is passed into QDateTime::setTime_t(uint). This QDateTime
> object is the "notValidBefore" part of the QSslCertificatePrivate object
> ("d") inside the QSslCertificate object. When it was created, the
> "spec" item was set (or defaulted) to "LocalUnknown" and has not been
> changed.
>
> setTime_t() saves that d->spec (which says "LocalUnknown") into local
> variable "oldSpec", then converts the date and time into absolute QDate
> and QTime values inside the QDateTimePrivate object. It then forces
> d->spec to indicate "UTC". If "oldSpec" is not "UTC", this function
> calls d->getLocal(QDate&, QTime&).
>
> Let's look inside QDateTimePrivate::getLocal(QDate&, QTime&). This
> function sets the output QDate and QTime to the QDateTimePrivate
> object's values. If the QDateTimePrivate's "spec" (d->spec to caller)
> is UTC, it calls "utcToLocal(QDate&, QTime&)" to convert to Local. That
> function works correctly.
>
> HOWEVER: setTime_t() --always-- sets d->spec to UTC -before- calling
> d->getLocal(), so getLocal() will --always-- convert that value to
> "Local", even if it was "Local" or "LocalUnknown" before getLocal() was
> called. See "oldSpec" in QDateTime::setTime_t(). This is exactly what
> I'm seeing!!
>
> SO...... I believe that is the source of the problem. Moving this line:
> d->spec = QDateTimePrivate::UTC;
> in QDateTime::setTime_t() to --AFTER-- the "if" block would make it work
> correctly. Callers of setTime_t() would have to ensure they set their
> QDateTime object's "spec" value correctly before the call, but maybe the
> default is correct for all cases. Of course, someone has to run a full
> set of testcases and regression tests to make sure it doesn't mess up
> all the other cases. :)
>
> So, please look over the bits I've pointed out and let me know if I've
> misanalysed something. I will post all of the above as a Bug at
> Trolltech unless someone shows me an error I've made. :)
>
> Thanks!
> Mike
--
[ signature omitted ]
Message 9 in thread
Hi,
> If you see any flaws in this reasoning, or have suggestions/preferences
> for the proposed solutions above, please let me know. I'm getting dizzy
> trying to keep this straight in my head! :) I will submit the bug
> report sometime this afternoon (GMT-5).
Yes, please do submit the bug report. It's best to just submit a small,
complete, compilable example that reproduces the problem. If I understand you
correctly, this is a QDateTime bug. If so, the example should involve just
QDateTime, not any QSsl* stuff. Don't bother analyzing the problem in much
detail, the programmer who will fix the bug will have to analyze it again anyway.
--
[ signature omitted ]
Message 10 in thread
I submitted it Friday; got confirmation e-mail today.
It was assigned #184282.
I didn't include an example; those boxes are infuriatingly small and keep
scrolling irrationally. I gave a summary and pointed them to this
thread. I also volunteered to give them more info if/when they ask.
Is there some way I can add info to the bug report?? I've trimmed the
example down considerably and it would isolate the problem right away. I
still used QSslCertificate because that was the easiest way to show that
UTC time is treated as Local then converted to GMT.
Yes, it really looks like QDateTime::setTime_t() is bad. It uses info
about the PRIOR stored value in order to set a NEW value. That's just
silly because the NEW value has nothing to do with the PRIOR value.
Mike
On Sat, 20 Oct 2007 05:06:35 -0500, Dimitri <dimitri@xxxxxxxxxxxxx> wrote:
> Hi,
>
>> If you see any flaws in this reasoning, or have suggestions/preferences
>> for the proposed solutions above, please let me know. I'm getting
>> dizzy trying to keep this straight in my head! :) I will submit the
>> bug report sometime this afternoon (GMT-5).
>
> Yes, please do submit the bug report. It's best to just submit a small,
> complete, compilable example that reproduces the problem. If I
> understand you correctly, this is a QDateTime bug. If so, the example
> should involve just QDateTime, not any QSsl* stuff. Don't bother
> analyzing the problem in much detail, the programmer who will fix the
> bug will have to analyze it again anyway.
>
> --
> Dimitri
--
[ signature omitted ]
