[SRU] etcd FTBFS on Focal

[Eduardo Barretto]

[Impact]

etcd version 3.2.26+dfsg-5 had its dependency on golang-github-prometheus-client-golang-dev updated to (>= 1.0.0~) but during Focal development cycle golang-github-prometheus-client-golang-dev >= 1.0.0 never got out of -proposed, staying on version 0.9.2-0ubuntu3. This makes etcd FTBFS.

etcd usually get CVEs assigned and even though it is a Universe package, it might be that it receives a critical CVE that the Ubuntu Security Team needs to patch, and currently it is not possible to patch it.

To fix this is basically revert what was done in version 3.2.26+dfsg-5, the attached debdiff shows the needed changes.

Even though this is a fairly simple fix, we are not so sure on its affect, as this could cause regressions. That's why I'm creating this SRU, so we get more people to take a look at it.

[Test Plan]

On Ubuntu 20.04:

$ sudo apt-get build-dep etcd
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:etcd : Depends: golang-github-prometheus-client-golang-dev (>= 1.0.0~) but 0.9.2-0ubuntu3 is to be installed
E: Unable to correct problems, you have held broken packages.

We should be able to get etcd source and build-dep and then run debuild to build it.

[Where problems could occur]

With the proposed change, the etcd test suite is still passing and we can upgrade or downgrade the package through apt. But by downgrading the build-dependency we could be adding regressions and ABI incompatibility.

[Other Info]

This only affects Focal.

[Marc Deslauriers (mdeslaur)]

The debdiff in comment #1 looks reasonable, uploaded for processing by the SRU team. Thanks!

[Chris Halse Rogers (raof)]

This seems like a reasonable change, but I am worried about potential API incompatibility - etcd 3.2.26+dfsg-6 has been in 20.04 for 2 years now, so there'll be plenty of users, some of which will almost certainly have explored every possible strange edge case.

This is still a reasonable SRU - we don't want users to have to notice any incompatibility at the same time as they need to deploy a critical security fix. We should do some deliberate testing for API compatibility, though. What can be done there?

[Eduardo Barretto (ebarretto)]

The test suite is passing fine.
If I compare binaries of current version and with debdiff applied I get the following attached files.
Other than that I am not too familiar with the package to extensively test all API

[Chris Halse Rogers (raof)]

Is there anyone (maybe on the Server team) who has experience with etcd? This still looks like a worthwhile SRU, but I'm hesitant to do it without a plan for testing.

[Eduardo Barretto (ebarretto)]

We asked around the server team, and no one over there has any experience with etcd either.
What should we do next?

[Eduardo Barretto (ebarretto)]

We (Security Team) had a discussion today about this issue and we would like to know if the SRU will proceed and if we can get more eyes on this.

If it doesn't, we still see ourselves in a position where we will need to fix this in the security pocket so we are able to patch vulnerabilities in this package.

[Robie Basak (racb)]

IIUC, SRU team members are reluctant to risk regressing this package today in order to fix the FTBFS now. And the security team are reluctant to leave it as-is because that makes a potential future security update difficult, and are wondering about risking that same regression in the security pocket instead.

But it strikes me that these two considerations don't directly oppose one another. What if we (SRU team) accept this into the proposed pocket today, and then stage it there without releasing it?

A future security update would then be easy, and at that stage the regression risk would be justified by the need for it.

In the meantime, users will have plenty of "notice" to alert us about regressions in advance. If they don't, and get a regression at the time of the security update anyway, then it doesn't really change the risk to them since the security update would have required us to take the risk anyway.

One catch: users may prefer to take the risk now, rather than at the time of the security update, since then if it goes wrong then they can revert without also being security-exposed by doing so.

But anyway, maybe worth considering? Or maybe the catch is significant and so we should take the risk now?

If the security team decide they want to release all the way to the security+update pockets right now for security reasons, then we should let them take the lead and make decisions on this but push it through the SRU process for better visibility. So if you choose to do that, please fully review to the extent you think appropriate, and then give your security +1 to accept this into -proposed (and later into -updates if you want), and I'll just do that wearing my SRU hat but without any further consideration or review. I say this because you (very appropriately) have the decision making power and authority to push this into the security pocket anyway, but in this case doing it through proposed/updates would probably be better for everyone.

[Eduardo Barretto (ebarretto)]

We just published a new version of etcd for Focal with the FTBFS fix + 4 CVEs as we were in the hook for those.
I'm setting this ticket as "Won't Fix", feel free to adjust it if you think otherwise.

[Robie Basak (racb)]

Thank you for the update!

OK, so the security update makes this SRU moot. Maybe Fix Released, since it no longer FTBFS? I'll also reject the SRU upload as that doesn't make sense to have any more.

[Robie Basak (racb)]

An upload of etcd to focal-proposed has been rejected from the upload queue for the following reason: "Superseded and fixed by security update. See LP: #1959757".