Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggested updates - MP 2021 Dec 21 #1

Open
mpelley-GovNL opened this issue Dec 21, 2021 · 3 comments
Open

Suggested updates - MP 2021 Dec 21 #1

mpelley-GovNL opened this issue Dec 21, 2021 · 3 comments

Comments

@mpelley-GovNL
Copy link

  • Suggested list of criteria - add standard code checksum requirement
  • Forking code - formal process required to clearly identify code forking, why it was required, who will be responsible for maintenance of the fork; we need a standardize place and mechanism for the documentation
  • Bill of Materials (BOM) - required for any code "imported" into national repository; need to know the source of origin. As noted elsewhere we need to have proper vetting of the "imported" code
  • Liability of code provided in national repository - we probably need to clearly state that best effort is provided in any code (maybe we need a formal "code of conduct" acceptance for joining the repository?) however there is no liability to the submitter ("Good Samaritan Law" if you will) -- likely need legal counsel (or maybe multiple jurisdictional?) to write this -- not sure about the agreement method (is this intergovernmental affairs-like?)

Governance

  • we need to start formalizing the governance method
  • previously noted "benevolent dictatorship" but I think that we need to start the outline/high level of what this looks like in the Directives and Guidelines
  • will need to formalize a separate document that states the governance; who sits on the governance board, terms of members, terms of reference, etc. (Maybe Linux Kernel might be used as starting point?)

Language

  • Are official languages for documentation required? If so, who is responsible for translation (not all jurisdictions have this capability/capacity; note also the translation of technical information may be an additional challenge)
  • Are there requirements for other languages than the official languages? (likely more challenging)
  • No idea on this one: Thoughts of the language used in the actual code?

Standards

  • We need to split this into Directives, Standards and Guidelines
  • e.g., Directive: What has to be done: All code shall have a mechanism to ensure the integrity of the code
  • e.g., Standard: How it will be done: All code will use a SHA256 checksum included in the repository
  • e.g., Guidelines: What is recommended to be done: it is recommended when code is downloaded the checksum is validated prior to using the code
@gcharest
Copy link
Contributor

Thanks for the addition! Really good points, I think I need to reformat the documents to better articulate the nuances you brought here and the ones that were shared in the last workshop.

@umuslu
Copy link

umuslu commented Dec 22, 2021

Defect Management/Urgent Updates:

Considering Mike's detailed comments, the only comment I can make is this. How would the process be during a crisis situation like the one we have all had for the last 2 weeks due to Log4J (Defect Management/Urgent Updates in Open Source)?

  • Who is going to modify all open source code, when?

Because everybody that makes contributions to the open-source codes would be taking care of proprietary codes first. Or every jurisdiction could try the fix the issue(s) locally at the same time and they would prefer to create MRs later.

  • Do we need to have something included in the guideline/directive?

@mpelley-GovNL
Copy link
Author

Excellent point! I think that we might have to have a separate discussion specific to vulnerability management. I can see this requiring in the directives an item around projects needing to have a vulnerability alerting and response "mechanism".

The standard would be the how (could be one to many that everyone finds acceptable) vulnerabilities are communicated to the project maintainer (likely also in a directive), how the maintainer responds, how the vulnerability is communicated, etc.

The guideline would likely be something around monitoring for updates, vulnerability alerts, etc.

Overall, this is something that we need to "codify" especially given the cyber security world we all work in.

Excellent suggestion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants