Proposed as a Blocker for 43-final by Fedora user decathorpe using the blocker tracking app because:

 The openh264 repository being enabled by default causes package management issues (failing transactions due to inability to download packages that are part of the requested transaction) both on first upgrade after a fresh install, during upgrades to Fedora 43, and likely also during installation of Fedora when using a netinstall image.

I think this is a violation of the "Installing, removing and updating software" final release criterion (https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Installing,_removing_and_updating_software) since this just prevents doing any package management operations in some circumstances.

*** Bug 2397165 has been marked as a duplicate of this bug. ***

I'd rather not disable it everywhere due to (bad, unfortunate, irritating) problems in some regions. 

I've asked dnf folks if there's something we can do to work around this problem there, but it's likely hard as the entire transaction has been resolved at that point. But perhapt they can come up with something. 

I know Jef had been trying to communicate with cisco on possible fixes. I don't know if he has gotten anywhere yet. ;( 
(adding him to cc for comment).

Finally, if we do disable this, we would probibly need to figure out a way to not break upgrades for virtually everyone. ie, those people who do have it installed and try and upgrade to the next version with it disabled. We would need to carefully figure out a way to remove it I guess? I am not convinced we can do this before final freeze, but perhaps I am overthinking it.

(In reply to Kevin Fenzi from comment #3)
> I'd rather not disable it everywhere due to (bad, unfortunate, irritating)
> problems in some regions. 
> 
> I've asked dnf folks if there's something we can do to work around this
> problem there, but it's likely hard as the entire transaction has been
> resolved at that point. But perhapt they can come up with something. 
> 
> I know Jef had been trying to communicate with cisco on possible fixes. I
> don't know if he has gotten anywhere yet. ;( 
> (adding him to cc for comment).
> 
> Finally, if we do disable this, we would probibly need to figure out a way
> to not break upgrades for virtually everyone. ie, those people who do have
> it installed and try and upgrade to the next version with it disabled. We
> would need to carefully figure out a way to remove it I guess? I am not
> convinced we can do this before final freeze, but perhaps I am overthinking
> it.

Hi. Please tell me why such drastic measures are necessary. Why is it necessary to remove a repository that could put users' packages at risk? I believe that Fedora can create a mirror of the website where the necessary packages from Cisco are located and change the address in the repository to the mirror. The key is to ensure that the mirror is accessible worldwide.

No, we can't. If we could do that we wouldn't need any of this stuff and the packages would just be part of the regular Fedora repositories. The packages have to be hosted by Cisco for legal (patent) reasons. That's why we have this problem.

(In reply to Adam Williamson from comment #5)
> No, we can't. If we could do that we wouldn't need any of this stuff and the
> packages would just be part of the regular Fedora repositories. The packages
> have to be hosted by Cisco for legal (patent) reasons. That's why we have
> this problem.

I got it. So, is it possible to use a proxy server that simply redirects requests to the Cisco server and receives responses? And will the proxy server be accessible worldwide?

AGREED RejectedFinalBlocker

Discussed at the 2025-09-22 (blocker / freeze exception) review meeting:

We agree that this is a very awkward state for folks in affected locations. However, as there is no entirely Fedora-controlled "fix" possible and the issue is not entirely limited to Fedora 43, we have decided it doesn't make sense to block on it. We will wait for Cisco to complete the process of refining their geoblock, then see where we stand and if we need to consider any changes on the Fedora side.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-22/f43-blocker-review.2025-09-22-16.01.txt

> We will wait for Cisco to complete the process of refining their geoblock, then see where we stand and if we need to consider any changes on the Fedora side.

We might have to wait a VERY long time. This problem has been ongoing for two months now.

Yes, but there isn't much else we can do. They're not just sitting on it, "fluffy" has been providing periodic updates. https://github.com/cisco/openh264/issues/3886#issuecomment-3271407996 was the most recent, on Sept 9.

> They're not just sitting on it, "fluffy" has been providing periodic updates.

He's posted a grand total of 3 comments so far: 2 on the same day, and 1 over a month later – with no resolution in sight.

That apart, a couple questions, if I may:

1. Are there any plans to fix librepo, at least? Ideally, by F43.

2. Since Fedora makes an exception by enabling a third-party repository with not-exactly-free software by default, why not do the same for, say, Nvidia drivers and Steam? I'm pretty sure the latter two are way more important for most users than a certain codec.

(In reply to Hasshu from comment #10)
> 2. Since Fedora makes an exception by enabling a third-party repository with
> not-exactly-free software by default, why not do the same for, say, Nvidia
> drivers and Steam? I'm pretty sure the latter two are way more important for
> most users than a certain codec.

OpenH264 is entirely free software, and it's built by Fedora. The only problem is we cannot host it ourselves, but that's not a restriction imposed by its copyright license. In contrast, NVIDIA drivers and Steam are actual proprietary software.

Notably, without OpenH264, almost all web browser video does not work (with only a few notable exceptions, like YouTube).

(In reply to Adam Williamson from comment #9)
> Yes, but there isn't much else we can do. They're not just sitting on it,
> "fluffy" has been providing periodic updates.

Based on my past interactions with Cisco regarding OpenH264, I recommend we assume they will take a very long time to fix this, if ever. They haven't even taken the time to close the spam duplicate bug reports yet.

> 1. Are there any plans to fix librepo, at least? Ideally, by F43.

What do you think can be fixed?

(In reply to Michael Catanzaro from comment #11)
> OpenH264 is entirely free software, and it's built by Fedora. The only
> problem is we cannot host it ourselves, but that's not a restriction imposed
> by its copyright license. In contrast, NVIDIA drivers and Steam are actual
> proprietary software.

Fair enough, though I find it difficult to consider the codec in question really free as it stands. Then again, I'm not a lawyer.

(In reply to Adam Williamson from comment #12)
> What do you think can be fixed?

As far as I can tell, librepo errors out when metadata for a package can be fetched, but the package itself cannot, and that's what ultimately breaks Fedora in the countries geo-blocked by Cisco.

See also these comments:
https://discussion.fedoraproject.org/t/ciscobinary-openh264-org-is-unreachable-in-some-countries-ru-ua-ir/161434/14
https://discussion.fedoraproject.org/t/ciscobinary-openh264-org-is-unreachable-in-some-countries-ru-ua-ir/161434/20

Kevin, thank you for the poke.

So based on my investigation.. what we have run into is a situation that is possible any time package level HTTP redirects are used in a repository.  This is probably not a common scenario but its possible for this to happen without geofencing due to a variety of network disruptions outside of the control of the client. So if there was a way for clients to address this, that would be great, as this is an uncommon but general deficiency in the client transaction model. But on to the specifics.

So codecs.fedoraproject.org self-hosts the repository metadata files needed for client transaction calculations. It uses HTTP redirects for specific packages hosted on another server.
Impacted clients are able to retrieve the metadata files, run the dependency calculation, but are unable to download the packages on the other side of the HTTP redirect. So the transaction fails.

I can reproduce this problem in an isolated homelab environment using arbitrary rpms, by splitting packages from repo metadata and using similar redirects, and then deliberately causing a network disruption only between the client and the the server hosting the packages.


The best technical workaround I can come up with, that does not require clientside enhancement, is for codecs.fedoraproject.org to also use HTTP redirects for the repository metadata.  
My understanding is, when repository metadata is inaccessible, the client can/should/may skip that repo, effectively disabling it for the transaction.  This needs to be tested.

If the client works as I expect and can ignore an enabled repo with unretrievable metadata, it would be possible to implement as a fix for codecs.fedoraproject.org with Cisco's help.  Cisco would have to agree to host additional repo metadata file content that we generated.  And we would have to construct additional HTTP redirects accordingly.

> As far as I can tell, librepo errors out when metadata for a package can be fetched, but the package itself cannot, and that's what ultimately breaks Fedora in the countries geo-blocked by Cisco.

To be fair (and also because you linked one of my posts), I don't think this is a bug in librepo - I would say it behaves just as expected: It is fed a list of repositories / repository metadata, and that's used to calculate a *completely valid* transaction in dnf. Only when dnf tries to *implement* that valid transaction, things go south, because it can't actually download all packages that are part of the requested transaction.

As far as I can tell, the only thing that's actually wrong is the assumption that if the repo *metadata* is downloadable, then the repo *contents* must *also* be downloadable. And I don't think there's a good way to tell dnf to attempt to download all packages that *could* be part of the transaction before *computing* the transaction - because that would basically require you to download ... well, all the packages.

Yeah, that's what I was going to say. The behaviour is, AFAICS, correct. It can't just "ignore" the missing packages, because then the transaction may not be solved any more.

There *could* be a mechanism where we somehow work back up the stack after a failure is encountered and re-run the transaction in question with the broken repo skipped, but that sounds complicated, and also like it might be the wrong behaviour in other cases. If there's a blip in access to the 'updates' repo I probably don't want the transaction automatically re-run with it disabled, I *want* it to error out...

Fabio and Adam, thank you for explaining. I'm not familiar with the inner workings of librepo and dnf, hence my "as far as I can tell".

(In reply to Jef Spaleta from comment #14)
> If the client works as I expect and can ignore an enabled repo with
> unretrievable metadata, it would be possible to implement as a fix for
> codecs.fedoraproject.org with Cisco's help.  Cisco would have to agree to
> host additional repo metadata file content that we generated.  And we would
> have to construct additional HTTP redirects accordingly.

Thanks for the update! That does sound promising.

So, moving the repodata to the cisco side would 'solve' this issue, but would raise some other ones. 

Users query mirrormanager for a metalink pointing to the actual repodata. Currently that points to our proxy network which we control. 

Currently the update cycle looks like:
* maintainer(s) build new openh264 packages
* we sign them and create a new repo with the new packages in a internal location.
* we give the signed binary packages to cisco.
* time passes
* They add the new packages and tell us
* We switch the repodata and tell mirrormanager about it.

If we move the repodata to the cisco side:
* maintainer(s) build new openh264 packages
* we sign them and create a new repo with the new packages in a internal location.
* we ship packages and repodata to cisco
* time passes
* They update things and immediately all users get a metadata mismatch, because mirrormanager doesn't match the actual data in the repo
* time passes
* We update mirrormanager with the new repodata.

So, it's not horrible, but it will mean everyone with this repo enabled is broken for a while until we are able to act and update mirrormanager.

It's possible we could adjust mirrormanager to accept the new repodata or the previous one, but might need some coding around that for this case.

Maybe it's worth moving fedora-cisco-openh264.repo to a separate subpackage (eg. fedora-repos-openh264) for easy removal?

Additionally, if it is fully uploaded to Cisco's side, it will no longer be considered an official Fedora repository and will need to be moved to Fedora's collection of third-party repositories, such as Steam, NVIDIA, and Chrome.

> So, moving the repodata to the cisco side would 'solve' this issue, but would raise some other ones.

I have a better solution: enable metalink for this repository and allow it to be mirrored. Users or organizations from different countries will be able to host this repository on their side, and Fedora will just need to update the metalink.

No real content will be hosted by Fedora -> no patent infringement will occur.

(In reply to Vitaly from comment #21)
> > So, moving the repodata to the cisco side would 'solve' this issue, but would raise some other ones.
> 
> I have a better solution: enable metalink for this repository and allow it
> to be mirrored. Users or organizations from different countries will be able
> to host this repository on their side, and Fedora will just need to update
> the metalink.
> 
> No real content will be hosted by Fedora -> no patent infringement will
> occur.

We could also have it as a mirror of one and implement empty returns for blocked countries.

(In reply to Vitaly from comment #21)
> > So, moving the repodata to the cisco side would 'solve' this issue, but would raise some other ones.
> 
> I have a better solution: enable metalink for this repository and allow it
> to be mirrored. Users or organizations from different countries will be able
> to host this repository on their side, and Fedora will just need to update
> the metalink.
> 
> No real content will be hosted by Fedora -> no patent infringement will
> occur.

Those mirrors would have to provide some documented evidence that they are valid patent license holders and have the right to distribute similar to Cisco.
If you can identify any other license holder that would be able to act in the same way as Cisco does currently and host copies of the packages, then we can perhaps have a discussion about how to include a 2nd licensed hoster in how this is implmented.