Also integrate the .h contents into the .cpp, to make it
easier to manage and to do the CMake work. The qmake
support has been updated to match.
svn path=/trunk/kdesupport/qca/; revision=594693
Gratutiously delete some whitespace
Add a test to verify that we don't crash on trying to
import files that don't exist.
svn path=/trunk/kdesupport/qca/; revision=594692
Changes:
1. The whole test is now a single file, so it is easier
to update, and to make the CMake integration simpler.
2. The old test certificates have expired. Those are
now used to test certificate expiry, and new certificates
(from http://openvalidation.org) have been added.
3. The old client and server cert tests have been updated
to reflect the updated certificates.
This passes for me on Qt 4.1.4, using qmake/qconf.
svn path=/trunk/kdesupport/qca/; revision=594680
CCMAIL: duncan@kde.org
Now we can compile qca with cmake
Need to fix plugins compile and unitest and other small error.
svn path=/trunk/kdesupport/qca/; revision=591302
Essentially if you had previously used a subclass
of Cipher, Hash or MAC, then you need to change
your code. The change is pretty simple - you
just pass a string name as the first argument.
svn path=/trunk/kdesupport/qca/; revision=576204
side providers.
There is a bit to be done on this, but right now
it demonstrates the problem I'm seeing with the
AES-CMAC example, in that the plugin loader
segfaults.
CCMAIL: justin@affinix.com
svn path=/trunk/kdesupport/qca/; revision=562878
One test covers certificates in DER format.
The other test is intended to demonstrate a problem
that we currently have with altname handling - we only
manage to provide one altname, irrespective of how
many there are.
svn path=/trunk/kdesupport/qca/; revision=540400
with QCA 2. Holger Tasch identified the problem with QCA1,
however it doesn't appear to be a problem with QCA2.
CCMAIL: holger.tasch@gmx.de
CCBUG: 126735
svn path=/trunk/kdesupport/qca/; revision=538936
to put the keys/certs back in. With that, it stops
asserting. Then it just fails to compare the messages.
If you encrypt the same data, with the same certs,
twice, you don't get the same result each time.
So I added the decrypt part, including re-use, and
checked that if you encrypt the same data twice, then
each decrypt produces the same result, and that result
is exactly what you started with. The test now passes.
svn path=/trunk/kdesupport/qca/; revision=529009
Message Syntax SecureMessage.
At the moment, it assert()s in the repeated use
of a SecureMessage. Until that is sorted out, it
can't be added to the full test suite.
svn path=/trunk/kdesupport/qca/; revision=528990
This covers all of 4.3, and the first part of 4.4.
There are a number of failing tests. At this stage
I think they represent problems with QCA or (more
likely) problems with the version of openssl I am
using.
svn path=/trunk/kdesupport/qca/; revision=524340
them into the test framework.
This is a very trivial test, but it already exists and
I wanted to clean up the left-over tests.
svn path=/trunk/kdesupport/qca/; revision=522582
Fix typo error in result for 4.1.6 - not valid, signature
on end entity certificate is invalid.
Also remove suggestion that libgcrypt will one day have
Certificate / CRL handling.
svn path=/trunk/kdesupport/qca/; revision=508539
These tests, and the test suite certificates and CRLs
are from the NIST Public Key Interoperability Test
Suite (PKITS), which is available from
http://csrc.nist.gov/pki/testing/x509paths.html
At the moment, this unit test only covers the 6
tests in 4.1 of the NIST test documentation.
svn path=/trunk/kdesupport/qca/; revision=508176
