Just for the record, I received the following response via private email from Michael
in relation to this issue. Since the original report was submitted publicly,
I’m sharing the reply here to maintain transparency for others who may encounter similar problems.

Akihito Kurita venit, vidit, dixit 2025-06-17 01:02:13:

Hi all,

I’d like to report an issue currently preventing me from contributing
to Fedora from Japan.

• SSH access to src.fedoraproject.org is consistently timing out
  from multiple Japanese networks (home ISP, Sakura VPS, EC2 Tokyo).
• HTTPS git push with API tokens fails as expected.
• I also cannot generate a Git Authentication Token (CLI token), as
  the option is missing from my account (redadmin).

I’ve filed a full report with evidence and screenshots here:
👉 https://pagure.io/fedora-infrastructure/issue/12602

This blocks all push access, even to forks, while I'm still waiting
for packager sponsorship.

Thanks for your time and attention.

Hi there, and welcome as a contributor!

I don't consider it an undue restriction if packaging infrastructure
is available to packagers only. You can clone dist-git freely, build
locally/in mock and submit spec files and patches via bugzilla or
otherwise. Indeed, being able to do that shows that you can test changes
before submitting them, which you should do as a packager.
Once you are in the packagers' group you have full access
(including pushes and cache uploads).

Cheers,
Michael

While I appreciate the response, I’m sharing it here for documentation purposes.
The original concerns—namely the missing Git token UI, inaccessible SSH, and push blockage—
remain unaddressed at the infrastructure level.

Best regards,
redadmin

Just for the record:
I answered to redadmin's posting to the epel-devel list by replying "to" the sender's address and epel-devel (in the same reply).

Thanks for clarifying.

For completeness: If the message was also sent to epel-devel, that helps document the broader context.
However, as this is an infrastructure-level issue affecting contribution mechanisms,
I believe the appropriate venue for resolution remains here on this ticket.

Regardless, thank you for the note.

– Akiyoshi Kurita

Kurita-san

I believe the documents you are looking for are:
https://fedoraproject.org/wiki/Package_Source_Control particularly https://fedoraproject.org/wiki/Package_Source_Control#Authentication_and_Authorization

and
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Maintenance_Guide/#using_fedpkg_anonymously
https://docs.fedoraproject.org/en-US/package-maintainers/Pull_Request_Guide/

The methods for non-packagers are not as easy as they could be, but they are currently bound by the limitations of the current git forge and legal requirements.

I'll repeat what I put in the other ticket you opened and add to it:

Hi. This is not expected to work.

For src.fedoraproject.org you need an oauth token, which fedpkg can get you.

See:

https://fedoraproject.org/wiki/Infrastructure/HTTPS-commits

If that doesn't work for some reason, feel free to reopen.

Adding:

It's expected that you cannot use ssh to push to src.fedoraproject.org. Packagers are the only ones who can use ssh there (for historical reasons).
You can use https, but you have to use fedpkg. pagure tokens or the like should work fine for pagure.io, but do not for src.fedoraproject.org because src.fedoraproject.org authentication is more tightly controlled by the account system.

Sorry if this is unclear or docs don't explain better. Improvements welcome.

Hi Kevin,

Thank you for your clarification. However, I would like to respectfully raise a concern:

🔒 The current design — requiring fedpkg and Fedora OAuth tokens while completely blocking SSH and basic HTTPS pushes — effectively creates a technical barrier for new contributors, especially in regions like Japan.

In my case, I attempted to contribute from multiple independent Japanese networks (residential fiber, VPS, EC2), and all SSH connections to src.fedoraproject.org failed due to timeout. The fallback to HTTPS was also blocked by the OAuth-only requirement, with no intuitive or documented method to obtain the token unless one is already familiar with Fedora-specific tooling.

🧭 This is not merely a misunderstanding of the documentation — it's a systemic onboarding issue. It assumes users already know to use fedpkg and already belong to the packager group, which makes early-stage contribution (e.g., submitting forks, requesting reviews) nearly impossible for new contributors.

I fully understand the historical reasons behind this design, but I strongly believe Fedora should aim to lower the barrier for first-time contributors — for example:
- Enabling OAuth token generation via the web interface.
- Allowing HTTPS pushes to forks with basic credentials, not only via fedpkg.

These changes would align better with standard Git workflows and would make Fedora more accessible globally.

Thank you again for your time and support.

– Akiyoshi Kurita
FAS: redadmin

This workflow should be improved when we switch from pagure to Forgejo.

SSH access to Fedora infrastructure is restricted to approved Fedora packagers. This restriction is in place for security and access control reasons and is not related to geographic location, nationality, or network origin — including Japan or any Japanese networks.

Contributing Code to Fedora Without Being a Packager

You do not need to be a Fedora packager to contribute code. Anyone can propose changes to Fedora packages via pull requests. Here's what you need to do:

• Create a Fedora Account
  Visit https://accounts.fedoraproject.org and register for an account.

• Sign the Fedora Project Contributor Agreement (FPCA)
  This is a simple legal agreement that enables you to contribute code to Fedora repositories. You can sign it through your Fedora account settings.

Once these steps are complete, you'll be able to open pull requests (PRs) against Fedora repositories hosted on https://src.fedoraproject.org.

Notably:

• You do not need to be a Fedora packager.

• You do not need to use OAuth tokens.

• You do not need to use fedpkg.

• You do not even need to run Fedora Linux or any Unix-like operating system.

Submitting a Pull Request to a Fedora Repository

To contribute your code changes via a pull request:

• Prepare your changes in a Git repository and push them to a publicly accessible Git hosting platform of your choice (e.g., GitHub, GitLab, Codeberg). (Detailed instructions on how to set up a public Git repo are out of scope for this note.)

• Visit https://src.fedoraproject.org and log in using your Fedora account.

• Navigate to the target repository you wish to contribute to.

• Click the “Open PR” button, then select “New Remote Pull Request.”

• Provide the URL of your public Git repository, specify the branch containing your changes, and complete any additional required fields.

Once submitted, your pull request will be visible to the maintainers for review and potential inclusion.

I hope that helps. There is nothing Fedora Infrastructure can do regarding this topic.

Dear Fedora/EPEL Team,

Thank you for your response regarding the SSH access issue. I understand that the access restrictions are in place for security reasons and are not geographically based. I appreciate the clarification.

However, the issue I raised goes beyond just SSH access. The core issue is the quality and reliability of EPEL packages, especially when fixes are overlooked or ignored, and contributions are dismissed due to procedural reasons.

It has come to my attention that Mikolaj Izdebsk personally intervened in this matter, which suggests that the issue is significant and cannot be overlooked. This is no longer just a procedural issue, but one that concerns the overall trustworthiness of Fedora/EPEL.

As I mentioned in my previous communication, I am responsible for infrastructure projects related to government systems in Japan, and it is critical that the EPEL packages we depend on are thoroughly reviewed, secure, and properly managed. I expect that the issues I raised will be addressed appropriately. Specifically, I am seeking answers to the following:

1. How does Red Hat ensure the reliability and security of EPEL packages for government-related projects?
2. Is the quality assurance process within Fedora/EPEL sufficient to guarantee that packages are properly reviewed and updated?
3. If necessary, what plans does Fedora have to improve the workflow to ensure contributions are fairly evaluated, regardless of group membership?

Additionally, if EPEL does not have a sufficiently reliable package management system, we may be forced to consider other distributions (e.g., AlmaLinux or Ubuntu) for future government projects. These distributions, like EPEL, are RHEL-compatible but are perceived to offer more transparent governance and security management, making them suitable choices for projects where reliability and security are paramount.

Therefore, if EPEL's quality management and vulnerability handling are found to be insufficient, we will have no choice but to adopt alternative distributions. This is to prioritize the stability and security of government-related infrastructure systems.

As these issues remain unresolved, we are moving towards a situation where a formal inquiry with Red Hat Japan will be necessary. We look forward to receiving a clear response from Red Hat Japan and will take the necessary steps based on their guidance.

I look forward to your response and to seeing improvements in the process so that EPEL can continue to be a secure and reliable option for all users.

Sincerely,
Akiyoshi Kurita
FAS: redadmin

Kurita-san,

It is quite apparent that these messages are being generated or heavily assisted by a large language model. This isn’t just due to the formatting and phrasing, but also because of several factually incorrect claims that would likely not be made by someone even remotely familiar with the systems in question, as you claim and otherwise seem to be.

I understand it can be tempting to rely on LLMs, especially if you’re not entirely comfortable communicating in English. In practice, it ends up being a significant crutch that makes conversations harder, not easier. It obscures your real intent, creates confusion, and erodes trust in the exchange.

I think more people would be open to engaging with you directly if the communication felt more authentic and grounded in personal understanding, rather than filtered through generic AI output that many find frustrating to read and respond to.

Very respectfully,
Neil

Dear Kurita-san,

Considering the questions being asked, I encourage you to reach out to your Red Hat liaison person to get a better understanding of Red Hat's stance on EPEL.
While the question of the use of EPEL by government entity is not new, I don't believe this is the right place for this discussion.

Using the remote pull-request feature as @mizdebsk pointed out solves the initial issue reported about 0Auth token.
What would be interesting from an infrastructure point of view is to understand why those ISP are blocking EPEL. 0Auth is a fairly standard protocol used by many ISP including google, so would we have any idea why EPEL specifically is blocked?

If you have any idea regarding this and what we could to do mitigate this, it would be greatly appreciated.

Best regards,
pingou

Dear Pingou,

Thank you for your thoughtful response.

I appreciate your continued engagement. I hope we can continue to collaborate positively going forward. I’m still very much interested in contributing to EPEL and supporting its long-term reliability.

Thank you again for your time and consideration.

Sincerely,
Akiyoshi Kurita

As a small follow-up, I just wanted to say that I don’t have any hard feelings toward Mikel or anyone involved. I believe this may have simply come down to a misunderstanding or a difference in expectations.

My intention throughout has been to support a healthy contribution process — one that values openness, clear communication, and mutual respect. I’m glad we’ve been able to move forward constructively, and I appreciate everyone’s time and efforts.