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
This fixes the problem associated with not being able to
install the bundled certificates.
It also ensures that the plugins get installed into an
appropriate directory.
Note that this does not fix problems associated with
not finding the system certificate stores.
svn path=/trunk/kdesupport/qca/; revision=593549
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
for (int n = 0; ....; ....)
{
....
int n = ....;
....
}
with Visual C++ (2005), or you get redefinition errors.
svn path=/trunk/kdesupport/qca/; revision=545218
Also update the documentation to indicate the behaviour.
There might be a case for adding a bool argument to matchesHostname()
so that you can test if it matches just the CN, or either CN or
altname.
This function should probably also test IP address (and perhaps also
XMPP) altnames, but I'd like to think about that a bit more first, and
trial it with a real certificate.
CCMAIL: justin@affinix.com
CCBUG: 107604
svn path=/trunk/kdesupport/qca/; revision=540564
alternative names. The change is to take the whole
list of values from the multimap, and join them
together before outputting, rather than just taking
the last entry.
CCBUG: 107604
svn path=/trunk/kdesupport/qca/; revision=540407
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
Syntax (CMS) (which is closely related to PKCS7 /
SMIME) signing/verifying for the "signed message"
type format (as opposed to detached signatures, which
are already supported).
I've already committed the unit tests for this, which
work correctly.
svn path=/trunk/kdesupport/qca/; revision=539592
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
Covers conversion to lower precision value, and
unused code/variable.
I didn't remove the unused function from the botan
part - just noted it.
svn path=/trunk/kdesupport/qca/; revision=535288
C Compiler. IIRC, this covers warnings over
converting 64 bit values to lower precision variables,
hiding variable names, and an unused variable.
svn path=/trunk/kdesupport/qca/; revision=535284
