This is a Request For Resources for Zezere (i.e. provision.fedoraproject.org), which is the provisioning service for Fedora IoT.
Software: Zezere Advantage for Fedora: It provides provisioning (installation and initial configuration) for Fedora IoT Sponsor: @pbrobinson (IoT Edition lead)
Upstream source: https://github.com/fedora-iot/zezere/ Development contacts: @puiterwijk, @pbrobinson Maintainership contacts: @puiterwijk, @pbrobinson Load balanceable: yes Caching: Yes, /static
SOP link: https://docs.pagure.io/infra-docs/….. Application Security Policy self-evaluation: There is a single code line exempted from security checks (nosec), which is justified in the code. Other than that, it passes the policies as written in the ASP, and has active tests to check that new patches don't break it Audit request: https://pagure.io/fedora-infrastructure/issue/9535 Audit timeline: 2020-12-16 - 2020-12-23
nosec
Ansible playbooks: ansible/playbooks/openshift-apps/zezere.yml Fully rebuilt from ansible: <yes> Production goal: 2020-12-20 Approved audit: https://pagure.io/fedora-infrastructure/issue/9535
Could this run in openshift?
Yes, absolutely, that is actually the only way I've ever deployed it. The current deployment is already in Openshift (Online at this moment). https://pagure.io/fedora-infra/ansible/pull-request/334 is the PR for adding it as such to Ansible.
Metadata Update from @zlopez: - Issue tagged with: ops
Audit timeline: <04-11-2025 - 06-11-2025> Production goal: <08-11-2025>
Are the dates correct? :)
Audit timeline: <04-11-2025 - 06-11-2025> Production goal: <08-11-2025> Are the dates correct? :)
Nope. Those are the template values, because I didn't fill those in yet 😀
For paperwork reasons:
Hat: application developer: I would like to formally request a security audit by the Fedora Infrastructure Security Officer.
Hat: security officer: This application has passed the rules set out in the Fedora Infrastructure Application Security Policy as available on 2020-12-16. Any further looks are very much appreciated, and this ticket will be considered not passing the audit until at least 2020-12-20, to give people time to look.
NOTE: If people disagree with this way of process, let me know, and I'd be happy to go the official route and try to find someone to delegate the audit to.
Any further looks are very much appreciated, and this ticket will be considered not passing the audit until at least 2020-12-20, to give people time to look.
Considering we're at the end of the year and some folks have already started to step away for some well deserved rest, I'd propose we defer this date until next year, I'm thinking maybe 2021-01-15 so people have some time to come back to work and catch up with their emails and tickets (including this one). This is, of course, unless you are on a tight schedule.
Metadata Update from @smooge: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: medium-gain, medium-trouble, request-for-resources
I see it has an OIDC login, what private information does it store? Does it come with a SAR script?
The only identifiable user information it stores is the subject (right now the anonymous one, but basically FAS username) and the email address it gets from FAS. Other than that, it stores the public part of an SSH key, and that's it.
There is no SAR script, because it doesn't have any user information that it doesn't get directly from FAS.
Any further looks are very much appreciated, and this ticket will be considered not passing the audit until at least 2020-12-20, to give people time to look. Considering we're at the end of the year and some folks have already started to step away for some well deserved rest, I'd propose we defer this date until next year, I'm thinking maybe 2021-01-15 so people have some time to come back to work and catch up with their emails and tickets (including this one). This is, of course, unless you are on a tight schedule.
Okay. Let's do 2021-01-15 then as deadline for initial comments.
Another quick question:
And a small ask: for stage 2 one is supposed to open an infrastructure thread about the request ( https://fedora-infra-docs.readthedocs.io/en/latest/sysadmin-guide/sops/requestforresources.html?highlight=rfr#requirements-for-continuing )
Another quick question: Could you categorized this application using the definitions at https://pagure.io/cpe/docs/pull-request/16#request_diff ?
I'd say it's "CPE run and don't maintain".
Thanks for the reminder. Here: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/JXEX7FCS7VUVF2ZPFMWB2XUFZIF2UMOZ/
Could you categorized this application using the definitions at https://pagure.io/cpe/docs/pull-request/16#request_diff ? I'd say it's "CPE run and don't maintain".
Could you categorized this application using the definitions at https://pagure.io/cpe/docs/pull-request/16#request_diff ?
Cool. Is that in critpah for the IOT edition or not at all?
This is not critpath for IoT building, but it is the default way for people to start using it if they don't have their own server or insert keys in another way. So semi-critpath?
Is there anything further to do here now? Or shall we close this as done?
@puiterwijk do you know the status of this request?
This was actually done, sorry for not closing.
Metadata Update from @puiterwijk: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.