amavisd-new & broken mysql

[pali at cpan.org]

Hi!

On Thursday 13 June 2019 10:51:43 Tom Sommer wrote:
> On 2019-06-13 10:17, pali at cpan.org wrote:
> 
> > For more then 2 years people complain about semi-broken support when
> > amavisd-new use MySQL database as a storage via DBD::mysql driver.
> > 
> > See e.g. this ticket:
> > https://github.com/perl5-dbi/DBD-mysql/issues/78
> > 
> > In past I tried to fix this problem in DBD::mysql, but due to
> > compatibility with legacy DBD::mysql applications, fix had to be
> > reverted.
> 
> To me, it seems better to fix the problem in Amavisd.

This would depend on amavisd developers. I suggested to look how
DBD::MariaDB could be used with amavisd and test if it is working or
not.

I can promise that if you found bug in DBD::MariaDB, I can look at it
and fix it. This was reason for creating DBD::MariaDB, to have
maintained, bug-free and working driver to connecting to the MariaDB and
MySQL databases.

As fixing DBD::mysql did not happen for 2 years, I guess it says about
state of DBD::mysql...

> I think the problem is the usage of untaint() in SQL statements, like this:
> 
>    $conn_h->execute($ins_msg,
>         $partition_tag, $msginfo->mail_id, $msginfo->secret_id,
>         $msginfo->log_id, int($msginfo->rx_time), $time_iso,
>         untaint($sid), c('policy_bank_path'),
> untaint($msginfo->client_addr),
>         0+untaint($msginfo->msg_size),
>         untaint(substr(idn_to_utf8(c('myhostname')),0,255)));
> 
> As far as I can see untaint() forces a string value, which fucks up the
> DBD::mysql driver.

I'm not sure that this is the problem. What we debugged two years ago
was problem with magical scalars which are on output -- not input.

And seems that BIGINT has nothing with magic scalars...

> In this example, $sid becomes a string, but the database-schema and driver
> expects a BIGINT?

In MySQL protocol this is irrelevant. Due to way how MySQL protocol is
designed, all input data from client to server are send as strings.

> But I'm really no expert in Perl, so I'm not 100% sure.
> 
> --
> Tom