microsoft
Prepare for CentOS/RHEL 10 release
Describe the problem you are experiencing. At the moment neither here https://packages.microsoft.com/config/centos/ nor here https://packages.microsoft.com/config/rhel/ (and potentially alma/rocky as well) is present the "10" major version. CentOS Stream 10 was released end of last year, and RHEL 10.0 will be released in May. So early adopters of CentOS/RHEL 10 may need the associated microsoft packages. I know you provide only the infrastructure, you don't maintain the packages themselves, but I think at least the packages root metadata shall be created, and the information that RHEL 10 is around the corner should be passed along to the different Microsoft teams.
Thanks ;)
Thanks, we are aware. RHEL 10 has decided to make some security-focused changes which, while a good thing overall, unfortunately mean that our existing signing key will no longer work by default. So in this case it's not as simple as creating the repos, we have additional work to do defining a new key and coming up with a transition strategy that will work properly with our various cross-distro repos and the various clients that connect to them. This work is in-progress, and we'll create the RHEL 10 repos when we are able.
https://github.com/microsoft/linux-package-repositories/issues/32#issue-1576514574 a couple of years back I suggested to use signing keys on a per rhel release basis, I still think that may be a good idea :)
@Klaas- It's not a bad idea if all repos were scoped to a particular distro version. The difficulty is with our cross-distribution repos like edge or azure-cli, which should theoretically work on any rpm-based linux distro. If those are to work on RHEL 10 clients they will need to be updated to use a RHEL 10-compatible key, which means all existing subscribers / clients will have to be compatible-with / updated to trust that key.
yeah, I don't think you can do both -- keep "old" linuxes happy and "new" ones as well. But at least for all packages under https://packages.microsoft.com/rhel/ you could use distro major version specific keys :)
which azure-cli rpm cross distribution repository are you talking about? the official docs only show distribution specific repos: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?pivots=dnf
In that particular case it looks like they moved to adding the azure-cli packages into the base repos for RHEL >= 8, but it's not the only one.
Red Hat will release RHEL 10 quite soon, between now and their Red Hat Summit starting on 19th of May. On Microsoft side do you have some clearer plan now on how to cope with the signing changes required to support the EL 10 ecosystem with a smooth transition from RHEL 9 ? (by the way, Red Hat hasn't pushed the same changes in Fedora before, so haven't you solved that issue for the Fedora repositories ?)
@Romain-Geissler-1A we will be signing RHEL 10 packages with the https://packages.microsoft.com/keys/microsoft-2025.asc key. For repos that are shared across distributions, like VS Code for example, we be working with those product teams on a case-by-case basis to figure out how they want to handle the transition.
(by the way, Red Hat hasn't pushed the same changes in Fedora before, so haven't you solved that issue for the Fedora repositories ?)
They talked about doing it during the Fedora 38 Beta, but then rolled that change back before release with no further communication as to why. So no, there has never been a Fedora release that did not work properly with our key, up to and including the current Fedora 42.
They talked about doing it during the Fedora 38 Beta, but then rolled that change back before release with no further communication as to why. So no, there has never been a Fedora release that did not work properly with our key, up to and including the current Fedora 42.
It was rolled back because Fedora wanted to give third parties such as Microsoft time to transition their keys, and the user experience of breaking many third party repositories would have been bad. Because pushing such a change takes engineering time, we haven't tried again for the next Fedora releases, but FESCo has actually asked that we re-consider and re-submit this change proposal for Fedora 43, so it'll be coming to Fedora at some point, too.
The same consideration does not apply to RHEL 10. In Fedora, we can take another shot at this transition every 6 months. For RHEL, whatever we do in a .0 release needs to work for the next 10 years, so accepting keys with a SHA-1 self-signature was an absolute non-starter.
If that comes as a surprise to you, I have to say I don't understand why. We told you this was an upcoming problem two years ago, there was time to prepare. Microsoft made this transition for Windows Updates 5 years ago.
I'm a few days late here, but the CentOS / RHEL 10 repos have been created and configuration files have been published for them. Closing.