forge/forge
11
8
Fork 8
Code Issues 98 Pull requests 1 Projects Wiki Activity Actions

Prototype workaround for private issues #657

New issue
Closed
opened 2026-07-13 01:36:06 +00:00 by ryanlerch · 5 comments
ryanlerch commented 2026-07-13 01:36:06 +00:00
Owner
Copy link

Summary

Prototype workaround for private issues

Details

Create a prototype Flask web application that allows Fedora users to file issues in private Forgejo repositories they don't have direct access to. Designed for sensitive reports like Code of Conduct violations, GDPR requests, and security issues.

Key Features Implemented

  • OIDC Authentication: Integration with Fedora Accounts via authlib for user authentication
  • Stateless Architecture: No database - Forgejo is the single source of truth
  • Issue Filing: Users can file issues with title, description/questions, and file attachments (up to 5 files, 10MB each)
  • Two-way Communication: Webhook-based system for maintainers to request additional information via @ForgeFiler request-info comments
  • Response Links: HMAC-signed tokens that allow reporters to add comments to their issues via email links
  • Configurable Forms: Support for both freeform description and structured question-based forms per repository
  • File Attachments: Upload support for images, PDFs, and text files on both initial filing and responses
  • Email Notifications: SMTP-based notifications for issue confirmation and info requests
  • Security: CSRF protection, HMAC webhook verification, OIDC authorization checks, automatic logout after submission

Technical Stack

  • Flask web framework with application factory pattern
  • Authlib for OIDC integration
  • Forgejo API integration via requests library
  • Flask-WTF for forms and CSRF protection
  • itsdangerous for signed response tokens
  • TOML configuration with environment variable overrides
  • Development mode with fake auth bypass for local testing
### Summary Prototype workaround for private issues ### Details Create a prototype Flask web application that allows Fedora users to file issues in private Forgejo repositories they don't have direct access to. Designed for sensitive reports like Code of Conduct violations, GDPR requests, and security issues. Key Features Implemented - OIDC Authentication: Integration with Fedora Accounts via authlib for user authentication - Stateless Architecture: No database - Forgejo is the single source of truth - Issue Filing: Users can file issues with title, description/questions, and file attachments (up to 5 files, 10MB each) - Two-way Communication: Webhook-based system for maintainers to request additional information via @ForgeFiler request-info comments - Response Links: HMAC-signed tokens that allow reporters to add comments to their issues via email links - Configurable Forms: Support for both freeform description and structured question-based forms per repository - File Attachments: Upload support for images, PDFs, and text files on both initial filing and responses - Email Notifications: SMTP-based notifications for issue confirmation and info requests - Security: CSRF protection, HMAC webhook verification, OIDC authorization checks, automatic logout after submission Technical Stack - Flask web framework with application factory pattern - Authlib for OIDC integration - Forgejo API integration via requests library - Flask-WTF for forms and CSRF protection - itsdangerous for signed response tokens - TOML configuration with environment variable overrides - Development mode with fake auth bypass for local testing
ryanlerch added this to the Sprint 24 project 2026-07-13 01:36:06 +00:00
ryanlerch commented 2026-07-20 09:21:51 +00:00
Author
Owner
Copy link

ForgeFiler Status Update — 2026-07-20

The ForgeFiler prototype is built and deployed to staging. Here's a walkthrough of the current workflow:

How it works

  1. A user visits a direct link for a specific report type (e.g. Code of Conduct or Personal Data Request)
  2. They authenticate via Fedora Accounts (OIDC)
  3. They fill out a form with a title and a set of custom questions configured per repository
  4. ForgeFiler creates the issue in the corresponding private Forgejo repository via a bot account — the reporter never gets access to the repo itself
  5. The reporter receives an email confirmation with their submission details
  6. If a maintainer needs more info, they comment on the issue with /respond followed by their question
  7. A webhook fires, and ForgeFiler emails the reporter a secure link to respond
  8. The reporter authenticates, submits their reply, and it's added as a comment on the issue

Issue numbers are never exposed to reporters — all links use cryptographically signed tokens. The app is fully stateless (no database); Forgejo issues are the single source of truth.

Staging Instance

The staging deployment is live at:
https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org

It is connected to forge.stg.fedoraproject.org with two dummy private repositories under the forgefiler org:

  • forgefiler/code-of-conduct — Code of Conduct reports (10 custom questions)
  • forgefiler/fedora-pdr — Personal Data Requests (2 custom questions)

Next Steps

  • Code review (forge/ForgeFiler#1)
  • Production deployment and Forgejo webhook configuration
## ForgeFiler Status Update — 2026-07-20 The ForgeFiler prototype is built and deployed to staging. Here's a walkthrough of the current workflow: ### How it works 1. A user visits a direct link for a specific report type (e.g. [Code of Conduct](https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org/code-of-conduct/file-issue) or [Personal Data Request](https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org/personal-data-request/file-issue)) 2. They authenticate via Fedora Accounts (OIDC) 3. They fill out a form with a title and a set of custom questions configured per repository 4. ForgeFiler creates the issue in the corresponding **private** Forgejo repository via a bot account — the reporter never gets access to the repo itself 5. The reporter receives an email confirmation with their submission details 6. If a maintainer needs more info, they comment on the issue with `/respond` followed by their question 7. A webhook fires, and ForgeFiler emails the reporter a secure link to respond 8. The reporter authenticates, submits their reply, and it's added as a comment on the issue Issue numbers are never exposed to reporters — all links use cryptographically signed tokens. The app is fully stateless (no database); Forgejo issues are the single source of truth. ### Staging Instance The staging deployment is live at: https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org It is connected to [forge.stg.fedoraproject.org](https://forge.stg.fedoraproject.org) with two dummy private repositories under the `forgefiler` org: - **forgefiler/code-of-conduct** — Code of Conduct reports (10 custom questions) - **forgefiler/fedora-pdr** — Personal Data Requests (2 custom questions) ### Next Steps - Code review (forge/ForgeFiler#1) - Production deployment and Forgejo webhook configuration
kevin commented 2026-07-20 17:06:11 +00:00
Copy link

I think this will probibly be workable... I'd like to get any input from @zlopez also, he's been processing the pdr requests lately a lot.

I think this will probibly be workable... I'd like to get any input from @zlopez also, he's been processing the pdr requests lately a lot.
zlopez commented 2026-07-21 09:29:23 +00:00
Copy link

It's not that convenient as private issues, but it seems to be workable. It fills the security requirements we have, but I'm not sure how the reporter will add anything. For example we process the request and then we get another comment from reporter that they want something above the standard way we are doing it.

Also how the reporter will be notified that the request was processed?

It's not that convenient as private issues, but it seems to be workable. It fills the security requirements we have, but I'm not sure how the reporter will add anything. For example we process the request and then we get another comment from reporter that they want something above the standard way we are doing it. Also how the reporter will be notified that the request was processed?
ryanlerch commented 2026-07-22 03:04:23 +00:00
Author
Owner
Copy link

For follow-up information from the reporter: when the team processing the request needs more details, they post a comment on the private issue starting with /respond. For example:

/respond
Can you provide more details about the timeline of events?

This triggers ForgeFiler to send the reporter an email containing a secure link. Every response from ForgeFiler to the reporter includes this link, and it is how the reporter interacts with that specific issue — clicking it takes them to a form where they can add additional comments and file attachments, without ever needing access to the private repository. The team can request more info as many times as needed.

For notifications: the reporter receives an email confirmation when they first file the issue, and then again each time the team uses /respond. When the request has been fully processed, the team simply uses /respond to let the reporter know it has been closed.

For follow-up information from the reporter: when the team processing the request needs more details, they post a comment on the private issue starting with `/respond`. For example: ``` /respond Can you provide more details about the timeline of events? ``` This triggers ForgeFiler to send the reporter an email containing a secure link. Every response from ForgeFiler to the reporter includes this link, and it is how the reporter interacts with that specific issue — clicking it takes them to a form where they can add additional comments and file attachments, without ever needing access to the private repository. The team can request more info as many times as needed. For notifications: the reporter receives an email confirmation when they first file the issue, and then again each time the team uses `/respond`. When the request has been fully processed, the team simply uses `/respond` to let the reporter know it has been closed.
ryanlerch commented 2026-07-22 04:03:16 +00:00
Author
Owner
Copy link

The prototype for ForgeFiler has been built and is deployed to staging for testing:

ForgeFiler is a Flask web app that provides a public-facing form for filing issues into private Forgejo repositories, with OIDC authentication via Fedora Accounts, file attachments, and a webhook-based /respond command for maintainer-reporter communication.

Any further issues, bugs, or feature requests should be filed in the forge/ForgeFiler issue tracker.

The prototype for ForgeFiler has been built and is deployed to staging for testing: - **Staging instance:** https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org/ - **Sample report form:** https://forgefiler-forgefiler.apps.ocp.stg.fedoraproject.org/personal-data-request/file-issue - **Source code:** https://forge.fedoraproject.org/forge/ForgeFiler ForgeFiler is a Flask web app that provides a public-facing form for filing issues into private Forgejo repositories, with OIDC authentication via Fedora Accounts, file attachments, and a webhook-based `/respond` command for maintainer-reporter communication. Any further issues, bugs, or feature requests should be filed in the [forge/ForgeFiler issue tracker](https://forge.fedoraproject.org/forge/ForgeFiler/issues).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
test
docs
No results found.
Labels
Clear labels   
ai-review-please
label for requesting AI code review

  
Org/Team Modification

   
Private Issues
Label for tracking development on Private Issues in Forgejo

  
Runner Request
  
Backlog Status
Needs Review
 Work items that have been created or updated but need review, refinement, or approval before they can be considered ready for sprint planning.

  
Backlog Status
Ready
 Work items that have been reviewed, refined, and are ready to be committed to a sprint. These items have clear requirements and can be worked on immediately when capacity is available.

  
chore
Work that needs to be done but doesn't add new functionality or fix bugs. Maintenance tasks that keep the system running smoothly and the codebase clean.

  
documentation
Work focused on creating, updating, or improving documentation for users, developers, or system administrators.

  
points
01
 A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points
02
 This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points
03
 Medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points
05
 A significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points
08
 Complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
points
13
 Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint and should be broken down.

  
Priority
High
 This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
Priority
Low
 This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
Priority
Medium
 This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
Sprint Status
Blocked
 Work items that cannot progress due to external dependencies, blockers, or issues that need resolution.

  
Sprint Status
Done
 Work items that have been completed, reviewed, and integrated. No further work is needed within the current sprint.

  
Sprint Status
In Progress
 Work items currently being worked on by a team member. Active development, research, or implementation is happening.

  
Sprint Status
Review
 Work items that are complete but need review, testing, or approval before being marked as done.

  
Sprint Status
To Do
 Work items that are committed to the sprint but haven't been started yet. These items are ready to be picked up by team members.

  
Technical Debt
Work that addresses shortcuts, workarounds, or suboptimal implementations that were done previously to meet deadlines. These items improve code quality, maintainability, or performance without adding new features.

  
Work Item
Bug
 Issues where the system is not working as intended or designed. Bugs represent deviations from expected behavior.

  
Work Item
Epic
 Large initiatives that are broken down into multiple smaller work items (user stories, tasks, bugs). Epics represent significant features or projects that span multiple sprints.

  
Work Item
Spike
 Time-boxed research, investigation, or proof-of-concept work to reduce uncertainty or explore solutions. Spikes help inform future development decisions.

  
Work Item
Task
 Used to break down larger user stories into smaller, manageable implementation pieces. They focus on the specific technical steps needed to deliver the user story's value.

  
Work Item
User Story
 User-facing features or functionality that can be framed from a user perspective, describing what someone wants to accomplish and why.

No labels
ai-review-please
Org/Team Modification
Private Issues
Runner Request
Backlog Status
Needs Review
Backlog Status
Ready
chore
documentation
points
01
points
02
points
03
points
05
points
08
points
13
Priority
High
Priority
Low
Priority
Medium
Sprint Status
Blocked
Sprint Status
Done
Sprint Status
In Progress
Sprint Status
Review
Sprint Status
To Do
Technical Debt
Work Item
Bug
Work Item
Epic
Work Item
Spike
Work Item
Task
Work Item
User Story
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Sprint 25
Assignees
Clear assignees
No assignees
ryanlerch
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forge/forge#657
No description provided.