Goals we want to achieve
- Create a release of hiero-enterprise-java and publish it to Maven Central under
org.hiero namespace.
- Have the steps that are needed in general to publish a (Java based) release to
org.hiero namespace documented
- Have documented what must be done to do such releases in a secure way without the possibility of any security risks within hiero.
Open questions / actions
- Step Security creates PRs against Non-Hashgraph repos (example Step-Security-PR). We need a public documentation on that containing the answers to “What is it?” and “Why is it needed?”. Since that tooling is coming from Hashgraph-Github-Maintainers and nobody else has knowledge about it, work on such documentation must be done by that team. Hashgraph-Github-Maintainers made clear that they have zero knowledge on those topics.
- To upload to Maven Central artifacts must be signed. Here a GPG key is needed. Some repos (gradle) have a GPG defined by repo. I believe we should have a global GPG key for hiero. Looks like Hashgraph-Github-Maintainers have created the current GPG keys. We need to understand where that key is coming from, if it should be a global key or if Hashgraph wants a key on its own. In that case the global community (with LFDT support) will create and manage a GPG key next to a special one Hashgraph uses (which can end in confusion). We need public documentation on how the GPG key that should be used for assigning can be used in actions. Once GPG is defined the community can take care of the public documentation but first Hashgraph-Github-Maintainers and LFDT-Github-Maintainers need to take actions to provide a GPG key.
- To upload to Maven Central we need to authenticate. Here a groupId is bound to accounts. We (hiero community) own an account that has access to
org.hiero groupId. We have not uploaded anything to that group so far. Today it is unclear who created the account for org.hiero and has access to it. Assumptions are Hashgraph-Github-Maintainers or LFDT-Github-Maintainers. We need to clarify who has access and how it is configured / stored in the org. As the GPG key this should be defined on org level (can we then activate it only for some given repos?) and be documented in the open so that maintainers understand how to use it. Once open questions are answered by Hashgraph-Github-Maintainers and LFDT-Github-Maintainers the community can take care of the public documentation.
Outcome
- Documentation on Step Security and Step Security PRs and any other security / DevOps related topics / restrictions (Snyk, random repo audits, ...?) projects maintainers need to know
- Documentation about GPG key usage in GitHub Actions within Hiero
- Documentation about usage of Maven Central secrets in GitHub Actions within Hiero
Once that is done the committers of hiero-enterprise-java can create a secure GitHub Action based workflow by using all the information to create releases and publish artifacts to Maven Central.
Goals we want to achieve
org.hieronamespace.org.hieronamespace documentedOpen questions / actions
org.hierogroupId. We have not uploaded anything to that group so far. Today it is unclear who created the account fororg.hieroand has access to it. Assumptions are Hashgraph-Github-Maintainers or LFDT-Github-Maintainers. We need to clarify who has access and how it is configured / stored in the org. As the GPG key this should be defined on org level (can we then activate it only for some given repos?) and be documented in the open so that maintainers understand how to use it. Once open questions are answered by Hashgraph-Github-Maintainers and LFDT-Github-Maintainers the community can take care of the public documentation.Outcome
Once that is done the committers of hiero-enterprise-java can create a secure GitHub Action based workflow by using all the information to create releases and publish artifacts to Maven Central.