https://bugzilla.redhat.com/show_bug.cgi?id=1877421
--- Comment #4 from Petr Pisar ppisar@redhat.com --- The only place where the deprecation is mentioned is a comment in a header file.
-int dbd_db_login6 _((SV *dbh, imp_dbh_t *imp_dbh, char *dbname, char *uid, char *pwd, SV*attribs)); +int dbd_db_login6 _((SV *dbh, imp_dbh_t *imp_dbh, char *dbname, char *uid, char *pwd, SV*attribs)); /* deprecated */
It's not either a function attribute (so that a compiler could emit a warning), nor noticed in a DBI::DBD documentation. E.g. The closest text regarding dbd_db_login6() reads:
Since DBI post v1.607, if a "dbd_db_login6_sv()" macro is defined (for a function like dbd_db_login6 but with scalar pointers for the dbname, username and password), it will be used instead. This will allow your login6 function to see if there are any Unicode characters in the dbname.
Also I'd like to note that those functions are not provided by DBI. DBI only provides their declarations in dbd_xsh.h to help the DBD drivers to implement them. So technically there is no vulnerability in DBI. It's in the driver that decides to implement the old interface that does not allow the driver to process Unicode characters properly. DBI common layer always prefer the safe functions:
void _login(dbh, dbname, username, password, attribs=Nullsv) SV * dbh SV * dbname SV * username SV * password SV * attribs CODE: { D_imp_dbh(dbh); #if !defined(dbd_db_login6_sv) STRLEN lna; char *u = (SvOK(username)) ? SvPV(username,lna) : (char*)""; char *p = (SvOK(password)) ? SvPV(password,lna) : (char*)""; #endif #ifdef dbd_db_login6_sv ST(0) = dbd_db_login6_sv(dbh, imp_dbh, dbname, username, password, attribs) ? &PL_sv_yes : &PL_sv_no; #elif defined(dbd_db_login6) ST(0) = dbd_db_login6(dbh, imp_dbh, SvPV_nolen(dbname), u, p, attribs) ? &PL_sv_yes : &PL_sv_no; #else PERL_UNUSED_ARG(attribs); ST(0) = dbd_db_login( dbh, imp_dbh, SvPV_nolen(dbname), u, p) ? &PL_sv_yes : &PL_sv_no; #endif }