Обсуждение: 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.
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.
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.
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:
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.
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:
> 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
Вложения
On 5/9/06, Marko Kreen <markokr@gmail.com> wrote:
Right on! SHA2 should fallback the same as AES!
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 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.
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 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.
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? 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. +