pgcrypto sha256/384/512 don't work on Redhat. Please help!
Hello,
Pgcrypto SHA 256/384/512 algorithm don't work on RedHat:
db=# SELECT digest('test', 'sha1');
digest
----------------------------------------------------------------------
\251J\217\345\314\261\233\246\034L\010s\323\221\351\207\230/\273\323
(1 row)
db=# SELECT digest('test', 'sha256');
ERROR: Cannot use "sha256": No such hash algorithm
I have standard Fedora Core 4 installed with standard PostgreSQL 8.1.3
Pgcrypto documentation says that it has built-in SHA256 and it should work
when OpenSSL is not found:
==============
Without OpenSSL, public-key encryption does not work, as pgcrypto does
not yet contain math functions for large integers.
Functionality built-in OpenSSL
----------------------------------------------------
MD5 yes yes
SHA1 yes yes
SHA256/384/512 yes since 0.9.8
=================
Fedora core has OpenSSL 0.9.7 installed by default. And it's not possible to
install 0.9.8 because of glibc conflict.
I suspect pgcrypto looks for SHA256 in OpeSSL lib when it should use
built-in.
SHA256 is working fine on Windows but on Redhat it fails. Maybe because
windows pgcrypto DLL is compiled statically with OpenSSL?
How to make pgcrypto use built-in sha256?
Thanks.
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
Fedora core has OpenSSL 0.9.7 installed by default. And it's not possible to
install 0.9.8 because of glibc conflict.I suspect pgcrypto looks for SHA256 in OpeSSL lib when it should use
built-in.
SHA256 is working fine on Windows but on Redhat it fails. Maybe because
windows pgcrypto DLL is compiled statically with OpenSSL?
OpenSSL vs. builtin is a compile-time decision, so the builtin code
cannot be fallback at runtime.
Windows code is using either builtin code or newer OpenSSL.
How to make pgcrypto use built-in sha256?
You need to recompile PostgreSQL. Don't try to use non-OpenSSL
pgcrypto with OpenSSL PostgreSQL, it will crash due to symbol
conflict.
Another variant is to try to compile separate OpenSSL 0.9.8 and
compile PostgreSQL against that. So you don't need to upgrade
system OpenSSL.
--
marko
Thanks, but I need it to work out-of-the-box, with standard installation of
RedHat or Gentoo and standard PostgreSQL rpm.
I am developing application with PortgreSQL and I can't tell customer to
"Recompile PostgreSQL and see if it works then try to use non-openssl
pgcrypto or try to compile openSSL 0.9.8."
Pgcrypto depends on OpenSSL 0.9.8. And 0.9.8 is not "Stable" in RedHat and
Gentoo. So you need to recompile pgcrypto/openssl anyway if you want to use
it. Can I report this in PostgreSQL bug system?
Regards.
Show quoted text
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
Fedora core has OpenSSL 0.9.7 installed by default. And it's not
possible to
install 0.9.8 because of glibc conflict.
I suspect pgcrypto looks for SHA256 in OpeSSL lib when it should use
built-in.
SHA256 is working fine on Windows but on Redhat it fails. Maybe because
windows pgcrypto DLL is compiled statically with OpenSSL?OpenSSL vs. builtin is a compile-time decision, so the builtin code
cannot be fallback at runtime.Windows code is using either builtin code or newer OpenSSL.
How to make pgcrypto use built-in sha256?
You need to recompile PostgreSQL. Don't try to use non-OpenSSL
pgcrypto with OpenSSL PostgreSQL, it will crash due to symbol
conflict.Another variant is to try to compile separate OpenSSL 0.9.8 and
compile PostgreSQL against that. So you don't need to upgrade
system OpenSSL.--
marko
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
Thanks, but I need it to work out-of-the-box, with standard installation of
RedHat or Gentoo and standard PostgreSQL rpm.I am developing application with PortgreSQL and I can't tell customer to
"Recompile PostgreSQL and see if it works then try to use non-openssl
pgcrypto or try to compile openSSL 0.9.8."Pgcrypto depends on OpenSSL 0.9.8. And 0.9.8 is not "Stable" in RedHat and
Gentoo. So you need to recompile pgcrypto/openssl anyway if you want to use
it. Can I report this in PostgreSQL bug system?
What bug are you refering to? Only bug that I can see is the
symbol-conflict problem, but as 8.1 pgcrypto uses always same
setting as core postgres, it should not be a big deal.
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.
OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?
--
marko
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
Thanks, but I need it to work out-of-the-box, with standard installation
of
RedHat or Gentoo and standard PostgreSQL rpm.
I am developing application with PortgreSQL and I can't tell customer
to
"Recompile PostgreSQL and see if it works then try to use non-openssl
pgcrypto or try to compile openSSL 0.9.8."Pgcrypto depends on OpenSSL 0.9.8. And 0.9.8 is not "Stable" in RedHat
and
Gentoo. So you need to recompile pgcrypto/openssl anyway if you want to
use
it. Can I report this in PostgreSQL bug system?
What bug are you refering to? Only bug that I can see is the
symbol-conflict problem, but as 8.1 pgcrypto uses always same
setting as core postgres, it should not be a big deal.The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.
It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto or install
openssl 0.9.8 which is considered as "unstable" by most distros.
Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.
OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?
Ideally, would be great if pgcrypto could fallback to built-in algorithm of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto would be
great.
Thanks a lot!
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto or install
openssl 0.9.8 which is considered as "unstable" by most distros.Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.
To be honest, pgcrypto actually falls back on built-in code for AES,
in case old OpenSSL that does not have AES. Thats because AES
should be "always there", together with md5/sha1/blowfish.
I do not consider SHA2 that important (yet?), so they don't
get same treatment.
OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?Ideally, would be great if pgcrypto could fallback to built-in algorithm of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto would be
great.
Attached is a patch that re-defines SHA2 symbols so that they would not
conflict with OpenSSL.
Now that I think about it, if your OpenSSL does not contain SHA2, then
there should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing. So I think its best to always apply this patch.
I think I'll send the patch to 8.2 later, not sure if it's important
enough for 8.1.
--
marko
Attachments:
sha2.conflict.difftext/x-patch; charset=us-ascii; name=sha2.conflict.diffDownload+26-16
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto orinstall
openssl 0.9.8 which is considered as "unstable" by most distros.
Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.To be honest, pgcrypto actually falls back on built-in code for AES,
in case old OpenSSL that does not have AES. Thats because AES
should be "always there", together with md5/sha1/blowfish.I do not consider SHA2 that important (yet?), so they don't
get same treatment.
Right on! SHA2 should fallback the same as AES!
Ideally, would be great if pgcrypto could fallback to built-in algorithm
of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto wouldbe
great.
Attached is a patch that re-defines SHA2 symbols so that they would not
conflict with OpenSSL.Now that I think about it, if your OpenSSL does not contain SHA2, then
there should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing. So I think its best to always apply this patch.
That was my thought too. Old OpenSSL doesn't have SHA2 so why SHA2 is still
blocked in pgcrypto? Is that by design or bug?
Thanks.
On Tue, May 09, 2006 at 22:17:21 +0300,
Joe Kramer <cckramer@gmail.com> wrote:
Right on! SHA2 should fallback the same as AES!
Note that it's SHA256, not SHA2.
SHA-1 is really a fix of the original SHA (sometimes referred to as SHA-0).
On 5/10/06, Bruno Wolff III <bruno@wolff.to> wrote:
On Tue, May 09, 2006 at 22:17:21 +0300,
Joe Kramer <cckramer@gmail.com> wrote:Right on! SHA2 should fallback the same as AES!
Note that it's SHA256, not SHA2.
It's SHA224/256/384/512, which together are more easily referred as SHA2.
SHA-1 is really a fix of the original SHA (sometimes referred to as SHA-0).
--
marko
Patch applied to CVS HEAD and 8.1.X. Thanks.
---------------------------------------------------------------------------
Marko Kreen wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto or install
openssl 0.9.8 which is considered as "unstable" by most distros.Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.To be honest, pgcrypto actually falls back on built-in code for AES,
in case old OpenSSL that does not have AES. Thats because AES
should be "always there", together with md5/sha1/blowfish.I do not consider SHA2 that important (yet?), so they don't
get same treatment.OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?Ideally, would be great if pgcrypto could fallback to built-in algorithm of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto would be
great.Attached is a patch that re-defines SHA2 symbols so that they would not
conflict with OpenSSL.Now that I think about it, if your OpenSSL does not contain SHA2, then
there should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing. So I think its best to always apply this patch.I think I'll send the patch to 8.2 later, not sure if it's important
enough for 8.1.--
marko
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
If it was commited to HEAD, it will appear in 8.1.5, right?
Show quoted text
On 5/30/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
Patch applied to CVS HEAD and 8.1.X. Thanks.
---------------------------------------------------------------------------
Marko Kreen wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto or install
openssl 0.9.8 which is considered as "unstable" by most distros.Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.To be honest, pgcrypto actually falls back on built-in code for AES,
in case old OpenSSL that does not have AES. Thats because AES
should be "always there", together with md5/sha1/blowfish.I do not consider SHA2 that important (yet?), so they don't
get same treatment.OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?Ideally, would be great if pgcrypto could fallback to built-in algorithm of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto would be
great.Attached is a patch that re-defines SHA2 symbols so that they would not
conflict with OpenSSL.Now that I think about it, if your OpenSSL does not contain SHA2, then
there should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing. So I think its best to always apply this patch.I think I'll send the patch to 8.2 later, not sure if it's important
enough for 8.1.--
marko[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
HEAD only appears in 8.2, but 8.1.X means it will appear in 8.1.5.
---------------------------------------------------------------------------
Joe Kramer wrote:
If it was commited to HEAD, it will appear in 8.1.5, right?
On 5/30/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote:
Patch applied to CVS HEAD and 8.1.X. Thanks.
---------------------------------------------------------------------------
Marko Kreen wrote:
On 5/9/06, Joe Kramer <cckramer@gmail.com> wrote:
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
The fact that Fedora pgcrypto is linked with OpenSSL that does not
support SHA256 is not a bug, just a fact.It's not Fedora only, same problem with Gentoo/portage.
I think it's problem for all distros. You need recompile pgcrypto or install
openssl 0.9.8 which is considered as "unstable" by most distros.Maybe pgcrypto should use built-in algorithms until OpenSSL 0.9.8 is
mainstream/default install.To be honest, pgcrypto actually falls back on built-in code for AES,
in case old OpenSSL that does not have AES. Thats because AES
should be "always there", together with md5/sha1/blowfish.I do not consider SHA2 that important (yet?), so they don't
get same treatment.OTOH, the nicest solution to your problem would be self-compiled
pgcrypto, that would work with stock PostgreSQL. As the conflict
happens with only (new) SHA2 functions, I can prepare a patch for
symbol conflict, would that be satisfactory for you?Ideally, would be great if pgcrypto could fallback to built-in algorithm of
OpenSSL don't support it.
But since it's compile switch, completely seld-compiled pgcrypto would be
great.Attached is a patch that re-defines SHA2 symbols so that they would not
conflict with OpenSSL.Now that I think about it, if your OpenSSL does not contain SHA2, then
there should be no conflict. But ofcourse, if someone upgrades OpenSSL,
server starts crashing. So I think its best to always apply this patch.I think I'll send the patch to 8.2 later, not sure if it's important
enough for 8.1.--
marko[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +