Apparently the core database code still uses "old" ciphers, the same ones
that are being flagged as "deprecated" by Solaris. Oops.
On Mon, Feb 11, 2019 at 1:24 AM Jose Rodriguez <jrodriguez2@xxxxxxxxxxx>
I would consider relinking the Oracle binaries after a Solaris upgrade. It
was in some MOS note some time ago, not sure if it still applies or what
the outcome may be.
Just try it first in a non prod environment ;)
[image: Pythian] <http://www.pythian.com/>
*Jose Rodriguez* | Oracle Project Engineer | [image: LinkedIn]
*t* +1 613 565 8696 <+1+613+565+8696> *ext.* 1393
*m* +34 607 55 49 91 <+34+607+55+49+91>
[image: Pythian] <https://www.pythian.com/email-footer-click>
On Fri, 8 Feb 2019 at 23:08, Charles Schultz <sacrophyte@xxxxxxxxx> wrote:
Good day, Listers,
After applying Solaris patch 11.4 to our oracle database servers, we are
now flooded with a stream of warnings in the console log about deprecated
We have opened several SRs, which have come to naught so far.
On our own, we have discovered that the warning message is from new
crypto libraries installed by the Solaris patch (/usr/lib/libucrypto.so.1).
We have noticed that the crypto libraries are linked to many oracle
binaries. So it stands to reason that something in the oracle binaries is
calling the deprecated cipher (aes-ecb). But so far, we have not yet
figured out where it exactly comes from.
I am sure there are many ways to reproduce the problem, but one sure way
we have found is this:
sqlplus / as sysdba
select count(*) From dba_data_files;
After a little bit of trial and error, it seems like this select will
also do it:
select count(*) from sys.x$ktfbhc;
We only see a corresponding warning in the console log the first time
this query runs for each session.
We are trying to diagnose with dtrace, but so far have not hit upon any
obvious clues (still trying).
We have tried this on OSEE 188.8.131.52, 184.108.40.206 and 220.127.116.11