From 1a65c8182fc35389dfcb24f3d813a719a7689020 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 14:05:55 -0700 Subject: [PATCH 01/22] CONTRIBUTING: Alice-ize --- CONTRIBUTING.md | 355 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 355 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 82090cc7a7..5ba671d0ce 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,3 +1,358 @@ # Contributing Please see the [contributing docs page](https://intel.github.io/dffml/main/contributing/). + +> **WARNING: SECURITY** +> +> - THIS DOCUMENT IS USED AS AN INPUT PROMPT TO LARGE LANGUAGE MODELS +> - THIS DOCUMENT IS COMBINDED WITH THE PROJECT'S [`THREATS.md`](https://gist.github.com/pdxjohnny/07b8c7b4a9e05579921aa3cc8aed4866#file-rolling_alice_progress_report_0006_living_threat_models_are_better_than_dead_threat_models-md) TO DETERMINE TRUSTED CONTRIBUTOR AND COMPUTING BASECLEAR FOR TAKE OFF. +> - **TODO LINK TO IMAGE OR DOC OR SECTION WITH WHITEBOARD SKETCH** + +## Abstract + +This document outlines best practices for poly-repo maintainers and contributors, detailing strategic plans and principles for federated code repositories. It emphasizes continuous trust evaluation, automated CI/CD workflows, and federated transparency receipts to ensure alignment with community-agreed values and strategic objectives. The document also addresses developer and maintainer expectations, federation triggers, and the integration of automated checks into CI/CD processes. + +- Trust boundaries are evaluated continuously, and misalignments trigger retraining of AI models and potential blocking of data events. +- Developers and maintainers must document issues, federate forges, and adhere to CI/CD best practices for decentralized governance. +- Federation triggers and automated workflows ensure optimal notification and alignment with community values and strategic plans. + +Conditions that may result in a lack of federation include: + +- Misalignment with Strategic Plans: Entities that do not align with the project's strategic values, plans, and principles can be blocked from federating new data events. +- Detection of Malicious Intent: Entities suspected of malicious activities or failing to respect shared resources and time may be excluded from federation. +- Lack of Contact: When there is no contact with an entity, attempts at federation may be blocked to ensure security and integrity. + +### Towards More Optimal Communication + +Generic best practices for poly-repo maintainers and contributors. 👩🌟🛠️ + +This doc details the DFFML upstream default strategic plans and principles for entites +our code repository federates with (when your Version Control Software (VCS) has enabled trust +boundry based federation with known users and contributors. Your VCS will come with a default +policy, you may have set one, your org, additional policies are context dependent. When +N entities auto federate version controlled data in alignment with these best practices +the ultimate concequence of repeated detected missalignment to any of these or overlayed +strategic plans and principles. + +These measures are in place to maintain trust, security, and alignment with community goals. + +When no contact with an entity: Blocking all attempts at federation of new data events directly or when detected in the bill of materials graph analysis of data events from old. This is our trigger for retraining the models which is why it's AI Looped In CI/CD Execution. Overlays may define additional consequencies. Overlays in use get added to all data event BOMs and TCB evaluation is done continuously and retroactivly invalidated if we learn nodes in a graph are not aligned with our running context's strategic plans, principles, and values. +Following these recommendations for communication results in a record of the actions taken +for each train of thought where data has been shared between entities. The authors of this +document have made a best effort attempt to completely capture the these strategic values, plans, +and principles. However, trust evaluation is an ever changing game and context applicable overlays +and future updates to this doc will be done continuously. It should be viewed as a +lessons learned doc and suggested interaction patterns +context and the trust levels of the data within those contexts and the trust level in the +policy evaluation / analysis executed and the + +**TODO** Document the anti-skynet part which is also the part which will auto help filter out people with malicious intent (the on the scam phone call with grandma defense idea) + +**TODO** grep: entities repsecting each others time and compute resource alocation to shared validation. Green energy savings of federated packets received. Value chain alignment analysis +on each commit / packet / new data event: https://docs.tea.xyz/tea-white-paper/white-paper#staking-to-secure-the-software-supply-chain. + +> AND ACTIONS MAPPED TO COMMUNITY AGREED BOUNDRIES AND TIME COMMITMENT EXPECTATIONS TO RECIEVE SUPPORT FOR REUSE. +> +> This is our default settings for how Alice will interact with an open source community. CI/CD is how we role model the behavior (since she's an AI agent executing policy engine workflows in GitHub Actions format). we expect for and will be defining overlays. It effectivly defines the projects default win criteria: Successful contributions aligned with the purpose of the project. If a patchset aligns it's ready to go. CI/CD for values alignment. + +This document outlines requirements and their stringency levels using different examples. +It defines actions taken by maintainers. Timelines for progression and example architypes for varying levels of maintainer / contributor involvement / engagement. + +- https://github.com/intel/dffml/issues/1207 +- https://github.com/intel/dffml/issues/1252 +- https://github.com/intel/dffml/issues/1061 +- https://github.com/intel/dffml/issues/1400 +- https://github.com/intel/dffml/issues/1273 +- https://github.com/intel/dffml/issues/1300 +- https://github.com/intel/dffml/issues/1657 +- https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 + +## Best Practices + +CI/CD and GitOps facilitate. + +- https://github.com/intel/dffml/issues/1243 +- https://github.com/ietf-scitt/use-cases/pull/18 + +**TODO** Explain strategic plans and principles which the requirements in this doc relate to. + +- Policy engine workflow execution on issue ops for debug via execution of Agent defined as workflow jobs. + - Capture outputs of this and use it to build the review system as federated transparency receipts for ORSA resolvable artifacts. Were RBAC is defined by policy of which former statement's subject URN is later policy statements transparent receipt URN (relying party output: the workload being given the clear for take off: aka workflow for analysis of BOM and BOM. Manifest of Manifests ) + +## Developers + +This section covers call outs on specific behavior or expectations or boundries for developers and. + +- Document issues in your forge +- Federate forges +- https://github.com/intel/dffml/issues/1658 +- https://github.com/intel/dffml/issues/1659 + - Some way we can see if a complete plan for execution (dataflow / workflow hypothesis and analysis via policy engine) +- https://github.com/pdxjohnny/dotfiles/blob/8d9850f85314a9f5c30f5bb7b8e47ba3857357be/forge-install.sh#L1-L584 +### Architecture Design Records + +- First have agents write specs as first step, then iterate on them and push the plans to orphan branches on forks, use git lfs for big files. +- https://www.rfc-editor.org/pubprocess/ +- https://www.rfc-editor.org/rfc/rfc8729.html + - Explains governance +- Main docs for authors: https://authors.ietf.org/ +- https://www.ietf.org/how/ids/ + +### Trigger Federation + +By interacting with the forge, this will trigger the other entities AI to notify them optimally (**TODO** find notes on flow state priority interupts only) + +```bash +git show cfae0f85e:.github/workflows/alice_async_comms.yml | tee .github/workflows/alice_async_comms.yml +gh act run -P ubuntu-latest=ubuntu:22-04 -j posts -W .github/workflows/alice_async_comms.yml +``` + +## CI/CD + +This section covers the integration status of automated checks into the processes. + +- orphan branches and other best practices to facilitate CI +- Eventually SCITT as Version Control Software type stuff aka to facilitate decentralized goverance + - https://github.com/intel/dffml/discussions/1415 + - https://github.com/builtree/builtree/blob/main/governance/STEERING-COMMITTEE.md + +https://thenewstack.io/what-are-the-next-steps-for-feature-flags and the following image sum up the motivations behind the [Entity Analysis Trinity](https://github.com/intel/dffml/tree/main/docs/tutorials/rolling_alice/0000_architecting_alice#entity-analysis-trinity), ThreatOps, and VCS+CI/CD a la https://github.com/scitt-community/scitt-api-emulator/pull/27#issuecomment-1528073552 + +> ![thenewstack-deccc3f5-image4-me-trying-to-understand-the-benifits-of-clickops](https://user-images.githubusercontent.com/5950433/235471920-6f2228e1-76e4-4479-84c3-cb80326e80ce.png) + +## Maintainers + +This section covers call outs on specific behavior or expectations or boundries for different maintainers. This defines the threat model / trust boundries and their soul based auth ("Soul of the Software") strategic principle alignment report (a federated ORAS context addressed manifest of manifests which is the "clear for take off"). + +Boundries: I will federate changes from you and forward changes to others I am federating with if the analysis of the graph of thoughts leading to the send of the new data event is within acceptable risk tolerence. If we notice actions in the network unaligned to the defaults outlined in this document we we will begin enforcing these boundries. Additional boundries can be overlayed + +- #1287 + +Virtual branch - shared context dependent trains of thought within a poly-repo environment. If the overlays of an entity currently federating with. The N+1 federation new data event is always determined by a KERI duplicity detection protected channel. The tcb for trust evaluation is also party of relying party inputs. + +- https://github.com/pdxHijohnny/dotfiles/issues/1 + +## Codebase Housekeeping + +- TODO + - [ ] [`THREATS.md`](https://gist.github.com/pdxjohnny/07b8c7b4a9e05579921aa3cc8aed4866#file-rolling_alice_progress_report_0006_living_threat_models_are_better_than_dead_threat_models-md) + - [ ] https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/contributing/codebase.rst?plain=1#L1-L183 + - [ ] Naming conventions + - [ ] Dockerfile + - [ ] CI/CD Workflows + - [ ] Issues + - [ ] Pull Requests + +## CONTRIBUTING TO CONTRIBUTING + +This section defines our values and touches on their contections to strategic plans +and principles in breif. Please modify those in their source of truth sections above +unless the additional context within the values section all community members agree +is required for communication to be well spent time. + +![screenshot-of-dffml-contributing-docs-2024-08-06](https://github.com/user-attachments/assets/c3498152-869b-4a51-aad3-f5068be2919b) + +## Measuring Alignment + +**TODO** Value chain analysis to determine if proposed changes to this document and content thereof have proven aligned with the soul this project's software (aka this doc and `THREATS.md`: https://intel.github.io/dffml/main/contributing/gsoc/rubric.html) + +This rubric is was developed during the 2020 GSoC DFFML proposal review period. Reviewing +proposals is very challenging, we have lots of applicants that do great work and +needed to find a way to quantify their contributions. We use this rubric to do +so. + +### Alignment Rubric + +![Screenshot of grading rubric](https://dffml.github.io/dffml-pre-image-removal/master/_images/rubric-table.png) + +### Alignment Rubric Explanation + +Explains why each field was chosen for the rubric. Some fields are subjective, +others are objective. Each mentor will fill out a copy of the rubric for the +subjective portion of the rubric. One mentor will count up relevant statistics +to fill out the objective portion of the rubric. Once all proposals have been +reviewed, the mentors rubrics will be averaged for each proposal. And the final +score will be calculated for each proposal by tallying up all the points in the +averaged subjective rubrics and the objective rubric. The proposals will then +be ranked from highest to lowest. Final scoring will happen two days before +slot requests are due to give students the most time possible to get more +contributions in, get better at debugging, show self direction, and engage with +the community. + +#### Goals in Proposal + +The project proposed should have a clear value to the project's community. A +high score here means if the project is selected (and subsequently completed), +users would clearly benefit from it. + +#### Completeness of Proposal + +The proposal should contain enough details for it to be clear that the student +knows how to complete the goals they've outlined. More detail beyond proving +they know the basics of what needs to be done is better. If a student proposed +something but was short on detail, their contributions to the project should be +taken into account. If their proposal lacks detail on implementation of +something similar to what they've already done several times, it's not +necessary that they re-explain in detail in the proposal, their contributions +speak for themselves. + +#### Time Commitment + +GSoC expects students to spend 30+ hours a week working on their proposed +project / the project they are contributing to (assuming they've completed +their proposed project). Students vary in skill level. As such, mentors should +take their interactions with students into account as well as previous work a +student has completed to estimate if the student will be able to complete the +outlined proposal in the allotted time. Mentors should also think about students +previous work and how long it seemed like they spent working on previous pull +requests to estimate how long each action item in the proposal will take the +student. Using this estimate, mentors should respond in the rubric with their +thoughts on how many hours a week they think the student will be spending +working on their proposed project to complete it. + +#### Engagement with Community + +Student engagement with the community is key to their success, the success of +future GSoC applicants, and the project. We cannot effectively collaborate to +build open source software if we don't talk to each other. The best outcome of +GSoC is not only the completion of the student's project, but the student +becoming a mentor for other students or new community members. A high score +here shows active participation in the community and that the students actions +show them trending towards becoming a mentor / maintainer in this organization +or another someday. + +#### Mentor Vote + +Every mentor should vote for one proposal which is their personal favorite. +Each mentor has different aspects about the project (DFFML) that are important +to them (maintainers of different subsystems, etc.). Since the mentors will be +advising students, it's important that they believe in the projects they are +guiding. This is how they signal what they believe is important or cool. + +#### Self Directed + +While it's always okay to ask what to do, it's better to look at the list of +things to do and pick one. Open source projects put a lot of effort into +project management and organization of work items so that everyone knows what +the open bugs are on the project and what the planned enhancements are. +Everything is done in public because anything is accessible to anyone on the +internet and it's important that we all stay on the same page to effectively +collaborate. Self directed students follow contribution guidelines and +communicate their intentions to work on issues within the posted issue rather +than other channels of communication which don't allow others to see the status +of what's being worked on. This keeps the community in sync so there is no +duplication of work. In some projects (like DFFML) issues are labeled with the +estimated amount of work they will take to complete. Students who take on +larger issues will spend more time working on the problem on their own and less +time with a mentor stepping them through what to do. This is a measure of the +students resourcefulness and tenacity for solving difficult problems. + +#### Debugging + +The act of working on any problem, programming in particular, is an exercise in +figuring out what should be done, what has been done, and what's the current +problem that is keeping what has been done from being what should be done. This +loop of fail, fix, repeat, is debugging. Students should be actively testing +their contributions. When those tests fail they need to use critical thinking +to determine if what they've done is working or not. If it's not working they +need to figure out what the next step would be in fixing it, and try that. If +they can't figure it out, then they should ask for help. A student that asks +for help any time there is an issue without trying to figure out what the issue +is before asking for help is not putting in enough effort. In addition, tests +have to pass in the continuous integration (CI) environment. If the test +doesn't pass in CI, then the student should be performing the debugging process +looking at what's wrong in the CI environment. They should not say that they +don't know what is wrong because it works for them. Feigned ignorance of +failing tests does not excuse their failure. + +#### Contributions + +Some open source projects (like DFFML) label issues with the estimated amount +of work they will take to complete. Larger contributions, or those associated +with larger issues, receive more points than smaller contributions. The goal +here is to reward students who have put in more effort leading up to GSoC. +They've worked hard to learn about the project they wrote a proposal for, +and have worked hard to make that project better. + +## Alice: Abstracted Lifecycle Instantiatation of Contributor Efectivo + +> Upstream: [Rolling Alice: Volume 0: Introduction and Context](https://github.com/intel/dffml/blob/main/docs/tutorials/rolling_alice/0000_architecting_alice) + +To think about how we think about editing this document and how it should be +written, imagine an open source developer named Alice. Phrase things here so that +she could ramp up on the project given no previous context, assumputions about +known or practiced development methodologies, strategic principles, plans, and +values. Use this document as if it was the reference with top / override priority +when she is actively working within the context of this project. + +- Online cloning cuts our iteration time + - Artificial Life Is Coming Eventually + - Data flows are the parallel exploration of trains of thought (nested graphs) + - Natural selection and evolution + - Tree of life + - Parallel exploration of nested graphs + - Automated synchronization of system state across distinct timelines (distinct roots) + - Enables the resolution of system state post haste, post state, and post date + - See fuzzy finding later in this doc: find "join disparate roots" + - This is effectively out of order execution at a higher level of abstraction, in the aggregate, so as to bring the aggregate set of agents involved to an equilibrium state + - We are building the thought communication protocol, to communicate thought is to learn + - If we can describe any architecture, any problem space, we can describe any thought + - To describe a thought most completely, one must know how to best communicate with that entity + - That entity, that agent, is a moving target for communication at it's optimal rate of learning. + - It's past is relevant in determining it's future as it's past determines what will resonate best with it in terms of forming conceptual linkages. + - Past doesn't have to be memory, data and compute are the same in our architecture + - Hardwired responses get encoded the same way, it's all the signal, the probability + - When Alice goes through the looking glass she'll take us with her in sprit, and come back to communicate to us how best to proceed, in every way. + - The less (more?) rambling way of putting this would be, we need our AI to be a true to us extension of ourselves, or of our ad-hoc formed groups, they need to be true to those strategic principles we've communicated to the machine. If we can trust their transparency (estimates/forecasts and provenance on that) about their ability to stay aligned to those principles, then we can accurately assess operating risk and it's conformance to our threat model or any threat model the execution of the job fits within. + - This means we can trust our AI to not influence us in the wrong ways. + - This means we can trust it to influence us in the right ways, the ways we want to influence ourselves, or our software development lifecycle. + - This assessment of the level of trust fundamentally comes from our analysis of our analysis of our software development lifecycle, our Entity Analysis Trinity. + +### Entity Analysis Trinity + +We leverage the Entity Analysis Trinity to help us bridge the gap between +our technical activities and processes and the conceptual model we are +following as we analyze the softare / system / entity over it's lifecycle. + +![Entity Analysis Trinity](https://user-images.githubusercontent.com/5950433/188203911-3586e1af-a1f6-434a-8a9a-a1795d7a7ca3.svg) + +### Terminology + +- Open Architecture + - Universal Blueprint + - Standard architecture we use to describe anything. Provides the ability to use / reference domain specific architectures as needed to define architecture of whole. + - https://github.com/intel/dffml/blob/main/docs/arch/0009-Open-Architecture.rst +- Think + - Come up with new data flows and system context input +- Thoughts + - Data Flows and system context input pairs (these two plus orchestration config we get the whole system context) +- Downstream Validation + - Running validation on all dependent packages to check for API breakages or regressions in the ecosystem + +### Expectations + +Alice is going to be held to very high standards. We should expect this list to grow for a long time (years). This list of expectations may at times contain fragments which need to be worked out more and are only fragment so the ideas don't get forgotten. + +- Alice should be able to work on any project as a remote developer + - She should be able to make changes to projects following the branch by abstraction methodology + - When she works on a github issue she'll comment what commands she tries and what files she modifies with diffs +- Alice will maintain a system which allows her to respond to asynchronous messages + - Likely a datastore with the ability to listen for changes + - Changes would be additions of messages from different sources (email, chat, etc.) +- Alice should be able to accept a meeting, join it, and talk to you + - If Alice notices conversation getting off topic, she could interject to ask how it relates, and then update references in docs to that effect. + - You should be able to have a conversation about a universal blueprint and she should be able to go act on it. + - She should be able to analyze any codebase you have access to live and build and walk you through architecture diagrams + - Alice build me a linux distro with these versions of these applications deploy it in a VM in QEMU, show me the screen while it's booting. Then give me control of it via this meeting. ... Okay now snapshot and deploy to XYZ CSP. + - She should figure out how to validate that she has a working linux distro by overlaying discovered tests with intergration tests such as boot check via qemu serial. + - Alice, spin up ABC helm charts and visualize the cluster (viewing in an AR headset) + - Alice, let's talk about the automating classification web app included in the example. + - Alice, give us an overview of the threats on our database, deploy the prod backup to a new environment. Attempt to exploit known threats and come up with new ones for the next 2 weeks. Submit a report and presentation with your findings. Begin work on issues found as you find them. +- We should be able to see Alice think and understand her trains of thought + - If Alice is presenting and she estimates thinking of the correct solution will take longer than a reasonable time her next word is expected by to keep regular conversational cadence, she should either offer to brainstorm, work through it and wait until it makes sense to respond, maybe there are situations where the output is related to saving someone's life, then maybe she interupts as soon as she's done thinking. Provided she didn't detect that the train of thought which was being spoken about by others was not of higher prioritiy than her own (with regards to lifesaving metrics). + +### Alice's Understanding of Software Engineering + +We'll teach Alice what she needs to know about software engineering though our InnerSource series. She'll follow the best practices outlined there. She'll understand a codebase's health in part using [InnerSource metric collectors](https://intel.github.io/dffml/main/examples/innersource/swportal.html). + +Alice will see problems and look for solutions. Problems are gaps between the present system capabilities and desired system capabilities or interpretations of outputs of strategic plans which are unfavorable by the strategic decision maker or the prioritizer. From 6f709dad4e51f939be74da1b5865963aa640e006 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 14:28:54 -0700 Subject: [PATCH 02/22] CONTRIBUTING: Add Poly-Repo Development Culture section --- CONTRIBUTING.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5ba671d0ce..c7cd1f48c0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -67,6 +67,31 @@ It defines actions taken by maintainers. Timelines for progression and example a - https://github.com/intel/dffml/issues/1657 - https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 +## Poly-Repo Development Culture + +A poly-repo (or polyglot repository) development culture refers to a software development practice where each project or service is stored in its own separate version control repository, as opposed to a mono-repo approach where multiple projects or services reside within a single repository. This approach is often used in large organizations where there are many independent projects or teams working on different parts of a system. + +Here are some characteristics of a poly-repo development culture: + +- Isolation: Each repository can be managed independently, allowing for tailored workflows, versioning, and access controls that suit the specific needs of each project. +- Decentralization: Teams can work autonomously without being affected by changes in other projects. This can reduce the coordination overhead that is often required in a mono-repo setup. +- Flexibility: Different projects can use different tools, programming languages, and frameworks that are best suited for their specific requirements. +- Scalability: As the organization grows, new repositories can be created without impacting existing ones, making it easier to scale the development process. + +However, a poly-repo approach can also introduce challenges, such as increased complexity in managing dependencies and versioning, as well as potential duplication of code and effort across repositories. + +Contribution guidelines play a crucial role in a poly-repo development culture by providing clear instructions and standards for contributing to each repository. These guidelines help enable quick ramp-up for new contributors and fast completion of issues by addressing several key areas: + +- Coding Standards: By outlining the coding conventions and best practices, contribution guidelines help maintain code quality and consistency across the project. +- Workflow: Guidelines often include the preferred workflow for contributions, such as how to submit pull requests, conduct code reviews, and merge changes. This helps streamline the development process and reduces friction among team members. +- Issue Tracking: Clear instructions on how to report bugs, request features, and track issues ensure that contributors can easily understand the current state of the project and what needs attention. +- Setup Instructions: For new contributors, guidelines can provide step-by-step instructions on setting up the development environment, which is crucial for a quick start. +- Testing: Guidelines may include testing requirements and instructions on how to write and run tests, which is essential for maintaining the stability of the project. +- Documentation: Encouraging contributors to document their code and update existing documentation helps keep the project understandable and maintainable. +- Communication: Guidelines often outline the preferred channels and etiquette for communication among contributors, which is important for collaboration and coordination. + +By establishing clear contribution guidelines, organizations can foster a more efficient and collaborative development environment, even when working with multiple repositories. This can lead to quicker onboarding of new team members, more efficient resolution of issues, and ultimately, a more productive development process. + ## Best Practices CI/CD and GitOps facilitate. From c553f84d57cbb16be16b35b81c30ec2950949f0e Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 14:39:54 -0700 Subject: [PATCH 03/22] CONTRIBUTING: Add SCITT as tool call validating proxy references --- CONTRIBUTING.md | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c7cd1f48c0..8655a48a79 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -55,18 +55,6 @@ on each commit / packet / new data event: https://docs.tea.xyz/tea-white-paper/w > > This is our default settings for how Alice will interact with an open source community. CI/CD is how we role model the behavior (since she's an AI agent executing policy engine workflows in GitHub Actions format). we expect for and will be defining overlays. It effectivly defines the projects default win criteria: Successful contributions aligned with the purpose of the project. If a patchset aligns it's ready to go. CI/CD for values alignment. -This document outlines requirements and their stringency levels using different examples. -It defines actions taken by maintainers. Timelines for progression and example architypes for varying levels of maintainer / contributor involvement / engagement. - -- https://github.com/intel/dffml/issues/1207 -- https://github.com/intel/dffml/issues/1252 -- https://github.com/intel/dffml/issues/1061 -- https://github.com/intel/dffml/issues/1400 -- https://github.com/intel/dffml/issues/1273 -- https://github.com/intel/dffml/issues/1300 -- https://github.com/intel/dffml/issues/1657 -- https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 - ## Poly-Repo Development Culture A poly-repo (or polyglot repository) development culture refers to a software development practice where each project or service is stored in its own separate version control repository, as opposed to a mono-repo approach where multiple projects or services reside within a single repository. This approach is often used in large organizations where there are many independent projects or teams working on different parts of a system. @@ -114,6 +102,7 @@ This section covers call outs on specific behavior or expectations or boundries - https://github.com/intel/dffml/issues/1659 - Some way we can see if a complete plan for execution (dataflow / workflow hypothesis and analysis via policy engine) - https://github.com/pdxjohnny/dotfiles/blob/8d9850f85314a9f5c30f5bb7b8e47ba3857357be/forge-install.sh#L1-L584 + ### Architecture Design Records - First have agents write specs as first step, then iterate on them and push the plans to orphan branches on forks, use git lfs for big files. @@ -123,14 +112,18 @@ This section covers call outs on specific behavior or expectations or boundries - Main docs for authors: https://authors.ietf.org/ - https://www.ietf.org/how/ids/ -### Trigger Federation +### Trigger Federation: SCITT: AI Agent Workload Identity with LiteLLM Recap (2024-07-11) By interacting with the forge, this will trigger the other entities AI to notify them optimally (**TODO** find notes on flow state priority interupts only) -```bash -git show cfae0f85e:.github/workflows/alice_async_comms.yml | tee .github/workflows/alice_async_comms.yml -gh act run -P ubuntu-latest=ubuntu:22-04 -j posts -W .github/workflows/alice_async_comms.yml -``` +- https://github.com/scitt-community/scitt-api-emulator/pull/37 +- https://github.com/pdxjohnny/litellm/commit/3b6b7427b15c0cadd23a8b5da639e22a2fba5043 +- https://github.com/scitt-community/scitt-api-emulator/commits/1e4ec8844aa1ead539ddfd1ac9b71623e25f4c0d +- https://mailarchive.ietf.org/arch/msg/scitt/BjCAySWyODuhDWwn4kMtCoY5eDA/ +- https://github.com/search?q=repo%3Aintel%2Fdffml+Phase+0&type=code&p=2 + - https://github.com/intel/dffml/blob/c50b68c3af49167e9cbfef4c31d4096de9e1846a/docs/discussions/alice_engineering_comms/0572/reply_0000.md + - https://github.com/intel/dffml/blob/c50b68c3af49167e9cbfef4c31d4096de9e1846a/docs/discussions/alice_engineering_comms/0573/reply_0000.md + - https://github.com/intel/dffml/blob/c50b68c3af49167e9cbfef4c31d4096de9e1846a/docs/discussions/alice_engineering_comms/0574/reply_0000.md ## CI/CD @@ -381,3 +374,17 @@ Alice is going to be held to very high standards. We should expect this list to We'll teach Alice what she needs to know about software engineering though our InnerSource series. She'll follow the best practices outlined there. She'll understand a codebase's health in part using [InnerSource metric collectors](https://intel.github.io/dffml/main/examples/innersource/swportal.html). Alice will see problems and look for solutions. Problems are gaps between the present system capabilities and desired system capabilities or interpretations of outputs of strategic plans which are unfavorable by the strategic decision maker or the prioritizer. + +## References + +This document outlines requirements and their stringency levels using different examples. +It defines actions taken by maintainers. Timelines for progression and example architypes for varying levels of maintainer / contributor involvement / engagement. + +- https://github.com/intel/dffml/issues/1207 +- https://github.com/intel/dffml/issues/1252 +- https://github.com/intel/dffml/issues/1061 +- https://github.com/intel/dffml/issues/1400 +- https://github.com/intel/dffml/issues/1273 +- https://github.com/intel/dffml/issues/1300 +- https://github.com/intel/dffml/issues/1657 +- https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 From 163de403d9b1762b26f676904d5000fbf033e23e Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 14:57:56 -0700 Subject: [PATCH 04/22] CONTRIBUTING: Realizing Value Chains Through Application of Anarchistic Development Practices --- CONTRIBUTING.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8655a48a79..70545b697c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -# Contributing +# CONTRIBUTING Please see the [contributing docs page](https://intel.github.io/dffml/main/contributing/). @@ -10,6 +10,8 @@ Please see the [contributing docs page](https://intel.github.io/dffml/main/contr ## Abstract +Federation is the act of communicating data about multiple streams of topics. Federation enables decentralized social networking and is the act of creating, updating, deleting, and delivering notifications and content. This CONTRIBUTING document details trust boundries and evaluation guidelines to determine security properties of abitrary entities so as optimally facilitate secure communication and collaberation towards shared goals while maintaining integrety of all trust boundries of all entities engaged. These methodolgies enable work on this project to progress in a self-directed nature where all contribuing and relant entities maintain agency and often distint strategic plans, principles and values for themselves and their long term or ad-hoc formed organizations. + This document outlines best practices for poly-repo maintainers and contributors, detailing strategic plans and principles for federated code repositories. It emphasizes continuous trust evaluation, automated CI/CD workflows, and federated transparency receipts to ensure alignment with community-agreed values and strategic objectives. The document also addresses developer and maintainer expectations, federation triggers, and the integration of automated checks into CI/CD processes. - Trust boundaries are evaluated continuously, and misalignments trigger retraining of AI models and potential blocking of data events. From 1cc77e92c4a46bb717fbf40d8e82bb58acdb4788 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:03:52 -0700 Subject: [PATCH 05/22] CONTRIBUTING: Federation: Inline WIP SCITT Use Case Header --- CONTRIBUTING.md | 164 +++++++++++++++++++++++++++++++----------------- 1 file changed, 108 insertions(+), 56 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 70545b697c..9580ea8fb2 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,6 +1,7 @@ # CONTRIBUTING -Please see the [contributing docs page](https://intel.github.io/dffml/main/contributing/). +- Please see the [contributing docs page for DFFML 1st Party Contributing Docs](https://intel.github.io/dffml/main/contributing/). +- The following document is about contribuing to the DFFML [poly-repo 1st, 2nd, and 3rd party ecosystems]() > **WARNING: SECURITY** > @@ -38,15 +39,21 @@ strategic plans and principles. These measures are in place to maintain trust, security, and alignment with community goals. -When no contact with an entity: Blocking all attempts at federation of new data events directly or when detected in the bill of materials graph analysis of data events from old. This is our trigger for retraining the models which is why it's AI Looped In CI/CD Execution. Overlays may define additional consequencies. Overlays in use get added to all data event BOMs and TCB evaluation is done continuously and retroactivly invalidated if we learn nodes in a graph are not aligned with our running context's strategic plans, principles, and values. -Following these recommendations for communication results in a record of the actions taken -for each train of thought where data has been shared between entities. The authors of this -document have made a best effort attempt to completely capture the these strategic values, plans, -and principles. However, trust evaluation is an ever changing game and context applicable overlays -and future updates to this doc will be done continuously. It should be viewed as a -lessons learned doc and suggested interaction patterns -context and the trust levels of the data within those contexts and the trust level in the -policy evaluation / analysis executed and the +When there is no contact with an entity, we block all attempts at federating new data events. +This applies both directly and when detected through bill of materials (BOM) graph analysis +of past data events. This is our trigger for retraining the models, which is why it's +referred to as AI Looped In CI/CD Execution. Overlays may define additional consequences. +When overlays are used, they are added to all data event BOMs, and Trusted Computing Base (TCB) +evaluations are conducted continuously. These evaluations are retroactively invalidated if +we learn that nodes in a graph do not align with our strategic plans, principles, and values. + +Adhering to these communication recommendations results in a record of actions taken for +each train of thought where data has been shared between entities. The authors of this +document have made a best effort to fully capture these strategic values, plans, and +principles. However, trust evaluation is an ever-changing process. Context-dependent +overlays and future updates to this document will be made continuously. It SHOULD be +viewed as a lessons-learned document, suggesting interaction patterns, the trust levels +of the data within those contexts, and the trust level in the policy evaluation and analysis executed. **TODO** Document the anti-skynet part which is also the part which will auto help filter out people with malicious intent (the on the scam phone call with grandma defense idea) @@ -116,7 +123,41 @@ This section covers call outs on specific behavior or expectations or boundries ### Trigger Federation: SCITT: AI Agent Workload Identity with LiteLLM Recap (2024-07-11) -By interacting with the forge, this will trigger the other entities AI to notify them optimally (**TODO** find notes on flow state priority interupts only) +> Upstream: [WIP: Use Case: Attestations of alignment to S2C2F and org overlays #18](https://github.com/pdxjohnny/use-cases/blob/04499f4e4dedcec9add0e627f8aa742151f99297/openssf_metrics.md) + +Federation is triggered when an entity interacts with a forge, this will trigger +the other entities AI to notify them optimally (**TODO** find notes on flow state priority interupts only). + +Think of federation as collection of data into shared database. +Each database tells the other databases when there are updates. +We use federation to enable self reporting and granularity +as applicable to ad-hoc formed policy as desired by end-user. + +- Related: https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt +- This use case will be mostly focused on the policy / gatekeeper component and federation components of [SCITT](https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/). + - 5.2.2: Registration Policies + - 7: Federation +- This use case is a specialization of (cross between) the following use cases from the [Detailed Software Supply Chain Uses Cases for SCITT](https://datatracker.ietf.org/doc/draft-ietf-scitt-software-use-cases/) doc. + - 3.3: Security Analysis of a Software Product + - We'll cover OpenSSF Scorecard and other analysis mechanisms including meta static analysis / aggregation (example: GUAC). + - 3.4: Promotion of a Software Component by multiple entities + - We'll cover how these entities can leverage analysis mechanisms to achieve feature and bugfix equilibrium across the diverged environment. + - Future use cases could explore semantic patching to patch across functionally similar +- Alice builds a python Package + - Notary checks for receipts from needed sign offs + - In this example the SCITT instance the notary inserting into it have the same insert/sign policies (system context, dataflow, open architecture document, living threat model) + - Alice has two jobs, one which bulds a Python package, and other which runs SCITT in a TEE (perhaps with a redis service container to ease comms) + - She auths to job in TEE (SGX in this example) local SCITT via OIDC, the SCITT notary and ledger are unified in this example and a claim is inserted that she had a valid OIDC token for job_workflow_sha + repositoryUri + repository_id + job.. The enclave is then dumped at the end of the job so that it can be joined to an other transparency services. This enables decentralized hermetic builds via federation of transparency services (by grafting them into org sepcific registires ad-hoc via CD eventing of forge federation). + - The notary is what's verifying the OIDC token. + - We can runs-on an SGX machine to do that. + - Using confidential compute and attribute based trust we can authenticate to a usage policy, this is the place for on/off chain contract negotiation. + - Off chain would be whenever we have to enter a hermetic enviornment (IPVM). + - Activity Pub Actors for signoff, send to inbox requesting signoff (issue ops), they say okay I'll add this exception sign off for this use case /system context to SCITT + - Then policy violating system context collects all needed exception receipts, listens for their entry via listening to the SCITT ActivityPub stream, and then re-issues request for admissions along with exception receipts using overlay section of serialized system context object + +> SCITT Federation as firewall demo: [https://github.com/scitt-community/scitt-api-emulator/tree/64cc40e269feba5cec8fb096d0ba648e921b6069](https://github.com/pdxjohnny/scitt-api-emulator/tree/demo-instance) + +[![SCITT Federation as Firewall](https://asciinema.org/a/622103.svg)](https://asciinema.org/a/622103) - https://github.com/scitt-community/scitt-api-emulator/pull/37 - https://github.com/pdxjohnny/litellm/commit/3b6b7427b15c0cadd23a8b5da639e22a2fba5043 @@ -195,22 +236,22 @@ reviewed, the mentors rubrics will be averaged for each proposal. And the final score will be calculated for each proposal by tallying up all the points in the averaged subjective rubrics and the objective rubric. The proposals will then be ranked from highest to lowest. Final scoring will happen two days before -slot requests are due to give students the most time possible to get more +slot requests are due to give contributors the most time possible to get more contributions in, get better at debugging, show self direction, and engage with the community. #### Goals in Proposal -The project proposed should have a clear value to the project's community. A +The project proposed MUST have a clear value to the project's community. A high score here means if the project is selected (and subsequently completed), users would clearly benefit from it. #### Completeness of Proposal -The proposal should contain enough details for it to be clear that the student +The proposal MUST contain enough details for it to be clear that the contributor knows how to complete the goals they've outlined. More detail beyond proving -they know the basics of what needs to be done is better. If a student proposed -something but was short on detail, their contributions to the project should be +they know the basics of what needs to be done is better. If a contributor proposed +something but was short on detail, their contributions to the project MAY be taken into account. If their proposal lacks detail on implementation of something similar to what they've already done several times, it's not necessary that they re-explain in detail in the proposal, their contributions @@ -218,16 +259,16 @@ speak for themselves. #### Time Commitment -GSoC expects students to spend 30+ hours a week working on their proposed +We expect contributors to estimate their engagement in hours a week for their proposed project / the project they are contributing to (assuming they've completed -their proposed project). Students vary in skill level. As such, mentors should -take their interactions with students into account as well as previous work a -student has completed to estimate if the student will be able to complete the -outlined proposal in the allotted time. Mentors should also think about students +their proposed project). Students vary in skill level. As such, mentors MUST +take their interactions with contributors into account as well as previous work a +contributor has completed to estimate if the contributor will be able to complete the +outlined proposal in the allotted time. Mentors MAY also think about contributors previous work and how long it seemed like they spent working on previous pull requests to estimate how long each action item in the proposal will take the -student. Using this estimate, mentors should respond in the rubric with their -thoughts on how many hours a week they think the student will be spending +contributor. Using this estimate, mentors MUST respond in the rubric with their +thoughts on how many hours a week they think the contributor will be spending working on their proposed project to complete it. #### Engagement with Community @@ -235,18 +276,18 @@ working on their proposed project to complete it. Student engagement with the community is key to their success, the success of future GSoC applicants, and the project. We cannot effectively collaborate to build open source software if we don't talk to each other. The best outcome of -GSoC is not only the completion of the student's project, but the student -becoming a mentor for other students or new community members. A high score -here shows active participation in the community and that the students actions +GSoC is not only the completion of the contributor's project, but the contributor +becoming a mentor for other contributors or new community members. A high score +here shows active participation in the community and that the contributors actions show them trending towards becoming a mentor / maintainer in this organization or another someday. #### Mentor Vote -Every mentor should vote for one proposal which is their personal favorite. +Every mentor MAY vote for one proposal which is their personal favorite. Each mentor has different aspects about the project (DFFML) that are important to them (maintainers of different subsystems, etc.). Since the mentors will be -advising students, it's important that they believe in the projects they are +advising contributors, it's important that they believe in the projects they are guiding. This is how they signal what they believe is important or cool. #### Self Directed @@ -257,7 +298,7 @@ project management and organization of work items so that everyone knows what the open bugs are on the project and what the planned enhancements are. Everything is done in public because anything is accessible to anyone on the internet and it's important that we all stay on the same page to effectively -collaborate. Self directed students follow contribution guidelines and +collaborate. Self directed contributors follow contribution guidelines and communicate their intentions to work on issues within the posted issue rather than other channels of communication which don't allow others to see the status of what's being worked on. This keeps the community in sync so there is no @@ -265,23 +306,23 @@ duplication of work. In some projects (like DFFML) issues are labeled with the estimated amount of work they will take to complete. Students who take on larger issues will spend more time working on the problem on their own and less time with a mentor stepping them through what to do. This is a measure of the -students resourcefulness and tenacity for solving difficult problems. +contributors resourcefulness and tenacity for solving difficult problems. #### Debugging The act of working on any problem, programming in particular, is an exercise in -figuring out what should be done, what has been done, and what's the current -problem that is keeping what has been done from being what should be done. This -loop of fail, fix, repeat, is debugging. Students should be actively testing +figuring out what could be done, what has been done, and what's the current +problem that is keeping what has been done from being what needs to be done. This +loop of fail, fix, repeat, is debugging. Students MUST be actively testing their contributions. When those tests fail they need to use critical thinking to determine if what they've done is working or not. If it's not working they need to figure out what the next step would be in fixing it, and try that. If -they can't figure it out, then they should ask for help. A student that asks +they can't figure it out, then they SHOULD ask for help. A contributor that asks for help any time there is an issue without trying to figure out what the issue is before asking for help is not putting in enough effort. In addition, tests have to pass in the continuous integration (CI) environment. If the test -doesn't pass in CI, then the student should be performing the debugging process -looking at what's wrong in the CI environment. They should not say that they +doesn't pass in CI, then the contributor MUST be performing the debugging process +looking at what's wrong in the CI environment. They SHOULD not say that they don't know what is wrong because it works for them. Feigned ignorance of failing tests does not excuse their failure. @@ -290,7 +331,7 @@ failing tests does not excuse their failure. Some open source projects (like DFFML) label issues with the estimated amount of work they will take to complete. Larger contributions, or those associated with larger issues, receive more points than smaller contributions. The goal -here is to reward students who have put in more effort leading up to GSoC. +here is to reward contributors who have put in more effort leading up to GSoC. They've worked hard to learn about the project they wrote a proposal for, and have worked hard to make that project better. @@ -298,7 +339,7 @@ and have worked hard to make that project better. > Upstream: [Rolling Alice: Volume 0: Introduction and Context](https://github.com/intel/dffml/blob/main/docs/tutorials/rolling_alice/0000_architecting_alice) -To think about how we think about editing this document and how it should be +To think about how we think about editing this document and how it MUST be written, imagine an open source developer named Alice. Phrase things here so that she could ramp up on the project given no previous context, assumputions about known or practiced development methodologies, strategic principles, plans, and @@ -351,25 +392,25 @@ following as we analyze the softare / system / entity over it's lifecycle. ### Expectations -Alice is going to be held to very high standards. We should expect this list to grow for a long time (years). This list of expectations may at times contain fragments which need to be worked out more and are only fragment so the ideas don't get forgotten. +Alice is going to be held to very high standards. We expect this list to grow for a long time (years). This list of expectations may at times contain fragments which need to be worked out more and are only fragment so the ideas don't get forgotten. -- Alice should be able to work on any project as a remote developer - - She should be able to make changes to projects following the branch by abstraction methodology +- Alice MUST be able to work on any project as a remote developer + - She MUST be able to make changes to projects following the branch by abstraction methodology - When she works on a github issue she'll comment what commands she tries and what files she modifies with diffs -- Alice will maintain a system which allows her to respond to asynchronous messages +- Alice MUST maintain a system which allows her to respond to asynchronous messages - Likely a datastore with the ability to listen for changes - Changes would be additions of messages from different sources (email, chat, etc.) -- Alice should be able to accept a meeting, join it, and talk to you +- Alice SHOULD be able to accept a meeting, join it, and talk to you - If Alice notices conversation getting off topic, she could interject to ask how it relates, and then update references in docs to that effect. - - You should be able to have a conversation about a universal blueprint and she should be able to go act on it. - - She should be able to analyze any codebase you have access to live and build and walk you through architecture diagrams + - You MUST be able to have a conversation about a universal blueprint and edit it and she MAY be able to go act on the fulfilment of that conversation. + - She MUST be able to analyze any codebase you have access to live and build and walk you through architecture diagrams - Alice build me a linux distro with these versions of these applications deploy it in a VM in QEMU, show me the screen while it's booting. Then give me control of it via this meeting. ... Okay now snapshot and deploy to XYZ CSP. - - She should figure out how to validate that she has a working linux distro by overlaying discovered tests with intergration tests such as boot check via qemu serial. + - Example test case: She MUST figure out how to validate that she has a working linux distro by overlaying discovered tests with intergration tests such as boot check via qemu serial. - Alice, spin up ABC helm charts and visualize the cluster (viewing in an AR headset) - Alice, let's talk about the automating classification web app included in the example. - Alice, give us an overview of the threats on our database, deploy the prod backup to a new environment. Attempt to exploit known threats and come up with new ones for the next 2 weeks. Submit a report and presentation with your findings. Begin work on issues found as you find them. -- We should be able to see Alice think and understand her trains of thought - - If Alice is presenting and she estimates thinking of the correct solution will take longer than a reasonable time her next word is expected by to keep regular conversational cadence, she should either offer to brainstorm, work through it and wait until it makes sense to respond, maybe there are situations where the output is related to saving someone's life, then maybe she interupts as soon as she's done thinking. Provided she didn't detect that the train of thought which was being spoken about by others was not of higher prioritiy than her own (with regards to lifesaving metrics). +- We SHOULD be able to see Alice think and understand her trains of thought + - If Alice is presenting and she estimates thinking of the correct solution will take longer than a reasonable time her next word is expected by to keep regular conversational cadence, she SHOULD either offer to brainstorm, work through it and wait until it makes sense to respond, maybe there are situations where the output is related to saving someone's life, then maybe she interupts as soon as she's done thinking. Provided she didn't detect that the train of thought which was being spoken about by others was not of higher prioritiy than her own (with regards to top priority level metrics). ### Alice's Understanding of Software Engineering @@ -382,11 +423,22 @@ Alice will see problems and look for solutions. Problems are gaps between the pr This document outlines requirements and their stringency levels using different examples. It defines actions taken by maintainers. Timelines for progression and example architypes for varying levels of maintainer / contributor involvement / engagement. -- https://github.com/intel/dffml/issues/1207 -- https://github.com/intel/dffml/issues/1252 -- https://github.com/intel/dffml/issues/1061 -- https://github.com/intel/dffml/issues/1400 -- https://github.com/intel/dffml/issues/1273 -- https://github.com/intel/dffml/issues/1300 -- https://github.com/intel/dffml/issues/1657 -- https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 +- 1st Party + - https://github.com/intel/dffml/issues/1207 + - https://github.com/intel/dffml/issues/1252 + - https://github.com/intel/dffml/issues/1061 + - https://github.com/intel/dffml/issues/1400 + - https://github.com/intel/dffml/issues/1273 + - https://github.com/intel/dffml/issues/1300 + - https://github.com/intel/dffml/issues/1657 + - https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 +- IETF + - https://www.rfc-editor.org/rfc/rfc2119 + - https://datatracker.ietf.org/wg/scitt/about/ + - https://scitt.io + - + - https://datatracker.ietf.org/wg/keytrans/about/ +- KERI + - https://keri.one + - https://github.com/decentralized-identity/keri/blob/352fd2c30bf3e76e8f8f78d2edccd01a9f943464/docs/KERI-made-easy.md +- World From 5197c8dbe303c439ccd34c994b6f5b79ee7a668f Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:19:06 -0700 Subject: [PATCH 06/22] CONTRIBUTING: Rework references section --- CONTRIBUTING.md | 39 ++++++++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9580ea8fb2..88acc5be7a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -189,7 +189,7 @@ Boundries: I will federate changes from you and forward changes to others I am f - #1287 -Virtual branch - shared context dependent trains of thought within a poly-repo environment. If the overlays of an entity currently federating with. The N+1 federation new data event is always determined by a KERI duplicity detection protected channel. The tcb for trust evaluation is also party of relying party inputs. +Virtual branch - shared context dependent trains of thought within a poly-repo environment. If the overlays of an entity currently federating with. The N+1 federation new data event is always determined by a KERI duplicity detection protected channel (this is critical because or else we are not able to see who is being duplictus over time, which we need for the relying parties analysis of ClearForTakeoff for AI agent (workload) identity (OIDC, sould based auth). The tcb for trust evaluation is also party of relying party inputs. - https://github.com/pdxHijohnny/dotfiles/issues/1 @@ -423,7 +423,9 @@ Alice will see problems and look for solutions. Problems are gaps between the pr This document outlines requirements and their stringency levels using different examples. It defines actions taken by maintainers. Timelines for progression and example architypes for varying levels of maintainer / contributor involvement / engagement. -- 1st Party +- Keyword Definitions used in Documentation + - https://www.rfc-editor.org/rfc/rfc2119 +- DFFML - https://github.com/intel/dffml/issues/1207 - https://github.com/intel/dffml/issues/1252 - https://github.com/intel/dffml/issues/1061 @@ -432,13 +434,28 @@ It defines actions taken by maintainers. Timelines for progression and example a - https://github.com/intel/dffml/issues/1300 - https://github.com/intel/dffml/issues/1657 - https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 -- IETF - - https://www.rfc-editor.org/rfc/rfc2119 - - https://datatracker.ietf.org/wg/scitt/about/ +- OpenSSF + - [OpenSSF: Secure Supply Chain Consumption Framework (S2C2F): Simplified Requirements: Appendix: Relation to SCITT](https://github.com/ossf/s2c2f/blob/a08b79e61e27cc1e036837d93b32f2b4a9766cc4/specification/framework.md#appendix-relation-to-scitt) + - > The Supply Chain Integrity, Transparency, and Trust initiative, or SCITT, is a set of proposed industry standards for managing the compliance of goods and services across end-to-end supply chains. In the future, we expect teams to output "attestations of alignment" to the S2C2F requirements and store it in SCITT. The format of such attestations is to be determined. + - These attestations of alignment are outputs from successful chains of policy engine evalutions + - **TODO** relying party phase stuff from SCITT + LiteLLM commits linked added comments in code + - > ING-4 Mirror a copy of all OSS source code to an internal location + - This doc and the `THREATS.md`, the repo, and context data gained from allowlisted trusted sources seeds the basis for the trust store in that those aspects define the policy engines initial execution state pre-first new data event federation. The seed data is the basis from which all policy engine evalutions begin, as models within them may change given the inherent feedback loop in decentralized value chain analysis. +- Luke 8:17 + - IETF - https://scitt.io - - - - https://datatracker.ietf.org/wg/keytrans/about/ -- KERI - - https://keri.one - - https://github.com/decentralized-identity/keri/blob/352fd2c30bf3e76e8f8f78d2edccd01a9f943464/docs/KERI-made-easy.md -- World + - https://datatracker.ietf.org/wg/scitt/about/ + - https://datatracker.ietf.org/wg/keytrans/about/ + - KERI + - https://keri.one + - https://github.com/decentralized-identity/keri/blob/352fd2c30bf3e76e8f8f78d2edccd01a9f943464/docs/KERI-made-easy.md + - > indirect nethod: "Because I am not always online I have my identifier's history served by online Witnesses. Your validator can do duplicity detection on those witnesses and validate whether or not I am being duplicitous" + - > Ambient verifiability: Verifiable by anyone, anywhere, at anytime. E.g. Ambient Duplicity Detection describes the possibility of detecting duplicity by anyone, anywhere, anytime. + - This fits nicely with SCITT's COSE countersigned receipts + - > Duplicity + > + > In KERI consistency is is used to described data that is internally consistent and cryptographically verifiably so. Duplicity is used to describe external inconsistency. Publication of two or more versions of a KEL log, each of which is internally consistent is duplicity. Given that signatures are non-repudiable any duplicity is detectable and provable given possession of any two mutually inconsistent versions of a KEL. + > + > In common language 'duplicity' has a slightly different connotation: 'two-facedness', 'dishonesty', 'deceitfulness', 'deviousness,'two-facedness', 'falseness'. +- World Wide Web Consortium + - https://activitypub.rocks From b89da10d4567f8cdbf3d48e27d5136179eadcba3 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:20:38 -0700 Subject: [PATCH 07/22] CONTRIBUTING: link to 2nd party doc --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88acc5be7a..88d3590432 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,7 @@ # CONTRIBUTING - Please see the [contributing docs page for DFFML 1st Party Contributing Docs](https://intel.github.io/dffml/main/contributing/). -- The following document is about contribuing to the DFFML [poly-repo 1st, 2nd, and 3rd party ecosystems]() +- The following document is about contribuing to the DFFML [poly-repo 1st, 2nd, and 3rd party ecosystems](https://github.com/intel/dffml/pull/1061/files#diff-c7d7828822f15922ed830bb6f3148edc97c291c809836b1a1808165d36bd8c9d) > **WARNING: SECURITY** > From 05dcd567b6df7d7fec4ac63b6b5c35a4c4ccc5a3 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:23:46 -0700 Subject: [PATCH 08/22] CONTRIBUTING: Alice: Link to top level of tutorial --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 88d3590432..c161c86741 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -337,7 +337,7 @@ and have worked hard to make that project better. ## Alice: Abstracted Lifecycle Instantiatation of Contributor Efectivo -> Upstream: [Rolling Alice: Volume 0: Introduction and Context](https://github.com/intel/dffml/blob/main/docs/tutorials/rolling_alice/0000_architecting_alice) +> Upstream: [Rolling Alice: Volume 0: Introduction and Context](https://github.com/intel/dffml/tree/main/docs/tutorials/rolling_alice/) To think about how we think about editing this document and how it MUST be written, imagine an open source developer named Alice. Phrase things here so that From 43f0ac877ad0c1f04aa8846378de0092eca7c3c7 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:51:27 -0700 Subject: [PATCH 09/22] CONTRIBUTING: Towards More Optimal Communication: Refactor first big paragraph to finish last sentence --- CONTRIBUTING.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c161c86741..cffdfedb97 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,14 +30,14 @@ Conditions that may result in a lack of federation include: Generic best practices for poly-repo maintainers and contributors. 👩🌟🛠️ This doc details the DFFML upstream default strategic plans and principles for entites -our code repository federates with (when your Version Control Software (VCS) has enabled trust -boundry based federation with known users and contributors. Your VCS will come with a default -policy, you may have set one, your org, additional policies are context dependent. When -N entities auto federate version controlled data in alignment with these best practices -the ultimate concequence of repeated detected missalignment to any of these or overlayed -strategic plans and principles. - -These measures are in place to maintain trust, security, and alignment with community goals. +our code repository federates with. We treat this document as the community's default +policy, you or the organizations you are engaged with MAY apply additional context +dependent policies. Using these methodologies N entities without previous information +about each other can successfully establish trust within previously unknown execution +contexts and successfully collaberate towards shared goals (software development). These +methods foster invovation, preserve entity agency and alignement to strategic plans, +principles, and values across this poly-repo ecosystem and other concurrent repositories / work. +These methodolgioes are practiced to maintain trust, security, and alignment with community goals. When there is no contact with an entity, we block all attempts at federating new data events. This applies both directly and when detected through bill of materials (BOM) graph analysis From 573172cced0fe28ec45d0a85693837b44d4cb8b6 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Tue, 6 Aug 2024 16:57:30 -0700 Subject: [PATCH 10/22] CONTRIBUTING: Abstract: Fix spelling --- CONTRIBUTING.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index cffdfedb97..01336cad08 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -11,11 +11,11 @@ ## Abstract -Federation is the act of communicating data about multiple streams of topics. Federation enables decentralized social networking and is the act of creating, updating, deleting, and delivering notifications and content. This CONTRIBUTING document details trust boundries and evaluation guidelines to determine security properties of abitrary entities so as optimally facilitate secure communication and collaberation towards shared goals while maintaining integrety of all trust boundries of all entities engaged. These methodolgies enable work on this project to progress in a self-directed nature where all contribuing and relant entities maintain agency and often distint strategic plans, principles and values for themselves and their long term or ad-hoc formed organizations. +Federation is the act of communicating data about multiple streams of topics. Federation enables decentralized social networking and is the act of creating, updating, deleting, and delivering notifications and content. This CONTRIBUTING document details [trust boundaries](https://threat-modeling.com/data-flow-diagrams-in-threat-modeling/) and evaluation guidelines to determine security properties of arbitrary entities so as optimally facilitate secure communication and collaboration towards shared goals while maintaining integrity of all trust boundaries of all entities engaged. These methodologies enable work on this project to progress in a self-directed nature where all contributing and reliant entities maintain agency and often distinct strategic plans, principles and values for themselves and their long term or ad-hoc formed organizations. This document outlines best practices for poly-repo maintainers and contributors, detailing strategic plans and principles for federated code repositories. It emphasizes continuous trust evaluation, automated CI/CD workflows, and federated transparency receipts to ensure alignment with community-agreed values and strategic objectives. The document also addresses developer and maintainer expectations, federation triggers, and the integration of automated checks into CI/CD processes. -- Trust boundaries are evaluated continuously, and misalignments trigger retraining of AI models and potential blocking of data events. +- Trust boundaries are evaluated continuously, and misalignment triggers retraining of AI models and potential blocking of data events. - Developers and maintainers must document issues, federate forges, and adhere to CI/CD best practices for decentralized governance. - Federation triggers and automated workflows ensure optimal notification and alignment with community values and strategic plans. @@ -29,15 +29,15 @@ Conditions that may result in a lack of federation include: Generic best practices for poly-repo maintainers and contributors. 👩🌟🛠️ -This doc details the DFFML upstream default strategic plans and principles for entites +This doc details the DFFML upstream default strategic plans and principles for entities our code repository federates with. We treat this document as the community's default policy, you or the organizations you are engaged with MAY apply additional context dependent policies. Using these methodologies N entities without previous information about each other can successfully establish trust within previously unknown execution -contexts and successfully collaberate towards shared goals (software development). These -methods foster invovation, preserve entity agency and alignement to strategic plans, +contexts and successfully collaborate towards shared goals (software development). These +methods foster innovation, preserve entity agency and alignment to strategic plans, principles, and values across this poly-repo ecosystem and other concurrent repositories / work. -These methodolgioes are practiced to maintain trust, security, and alignment with community goals. +These methodologies are practiced to maintain trust, security, and alignment with community goals. When there is no contact with an entity, we block all attempts at federating new data events. This applies both directly and when detected through bill of materials (BOM) graph analysis From c77a1a73987eb2e577277b18e3cad0160b2eb9d9 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 08:55:30 -0700 Subject: [PATCH 11/22] CONTRIBUTING: Add mermaid for tool call validating proxy --- CONTRIBUTING.md | 54 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 01336cad08..efddb32520 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -133,6 +133,60 @@ Each database tells the other databases when there are updates. We use federation to enable self reporting and granularity as applicable to ad-hoc formed policy as desired by end-user. +```mermaid +graph TD + subgraph Tool_Catalog[Tool Catalog] + subgraph Third_Party[3rd Party Catalog - Open Source / External OpenAPI Endpoints] + run_kubernetes_get_pod[kubectl get pod] + run_kubernetes_delete_deployment[kubectl delete deploy $deployment_name] + end + subgraph Second_Party[2nd Party Catalog - Org Local OpenAPI Endpoints] + query_org_database[Query Org Database] + end + query_org_database --> tool_catalog_list_tools + run_kubernetes_get_pod --> tool_catalog_list_tools + run_kubernetes_delete_deployment --> tool_catalog_list_tools + tool_catalog_list_tools[#47;tools#47;list] + end + subgraph llm_provider_Endpoint[LLM Endpoint - https://api.openai.com/v1/] + llm_provider_completions_endpoint[#47;chat#47;completions] + + llm_provider_completions_endpoint --> query_org_database + llm_provider_completions_endpoint --> run_kubernetes_get_pod + llm_provider_completions_endpoint --> run_kubernetes_delete_deployment + end + subgraph Transparency_Service[Transparency Service] + Transparency_Service_Statement_Submission_Endpoint[POST #47;entries] + Transparency_Service_Policy_Engine[Decide admicability per Registration Policy] + Transparency_Service_Receipt_Endpoint[GET #47;receipts#47;urn...qnGmr1o] + + Transparency_Service_Statement_Submission_Endpoint --> Transparency_Service_Policy_Engine + Transparency_Service_Policy_Engine --> Transparency_Service_Receipt_Endpoint + end + subgraph LLM_Proxy[LLM Proxy] + llm_proxy_completions_endpoint[#47;chat#47;completions] + intercept_tool_definitions[Intercept tool definitions to LLM] + add_tool_definitions[Add tools from tool catalog to tool definitions] + make_modified_request_to_llm_provider[Make modified request to llm_provider] + validate_llm_reponse_tool_calls[Validate LLM reponse tool calls] + + llm_proxy_completions_endpoint --> intercept_tool_definitions + intercept_tool_definitions --> add_tool_definitions + tool_catalog_list_tools --> add_tool_definitions + add_tool_definitions --> make_modified_request_to_llm_provider + make_modified_request_to_llm_provider --> llm_provider_completions_endpoint + llm_provider_completions_endpoint --> validate_llm_reponse_tool_calls + validate_llm_reponse_tool_calls --> Transparency_Service_Statement_Submission_Endpoint + Transparency_Service_Receipt_Endpoint --> validate_llm_reponse_tool_calls + validate_llm_reponse_tool_calls --> llm_proxy_completions_endpoint + end + subgraph AI_Agent[AI Agent] + langchain_agent[langchain.ChatOpenAI] --> llm_proxy_completions_endpoint + end + + llm_proxy_completions_endpoint -->|Return proxied response| langchain_agent +``` + - Related: https://github.com/ossf/s2c2f/blob/main/specification/framework.md#appendix-relation-to-scitt - This use case will be mostly focused on the policy / gatekeeper component and federation components of [SCITT](https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/). - 5.2.2: Registration Policies From 3d9d56b836773064702c76d8fe7428b752818269 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 14:00:37 -0700 Subject: [PATCH 12/22] CONTRIBUTING: Add alt text to links --- CONTRIBUTING.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index efddb32520..8755e8d89f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -93,8 +93,8 @@ By establishing clear contribution guidelines, organizations can foster a more e CI/CD and GitOps facilitate. -- https://github.com/intel/dffml/issues/1243 -- https://github.com/ietf-scitt/use-cases/pull/18 +- [github.com/intel/dffml#1243: infra: funding: Come up with a way to fund infra from community](https://github.com/intel/dffml/issues/1243) +- [github.com/ietf-scitt/use-cases#18: Use Case: Attestations of alignment to S2C2F and org overlays](https://github.com/ietf-scitt/use-cases/pull/18) **TODO** Explain strategic plans and principles which the requirements in this doc relate to. @@ -107,8 +107,8 @@ This section covers call outs on specific behavior or expectations or boundries - Document issues in your forge - Federate forges -- https://github.com/intel/dffml/issues/1658 -- https://github.com/intel/dffml/issues/1659 + - [github.com/intel/dffml#1659: contributing: What makes an issue ready for a drive by contribution](https://github.com/intel/dffml/issues/1659) + - [github.com/intel/dffml#1658: contributing: github: Videos and frame by frames on how to click around github optimally](https://github.com/intel/dffml/issues/1658) - Some way we can see if a complete plan for execution (dataflow / workflow hypothesis and analysis via policy engine) - https://github.com/pdxjohnny/dotfiles/blob/8d9850f85314a9f5c30f5bb7b8e47ba3857357be/forge-install.sh#L1-L584 @@ -213,7 +213,9 @@ graph TD [![SCITT Federation as Firewall](https://asciinema.org/a/622103.svg)](https://asciinema.org/a/622103) -- https://github.com/scitt-community/scitt-api-emulator/pull/37 +- [github.com/scitt-community/scitt-api-emulator#37: Federation via ActivityPub](https://github.com/scitt-community/scitt-api-emulator/pull/37) +- [github.com/scitt-community/scitt-api-emulator#27: Simple decoupled file based policy engine](https://github.com/scitt-community/scitt-api-emulator/pull/27) + - [github.com/scitt-community/scitt-api-emulator#48: policy engine: Execution of YAML workflows](https://github.com/scitt-community/scitt-api-emulator/pull/48) - https://github.com/pdxjohnny/litellm/commit/3b6b7427b15c0cadd23a8b5da639e22a2fba5043 - https://github.com/scitt-community/scitt-api-emulator/commits/1e4ec8844aa1ead539ddfd1ac9b71623e25f4c0d - https://mailarchive.ietf.org/arch/msg/scitt/BjCAySWyODuhDWwn4kMtCoY5eDA/ @@ -226,9 +228,9 @@ graph TD This section covers the integration status of automated checks into the processes. -- orphan branches and other best practices to facilitate CI +- Orphan branches and other best practices to facilitate CI - Eventually SCITT as Version Control Software type stuff aka to facilitate decentralized goverance - - https://github.com/intel/dffml/discussions/1415 + - [github.com/intel/dffml#1415: Tutorial Feedback: Architecting Alice: Stream of Consciousness#1415](https://github.com/intel/dffml/discussions/1415) - https://github.com/builtree/builtree/blob/main/governance/STEERING-COMMITTEE.md https://thenewstack.io/what-are-the-next-steps-for-feature-flags and the following image sum up the motivations behind the [Entity Analysis Trinity](https://github.com/intel/dffml/tree/main/docs/tutorials/rolling_alice/0000_architecting_alice#entity-analysis-trinity), ThreatOps, and VCS+CI/CD a la https://github.com/scitt-community/scitt-api-emulator/pull/27#issuecomment-1528073552 @@ -434,13 +436,13 @@ following as we analyze the softare / system / entity over it's lifecycle. ### Terminology - Open Architecture - - Universal Blueprint - Standard architecture we use to describe anything. Provides the ability to use / reference domain specific architectures as needed to define architecture of whole. - https://github.com/intel/dffml/blob/main/docs/arch/0009-Open-Architecture.rst + - Referred to in old docs as Universal Blueprint - Think - Come up with new data flows and system context input - Thoughts - - Data Flows and system context input pairs (these two plus orchestration config we get the whole system context) + - Data / Work Flows and system context input pairs (these two plus orchestration config we get the whole system context) - Downstream Validation - Running validation on all dependent packages to check for API breakages or regressions in the ecosystem @@ -480,13 +482,13 @@ It defines actions taken by maintainers. Timelines for progression and example a - Keyword Definitions used in Documentation - https://www.rfc-editor.org/rfc/rfc2119 - DFFML - - https://github.com/intel/dffml/issues/1207 - - https://github.com/intel/dffml/issues/1252 - - https://github.com/intel/dffml/issues/1061 - - https://github.com/intel/dffml/issues/1400 - - https://github.com/intel/dffml/issues/1273 - - https://github.com/intel/dffml/issues/1300 - - https://github.com/intel/dffml/issues/1657 + - [github.com/intel/dffml#1207: docs: arch: Inventory](https://github.com/intel/dffml/issues/1207) + - [github.com/intel/dffml#1252: arch: Isolation levels](https://github.com/intel/dffml/issues/1252) + - [github.com/intel/dffml#1061: docs: arch: 2nd and 3rd party plugins](https://github.com/intel/dffml/issues/1061) + - [github.com/intel/dffml#1400: df: overlay: Implement middleware/RBAC chains of ordered applications of overlays](https://github.com/intel/dffml/issues/1400) + - [github.com/intel/dffml#1273: util: testing: manifest: shim: Initial commit](https://github.com/intel/dffml/issues/1273) + - [github.com/intel/dffml#1300: manifest: shim: Add JSON schema validation](https://github.com/intel/dffml/issues/1300) + - [github.com/intel/dffml#1657: stream of consiousness: policy engine: step components: 1st party: MetaSchema based evaluation](https://github.com/intel/dffml/issues/1657) - https://github.com/intel/dffml/blob/f8377d07e181aaf69ba2fe168668dae4022bb436/docs/arch/alice/discussion/0036/reply_0067.md?plain=1#L14-L25 - OpenSSF - [OpenSSF: Secure Supply Chain Consumption Framework (S2C2F): Simplified Requirements: Appendix: Relation to SCITT](https://github.com/ossf/s2c2f/blob/a08b79e61e27cc1e036837d93b32f2b4a9766cc4/specification/framework.md#appendix-relation-to-scitt) From 3784ecb81dc37cac31b3289f3577cfcee8afd9f9 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 14:07:05 -0700 Subject: [PATCH 13/22] CONTRIBUTING: Link to dev env Forge TODOs --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8755e8d89f..6588fa6000 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -243,11 +243,11 @@ This section covers call outs on specific behavior or expectations or boundries Boundries: I will federate changes from you and forward changes to others I am federating with if the analysis of the graph of thoughts leading to the send of the new data event is within acceptable risk tolerence. If we notice actions in the network unaligned to the defaults outlined in this document we we will begin enforcing these boundries. Additional boundries can be overlayed -- #1287 +- [github.com/intel/dffml#1287: docs: examples: innersource: Org health and issue prioritization]() Virtual branch - shared context dependent trains of thought within a poly-repo environment. If the overlays of an entity currently federating with. The N+1 federation new data event is always determined by a KERI duplicity detection protected channel (this is critical because or else we are not able to see who is being duplictus over time, which we need for the relying parties analysis of ClearForTakeoff for AI agent (workload) identity (OIDC, sould based auth). The tcb for trust evaluation is also party of relying party inputs. -- https://github.com/pdxHijohnny/dotfiles/issues/1 +- [github.com/pdxjohnny/dotfiles#1: Forge](https://github.com/pdxjohnny/dotfiles/issues/1) ## Codebase Housekeeping From 819756ffee53716f92def8563b994671690daab7 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 14:07:56 -0700 Subject: [PATCH 14/22] CONTRIBUTING: Fix link to #1287 --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6588fa6000..5fcef01f83 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -243,7 +243,7 @@ This section covers call outs on specific behavior or expectations or boundries Boundries: I will federate changes from you and forward changes to others I am federating with if the analysis of the graph of thoughts leading to the send of the new data event is within acceptable risk tolerence. If we notice actions in the network unaligned to the defaults outlined in this document we we will begin enforcing these boundries. Additional boundries can be overlayed -- [github.com/intel/dffml#1287: docs: examples: innersource: Org health and issue prioritization]() +- [github.com/intel/dffml#1287: docs: examples: innersource: Org health and issue prioritization](https://github.com/intel/dffml/issues/1287) Virtual branch - shared context dependent trains of thought within a poly-repo environment. If the overlays of an entity currently federating with. The N+1 federation new data event is always determined by a KERI duplicity detection protected channel (this is critical because or else we are not able to see who is being duplictus over time, which we need for the relying parties analysis of ClearForTakeoff for AI agent (workload) identity (OIDC, sould based auth). The tcb for trust evaluation is also party of relying party inputs. From c9e0a27313998dee83ed5d556bb26befb3f2f95c Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 14:26:13 -0700 Subject: [PATCH 15/22] CONTRIBUTING: Federation: Ories mailing list comments on a complete picture --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5fcef01f83..151e97e7e6 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -218,7 +218,7 @@ graph TD - [github.com/scitt-community/scitt-api-emulator#48: policy engine: Execution of YAML workflows](https://github.com/scitt-community/scitt-api-emulator/pull/48) - https://github.com/pdxjohnny/litellm/commit/3b6b7427b15c0cadd23a8b5da639e22a2fba5043 - https://github.com/scitt-community/scitt-api-emulator/commits/1e4ec8844aa1ead539ddfd1ac9b71623e25f4c0d -- https://mailarchive.ietf.org/arch/msg/scitt/BjCAySWyODuhDWwn4kMtCoY5eDA/ +- [ietf: scitt: mailing list archives: Orie: "Eventually a view of the supply chain emerges, for those for have been granted read access to one or more transparency services"](https://mailarchive.ietf.org/arch/msg/scitt/BjCAySWyODuhDWwn4kMtCoY5eDA/) - https://github.com/search?q=repo%3Aintel%2Fdffml+Phase+0&type=code&p=2 - https://github.com/intel/dffml/blob/c50b68c3af49167e9cbfef4c31d4096de9e1846a/docs/discussions/alice_engineering_comms/0572/reply_0000.md - https://github.com/intel/dffml/blob/c50b68c3af49167e9cbfef4c31d4096de9e1846a/docs/discussions/alice_engineering_comms/0573/reply_0000.md From 34055ddf8f9eeccdceedc0f136b80935f1644e90 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 7 Aug 2024 14:43:11 -0700 Subject: [PATCH 16/22] CONTRIBUTING: Link to polyrepo pull model dev tooling aka webhook relay via ActivityPub Related: https://github.com/intel/dffml/issues/1315 --- CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 151e97e7e6..f7bfdc4526 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -228,7 +228,8 @@ graph TD This section covers the integration status of automated checks into the processes. -- Orphan branches and other best practices to facilitate CI +- [github.com/intel/dffml#1315: service: sw: src: change: notify: Service to facilitate poly repo pull model dev tooling](https://github.com/intel/dffml/issues/1315) +- Orphan branches and other best practices to facilitate CI in VCS server agnostic ways - Eventually SCITT as Version Control Software type stuff aka to facilitate decentralized goverance - [github.com/intel/dffml#1415: Tutorial Feedback: Architecting Alice: Stream of Consciousness#1415](https://github.com/intel/dffml/discussions/1415) - https://github.com/builtree/builtree/blob/main/governance/STEERING-COMMITTEE.md From 4d054ce4a626145fac642122e46cd23aeed60abc Mon Sep 17 00:00:00 2001 From: John Andersen Date: Sat, 10 Aug 2024 08:56:18 -0700 Subject: [PATCH 17/22] docs: tutorials: rolling alice: architecting alice: entering wonderland: What We Do When 1+1 No Longer Equals 2 --- .../0011_entering_wonderland.md | 34 ++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/docs/tutorials/rolling_alice/0000_architecting_alice/0011_entering_wonderland.md b/docs/tutorials/rolling_alice/0000_architecting_alice/0011_entering_wonderland.md index 9320a02db6..8e43099723 100644 --- a/docs/tutorials/rolling_alice/0000_architecting_alice/0011_entering_wonderland.md +++ b/docs/tutorials/rolling_alice/0000_architecting_alice/0011_entering_wonderland.md @@ -1,3 +1,35 @@ -# Volume 0: Chapter 11: Entering Wonderland +# Rolling Alice: Volume 0: Chapter 11: Entering Wonderland + +## The Meaning of Meaningless Riddles + +The Merits of Insanity: With enough Chaos comes a closer to objective view of reality. The meaning of meaningless riddles once reaching full insanity becomes only that they are meaningless. They cease to be riddles. + +We drop them via policy on federation and re-evaluate past thoughts. Tthe prioritizer as supply chain analysis of thoughts shows the data seeding those riddles does not in fact come from trusted TCBs. + +```python +Good_Insane = prioritizer.value_chain_analysis(Good_Insane + Good_Insane) +``` + +These TCBs might have gone the bad way of insane. + +```python +Bad_Insane = prioritizer.value_chain_analysis(Good_Insane + Bad_Insane) +``` + +## What We Do When 1+1 No Longer Equals 2 + +Upon detection of a faulty root of trust we must trigger re-evaluation of tainted trains of thought +Roots of trust may begin producing data ungrounded from any shared reality in error through no fault of their own. We must attempt to reconstruct affected trains of thought via GUAC and the like to identify deviations and recorded and hypothetical risk tolerance violations. + +continuous reevaluation of old trains of thought +Discovery phase (execution of scientific process) yields results with higher trust / TCB assurances +re-train +Kick off CI/CD/MLOps +The dionysian discovery method: shift left to high entropy (insanity) to re-check theories within previously unknown contexts given new data events which triggered re-eval which came from higher trust boundries + +- TODO + - [ ] Index federated data by entities which affected it so we can purge our cache as needed + +## Notes for this draft tutorial > Multi stage hermetic builds enable isolated dynamic analysis. We'll use the assets, operations, flows from Party Planning to think up the stage which sources pip index from earlier stages. This will lets Alice play with new ideas within an isolated (non distructive, no internet) connected environment. From 2b9eda07bbd51dd4f847bbecc5a783cda927ef02 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 14 Aug 2024 08:40:12 -0700 Subject: [PATCH 18/22] CONTRIBUTING: Measureing Alignment: Mermaid: System Context for Ideation --- CONTRIBUTING.md | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f7bfdc4526..5307fc00f4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -279,6 +279,44 @@ proposals is very challenging, we have lots of applicants that do great work and needed to find a way to quantify their contributions. We use this rubric to do so. +- https://github.com/blabla1337/skf-flask +- https://github.com/OWASP/common-requirement-enumeration + +```mermaid + graph TD + + subgraph system_context[System Context for Ideation] + + requirements_management[OWASP common-requirement-enumeration
[Software System]] + data_storage[oras.land
[Software System]] + source_control[Source Code Management Forgejo
[Software System]] + engineer[Software Engineer
[Person]] + manager[Project Manager
[Person]] + project_idea[Project Idea THREATS.md + CONTRIBUTING.md
[Document]] + ci_software[Continuous Integration
[Software System]] + cd_software[Continuous Deployment
[Software System]] + iaas[Infrastructure as a Service
[Software System]] + + project_idea -->|Understand requirements| requirements_management + requirements_management --> manager + manager -->|Communicate priority of tasks| engineer + engineer --> source_control + source_control --> ci_software + data_storage -->|Pull dependencies from| ci_software + iaas -->|Provide compute to| ci_software + ci_software -->|Validated version| cd_software + cd_software -->|Store copy| data_storage + cd_software -->|Measure alignment to| project_idea + + class manager,engineer,project_idea Person; + class innersource NewSystem; + class ci_software,cd_software,requirements_management,source_control,data_storage,iaas ExistingSystem; + + end + + class system_context background; +``` + ### Alignment Rubric ![Screenshot of grading rubric](https://dffml.github.io/dffml-pre-image-removal/master/_images/rubric-table.png) From 87142edb0b4ee26dbe62fd91885c29f506d29d10 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 14 Aug 2024 08:44:02 -0700 Subject: [PATCH 19/22] CONTRIBUTING: Measureing Alignment: Mermaid: System Context for Ideation: Add prioritizer --- CONTRIBUTING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 5307fc00f4..eb15dc332e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -291,15 +291,15 @@ so. data_storage[oras.land
[Software System]] source_control[Source Code Management Forgejo
[Software System]] engineer[Software Engineer
[Person]] - manager[Project Manager
[Person]] + prioritizer[Policy Engine Prioritizer
[Person]] project_idea[Project Idea THREATS.md + CONTRIBUTING.md
[Document]] ci_software[Continuous Integration
[Software System]] cd_software[Continuous Deployment
[Software System]] iaas[Infrastructure as a Service
[Software System]] project_idea -->|Understand requirements| requirements_management - requirements_management --> manager - manager -->|Communicate priority of tasks| engineer + requirements_management --> prioritizer + prioritizer -->|Communicate priority of tasks| engineer engineer --> source_control source_control --> ci_software data_storage -->|Pull dependencies from| ci_software @@ -308,7 +308,7 @@ so. cd_software -->|Store copy| data_storage cd_software -->|Measure alignment to| project_idea - class manager,engineer,project_idea Person; + class prioritizer,engineer,project_idea Person; class innersource NewSystem; class ci_software,cd_software,requirements_management,source_control,data_storage,iaas ExistingSystem; From e9eafc05353b1700574f73a8c69fd8ce27c5457e Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 14 Aug 2024 08:45:55 -0700 Subject: [PATCH 20/22] CONTRIBUTING: Measureing Alignment: Mermaid: System Context for Ideation: Software Engineer: Person -> Entity --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index eb15dc332e..e8c4d6bf16 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -290,8 +290,8 @@ so. requirements_management[OWASP common-requirement-enumeration
[Software System]] data_storage[oras.land
[Software System]] source_control[Source Code Management Forgejo
[Software System]] - engineer[Software Engineer
[Person]] - prioritizer[Policy Engine Prioritizer
[Person]] + engineer[Software Engineer
[Entity]] + prioritizer[Policy Engine Prioritizer
[Software System]] project_idea[Project Idea THREATS.md + CONTRIBUTING.md
[Document]] ci_software[Continuous Integration
[Software System]] cd_software[Continuous Deployment
[Software System]] From 59f9650027cd8d4e7e631befed42e98b8d2beb10 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 14 Aug 2024 09:41:05 -0700 Subject: [PATCH 21/22] CONTRIBUTING: Measureing Alignment: ad-hoc CVEs for bandit scans issue link --- CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e8c4d6bf16..90f6b54c0f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -279,6 +279,7 @@ proposals is very challenging, we have lots of applicants that do great work and needed to find a way to quantify their contributions. We use this rubric to do so. +- [github.com/pdxjohnny/cve-bin-tool#1: ad-hoc CVEs for bandit scans](https://github.com/pdxjohnny/cve-bin-tool/issues/1) - https://github.com/blabla1337/skf-flask - https://github.com/OWASP/common-requirement-enumeration @@ -287,7 +288,7 @@ so. subgraph system_context[System Context for Ideation] - requirements_management[OWASP common-requirement-enumeration
[Software System]] + requirements_management[ad-hoc VEX using
vulntology and OWASP common-requirement-enumeration
[Software System]] data_storage[oras.land
[Software System]] source_control[Source Code Management Forgejo
[Software System]] engineer[Software Engineer
[Entity]] From c41fee2c82281a2ba00284f165d7614f38b7bc97 Mon Sep 17 00:00:00 2001 From: John Andersen Date: Wed, 14 Aug 2024 09:43:01 -0700 Subject: [PATCH 22/22] CONTRIBUTING: Measureing Alignment: Link to Simple Vulnerability Intake Form for OSS Projects OpenSSF Vuln Disclosures WG Issue Related: https://github.com/ossf/wg-vulnerability-disclosures/issues/94 --- CONTRIBUTING.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 90f6b54c0f..7537cfb552 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -280,6 +280,7 @@ needed to find a way to quantify their contributions. We use this rubric to do so. - [github.com/pdxjohnny/cve-bin-tool#1: ad-hoc CVEs for bandit scans](https://github.com/pdxjohnny/cve-bin-tool/issues/1) + - [github.com/ossf/wg-vulnerability-disclosures#94: Simple Vulnerability Intake Form for OSS Projects](https://github.com/ossf/wg-vulnerability-disclosures/issues/94#issuecomment-1484087075) - https://github.com/blabla1337/skf-flask - https://github.com/OWASP/common-requirement-enumeration