https://bugzilla.redhat.com/show_bug.cgi?id=1877421
--- Comment #4 from Petr Pisar <ppisar(a)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
}
--
You are receiving this mail because:
You are on the CC list for the bug.