Switch to new MySQL public key

[potiuk]

MySQL changed key used to sign their apt packages. This caused
docker building failing for prod images as MySQL could not be
installed.

New Public Key is used instead.

Fixes: #20911

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[potiuk]

Note. I will also need to (doing it now) rebuild past released docker images to allow people to extend those (apt-get update fails without the key) (only 2.* images as 1.10 is end-of-life and there is a workaround available - see below).

[potiuk]

Will the DockerHub images be updated with this fix? I'm having issues with dockerhub.docker.artifactory.viasat.com/apache/airflow:1.10.15-python3.6 due to the key change.

Only 2.* images. The 1.10 is already end-of-life as of June 2021 and will not receive any fixes. You can manually apply the workaround mentioned in #20911 - add the apt-key line in your extended image if you are going to use it as migration "bridge":

USER root
RUN sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
RUN apt-get update

[potiuk]

If any committer approves it - please merge it. This is needed to stop PRs/main builds from failing

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.

[jurovee]

Hi @potiuk, can we be assured that these changes will be included in future releases source codes (Dockerfile) here https://github.com/apache/airflow/releases?

Thing is, we are building our custom base images from there and currently it's not possible in 2.2.2/2.2.3 due to this issue as the archives don't seem to be updated. Until then we can use this temporary solution in our extended images (which we are building from custom base images described above):

RUN sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 467B942D3A79BD29

Thanks!

[potiuk]

Hi @potiuk, can we be assured that these changes will be included in future releases source codes (Dockerfile) here https://github.com/apache/airflow/releases?

Yes. They will be. Good point. I just marked it as 2.2.4 release - I am going to cherry-pick some more Docker Image changes to 2.2.4 as there were quite a number of refactorings and improvements there. Rest assured it will be added. I am also thinking actually on how we could protect against similar cases in the future. Not sure if this is possible though (embedding the key id used by 3rd-party is the only way can make sure installing a package is "safe" so I am not sure if we can do it.

[ruben-ortiz-buybay]

One of the side effects of this change, for the previous images, is that some packages versions for MySQL change, from 8.0.27-1debian10 to 8.0.28-1debian10 (mysql-client and libmysqlclient21) In my case, this change on versions ends in an error, connecting to AWS RDS Mysql:

MySQLdb._exceptions.OperationalError: (2026, 'SSL connection error: error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol')

Checking the changelog for version 8.0.28 ( https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html ) includes an important change that can affect legacy systems:

Support for the TLSv1 and TLSv1.1 connection protocols is removed as of MySQL 8.0.28. The protocols were deprecated from MySQL 8.0.26. For background, refer to the IETF memo Deprecating TLSv1.0 and TLSv1.1. Make connections using the more-secure TLSv1.2 and TLSv1.3 protocols. TLSv1.3 requires that both the MySQL Server software and the client application were compiled with OpenSSL 1.1.1 or higher.

A workaround the issue is using docker images by SHA and not by version (and adding the new key if package updates are needed)

[potiuk]

A workaround the issue is using docker images by SHA and not by version (and adding the new key if package updates are needed)

Thanks. However I'd heartily recommend to update your MySQL server is updated to support TLS 1.2.

We've seen a lot of vendors following the recommendation to get rid of TLS1.1 because in modern world it is not secure enough. This is actually a regulatory requirement in many countries to disable TLS1.0 and very strong recommendation to disable TLS1.1 as well..

Pretty much all vendors disabled support bu default for TLS1.2 mid 2020.

BTW. One could argue thta another workaround would be to disable SSL at all because, well, TLS1.1 is not secure and gives false sense of security.