I have discovered either a bug in pgcrypto (postgresql-9.0.1) or at least a=
n implementation change that is incompatible with how I've been using pgcry=
pto. I'm hoping a discussion here on bugs@ is an appropriate first course o=
f discussion.
I have a couple of databases in which I have been using pgcrypto for about =
10 years (one relation has > 1.8 million records). I believe I started usin=
g pgcrypto with postgresql-7.2.x and have had absolutely no adverse issues =
with my data during regular upgrades through postgresql-8.4.5. I know that =
the raw encrypt() and decrypt() are no longer recommended when the pgp_*() =
can be used, but this is now a legacy issue since the pgp_*() functions did=
not even exist 10 years ago. Please note that the pgp_*() functions do wor=
k fine in postgresql-9.0.1.
During testing of upgrade to 9.0.1 (I _love_ streaming replication!), my en=
crypted data gets mangled during import (psql -f <file_dumped_with_pg_dump>=
) and, in fact, I can't even use encrypt() or decrypt() on new data in my "=
usual way". Here's an example that works on 7.2.x through 8.4.5 but not 9.0=
.1 (additional platform details are below):
--
-- Pull in pgcrypto functions:
--
\i /usr/local/pgsql/share/contrib/pgcrypto.sql
--
-- Create a test table:
--
create table cryptest (
id serial not null primary key,
plaint character varying not null,
enct bytea
);
--
-- Insert some data:
--
insert into cryptest (plaint, enct) values
('Testing blowfish...', encrypt('Testing blowfish...',
E'I know this is not a proper key but it _should_ work', 'b=
f'));
--
-- Fetch the data:
--
select
id,
plaint,
decrypt(enct, E'I know this is not a proper key but it _should_ w=
ork', 'bf')
from
cryptest;
Platform:
CentOS-5.5 (fully up to date with 'yum update') both i386 and x86_64
Postgresql configured with './configure --with-openssl'
I'll be happy to provide any additional information necessary and do any so=
rt of testing (if it should prove to be necessary) though my skills in this=
are somewhat limited.
Thanks,
Daniel
