[debian-mysql] Bug#914172: mariadb-server-10.1: mariadb-server sec-update (10.1.37-0+deb9u1) uninstalls default-mysql-server, mysql-server, mariadb-server-10.1 & mariadb-client-10.1

[Jeremy Davis]

Thanks for your input Chris,

On 4/12/18 09:12, Chris Lamb wrote:
> My quick glance at this bug report suggests there is something wrong
> with your APT setup and/or unattended-upgrades. I apologise I was not
> aware of all this context & history until now...

I can't speak for unattended-upgrades, but AFAIU our apt config is
essentially doing what it's designed to do. I.e. only installing updated
packages within the security repo - albeit a little too violently!

> You appear to be overly-preoccupied with persuing whether adding
> dependencies is a "policy" or not but it remains unclear to me what you
> would do with this information either way. I have my own thoughts on
> whether it is a policy, but that is entirely academic.

Sorry if my intention is not clear.

From my perspective, the understanding of whether or not this occurrence
(i.e. new deps in sec updates, not being within the sec repo) is
"legitimate"  is  not academic.

It is the vital piece of info to inform what we do next. Perhaps my
message to the security team (cc this bug) helps?

In case not:

Our current config rests on the assumption that all security updates
(and their dependencies) will be hosted within the security apt repo.
(FWIW, it appears unattended-updates default config also rests on this
assumption).

Judging by this occurrence, this is clearly not always the case. What we
do next with this info depends on whether this is "how it is" (albeit
uncommon) or a mistake.

If we are making an unreasonable assumption , then our apt config needs
to change as a matter of urgency as it is clearly not safe! Further we'd
need to investigate what alternative measures to take. Also, we probably
should file a bug against unattended updates.

If instead, the assumption is reasonable, but a human error has occurred
in this instance, then we would be keen to see how we might support the
security team to avoid this happening again.

> If you could provide a minimal testcase in Debian stretch for your
> issue here, that would be ideal. Alas, downloading and applying some
> custom configuration to a Turnkey appliance VM might be a request too
> far for someone more-knowledgeable than me who wishing you help you,
> I'm afraid.

Thanks, but it seems clear (to me at least) that we've worked out the
"how" and the "why" we got the result we did. What remains to be
understood is whether the issue is with our config making incorrect
assumptions, or a mistake/bug with this update.

Hope I don't sound like I'm ranting and my position makes more sense
now?! :)

Regards,
Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-mysql-maint/attachments/20181205/85a0cd04/attachment-0001.sig>