[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]

Apologies on the really slow response. Also apologies that I wasn't able
to fill the knowledge gaps sooner.

It seems as if everyone now understand what happened. If anyone needs
anything further from me, please ask.

On 23/11/18 01:44, Faustin Lammler wrote:
>
> Let me check with Otto why this new dependence was added.

From what I can see, it was added as a fix[1][2] for a bug[3].

[1]
https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/b3e8b645c018d49f7889990e4ad27ca12369cc0d
[2]
https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/changelog#L61
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875708


On 22/11/18 21:59, Olaf van der Spek wrote:> On Thu, Nov 22, 2018 at
>
> https://wiki.debian.org/UnattendedUpgrades

Thanks for the suggestion, but as per David's note (in a later message),
my testing confirms his experience. If unattended-upgrades is configured
for security updates only, then the MariaDB update still fails - albeit
not quite so spectacularly.

On one hand, I think it could be legitimately argued that not installing
the update (rather than removing MariaDB) is preferable in most
scenarios. OTOH I'd personally rather know for sure that something is
broken, rather than think everything is great when it isn't... I.e.
thinking you are automatically getting security updates whilst still
running a vulnerable piece of software is far from ideal.

On 23/11/18 04:32, Robie Basak wrote:
> You should use apt pinning to restrict package upgrades to security
> updates only. See what the unattended-upgrades package does for an
> example. Removing apt's visibility of stuff that it already has
> installed on the system is a hack that will lead to the problem you've
> discovered.

Thanks for sharing your opinion Robie, although I would argue that
explicitly installing updates __only__ from a specific repo (or set of
repos - security in this instance) is a desirable and legitimate
configuration. (Even if you consider the way we currently do it as a
"hack").

FWIW, it's not really removing apt's visibility of what is already
installed, it's more removing apt's ability to see what's available from
repos other than those explicitly being queried.

As noted above, unattended-upgrades still has an undesirable end result
- the security update does not occur. I'd be tempted to swap out our
simple solution for the the added complexity of unattended-upgrades if
it could indeed do what we wanted, but it appears that it can't.

Also, as hinted, some of our appliances include third party apt repos
which are relatively untrusted. They are already pinned, both for
security and convenience. They may also contain newer versions which
users will likely not want auto-updated, but at some point may wish to
update interactively.

We block install of additional software from 3rd party repos via pinning
already too (aiming to mitigate potential security risks) but I feel
much more comfortable in completely excluding them from auto security
updates.

Perhaps I'm missing something, but how would pinning to only allow
security updates, resolve a scenario such as this? I.e when a new
dependency (not hosted in security) is a (new) required dependency of a
security update? Wouldn't it at best give the same result as
unattended-upgrades?

> I'm interested for someone to confirm that pinning will solve this
> problem correctly in this particular case. I believe that it will but am
> not certain.

TBH I'm not even clear where to start with configuring pinning to
achieve our ends? I don't understand how pinning could allow you to
install and update all packages like "normal"; whilst also allowing
__only__ security packages (and any new dependencies?!) to be
automatically updated on a schedule?!

Although there's a good chance that I'm completely missing something!
Could you please elaborate a little on how you think it might work?

> I don't know about Debian's policies in adding dependencies to security
> updates. Clearly it is to be avoided, but there might be some situations
> when it is necessary for security purposes.

As Olaf mentioned, I was under the impression that adding new
dependencies to security updates is a contravention of Debian policy.
FWIW, that's why we felt pretty confident of the config we've been using
for the last 10 years.

However, my searching has come up empty and I am unable to confirm
whether or not that is indeed policy. I will follow up a little further,
but if anyone has a reference, please share.

> Therefore, I'm not sure that
> this should be considered a bug at all from mariadb packaging's point of
> view, unless there is some other reason that the dependency addition
> should not have gone in.
> 

Well if it's a contravention of policy, I'm pretty sure that counts as a
bug, right?!

I do agree that there are cases where adding a new dependency to a
security update may be legitimate. But I would argue in those cases,
adding the new dependency to the security repo as well is the right way
to do it (then both our config and unattended-updates would still work
as expected).

Regardless, it seems to me that we need clarity on policy to decide
whether this is indeed a bug or not.

My 2c...

-------------- 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/20181203/5b75f52f/attachment.sig>