Re: 4 pgcrypto regressions failures - 1 unsolved
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2005-07-11%2002:30:00>
NetBSD 1.6 with older OpenSSL. OpenSSL < 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
And the AES tests fails anyway. I guess it can stay as expected
failure.
Please try to avoid expected failures if possible. If you must have them,
move them into a test file of their own. Consider the possibility of using
alternative .out files.
This doesn't matter to Buildfarm quite so much for contrib as it does for
main or PL regression sets, as contrib is the last thing checked, so a
failure there doesn't block any other steps in the checking process. Still,
a contrib failure will show up as yellow rather than green.
Buildfarm does not currently have a way of knowing what failure is expected
and what is not - it currently treats any regression failure as unexpected.
Changing that is on my TODO list, but it's not going to happen any time soon.
cheers
andrew
Import Notes
Reply to msg id not found: 20050711105421.GA11824@l-t.eeReference msg id not found: 20050711105421.GA11824@l-t.ee
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2005-07-11%2002:30:00>NetBSD 1.6 with older OpenSSL. OpenSSL < 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
And the AES tests fails anyway. I guess it can stay as expected
failure.Please try to avoid expected failures if possible. If you must have them,
move them into a test file of their own. Consider the possibility of using
alternative .out files.
I need either to use included rijndael.c for AES with older
OpenSSL or rerun all tests to be Blowfish-only.
I want to standardise on AES so the former is preferred.
Now there's a choice:
1. Check OpenSSL version in main configure
2. #include "rijndael.c" in openssl.c
I guess 1. is nicer. I try to hack something together.
--
marko
On Mon, Jul 11, 2005 at 02:59:54PM +0300, Marko Kreen wrote:
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=2005-07-11%2002:30:00>NetBSD 1.6 with older OpenSSL. OpenSSL < 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
And the AES tests fails anyway. I guess it can stay as expected
failure.Please try to avoid expected failures if possible. If you must have them,
move them into a test file of their own. Consider the possibility of using
alternative .out files.I need either to use included rijndael.c for AES with older
OpenSSL or rerun all tests to be Blowfish-only.I want to standardise on AES so the former is preferred.
Now there's a choice:
1. Check OpenSSL version in main configure
2. #include "rijndael.c" in openssl.cI guess 1. is nicer. I try to hack something together.
I tried 1. but that was messing with main build system for no
good reason. As the openssl.c would still be mess, so I went
with 2.
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.
--
marko
Attachments:
aes-support.difftext/plain; charset=us-asciiDownload
Index: contrib/pgcrypto/openssl.c
===================================================================
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.22
diff -u -c -r1.22 openssl.c
*** contrib/pgcrypto/openssl.c 10 Jul 2005 13:54:34 -0000 1.22
--- contrib/pgcrypto/openssl.c 11 Jul 2005 13:02:00 -0000
***************
*** 44,53 ****
/*
* Does OpenSSL support AES?
*/
- #undef GOT_AES
#if OPENSSL_VERSION_NUMBER >= 0x00907000L
! #define GOT_AES
#include <openssl/aes.h>
#endif
/*
--- 44,89 ----
/*
* Does OpenSSL support AES?
*/
#if OPENSSL_VERSION_NUMBER >= 0x00907000L
!
! /* Yes, it does. */
#include <openssl/aes.h>
+
+ #else
+
+ /*
+ * No, it does not. So use included rijndael code to emulate it.
+ */
+ #include "rijndael.c"
+
+ #define AES_ENCRYPT 1
+ #define AES_DECRYPT 0
+ #define AES_KEY rijndael_ctx
+
+ #define AES_set_encrypt_key(key, kbits, ctx) \
+ aes_set_key((ctx), (key), (kbits), 1)
+
+ #define AES_set_decrypt_key(key, kbits, ctx) \
+ aes_set_key((ctx), (key), (kbits), 0)
+
+ #define AES_ecb_encrypt(src, dst, ctx, enc) \
+ do { \
+ memcpy((dst), (src), 16); \
+ if (enc) \
+ aes_ecb_encrypt((ctx), (dst), 16); \
+ else \
+ aes_ecb_decrypt((ctx), (dst), 16); \
+ } while (0)
+
+ #define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
+ do { \
+ memcpy((dst), (src), (len)); \
+ if (enc) \
+ aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
+ else \
+ aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+ } while (0)
+
#endif
/*
***************
*** 205,213 ****
DES_key_schedule k1, k2, k3;
} des3;
CAST_KEY cast_key;
- #ifdef GOT_AES
AES_KEY aes_key;
- #endif
} u;
uint8 key[EVP_MAX_KEY_LENGTH];
uint8 iv[EVP_MAX_IV_LENGTH];
--- 241,247 ----
***************
*** 549,556 ****
/* AES */
- #ifdef GOT_AES
-
static int
ossl_aes_init(PX_Cipher * c, const uint8 *key, unsigned klen, const uint8 *iv)
{
--- 583,588 ----
***************
*** 642,648 ****
AES_cbc_encrypt(data, res, dlen, &od->u.aes_key, od->iv, AES_DECRYPT);
return 0;
}
- #endif
/*
* aliases
--- 674,679 ----
***************
*** 711,717 ****
64 / 8, 128 / 8, 0
};
- #ifdef GOT_AES
static const struct ossl_cipher ossl_aes_ecb = {
ossl_aes_init, ossl_aes_ecb_encrypt, ossl_aes_ecb_decrypt,
128 / 8, 256 / 8, 0
--- 742,747 ----
***************
*** 721,727 ****
ossl_aes_init, ossl_aes_cbc_encrypt, ossl_aes_cbc_decrypt,
128 / 8, 256 / 8, 0
};
- #endif
/*
* Special handlers
--- 751,756 ----
***************
*** 742,751 ****
{"des3-cbc", &ossl_des3_cbc},
{"cast5-ecb", &ossl_cast_ecb},
{"cast5-cbc", &ossl_cast_cbc},
- #ifdef GOT_AES
{"aes-ecb", &ossl_aes_ecb},
{"aes-cbc", &ossl_aes_cbc},
- #endif
{NULL}
};
--- 771,778 ----
Marko Kreen <marko@l-t.ee> writes:
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.
Looks good, but I'm still getting these compile warnings:
openssl.c: In function `ossl_des3_ecb_encrypt':
openssl.c:484: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c: In function `ossl_des3_ecb_decrypt':
openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
The following addition to the patch shuts up gcc with openssl 0.9.7a,
but I'm not sure if it will break anything with older openssl ---
comments?
regards, tom lane
*** /home/postgres/pgsql/contrib/pgcrypto/openssl.c Sun Jul 10 12:35:38 2005
--- new/openssl.c Mon Jul 11 10:06:30 2005
***************
*** 446,452 ****
ossldata *od = c->ptr; for (i = 0; i < dlen / bs; i++)
! DES_ecb3_encrypt(data + i * bs, res + i * bs,
&od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 1);
return 0;
}
--- 480,487 ----
ossldata *od = c->ptr; for (i = 0; i < dlen / bs; i++)
! DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
! (DES_cblock *) (res + i * bs),
&od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 1);
return 0;
}
***************
*** 460,466 ****
ossldata *od = c->ptr;
for (i = 0; i < dlen / bs; i++)
! DES_ecb3_encrypt(data + i * bs, res + i * bs,
&od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 0);
return 0;
}
--- 495,502 ----
ossldata *od = c->ptr; for (i = 0; i < dlen / bs; i++)
! DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
! (DES_cblock *) (res + i * bs),
&od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 0);
return 0;
}
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
Marko Kreen <marko@l-t.ee> writes:
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.Looks good, but I'm still getting these compile warnings:
openssl.c: In function `ossl_des3_ecb_encrypt':
openssl.c:484: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c: In function `ossl_des3_ecb_decrypt':
openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer typeThe following addition to the patch shuts up gcc with openssl 0.9.7a,
but I'm not sure if it will break anything with older openssl ---
comments?
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:
void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);
so it seems to me that with your patch the warnings will appear
on newer OpenSSL. (Confirmed)
--
marko
Marko Kreen <marko@l-t.ee> writes:
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
The following addition to the patch shuts up gcc with openssl 0.9.7a,
but I'm not sure if it will break anything with older openssl ---
comments?
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:
void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);
so it seems to me that with your patch the warnings will appear
on newer OpenSSL. (Confirmed)
Grumble --- you're right. It's probably not worth ifdef'ing the code to
suppress the warnings on 0.9.7a ...
regards, tom lane
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
Marko Kreen <marko@l-t.ee> writes:
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);so it seems to me that with your patch the warnings will appear
on newer OpenSSL. (Confirmed)Grumble --- you're right. It's probably not worth ifdef'ing the code to
suppress the warnings on 0.9.7a ...
Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:
void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
On Mon, Jul 11, 2005 at 09:19:37AM -0600, Michael Fuhr wrote:
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
Marko Kreen <marko@l-t.ee> writes:
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);so it seems to me that with your patch the warnings will appear
on newer OpenSSL. (Confirmed)Grumble --- you're right. It's probably not worth ifdef'ing the code to
suppress the warnings on 0.9.7a ...Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:
void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
DES_key_schedule *ks1,DES_key_schedule *ks2,
DES_key_schedule *ks3, int enc);
Ugh. As I see the old signature goes up to 0.9.7d, and only
0.9.7[e,f,g] have the new signature.
0.9.7e is released on Oct 2004. There is a chance that the 0.9.8 serie
was branched before that and later 0.9.8x releases will also
change signature. Or the change was mistake, and it was
reversed in 0.9.8 - but then why release 0.9.7[f,g] with new
signature?
When I saw that only 0.9.7[efg] have new signature I even
considered macrofying that. But now with 0.9.8 again different
I really would like to not to touch it, as I have no idea which
one will be the stable signature.
Comments?
--
marko
On Mon, Jul 11, 2005 at 06:41:35PM +0300, Marko Kreen wrote:
When I saw that only 0.9.7[efg] have new signature I even
considered macrofying that. But now with 0.9.8 again different
I really would like to not to touch it, as I have no idea which
one will be the stable signature.Comments?
Sounds like a question for the OpenSSL developers. If a search
through their list archives or CVS repository doesn't yield the
answer, then maybe asking the question on one of their lists will.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/