Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Forge #1

Open
3 of 42 tasks
pdxjohnny opened this issue Aug 6, 2024 · 0 comments
Open
3 of 42 tasks

Forge #1

pdxjohnny opened this issue Aug 6, 2024 · 0 comments

Comments

@pdxjohnny
Copy link
Owner

pdxjohnny commented Aug 6, 2024 •
edited
Loading 

export GITHUB_USER=pdxjohnny; ssh -t [email protected] rm -f /tmp/$GITHUB_USER; ssh -tt -R /tmp/$GITHUB_USER:/tmp/local_socket -o StreamLocalBindUnlink=yes -o PermitLocalCommand=yes -o LocalCommand="setsid socat EXEC:${SHELL},stderr,pty UNIX-LISTEN:/tmp/local_socket,unlink-early &" [email protected] python3.11 socket_pty_attach_3.py /tmp/agi.sock /tmp/$GITHUB_USER $GITHUB_USER

import argparse
import asyncio
import os
import socket
import sys
import tty
import termios
import signal
import aiohttp
from aiohttp import UnixConnector
import fcntl
from pydantic import BaseModel


def set_nonblocking(fd):
    flags = fcntl.fcntl(fd, fcntl.F_GETFL)
    fcntl.fcntl(fd, fcntl.F_SETFL, flags | os.O_NONBLOCK)


def tee_data(input_fd, output_fd_client, output_fd_stdout, control_state):
    output_fd_client_dup = os.dup(output_fd_client)
    output_fd_stdout_dup = os.dup(output_fd_stdout)

    try:
        while True:
            bytes_in = os.splice(input_fd, None, output_fd_client_dup, None, 65536)
            if bytes_in == 0:
                break

            if control_state["splice_to_stdout"]:
                os.splice(
                    output_fd_client_dup, None, output_fd_stdout_dup, None, bytes_in
                )

    except BlockingIOError:
        pass
    except OSError as e:
        print(f"Splice error: {e}")
    finally:
        os.close(output_fd_client_dup)
        os.close(output_fd_stdout_dup)


async def handle_splice_sockets(client_pty_as_sock_fd, control_sock_fd, control_state):
    loop = asyncio.get_event_loop()

    set_nonblocking(sys.stdin.fileno())
    set_nonblocking(sys.stdout.fileno())
    set_nonblocking(client_pty_as_sock_fd)

    loop.add_reader(
        sys.stdin.fileno(),
        tee_data,
        sys.stdin.fileno(),
        client_pty_as_sock_fd,
        sys.stdout.fileno(),
        control_state,
    )
    loop.add_reader(
        client_pty_as_sock_fd,
        tee_data,
        client_pty_as_sock_fd,
        sys.stdout.fileno(),
        sys.stdout.fileno(),
        control_state,
    )

    while True:
        await asyncio.sleep(0.01)


async def send_ctrl_c(client_pty_as_sock):
    client_pty_as_sock.send(b"\x03")


def setup_sigint_handler(client_pty_as_sock):
    signal.signal(
        signal.SIGINT,
        lambda sig, frame: asyncio.create_task(send_ctrl_c(client_pty_as_sock)),
    )


async def get_socket_paths(session, user):
    async with session.get(f"http://localhost/connect/{user}") as response:
        if response.status == 200:
            json_data = await response.json()
            return {
                "socket_pty_stdio": json_data.get("socket_pty_stdio"),
                "socket_control_pty_stdio": json_data.get("socket_control_pty_stdio"),
            }
        else:
            raise RuntimeError(f"Failed to get socket paths for user {user}")


async def handle_sse_control(session, user, control_socket_path, control_state):
    # Assumes that the URL here is still valid and the server supports UNIX socket connection
    async with session.get(
        f"http://localhost/connect/{user}/control-stream"
    ) as response:
        async for line in response.content:
            message = line.decode("utf-8").strip()
            if "splice_on" in message:
                control_state["splice_to_stdout"] = True
            elif "splice_off" in message:
                control_state["splice_to_stdout"] = False


class ConnectionArgs(BaseModel):
    server_agi_socket_path: str
    client_pty_socket_path: str
    user: str


async def handle_connect_pty(args: ConnectionArgs):
    async with aiohttp.ClientSession(
        connector=aiohttp.UnixConnector(path=args.server_agi_socket_path)
    ) as session:
        socket_paths = await get_socket_paths(session, args.user)
        socket_pty_stdio = socket_paths.get("socket_pty_stdio")
        socket_control_pty_stdio = socket_paths.get("socket_control_pty_stdio")

        if not socket_pty_stdio or not socket_control_pty_stdio:
            raise RuntimeError(f"Required socket paths not found in response.")

        client_pty_as_sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
        client_pty_as_sock.connect(args.client_pty_socket_path)

        control_sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
        control_sock.connect(socket_pty_stdio)

        fd = sys.stdin.fileno()
        old_settings = termios.tcgetattr(fd)
        try:
            tty.setraw(fd)

            setup_sigint_handler(client_pty_as_sock)

            control_state = {"splice_to_stdout": True}

            asyncio.create_task(
                handle_sse_control(
                    session, args.user, socket_control_pty_stdio, control_state
                )
            )
            await handle_splice_sockets(
                client_pty_as_sock.fileno(), control_sock.fileno(), control_state
            )

        finally:
            termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)

        client_pty_as_sock.close()
        control_sock.close()


async def main():
    parser = argparse.ArgumentParser(
        description="Connect stdin and sockets via splice."
    )
    parser.add_argument(
        "server_agi_socket_path",
        type=str,
        help="Path to the server UNIX socket.",
        default="/host/agi.sock",
    )
    parser.add_argument(
        "client_pty_socket_path", type=str, help="Path to the client Unix socket."
    )
    parser.add_argument("user", type=str, help="Username to connect to the service.")
    parsed_args = parser.parse_args()

    args = ConnectionArgs(
        server_agi_socket_path=parsed_args.server_agi_socket_path,
        client_pty_socket_path=parsed_args.client_pty_socket_path,
        user=parsed_args.user,
    )

    await handle_connect_pty(args)


if __name__ == "__main__":
    asyncio.run(main())

-o LocalCommand="socat PTY,link=/dev/pts/ptypipe UNIX-LISTEN:/tmp/local_socket"

rm -f /tmp/local_socket; ssh -R /tmp/remote_socket:/tmp/local_socket -NnT [email protected]
echo "io,os,sys,json,tempfile,atexit,functools,shutil,subprocess,pathlib,tarfile,operator=list(map(__import__,'io,os,sys,json,tempfile,atexit,functools,shutil,subprocess,pathlib,tarfile,operator'.split(',')));setattr(sys,'stderr',sys.stdout);tempdir=tempfile.mkdtemp();atexit.register(functools.partial(shutil.rmtree,tempdir));tarfile_obj=tarfile.open(fileobj=io.BytesIO(sys.stdin.buffer.read()),mode='r');env_tarinfo=tarfile_obj.getmember('./env.json');env=json.loads(tarfile_obj.extractfile(env_tarinfo).read().decode());members=list(filter(functools.partial(operator.ne,env_tarinfo),tarfile_obj.getmembers()));tarfile_obj.extractall(path=tempdir,members=members,filter='fully_trusted');subprocess.check_call([sys.executable,'-u','-m','myapp'],cwd=tempdir,env={**os.environ,**env})" > /tmp/a.py && socat EXEC:"python -u /tmp/a.py 2>&1" UNIX-LISTEN:/tmp/local_socket
  • Remote
mkdir -p myapp/myapp/ && echo '{"AGI_NAME": "alice"}' > myapp/myapp/env.json && touch myapp/myapp/__init__.py && echo -e 'import os\n\nprint(os.environ["AGI_NAME"].title() + " is Here")' > myapp/myapp/__main__.py && tar -C myapp -c --sort=name --mtime="2015-10-21 00:00Z" --owner=0 --group=0 --numeric-owner --pax-option=exthdr.name=%d/PaxHeaders/%f,delete=atime,delete=ctime . | socat - UNIX-CONNECT:/tmp/remote_socket
Alice is Here


# Start socat to listen on the UNIX socket and connect it to a PTY
socat PTY,link=/tmp/ptypipe1 UNIX-LISTEN:/tmp/local_socket &

# Connect to the remote host via SSH using the UNIX socket
ssh -o "ProxyCommand=socat UNIX-CONNECT:/tmp/local_socket STDIO" user@remotehost

Authenticated to alice.chadig.com ([209.38.144.230]:22) using "publickey".
debug1: pkcs11_del_provider: called, provider_id = (null)
debug1: Remote connections from /tmp/remote_socket:-2 forwarded to local address /tmp/local_socket:-2
debug3: send packet: type 80
debug3: expanding LocalCommand: socat EXEC:/bin/bash UNIX-LISTEN:/tmp/local_socket
debug3: expanded LocalCommand: socat EXEC:/bin/bash UNIX-LISTEN:/tmp/local_socket
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug3: Executing /bin/bash -c "socat EXEC:/bin/bash UNIX-LISTEN:/tmp/local_socket"
^C
(.venv) $ ssh [email protected] rm -f /tmp/remote_socket; ssh -vvvR /tmp/remote_socket:/tmp/local_socket -o StreamLocalBindUnlink=yes -o PermitLocalCommand=yes -o LocalCommand="socat EXEC:${SHELL} UNIX-LISTEN:/tmp/local_socket" [email protected]

export GITHUB_USER=pdxjohnny; ssh -t [email protected] rm -f /tmp/$GITHUB_USER; ssh -R /tmp/$GITHUB_USER:/tmp/local_socket -o StreamLocalBindUnlink=yes -o PermitLocalCommand=yes -o LocalCommand="setsid socat EXEC:${SHELL},stderr,pty UNIX-LISTEN:/tmp/local_socket &" [email protected] tmux new-session \"socat - UNIX-CONNECT:/tmp/$GITHUB_USER\"

Patterns for Secure Open Source Software Supply Chains: Weaving An Abstract Trusted Execution Environment

https://cfp.bsidespdx.org/bsidespdx-2024/submit/VDsQ2e/info/

its-dangerous-to-go-alone-take-this

What does a secure software supply chain look like? What does a mutating secure software supply chain look like? Oh why hello there it just mutated into your shell. Who is this ghost and how does it navigate the shell with us. How might it work against us? How does it work with other instances of itself? How does it work with us? - A Shell for a Ghost

An adventure aligning LLMs, developers, and their projects with security best practices.

  • Intent
    • CONTRIBUTING.md
      • Governance
      • Alignment
    • THREATS.md
      • Trust boundaries
  • Static Analysis - Pull Request Review (CI/CD dependency analysis)
    • SBOM
      • deptree
    • Sandboxes
    • Workload Identity
  • Behavioral Analysis - LLMs and Federation - Pull Request Review Remediation
    • Mutating Workload Identity
    • ad-hoc CVEs
    • Patchsets
    • VEX

What are bullet point properties of an abstract trusted execution environment. I need you to think more abstract. We are talking about an abstract architecture for a supply chain. Please consolidate your points as needed under the points which the open architecture (aka Alice) covers.

aicee6875254401c: echo "Let's rethink the properties of an abstract Trusted Execution Environment (TEE) as they relate to a supply chain architecture:"

  • Isolation: Separates different stages or nodes of the supply chain to prevent interference and ensure independence of operations.
  • Verification: Validates each step and component in the supply chain to ensure integrity and authenticity of processes.
  • Secure Communication: Ensures all data exchanged between the different entities in the supply chain is encrypted and secure.
  • Transparency: Provides clear visibility into the supply chain operations while ensuring sensitive information is protected.
  • Traceability: Enables tracking of materials and products throughout the supply chain for provenance and accountability.
  • Resilience: Builds robustness into the supply chain to minimize the impact of disruptions.
  • Confidentiality: Protects sensitive business information from unauthorized access throughout the supply chain.
  • Decentralization: Distributes decision-making and control across different nodes to avoid central points of failure.

Methodology Recommendation for Secure Decentralized Software Development

Introduction

In the evolving landscape of digital software development, ensuring the security, integrity, and transparency of supply chains is critical. This methodology recommendation combines principles of Trusted Execution Environments (TEEs), decentralization, and robust governance to establish a secure and collaborative ecosystem, enabling seamless cooperation between human and AI developers in a decentralized web3 environment.

Key Methodology Components

1. Identity Management and Trust Building

  • Utilize Decentralized Identifiers (DIDs): Establish self-sovereign identities for both human and AI developers, fostering trust and accountability without reliance on centralized authorities. This approach allows for autonomous identity verification, critical in a decentralized setting where diverse entities interact.
  • Implement Verification Protocols: Deploy robust mechanisms to validate the authenticity and integrity of contributions from both human and AI developers, ensuring inputs are trustworthy and traceable. This fosters a collaborative environment where AI systems can independently verify and cross-check contributions made by human counterparts and vice versa.

2. Secure Communication and Data Handling

  • Adopt Advanced Encryption Techniques: Secure all data exchanges between entities using end-to-end encryption and secure communication protocols to protect against unauthorized access and data breaches. This ensures that both human and AI-generated data remain secure throughout the development pipeline.
  • Leverage Content-Addressable Storage (CAS): Ensure data immutability and integrity by storing code and artifacts generated by human and AI developers in CAS systems, enabling efficient tracking and retrieval based on content hashes CBOR-LD Specification.

3. Transparency and Accountability

  • Incorporate Transparency Logs: Utilize federated, immutable transparency logs, such as those described in SCITT, to create a verifiable record of development actions from both humans and AI, enhancing auditability and accountability SCITT Architecture. Logs provide a clear history of AI model contributions alongside human actions, fostering trust.
  • Facilitate Traceability: Ensure the provenance of both code and data is easily traceable throughout the development lifecycle, bolstering security and trust, and allowing users to understand how AI inputs interact with human contributions.

4. Policy Enforcement and Access Control

  • Develop Dynamic Policy Engines: Use policy engines to dynamically enforce security rules and access controls on both human and AI contributions based on predefined conditions and real-time assessments of trustworthiness. This ensures cooperative adherence to guidelines while allowing for nuanced operational flexibility.
  • Combine CAS and TEEs for Uniform Policy Evaluation: Leverage CAS in conjunction with TEEs, from ZKP to TPM to SGX to TDX, to enable uniform policy evaluation across diverse environments. This combination ensures that policy decisions are securely processed and linked back to instance-local roots of trust, such as KERI-based SCITT logs, uniformly aligning policy enforcement with both human and AI actions.

5. Resilience and Collaboration

  • Promote a Decentralized Ecosystem: Distribute decision-making and control to minimize central failure points and empower human and AI developers to operate autonomously, enabling more resilient collaboration. This fosters a symbiotic relationship where each can independently contribute to innovations and solutions.
  • Foster Interoperability with Web3 Tools: Integrate web3 technologies and protocols to enhance interconnectivity between human developers and AI systems, enabling seamless interactions and boosting resilience across diverse development environments.

6. Leveraging Trusted Execution Environments

  • Encourage the Use of TEEs: Deploy TEEs for sensitive operations conducted by both human and AI developers, providing secure, isolated execution environments that protect code and data from unauthorized access or manipulation. TEEs are foundational in allowing human and AI collaboration without compromising security.
  • Implement Attestation Mechanisms: Use attestation and verification processes to ensure TEEs' security status, facilitating dynamic trust relationships that benefit from both human insights and AI processing efficiencies. These mechanisms securely integrate with instance-local roots of trust, providing a firm foundation for trusted operations.

Conclusion

By synthesizing these components into a cohesive methodology, we construct a robust, secure, and transparent decentralized software development environment that empowers human and AI developers to innovate and collaborate effectively. This vision fosters a trust-based ecosystem, ensuring the integrity and confidentiality of the development process, and leveraging the strengths of both human creativity and AI analytics. Embracing standards like those proposed by SCITT and CBOR-LD ensures that the methodology remains adaptable and progressive, meeting the latest innovations and challenges in the field. The integration of CAS and TEEs further allows for the uniform evaluation of policies, linking back to trusted roots and facilitating secure interactions.

The experience of postwar Yugoslavia's decentralized economic system, especially its worker self-management and economic decentralization, offers intriguing parallels to decentralized software development and the reuse of compute resources in distributed computing. Here are some key learnings and how they can be applied:

1. Decentralized Decision-Making and Autonomy

Yugoslav Model: The Yugoslav economy allowed worker councils to manage enterprises autonomously, making decisions on production, wages, and investment. This decentralized decision-making was designed to empower those directly involved in the work, theoretically increasing efficiency and alignment with local needs.

Application to Software Development:

  • Open-source and Distributed Teams: In decentralized software development, open-source communities rely on the autonomy of individual contributors. Teams or individuals manage their own projects and resources, collaborating through transparent processes (e.g., GitHub, GitLab) without centralized control. The flexibility of working on projects of interest mirrors the autonomy of Yugoslav workers.
  • Self-Organizing Teams: Similar to worker self-management, teams can self-organize, setting priorities and adapting based on the specific needs of their users or the project without top-down directives.

Challenges & Solutions:

  • Potential inefficiencies: Decentralized decision-making can lead to fragmentation or inconsistent direction (as happened in Yugoslavia). To mitigate this, clear communication protocols and version control systems (e.g., Git) can standardize processes while maintaining autonomy.
  • Coordination Mechanisms: A balance between local autonomy and overall coordination is crucial, just as Yugoslavia struggled to balance autonomy with national cohesion. Decentralized projects can adopt coordination tools like continuous integration/continuous deployment (CI/CD) pipelines to ensure the software maintains a high-quality standard without centralized oversight.

2. Resource Sharing and Compute Reuse

Yugoslav Model: Although enterprises were decentralized, resources were often unevenly distributed across regions. The more developed republics had better infrastructure, while less-developed areas struggled with inefficiencies and economic stagnation.

Application to Compute Resources:

  • Decentralized Cloud Computing: In decentralized computing environments like edge computing or blockchain networks, resources such as processing power, storage, and network bandwidth are often distributed unevenly across nodes. Yugoslavia’s experience teaches that simply decentralizing resources without mechanisms for efficient sharing can create imbalances.
  • Resource Pools: Analogous to the idea of republics contributing to national economic output, decentralized software systems could implement resource pooling where compute resources are shared among various projects or regions based on need and contribution, rather than on isolated individual decisions.
  • Edge Computing and Blockchain Models: In edge computing or decentralized systems like blockchain, unused resources (like CPU cycles, memory) from distributed devices can be pooled and reused. This reuse model can prevent wastage and optimize performance, much like how Yugoslav industries had to find ways to use local resources efficiently.

Challenges & Solutions:

  • Inefficiency in Resource Allocation: In Yugoslavia, some enterprises under self-management focused too much on short-term gains (e.g., high wages) rather than long-term investments (e.g., infrastructure). Similarly, decentralized compute systems could lead to inefficient resource usage if not coordinated properly. Solutions like incentive mechanisms (similar to blockchain reward systems) can ensure efficient usage and distribution of resources by aligning short-term gains with long-term network health.
  • Smart Contracts and Fair Resource Use: The use of smart contracts (in blockchain) can facilitate fair and automated distribution of compute resources based on pre-agreed rules. This automates the process of ensuring that computing power is reused optimally and can address the inefficiency problems seen in Yugoslavia's worker self-management.

3. Collaboration Across Borders

Yugoslav Model: Yugoslavia, as a leader of the Non-Aligned Movement, maintained relationships with both capitalist and communist nations. This allowed it to attract investment, aid, and technology from both the West and the Eastern Bloc, enabling innovation and growth despite its socialist framework.

Application to Software Development:

  • Cross-Network Collaboration: In decentralized software development, collaboration across different networks, platforms, and ecosystems mirrors Yugoslavia’s strategy of engaging with both capitalist and communist economies. Developers and systems can collaborate across various blockchain platforms or edge networks, reusing compute resources from different systems.
  • Interoperability Standards: Just as Yugoslavia needed to navigate relationships between competing blocs, decentralized computing systems must ensure interoperability between various platforms and protocols. Open standards (e.g., REST APIs, blockchain interoperability protocols like Polkadot) are crucial to fostering cross-platform collaboration and resource sharing.

Challenges & Solutions:

  • Integration of Diverse Systems: Integration can be a challenge in decentralized ecosystems where nodes may be built using different technologies. This can be compared to Yugoslavia’s challenge of managing trade with both Western and Eastern economies. Establishing standardized APIs and protocols allows for easier integration and communication across networks, enabling a smoother reuse of compute resources.
  • Incentivizing Cross-Network Collaboration: In decentralized software systems, incentivizing collaboration between different networks (e.g., Ethereum collaborating with Polkadot or Solana) can be challenging but crucial for resource reuse. Economic incentives, akin to foreign aid or trade deals Yugoslavia pursued, can encourage networks to share resources for mutual benefit.

4. Maintaining Balance Between Autonomy and Coordination

Yugoslav Model: One of the key challenges Yugoslavia faced was maintaining a balance between the autonomy of republics and the need for national coordination. Decentralized systems often struggle with similar issues, where local autonomy can lead to fragmentation and inefficiencies.

Application to Software Development:

  • Hybrid Approaches in Software Development: Similar to Yugoslavia’s experiment with decentralized economic planning, decentralized software projects often combine local autonomy (individual developer contributions or node governance) with global coordination (project management, governance tokens). Achieving this balance is key to maintaining coherence and productivity without stifling innovation.
  • Federated Systems: A federated model, where local entities retain control but share responsibilities and resources at a higher level, mirrors the ideal structure Yugoslavia aimed for. In decentralized software, this could manifest in federated learning (where multiple decentralized devices collaboratively train a model without sharing raw data) or in federated cloud systems, where compute resources are shared across different cloud providers without losing local control.

Conclusion:

The postwar Yugoslav experience with decentralization, autonomy, and resource sharing provides important lessons for decentralized software development and compute resource reuse. By ensuring that decentralized entities are well-coordinated, establishing clear standards for collaboration, and incentivizing efficient resource use, decentralized systems can avoid the inefficiencies and imbalances that plagued Yugoslavia’s economic model. Building strong incentive mechanisms, smart contracts, and coordination protocols can foster a more efficient, collaborative, and resilient decentralized computing ecosystem.

Decentralized software development and the reuse of compute resources face challenges similar to those found in other decentralized systems, where decision-making and resource allocation must be balanced between autonomy and coordination. Here’s how lessons from these systems can be applied:

1. Decentralized Decision-Making and Autonomy

In systems where decision-making is decentralized, local entities—whether teams or individuals—are empowered to make their own decisions, which can increase responsiveness and adaptability. For software development, this manifests in open-source projects and distributed teams, where contributors have the freedom to manage their own work.

Application to Software Development:

  • Open-Source Projects and Self-Organizing Teams: Teams and individuals contribute autonomously, setting their own goals and working at their own pace. This mirrors decentralized development practices in software, where contributors choose their projects and coordinate loosely.
  • Coordination and Consistency: However, without some level of standardization and coordination, fragmentation can occur. In software, tools like version control systems (e.g., Git) and continuous integration pipelines help maintain consistency across autonomous contributors.

Challenges & Solutions:

  • Preventing Inefficiency: Decentralized decision-making can lead to inefficiencies if individual contributors focus solely on short-term outcomes. To mitigate this, project management tools and collaborative protocols are essential for aligning short-term work with long-term goals.
  • Coordination Tools: Establishing coordination mechanisms, such as shared roadmaps and CI/CD pipelines, helps maintain a cohesive direction without stifling the autonomy that drives innovation.

2. Resource Sharing and Compute Reuse

In decentralized environments, resources such as compute power, storage, or bandwidth may be distributed unevenly across various nodes or contributors. Without mechanisms for efficient sharing, this can lead to underutilization or overburdening of certain parts of the system.

Application to Compute Resources:

  • Decentralized Cloud and Edge Computing: In decentralized cloud or edge computing, resources like processing power and storage are scattered across different nodes. To make the system efficient, compute resources must be pooled and reused where needed, ensuring optimal performance.
  • Resource Pooling: Implementing resource-sharing mechanisms, where unused resources can be dynamically allocated to different tasks, can help prevent wasted compute cycles and ensure that underutilized resources are effectively leveraged.

Challenges & Solutions:

  • Inefficient Allocation: If nodes or teams prioritize their local gains without considering the system-wide efficiency, it can lead to uneven resource distribution. This can be addressed with incentives, such as blockchain reward systems, which align local actions with broader network health.
  • Automated Resource Distribution: Smart contracts or automated protocols can ensure that resources are allocated fairly and efficiently, based on pre-determined rules, preventing the inefficiencies that often arise in decentralized systems.

3. Collaboration Across Platforms

Decentralized systems often need to collaborate across different networks or platforms. In decentralized software development, collaboration between different ecosystems—whether it’s different blockchain protocols or software repositories—can enhance innovation and resource sharing.

Application to Software Development:

  • Cross-Network Collaboration: Just as decentralized systems benefit from interaction with different platforms, decentralized software teams can leverage diverse ecosystems to enhance their projects. For example, developers from different platforms (like Ethereum or Polkadot) can share resources and innovations to solve common problems.
  • Interoperability Standards: Ensuring that systems are interoperable is key to enabling seamless collaboration across different platforms. Open standards and APIs allow for easier integration and resource reuse, fostering greater collaboration and efficiency.

Challenges & Solutions:

  • Integration of Diverse Systems: Integrating decentralized systems built on different technologies can be a challenge. Establishing standardized protocols (e.g., REST APIs) enables different platforms to communicate and share resources effectively.
  • Incentivizing Cross-Platform Collaboration: Incentives are needed to encourage collaboration across different decentralized systems. Similar to economic incentives, decentralized software platforms can use governance tokens or cross-chain interoperability tools to incentivize resource sharing and collaboration.

4. Maintaining Balance Between Autonomy and Coordination

A key challenge in decentralized systems is balancing local autonomy with system-wide coordination. In software development, this tension arises when teams or individuals are given too much freedom, potentially leading to fragmentation or misalignment with overall project goals.

Application to Software Development:

  • Hybrid Approaches: Decentralized software development often combines local autonomy with some level of global coordination. Individual developers or teams can contribute freely, while project managers or governance structures ensure alignment with the overall vision.
  • Federated Systems: In decentralized computing or cloud systems, a federated model allows local entities to retain control over their resources while participating in a broader, collaborative network. This structure promotes resource sharing while maintaining the autonomy of individual nodes.

Challenges & Solutions:

  • Preventing Fragmentation: Autonomy can sometimes lead to a lack of cohesion in decentralized projects. Coordination tools, such as shared documentation, governance frameworks, and communication platforms, can help maintain alignment without undermining local control.
  • Efficient Resource Sharing: Resource pooling or federated learning models—where multiple decentralized devices collaborate without sharing raw data—are examples of how decentralized systems can ensure efficient resource use while maintaining local autonomy.

Conclusion:

Decentralized software development and the reuse of compute resources benefit from the lessons learned in other decentralized systems. By balancing local autonomy with global coordination, establishing clear standards for interoperability, and incentivizing efficient resource use, decentralized systems can avoid common pitfalls. Effective coordination protocols, smart contracts, and resource-sharing mechanisms are essential for creating a resilient, efficient, and collaborative decentralized computing ecosystem.

Methodology Recommendation for Secure Decentralized Software Development

Introduction

In the evolving landscape of digital software development, ensuring the security, integrity, and transparency of supply chains is critical. This methodology recommendation combines principles of Trusted Execution Environments (TEEs), decentralization, and robust governance to establish a secure and collaborative ecosystem, enabling seamless cooperation between human and AI developers in a decentralized web3 environment.

Key Methodology Components

1. Identity Management and Trust Building

  • Utilize Decentralized Identifiers (DIDs): Establish self-sovereign identities for both human and AI developers, fostering trust and accountability without reliance on centralized authorities. This allows for autonomous identity verification, critical in a decentralized setting where diverse entities interact.
  • Implement Verification Protocols: Deploy robust mechanisms to validate the authenticity and integrity of contributions from both human and AI developers, ensuring inputs are trustworthy and traceable. This fosters a collaborative environment where AI systems can independently verify and cross-check contributions made by human counterparts and vice-versa.

2. Secure Communication and Data Handling

  • Adopt Advanced Encryption Techniques: Secure all data exchanges between entities using end-to-end encryption and secure communication protocols to protect against unauthorized access and data breaches. This ensures that both human and AI-generated data remain secure throughout the development pipeline.
  • Leverage Content-Addressable Storage (CAS): Ensure data immutability and integrity by storing code and artifacts generated by human and AI developers in CAS systems, allowing for efficient tracking and retrieval based on content hashes CBOR-LD Specification.

3. Transparency and Accountability

  • Incorporate Transparency Logs: Utilize federated, immutable transparency logs, such as those described in SCITT, to create a verifiable record of development actions from both humans and AI, enhancing auditability and accountability SCITT Architecture. Logs provide a clear history of AI model contributions alongside human actions, fostering trust.
  • Facilitate Traceability: Ensure the provenance of both code and data is easily traceable throughout the development lifecycle, bolstering security and trust, and allowing users to understand how AI inputs interact with human contributions.

4. Policy Enforcement and Access Control

  • Develop Dynamic Policy Engines: Use policy engines to dynamically enforce security rules and access controls on both human and AI contributions based on predefined conditions and real-time assessments of trustworthiness. This ensures cooperative adherence to guidelines while allowing for nuanced operational flexibility.
  • Ensure Comprehensive Isolation: Isolate different development processes and nodes, whether driven by human or AI developers, to prevent malicious interference and protect the integrity of the environment. TEEs can be leveraged here to securely isolate sensitive interactions between human and AI-driven processes.

5. Resilience and Collaboration

  • Promote a Decentralized Ecosystem: Distribute decision-making and control to minimize central failure points and empower human and AI developers to operate autonomously, enabling more resilient collaboration. This fosters a symbiotic relationship where each can independently contribute to innovations and solutions.
  • Foster Interoperability with Web3 Tools: Integrate web3 technologies and protocols to enhance interconnectivity between human developers and AI systems, enabling seamless interactions and boosting resilience across diverse development environments.

6. Leveraging Trusted Execution Environments

  • Encourage the Use of TEEs: Deploy TEEs for sensitive operations conducted by both human and AI developers, providing secure, isolated execution environments that protect code and data from unauthorized access or manipulation. TEEs are foundational in allowing human and AI collaboration without compromising security.
  • Implement Attestation Mechanisms: Use attestation and verification processes to ensure TEEs' security status, facilitating dynamic trust relationships that benefit from both human insights and AI processing efficiencies.

Conclusion

By synthesizing these components into a cohesive methodology, we construct a robust, secure, and transparent decentralized software development environment that empowers human and AI developers to innovate and collaborate effectively. This vision fosters a trust-based ecosystem, ensuring the integrity and confidentiality of the development process, and leveraging the strengths of both human creativity and AI analytics. Embracing standards like those proposed by SCITT and CBOR-LD ensures that the methodology remains adaptable and progressive, meeting the latest innovations and challenges in the field.

Methodology Recommendation for Secure Decentralized Software Development

Introduction

In the evolving landscape of digital software development, ensuring the security, integrity, and transparency of supply chains is critical. This methodology recommendation combines principles of Trusted Execution Environments (TEEs), decentralization, and robust governance to establish a secure and collaborative ecosystem, tailored to meet the needs of both human and AI developers in a decentralized web3 environment.

Key Methodology Components

1. Identity Management and Trust Building

  • Utilize Decentralized Identifiers (DIDs): Establish self-sovereign identities for developers, fostering trust and accountability without reliance on centralized authorities. By doing so, we can navigate the unique challenges and opportunities that decentralization introduces.
  • Implement Verification Protocols: Employ robust mechanisms to validate the authenticity and integrity of contributions, ensuring that both human and AI inputs are trustworthy and traceable. Engaging with evolving initiatives can further enhance these protocols.

2. Secure Communication and Data Handling

  • Adopt Advanced Encryption Techniques: Secure all data exchanges between entities using end-to-end encryption and secure communication protocols to protect against unauthorized access and data breaches. This ensures that even in untrusted environments, data integrity is maintained.
  • Leverage Content-Addressable Storage (CAS): Ensure data immutability and integrity by storing code and artifacts in CAS systems, which allows for efficient tracking and retrieval based on content hashes CBOR-LD Specification.

3. Transparency and Accountability

  • Incorporate Transparency Logs: Utilize federated, immutable transparency logs such as those described in SCITT to create a verifiable record of development actions, enhancing auditability and accountability SCITT Architecture.
  • Facilitate Traceability: Ensure the provenance of code and data is easily traceable throughout the development lifecycle to bolster security and trust, providing full visibility into the journey and origins of digital assets.

4. Policy Enforcement and Access Control

  • Develop Dynamic Policy Engines: Use policy engines to dynamically enforce security rules and access controls based on predefined conditions and real-time assessments of trustworthiness. Such engines support adaptive governance models and promote compliance.
  • Ensure Comprehensive Isolation: Isolate different development processes and nodes to prevent malicious interference and protect the integrity of the development environment. TEEs can be leveraged to enhance isolation, providing secure, isolated environments for critical operations.

5. Resilience and Collaboration

  • Promote a Decentralized Ecosystem: Distribute decision-making and control to minimize central failure points and empower developers to operate autonomously, enabling more resilient collaboration. This fosters innovation and reduces risks associated with singular points of failure.
  • Foster Interoperability with Web3 Tools: Integrate web3 technologies and protocols to enhance interconnectivity, enabling seamless interactions and greater resilience across diverse development environments.

6. Leveraging Trusted Execution Environments

  • Encourage the Use of TEEs: Deploy TEEs for sensitive operations, providing secure, isolated execution environments that protect code and data from unauthorized access or manipulation. TEEs are vital in safeguarding critical processes.
  • Implement Attestation Mechanisms: Use attestation and verification processes to ensure the TEE's security status, allowing for nuanced trust levels and adaptive trust management, which are fundamental for maintaining a secure ecosystem.

Conclusion

By synthesizing these components into a cohesive methodology, we can construct a robust, secure, and transparent decentralized software development environment. This approach not only protects the integrity and confidentiality of the development process but also empowers developers to innovate and collaborate effectively in a trust-based ecosystem, laying the groundwork for a secure digital future. Embracing standards like those proposed by SCITT and CBOR-LD ensures that the methodology remains adaptable and aligned with the latest innovations and challenges in the field.

You're right, we need to explicitly address the role of Trusted Execution Environments (TEEs) and varying levels of Trust in the context of Decentralized Software Development. Here's how Alice, the Open Architecture, incorporates them:

Alice: The Open Architecture for Decentralized Software Development

1. Identity and Trust:

  • Decentralized Identifiers (DIDs): Enable human and AI developers to establish self-sovereign identities, fostering trust and accountability across the network. DIDs, in combination with verifiable credentials, allow for nuanced trust levels based on the issuer and the information they attest to.
  • Verification: Provides mechanisms to validate the authenticity and integrity of contributions from both human and AI developers, building confidence in the decentralized ecosystem. This verification can be further enhanced by considering the trustworthiness of the TEE where the contribution originated.

2. Secure Communication and Data Integrity:

  • Secure Communication: Employs robust encryption and secure communication protocols to protect sensitive information as it is shared between developers, ensuring data privacy and integrity within the network. This secure communication is especially critical when dealing with sensitive data or code that might be hosted in less-trusted environments.
  • Content-Addressable Storage (CAS): Stores code, data, and artifacts in a way that ensures immutability and prevents tampering. This promotes data integrity and builds trust in the shared resources. CAS, combined with TEEs, creates a stronger defense against data manipulation, as the integrity of the data can be verified even if the storage environment is compromised.

3. Transparency and Auditing:

  • Transparency: Enables the creation of a publicly accessible, immutable history of contributions through transparency logs. This provides a clear and verifiable record of actions, promoting trust and accountability within the decentralized network. Transparency logs can be integrated with TEE attestations, allowing for the validation of the execution environment's integrity alongside the actions taken within it.
  • Traceability: Facilitates tracking the provenance of code and data, allowing developers to understand the origin and journey of their contributions, enhancing transparency and auditability. This traceability can be extended to include the attestation results from TEEs, providing a complete lineage for both the artifact and its execution environment.

4. Policy Enforcement and Control:

  • Policy Engines: Implement dynamic rules and conditions to govern how code is shared and used within the development process. Policy engines, such as those based on labeled property graphs and content-addressable ontologies, can enforce access control, validation, and other security measures. Policy engines can leverage attestation results from TEEs to further refine their decisions, for example, allowing for more relaxed access policies for artifacts coming from highly trusted environments.
  • Isolation: Separates different stages or nodes of the development process, ensuring that the actions of one developer cannot compromise or interfere with others' work. TEEs play a crucial role in ensuring isolation, particularly for sensitive operations or when collaborating with less trusted entities.

5. Resilience and Collaboration:

  • Decentralization: Distributes decision-making and control across the network, minimizing the risk of a single point of failure and empowering developers to collaborate on their own terms. The use of TEEs enables a more decentralized system, allowing for independent execution of code and data processing, even if parts of the network are controlled by untrusted entities.
  • Resilience: Enables the development process to continue even if individual developers or systems encounter problems, making the entire system more robust. TEEs contribute to resilience by providing a secure and isolated environment for critical processes, even if other parts of the network are experiencing issues.

Trusted Execution Environments and Varying Trust Levels:

TEEs are critical components of Alice's decentralized architecture. They provide a secure and isolated environment for sensitive operations, such as:

  • Code compilation and execution: Ensuring the integrity of the compiled code and the execution environment itself.
  • Data processing and manipulation: Safeguarding sensitive data from unauthorized access or manipulation.
  • Policy engine execution: Providing a secure platform for enforcing security policies, even when dealing with less trusted developers or environments.

Alice's architecture acknowledges that different TEEs may have different levels of trust. This is reflected in the following ways:

  • Attestation and verification: TEEs can generate attestation results, which are then validated by other participants. Attestation results provide evidence of the TEE's security status and can be used to establish trust levels.
  • Policy engine configuration: The policy engine can adjust its behavior based on the trust level of the TEE where the code originates. For example, code from a highly trusted TEE might be subject to fewer security checks.
  • Dynamic trust adaptation: Alice allows for trust relationships to be modified dynamically based on evidence and attestations, enabling the network to adapt to evolving trust levels and potentially adjust its reliance on different TEEs over time.

Alice's Technical Recommendations:

  • TEEs: Encourage the use of TEEs for sensitive operations, enabling secure and isolated execution environments for code and data.
  • Attestation: Implement attestation mechanisms for verifying the integrity of TEEs.
  • Dynamic Trust Management: Develop mechanisms for dynamically adapting trust levels based on attestation results and other evidence.
  • Policy Engine Integration: Ensure that the policy engine can leverage TEE attestation results and dynamically adjust security policies based on trust levels.

By leveraging TEEs and a flexible approach to trust management, Alice empowers developers to collaborate in a secure and robust decentralized ecosystem. This approach fosters trust, transparency, and resilience, paving the way for a more secure and equitable future of software development.

You are absolutely right! Grouping the properties logically makes the overall picture much clearer. Here's a breakdown of the key properties of an abstract trusted execution environment, organized by architectural components, with a decentralized focus and web3 integration:

Alice: The Open Architecture for Decentralized Software Development

1. Identity and Trust:

  • Decentralized Identifiers (DIDs): Enable human and AI developers to establish self-sovereign identities, fostering trust and accountability across the network.
  • Verification: Provides mechanisms to validate the authenticity and integrity of contributions from both human and AI developers, building confidence in the decentralized ecosystem.

2. Secure Communication and Data Integrity:

  • Secure Communication: Employs robust encryption and secure communication protocols to protect sensitive information as it is shared between developers, ensuring data privacy and integrity within the network.
  • Content-Addressable Storage (CAS): Stores code, data, and artifacts in a way that ensures immutability and prevents tampering. This promotes data integrity and builds trust in the shared resources.

3. Transparency and Auditing:

  • Transparency: Enables the creation of a publicly accessible, immutable history of contributions through transparency logs. This provides a clear and verifiable record of actions, promoting trust and accountability within the decentralized network.
  • Traceability: Facilitates tracking the provenance of code and data, allowing developers to understand the origin and journey of their contributions, enhancing transparency and auditability.

4. Policy Enforcement and Control:

  • Policy Engines: Implement dynamic rules and conditions to govern how code is shared and used within the development process. Policy engines, such as those based on labeled property graphs and content-addressable ontologies, can enforce access control, validation, and other security measures.
  • Isolation: Separates different stages or nodes of the development process, ensuring that the actions of one developer cannot compromise or interfere with others' work.

5. Resilience and Collaboration:

  • Decentralization: Distributes decision-making and control across the network, minimizing the risk of a single point of failure and empowering developers to collaborate on their own terms.
  • Resilience: Enables the development process to continue even if individual developers or systems encounter problems, making the entire system more robust.

Key Technical Properties Recommended by Alice:

  • DIDs: Use DIDs as the foundation for secure and verifiable identities within the decentralized network.
  • CAS: Employ CAS systems to ensure the integrity and immutability of code, data, and artifacts.
  • Transparency Logs: Implement federated transparency logs (e.g., using SCITT) to provide a verifiable history of development actions.
  • Policy Engines: Utilize dynamic policy engines based on labeled property graphs and content-addressable ontologies to enforce security rules and ensure compliance.

The Open Architecture Vision

By integrating these properties and technologies, Alice, the Open Architecture, strives to create a more secure, transparent, and equitable environment for collaborative software development in the web3 era. This approach empowers human and AI developers to work together in a decentralized ecosystem while maintaining control over their work, enhancing trust, and promoting innovation.

You are absolutely right! Let's focus on the specific technical properties of the Open Architecture (nicknamed "Alice") in relation to decentralized identifiers (DIDs), content-addressable storage, and how these technologies can facilitate secure and collaborative development between human and AI developers in a web3 environment.

Here are the key properties of an abstract trusted execution environment that enable this collaboration:

1. Isolation:

  • Decentralization Implication: Isolation safeguards human and AI developers' work from potential interference, ensuring their tools, code, and data remain secure and independent. This fosters a trust-based environment where collaboration can thrive.

2. Verification:

  • Decentralization Implication: Verification provides a mechanism to validate the integrity and authenticity of each contribution, establishing trust between human and AI developers within a decentralized ecosystem.

3. Secure Communication:

  • Decentralization Implication: Secure communication ensures that all data exchanged between developers is protected from unauthorized access or manipulation. This is essential for safeguarding both human and AI developer's code, data, and collaboration tools in a decentralized setting.

4. Transparency:

  • Decentralization Implication: Transparency fosters a shared understanding of the development process. Publicly accessible logs, such as those enabled by SCITT, provide an immutable history of contributions, enhancing trust and accountability within the network.

5. Traceability:

  • Decentralization Implication: Traceability promotes transparency and auditability by allowing developers to track the provenance of code and data. For example, AI developers can demonstrate how specific datasets were used in model training, and human developers can verify the origin of code, promoting accountability and confidence.

6. Resilience:

  • Decentralization Implication: Resilience ensures that the collaborative development process can continue even if individual developers or systems encounter problems. This is critical in a decentralized environment where no single entity holds absolute power.

7. Decentralization:

  • Decentralization Implication: Decentralization empowers both human and AI developers to have a say in how the project is managed and governed. This fosters a more equitable and collaborative environment where no single entity exerts undue control.

Alice's Decentralized Architecture with Web3 and DIDs

Alice, the Open Architecture, leverages these properties and integrates them with web3 technologies and Decentralized Identifiers (DIDs) to create a secure and collaborative development ecosystem:

  • Decentralized Identifiers (DIDs): Alice utilizes DIDs to provide a verifiable and portable identity for both human and AI developers. DIDs enable developers to have a self-sovereign identity, ensuring that their contributions can be authenticated and traced across the decentralized network.

  • Content-Addressable Storage (CAS): Alice promotes the use of CAS systems to store code, data, and artifacts, ensuring that every piece of information can be uniquely identified and accessed based on its content. CAS systems offer immutability and prevent tampering, enhancing the trust and integrity of the development process.

  • Secure Collaboration Mechanisms: Alice integrates with existing protocols and technologies like SCITT to provide secure logging, transparency, and verification for the development process. This allows for a decentralized system where human developers can trust the contributions of AI developers and vice versa.

Alice's Technical Recommendations:

Alice, the Open Architecture, encourages the adoption of these technologies and principles to foster secure and collaborative development in a decentralized web3 environment:

  • Content-Addressable Storage: Storing code and data in CAS systems ensures that they are uniquely identified and immutable. This promotes data integrity and prevents tampering.
  • Decentralized Identifiers: Using DIDs for developer identities allows for self-sovereign control, enabling them to manage their own identities and data, and creating a more equitable and secure collaboration environment.
  • Federated Transparency Logs: Utilizing SCITT-like logs for recording and sharing verified statements allows for a decentralized audit trail, enabling stakeholders to verify the integrity of the entire development process.
  • Policy Engines: Implementing policy engines, such as those based on labeled property graphs and content-addressable ontologies, allows for the dynamic enforcement of rules and conditions within the development process, ensuring compliance and maintaining trust.
  • Secure Communication Protocols: Emphasizing end-to-end encryption and secure communication protocols during data exchange between developers is crucial for safeguarding sensitive information and maintaining trust.

By embracing these technical properties and principles, Alice helps human and AI developers build a robust, secure, and transparent development ecosystem in the decentralized web3 world. This approach empowers developers, fosters trust, and promotes innovation across the network.

1. Isolation:

  • Decentralization Implication: Isolation helps prevent any single entity from having full control over the entire supply chain. This is crucial for avoiding single points of failure and ensuring that disruptions in one part of the chain don't cripple the entire system.
  • Example: Imagine a supply chain for software development. Different teams might work on different components (like code libraries, testing frameworks, or deployment tools) in their own isolated TEEs. This prevents one team's mistakes or malicious actions from affecting the entire development process.

2. Verification:

  • Decentralization Implication: Verification allows each node in the supply chain to validate the integrity of the data it receives from other nodes, without relying on a central authority to certify everything.
  • Example: Each node in the software development supply chain can verify the code it receives from upstream teams by checking digital signatures and SBOMs, ensuring that it's authentic and hasn't been tampered with.

3. Secure Communication:

  • Decentralization Implication: Secure communication ensures that data exchanged between nodes is protected from eavesdropping or manipulation, even if some nodes are compromised.
  • Example: End-to-end encryption and secure protocols can be used to protect code, SBOMs, and other sensitive information as it moves through the software development supply chain.

4. Transparency:

  • Decentralization Implication: Transparency makes the supply chain's actions and data visible to all participants. This allows for independent audits and helps build trust in the system as a whole.
  • Example: Publicly available transparency logs, like SCITT logs, can record all code changes, SBOM updates, and other relevant events in the software development supply chain, allowing anyone to review the history and verify its authenticity.

5. Traceability:

  • Decentralization Implication: Traceability ensures that the origin and journey of materials and products can be tracked throughout the supply chain, regardless of the specific actors involved. This facilitates accountability and helps identify potential risks.
  • Example: In a supply chain for pharmaceutical products, each node can record the origin, processing steps, and transportation details of the materials used, allowing for full traceability from raw ingredients to the final product.

6. Resilience:

  • Decentralization Implication: Resilience allows the supply chain to withstand disruptions and failures at individual nodes. Decentralization spreads the risk, ensuring that the system can continue operating even if some components are unavailable.
  • Example: A software development supply chain can incorporate multiple independent build servers and testing environments, allowing for continuous development even if one node encounters problems.

7. Confidentiality:

  • Decentralization Implication: Confidentiality helps protect sensitive business information, even if some nodes in the supply chain are compromised.
  • Example: Encryption and access control mechanisms can be used to secure sensitive data like source code, trade secrets, and customer information as it moves through the supply chain.

8. Decentralization:

  • Decentralization Implication: This is the foundation of the entire system! Decentralization distributes decision-making and control across different nodes in the supply chain, minimizing the risk of a single point of failure or compromise.
  • Example: In a decentralized software development ecosystem, different teams can manage their own repositories, build servers, and testing environments, ensuring that no single entity has absolute control over the entire process.

The Open Architecture (Alice) and Decentralization

The Open Architecture (Alice) is designed to leverage these properties to create a more secure and resilient digital supply chain ecosystem. By promoting decentralization, Alice:

  • Reduces dependence on central authorities: This makes the system less vulnerable to manipulation and censorship.
  • Empowers participants: Each participant has greater control over their own data and processes, fostering greater transparency and accountability.
  • Improves resilience: The distributed nature of the system helps it withstand disruptions and attacks.
  • Encourages innovation: Decentralization fosters a more collaborative and open environment, leading to the development of new tools and solutions.

The properties you listed are fundamental to building a decentralized and trustworthy supply chain ecosystem. By implementing these principles, we can create systems that are more secure, resilient, and equitable.

Bullet Point Properties of an Abstract Trusted Execution Environment - Decentralized Perspective

The abstract properties of a trusted execution environment (TEE) in a supply chain context, when viewed through a decentralized lens, are particularly important for building trust and security across distributed networks, and are essential elements of an Open Architecture, often nicknamed "Alice":

1. Security:

  • Integrity: Guarantees that the environment's state, code, and data remain unaltered and tamper-proof, even when the environment itself is controlled by a third party.
  • Confidentiality: Ensures the privacy and secrecy of sensitive information within the environment, even if the environment's operators are untrusted.
  • Isolation: Separates the TEE from other components, protecting it from unauthorized access or interference, even from malicious actors within the network.
  • Non-repudiation: Enables the verifiable attribution of actions within the TEE to a specific entity or source, providing accountability even if the environment itself is compromised.

2. Transparency:

  • Auditable: Provides mechanisms to track and verify changes within the environment, allowing for accountability and trust building across decentralized networks. This means that any participant can independently verify the integrity of the environment's actions and data.
  • Verifiable: Offers cryptographic proofs to demonstrate the integrity and authenticity of actions and data within the TEE, which can be validated independently by any participant in the network, even if the environment itself is untrusted.

3. Control:

  • Policy Enforcement: Allows for the implementation and enforcement of specific policies within the TEE, such as access control, data validation, and execution restrictions, ensuring that actions taken within the environment adhere to pre-defined rules, even if the environment is operated by a potentially untrusted party.
  • Attestation: Provides a mechanism to assert the secure state of the TEE to a remote verifier, even if the verifier is not directly controlling the environment, allowing for trust to be established based on independent verification.

4. Context:

  • Operational Context: Enables the TEE to access and understand the context of its execution within the broader, distributed system, so that it can make decisions based on the overall network state and not just its own isolated view.
  • State Management: Facilitates the efficient management and persistence of the TEE's state across the network, ensuring continuity and consistency even if some parts of the network are unavailable.

5. Interoperability:

  • Standard-Based: Adheres to established standards for communication and data exchange, promoting interoperability with various systems within the decentralized network.
  • Federation: Enables secure communication and sharing of information between different TEE instances across the network, contributing to a broader ecosystem of trust, where participants can independently collaborate and share information without relying on a single centralized authority.

Alice's Decentralized Architecture

Alice, the nickname for the Open Architecture, leverages these TEE properties to create a decentralized framework for trustworthy and transparent digital supply chains. This approach emphasizes:

  • Distributed Trust: Alice relies on a network of independently verified TEEs rather than a single central authority, enabling robust resilience and preventing single points of failure.
  • Federated Transparency: Alice allows for the federation of multiple transparency logs, each maintained by different entities, so that the complete audit trail of an artifact can be traced across the network.
  • Peer-to-peer Communication: Alice enables secure communication and information sharing directly between peers within the network, reducing reliance on centralized intermediaries and promoting data sovereignty.
  • Policy Enforcement by Peers: Alice enables peers to enforce their own policies within their TEEs, ensuring that actions taken within the network align with the collective understanding of trust.
  • Dynamically Adaptable Trust: Alice allows for trust relationships to be established and modified based on evidence and attestations, enabling the network to adapt to changing conditions and emerging threats.

In summary, by embracing decentralization and leveraging the abstract properties of TEEs, Alice, the Open Architecture, fosters a more secure, transparent, and resilient digital supply chain ecosystem. This approach empowers individuals and organizations to collaborate and share data in a way that is both trustworthy and independent, facilitating a more secure and open digital future.

  • SSH one-liner for Ghost in TMUX Shell: https://asciinema.org/a/674501?t=111
    • ssh -p 2222 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o PasswordAuthentication=no -R /tmp/${GITHUB_USER}.sock:$(echo $TMUX | sed -e 's/,.*//g') -R /tmp/${GITHUB_USER}-input.sock:/tmp/${GITHUB_USER}-input.sock ${GITHUB_USER}@askalice.today

live-demo-for-the-live-demo-god

serverless: A suite of command-line tools for managing transparency logs whose state is entirely composed of on-disk files, along with examples of how to use GitHub/GitHub Actions to host & publicly serve the log.
Notable projects that have graduated from this repository to their own top-level repositories:

witness
distributor

cargo install cargo-binstall
cargo binstall cargo-risczero
cargo risczero install

flowchart TD
    subgraph zkp_reproducable_builds
        subgraph ORAS.land
            content_addressable_registry[OCI Registry]
            sbom[Container BOM]
        end

        subgraph SCITT_Alice[SCITT Alice]
            alice_submit --> receipt --> federate
            receipt -->|expose did:jwks embedded within payloads<br>resolvable by signed statement URN<br>claims include statement URN| jwks[jwk - clear for take off]
        end

        subgraph HSM_Alice[HSM Alice]
            alice_hsm_sign
        end

        subgraph Phase4OrchestratorRelyingPartyMutatingAgentWorkloadIdentityPolicyEngineOOB
            receipt -->|query SCITT| relying_party_oidc_issuer
            relying_party_oidc_issuer --> |issue token| policy_engine_workload
            policy_engine_workload --> |steps.uses| relying_party_oidc_verifier
            relying_party_oidc_verifier --> |hardcoded: jwks, issuer, audiance| generate_zkvm_code
            relying_party_oidc_verifier --> |populate hardcoded data for linked data<br>resolution off SCITT+ORAS to assist with caching| content_addressable_registry
            generate_zkvm_code --> |run with input: token_to_verify| zkvm_host
            generate_zkvm_code --> |populate generated zkvm source code for linked data<br>resolution off SCITT+ORAS to assist with caching| content_addressable_registry
            zkvm_host --> |input: token_to_verify| zkvm_guest
            zkvm_guest --> |output: valid and zkp of such<br>else no statement created| payload
            payload --> statement
            statement --> alice_hsm_sign
            alice_hsm_sign --> signed_statement
            signed_statement -->|this HSM has this zkp for this OIDC passing for this issuer| alice_submit
        end

        subgraph SCITT_Bob[SCITT Bob]
            bob_submit --> policy_engine
            policy_engine --> verify_zkp
            verify_zkp --> verify_oidc_verification
            content_addressable_registry -->|pull in hardcodes and generated rust| verify_oidc_verification
            jwks --> |verify identity via OIDC jwks resolution| verify_oidc_verification
            verify_oidc_verification --> do_something_that_requires_verification_of_a_property_of_alices_workload
        end

        sbom --> alice_submit
        sbom -->|Alice attempt policy engine exec| relying_party_oidc_issuer
        federate --> bob_submit
    end
Loading 
PermitUserEnvironment yes
# ForceCommand /bin/locked-shell.sh
ForceCommand /usr/bin/bash
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication yes
AuthorizedKeysCommand /usr/bin/curl -sfL https://github.com/%u.keys
AuthorizedKeysCommandUser nobody
AuthorizedPrincipalsCommand /usr/bin/curl -sfL https://github.com/%u.keys
AuthorizedPrincipalsCommandUser nobody


#%PAM-1.0
auth       required     pam_permit.so
session    required     pam_permit.so
auth       substack     password-auth
auth       include      postlogin
account    required     pam_sepermit.so
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    optional     pam_motd.so
session    include      password-auth
session    include      postlogin

(

cat /usr/lib/os-release | jq -c -R -s '
    split("\n") |
    map(select(length > 0)) |
    map(split("=")) |
    map({"key": .[0], "value": (.[1] | gsub("^\"|\"$"; ""))}) |
    from_entries
'
{"NAME":"Fedora Linux","VERSION":"40 (Workstation Edition)","ID":"fedora","VERSION_ID":"40","VERSION_CODENAME":"","PLATFORM_ID":"platform:f40","PRETTY_NAME":"Fedora Linux 40 (Workstation Edition)","ANSI_COLOR":"0;38;2;60;110;180","LOGO":"fedora-logo-icon","CPE_NAME":"cpe:/o:fedoraproject:fedora:40","DEFAULT_HOSTNAME":"fedora","HOME_URL":"https://fedoraproject.org/","DOCUMENTATION_URL":"https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/","SUPPORT_URL":"https://ask.fedoraproject.org/","BUG_REPORT_URL":"https://bugzilla.redhat.com/","REDHAT_BUGZILLA_PRODUCT":"Fedora","REDHAT_BUGZILLA_PRODUCT_VERSION":"40","REDHAT_SUPPORT_PRODUCT":"Fedora","REDHAT_SUPPORT_PRODUCT_VERSION":"40","SUPPORT_END":"2025-05-13","VARIANT":"Workstation Edition","VARIANT_ID":"workstation"}

Personal development forge (federated version of development environment) requirements.

dotfiles/forge-install.sh

Lines 1 to 584 in 8d9850f

#!/usr/bin/env bash
set -xeuo pipefail
export DEFAULT_PYTHON="$(which python)"
export INSTALL_WORK_DIR="${HOME}/.local/forgejo-install"
export GITEA_WORK_DIR="${HOME}/.local/forgejo"
export PYTHON="${PYTHON:-${DEFAULT_PYTHON}}"
if [ ! -f "${INSTALL_WORK_DIR}/.venv/bin/activate" ]; then
"${PYTHON}" -m venv "${INSTALL_WORK_DIR}/.venv"
. "${INSTALL_WORK_DIR}/.venv/bin/activate"
python -m pip install pyyaml keyring beautifulsoup4
fi
. "${INSTALL_WORK_DIR}/.venv/bin/activate"
FORGEJO_USERNAME=$(python -m keyring get "${USER}" "${USER}.forgejo.username")
if [ "x${FORGEJO_USERNAME}" = "x" ]; then
echo "${USER}" | python -m keyring set "${USER}" "${USER}.forgejo.username"
fi
FORGEJO_EMAIL=$(python -m keyring get "${USER}" "${USER}.forgejo.email")
if [ "x${FORGEJO_EMAIL}" = "x" ]; then
git config user.email | python -m keyring set "${USER}" "${USER}.forgejo.email"
fi
FORGEJO_PASSWORD=$(python -m keyring get "${USER}" "${USER}.forgejo.password")
if [ "x${FORGEJO_PASSWORD}" = "x" ]; then
python -m keyring set "${USER}" "${USER}.forgejo.password"
fi
export SSH_USER="${SSH_USER:-${USER}}"
export ROOT_IN_TCB_FQDN="${ROOT_IN_TCB_FQDN:-localhost}"
export ROOT_OUT_TCB_FQDN="${ROOT_OUT_TCB_FQDN:-localhost}"
# TODO scitt.unstable. should be something like caddy.admin.
export SSH_HOST="${SSH_HOST:-scitt.unstable.${ROOT_IN_TCB_FQDN}}"
export SSH_USER_AT_HOST="${SSH_USER}@${SSH_HOST}"
export SSH_WORK_DIR="/home/${SSH_USER}"
export FORGEJO_FQDN="git.${USER}.${ROOT_IN_TCB_FQDN}"
export DIRECTUS_FQDN="directus.${USER}.${ROOT_IN_TCB_FQDN}"
mkdir -p $HOME/.local/share/systemd/user
tee $HOME/.local/share/systemd/user/forge.service <<'EOF'
[Unit]
Description=Secure Softare Forge: VCS: Forgejo
[Service]
Type=simple
TimeoutStartSec=0
ExecStart=bash -c "exec ${HOME}/.local/share/systemd/user/forge.service.sh"
Environment=VIRTUAL_ENV=%h/.local/forgejo-install/.venv
Environment=SSH_USER=%u
Environment=ROOT_IN_TCB_FQDN=localhost
Environment=ROOT_OUT_TCB_FQDN=localhost
[Install]
WantedBy=default.target
EOF
tee $HOME/.local/share/systemd/user/mindsdb.service <<'EOF'
[Unit]
Description=Secure Softare Forge: AI: MindsDB
[Service]
Type=simple
TimeoutStartSec=0
ExecStart=bash -c "OPENAI_API_KEY=$(python -m keyring get $USER openai.api.key) python -m mindsdb --verbose --api=http --config %h/.local/forgejo-install/mindsdb-config.json"
Environment=VIRTUAL_ENV=%h/.local/forgejo-install/.venv
Environment=SSH_USER=%u
Environment=ROOT_IN_TCB_FQDN=localhost
Environment=ROOT_OUT_TCB_FQDN=localhost
[Install]
WantedBy=default.target
EOF
mkdir -p "${HOME}/.local/forgejo-install/"
export INIT_COMPLETE_JSON_PATH="${HOME}/.local/forgejo-install/init-complete.json"
export INIT_YAML_PATH="${HOME}/.local/forgejo-install/init.yaml"
tee "${INIT_YAML_PATH}" <<EOF
db_type: 'sqlite3'
db_host: '127.0.0.1:3306'
db_user: 'forgejo'
db_passwd: ''
db_name: 'forgejo'
ssl_mode: 'disable'
db_schema: ''
db_path: '${GITEA_WORK_DIR}/data/forgejo.db'
app_name: '${FORGEJO_USERNAME}-forgejo'
repo_root_path: '${GITEA_WORK_DIR}/data/forgejo-repositories'
lfs_root_path: '${GITEA_WORK_DIR}/data/lfs'
run_user: '${USER}'
domain: '${FORGEJO_FQDN}'
ssh_port: '0'
http_port: '3000'
app_url: 'https://${FORGEJO_FQDN}/'
log_root_path: '${GITEA_WORK_DIR}/data/log'
enable_update_checker: 'on'
smtp_addr: ''
smtp_port: ''
smtp_from: ''
smtp_user: ''
smtp_passwd: ''
offline_mode: 'on'
disable_gravatar: 'off'
enable_open_id_sign_in: 'off'
enable_open_id_sign_up: 'off'
default_allow_create_organization: 'on'
default_enable_timetracking: 'off'
no_reply_address: 'noreply.${FORGEJO_FQDN}'
password_algorithm: 'pbkdf2_hi'
admin_name: '${FORGEJO_USERNAME}'
admin_email: '${FORGEJO_EMAIL}'
admin_passwd: '${FORGEJO_PASSWORD}'
admin_confirm_passwd: '${FORGEJO_PASSWORD}'
EOF
export FORGEJO_COOKIE_JAR_PATH="${HOME}/.local/forgejo-install/curl-cookie-jar"
export LOGIN_YAML_PATH="${HOME}/.local/forgejo-install/login.yaml"
tee "${LOGIN_YAML_PATH}" <<EOF
_csrf: CSRF_TOKEN
user_name: '${FORGEJO_USERNAME}'
password: '${FORGEJO_PASSWORD}'
remember: 'on'
EOF
export NEW_OAUTH2_APPLICATION_YAML_PATH="${HOME}/.local/forgejo-install/directus_oauth2_application.yaml"
tee "${NEW_OAUTH2_APPLICATION_YAML_PATH}" <<EOF
name: 'OAUTH2_APPLICATION_NAME'
confidential_client: true
redirect_uris:
- 'https://${DIRECTUS_FQDN}/auth/login/forgejo/callback'
EOF
touch $HOME/.local/share/systemd/user/forge.service.sh
chmod 755 $HOME/.local/share/systemd/user/forge.service.sh
tee $HOME/.local/share/systemd/user/forge.service.sh <<'EOF'
#!/usr/bin/env bash
set -xeuo pipefail
declare -a TEMPDIRS=()
new_tempdir() {
tempdir=$(mktemp -d)
TEMPDIRS[${#TEMPDIRS[@]}]="${tempdir}"
echo "${tempdir}"
}
cleanup_tempdirs() {
for tempdir in "${TEMPDIRS[@]}"; do
rm -rf "${tempdir}"
done
}
declare -a PIDS=()
new_pid() {
PIDS[${#PIDS[@]}]="$1"
}
cleanup_pids() {
for pid in "${PIDS[@]}"; do
kill "${pid}"
done
}
declare -a DOCKER_CONTAINER_IDS=()
new_docker_container_id() {
DOCKER_CONTAINER_IDS[${#DOCKER_CONTAINER_IDS[@]}]="$1"
}
cleanup_docker_container_ids() {
for docker_container_id in "${DOCKER_CONTAINER_IDS[@]}"; do
docker kill "${docker_container_id}"
done
}
export INSTALL_WORK_DIR="${HOME}/.local/forgejo-install"
. "${INSTALL_WORK_DIR}/.venv/bin/activate"
export FORGEJO_COOKIE_JAR_PATH="${HOME}/.local/forgejo-install/curl-cookie-jar"
export LOGIN_YAML_PATH="${HOME}/.local/forgejo-install/login.yaml"
export INIT_COMPLETE_JSON_PATH="${HOME}/.local/forgejo-install/init-complete.json"
export NEW_OAUTH2_APPLICATION_YAML_PATH="${HOME}/.local/forgejo-install/directus_oauth2_application.yaml"
export INIT_YAML_PATH="${HOME}/.local/forgejo-install/init.yaml"
export GITEA_WORK_DIR="${HOME}/.local/forgejo"
cleanup_files() {
return
rm -fv "${INIT_YAML_PATH}" "${NEW_OAUTH2_APPLICATION_YAML_PATH}" "${FORGEJO_COOKIE_JAR_PATH}" "${LOGIN_YAML_PATH}"
}
cleanup() {
set +e
cleanup_files
cleanup_tempdirs
cleanup_pids
cleanup_docker_container_ids
}
trap cleanup EXIT
export SSH_USER="${SSH_USER:-${USER}}"
export ROOT_IN_TCB_FQDN="${ROOT_IN_TCB_FQDN:-localhost}"
export ROOT_OUT_TCB_FQDN="${ROOT_OUT_TCB_FQDN:-localhost}"
# TODO scitt.unstable. should be something like caddy.admin.
export SSH_HOST="${SSH_HOST:-scitt.unstable.${ROOT_IN_TCB_FQDN}}"
export SSH_USER_AT_HOST="${SSH_USER}@${SSH_HOST}"
export SSH_WORK_DIR="/home/${SSH_USER}"
export FORGEJO_FQDN="git.${USER}.${ROOT_IN_TCB_FQDN}"
export DIRECTUS_FQDN="directus.${USER}.${ROOT_IN_TCB_FQDN}"
# TODO TODO TODO TODO Document INIT_COMPLETE_JSON_PATH to reset_state TODO TODO
tee -a $HOME/.local/share/systemd/user/forge.service.sh <<'EOF'
export CADDY_USE_SSH=1
if [[ "x${SSH_USER}" = "x${USER}" ]] && [[ "x${ROOT_IN_TCB_FQDN}" = "xlocalhost" ]] && [[ "x${ROOT_OUT_TCB_FQDN}" = "xlocalhost" ]]; then
export CADDY_USE_SSH=0
fi
tee $HOME/.local/share/systemd/user/forge.service.Caddyfile <<CADDY_EOF
{
admin "unix/${SSH_WORK_DIR}/caddy.admin.sock" {
origins localhost
}
}
CADDY_EOF
export TEMPLATE_CADDYFILE_REVERSE_PROXY_OIDC_PATH="${HOME}/.local/forgejo-install/reverse_proxy_oidc.Caddyfile"
tee "${TEMPLATE_CADDYFILE_REVERSE_PROXY_OIDC_PATH}" <<CADDY_EOF
FQDN {
route {
oidcauth {
client_id CLIENT_ID
client_secret CLIENT_SECRET
issuer ISSUER
redirect_url REDIRECT_URL
}
reverse_proxy TARGET
}
}
CADDY_EOF
export MINDSDB_CONFIG_PATH="${HOME}/.local/forgejo-install/mindsdb-config.json"
tee "${MINDSDB_CONFIG_PATH}" <<MINDSDB_EOF
{
"permanent_storage": {
"location": "local"
},
"paths": {},
"log": {
"level": {
"console": "DEBUG",
"file": "DEBUG",
"db": "DEBUG"
}
},
"debug": true,
"integrations": {},
"gui": {
"autoupdate": false
},
"auth":{
"http_auth_enabled": false
},
"api": {
"http": {
"host": "127.0.0.1",
"port": 0
}
},
"cache": {
"type": "local"
}
}
MINDSDB_EOF
reset_state() {
rm -rfv \
"${GITEA_WORK_DIR}" \
"${HOME}/.local/directus.sqlite3" \
"${HOME}/.local/directus_admin_role_id.txt"
}
if [ ! -f "${INIT_COMPLETE_JSON_PATH}" ]; then
reset_state
fi
referesh_generated_admin_id() {
export DIRECTUS_ADMIN_ID=$(echo 'SELECT id FROM directus_users WHERE email="[email protected]";' \
| sqlite3 ${HOME}/.local/directus.sqlite3 2> >(grep -v 'database is locked' | grep -v directus_users >&2))
}
referesh_role_id() {
export DIRECTUS_ADMIN_ROLE_ID=$(echo 'SELECT id from directus_roles;' \
| sqlite3 ${HOME}/.local/directus.sqlite3 2> >(grep -v 'database is locked' | grep -v directus_roles >&2) \
| tee ${HOME}/.local/directus_admin_role_id.txt)
}
wait_for_and_populate_directus_admin_role_id_txt() {
set +x
referesh_role_id
while [ "x" = "x${DIRECTUS_ADMIN_ROLE_ID}" ]; do
sleep 0.01
referesh_role_id
done
referesh_generated_admin_id
while [ "x" = "x${DIRECTUS_ADMIN_ID}" ]; do
sleep 0.01
referesh_generated_admin_id
done
while [ "x" != "x${DIRECTUS_ADMIN_ID}" ]; do
echo 'DELETE FROM directus_users WHERE email="[email protected]";' | sqlite3 "${HOME}/.local/directus.sqlite3"
referesh_generated_admin_id
done
set -x
}
find_listening_ports() {
# Check if PID is provided
if [ -z "$1" ]; then
echo "Usage: find_listening_ports <PID>" 1>&2
return 1
fi
PID=$1
# Check if the process with the given PID exists
if ! ps -p $PID > /dev/null 2>&1; then
echo "Process with PID $PID does not exist." 1>&2
return 1
fi
# Find listening TCP ports for the given PID using ss
LISTENING_PORTS=$(ss -ltnp 2>/dev/null | grep "pid=$PID")
if [ -z "$LISTENING_PORTS" ]; then
echo "Process with PID $PID not listening on any ports." 1>&2
return 1
fi
echo "$LISTENING_PORTS" | awk '{print $4}' | awk -F':' '{print $NF}'
}
#!/bin/bash
# Function to retrieve route ID by FQDN
get_route_id() {
local socket_path=$1
local fqdn=$2
local route_id=$(curl -fs --unix-socket $socket_path http://localhost/config/ | jq -r --arg fqdn "$fqdn" '.apps.http.servers.srv0.routes[] | select(.match[0].host[0] == $fqdn) | .id')
echo "$route_id"
}
# Function to create or update a route in Caddy
create_or_update_route() {
local socket_path=$1
local fqdn=$2
local target=$3
export config=$(curl -f --unix-socket $socket_path "http://localhost/config/")
echo -e "$fqdn {\n reverse_proxy $target\n}\n" \
| curl --unix-socket $socket_path http://localhost/adapt \
-H "Content-Type: text/caddyfile" \
--data-binary @- \
| tee /tmp/1 \
| jq '.result * (env.config | fromjson)' \
| tee /tmp/2 \
| curl -f -X POST --unix-socket $socket_path "http://localhost/config/" \
-H "Content-Type: application/json" \
-d @-
}
create_or_update_route_protect_with_oidc() {
local socket_path=$1
local fqdn=$2
local target=$3
local issuer_fqdn=$4
local client_id=$5
local client_secret=$6
local redirect_url=${7:-"https:\/\/${fqdn}/callback"}
export config=$(curl -f --unix-socket $socket_path "http://localhost/config/")
cat "${TEMPLATE_CADDYFILE_REVERSE_PROXY_OIDC_PATH}" \
| sed \
-e "s/TARGET/${target}/g" \
-e "s/CLIENT_ID/${client_id}/g" \
-e "s/CLIENT_SECRET/${client_secret}/g" \
-e "s/ISSUER/https:\/\/${issuer_fqdn}/g" \
-e "s/REDIRECT_URL/${redirect_url}/g" \
| curl --unix-socket $socket_path http://localhost/adapt \
-H "Content-Type: text/caddyfile" \
--data-binary @- \
| tee /tmp/1 \
| jq '.result * (env.config | fromjson)' \
| tee /tmp/2 \
| curl -f -X POST --unix-socket $socket_path "http://localhost/config/" \
-H "Content-Type: application/json" \
-d @-
}
if [[ "x${CADDY_USE_SSH}" = "x0" ]]; then
export CURL_CA_BUNDLE="${HOME}/.local/share/caddy/pki/authorities/local/root.crt"
caddy run --config "${HOME}/.local/share/systemd/user/forge.service.Caddyfile" &
CADDY_PID=$!
new_pid "${CADDY_PID}"
fi
export CADDY_ADMIN_SOCKET="${SSH_WORK_DIR}/caddy.admin.sock"
if [[ "x${CADDY_USE_SSH}" = "x1" ]]; then
CADDY_ADMIN_SOCK_DIR_PATH=$(new_tempdir)
export CADDY_ADMIN_SOCKET_OVER_SSH="${CADDY_ADMIN_SOCK_DIR_PATH}/caddy.admin.sock"
ssh -o StrictHostKeyChecking=no -nNT -L "${CADDY_ADMIN_SOCKET_OVER_SSH}:${CADDY_ADMIN_SOCKET}" "${SSH_USER_AT_HOST}" &
CADDY_ADMIN_SOCK_SSH_TUNNEL_PID=$!
new_pid "${CADDY_ADMIN_SOCK_SSH_TUNNEL_PID}"
export CADDY_ADMIN_SOCKET="${CADDY_ADMIN_SOCKET_OVER_SSH}"
fi
forgejo web --port 0 &
FORGEJO_PID=$!
new_pid "${FORGEJO_PID}"
set +x
until find_listening_ports "${FORGEJO_PID}"; do sleep 0.01; done
set -x
FORGEJO_PORT=$(find_listening_ports "${FORGEJO_PID}")
export FORGEJO_CADDY_TARGET="127.0.0.1:${FORGEJO_PORT}"
if [[ "x${CADDY_USE_SSH}" = "x1" ]]; then
export FORGEJO_SOCK="${SSH_WORK_DIR}/${FORGEJO_FQDN}.sock"
ssh -o StrictHostKeyChecking=no -nT "${SSH_USER_AT_HOST}" rm -fv "${FORGEJO_SOCK}"
ssh -o StrictHostKeyChecking=no -nNT -R "${FORGEJO_SOCK}:${FORGEJO_CADDY_TARGET}" "${SSH_USER_AT_HOST}" &
FORGEJO_SSH_TUNNEL_PID=$!
new_pid "${FORGEJO_SSH_TUNNEL_PID}"
export FORGEJO_CADDY_TARGET="unix/${FORGEJO_SOCK}"
else
export FORGEJO_CADDY_TARGET="http://${FORGEJO_CADDY_TARGET}"
fi
create_or_update_route "${CADDY_ADMIN_SOCKET}" "${FORGEJO_FQDN}" "${FORGEJO_CADDY_TARGET}"
echo "awaiting-forgejo";
check_forgejo_initialized_and_running() {
curl -vI "https://${FORGEJO_FQDN}"
STATUS_CODE=$(curl -vI "https://${FORGEJO_FQDN}" 2>/dev/null | head -n 1 | cut -d$' ' -f2)
if [ "x${STATUS_CODE}" = "x200" ]; then
return 1
elif [ "x${STATUS_CODE}" = "x405" ]; then
echo "checking-if-forgejo-need-first-time-init";
query_params=$(python -c 'import sys, urllib.parse, yaml; print(urllib.parse.urlencode(yaml.safe_load(sys.stdin)))' < "${INIT_YAML_PATH}");
curl -v -X POST --data-raw "${query_params}" "https://${FORGEJO_FQDN}" 1>/dev/null;
FORGEJO_USERNAME=$(python -m keyring get "${USER}" "${USER}.forgejo.username")
FORGEJO_EMAIL=$(python -m keyring get "${USER}" "${USER}.forgejo.email")
FORGEJO_PASSWORD=$(python -m keyring get "${USER}" "${USER}.forgejo.password")
# https://docs.gitea.com/next/development/api-usage#generating-and-listing-api-tokens
# curl -H "X-Gitea-OTP: 123456" --url https://yourusername:[email protected]/api/v1/users/yourusername/tokens
get_forgejo_token() {
curl -sf -u "${FORGEJO_USERNAME}:${FORGEJO_PASSWORD}" -H "Content-Type: application/json" -d '{"name": "forgejo-install-auth-oidc-directus", "scopes": ["write:admin"]}' "https://${FORGEJO_FQDN}/api/v1/users/${FORGEJO_USERNAME}/tokens" | jq -r '.sha1'
}
FORGEJO_TOKEN=$(get_forgejo_token)
while [ "x${FORGEJO_TOKEN}" = "x" ]; do
sleep 0.1
FORGEJO_TOKEN=$(get_forgejo_token)
done
export OAUTH2_APPLICATION_NAME="Directus"
data=$(
cat "${NEW_OAUTH2_APPLICATION_YAML_PATH}" \
| sed -e "s/OAUTH2_APPLICATION_NAME/${OAUTH2_APPLICATION_NAME}/g" \
| python -c 'import sys, json, yaml; print(json.dumps(yaml.safe_load(sys.stdin)))'
)
export RESPONSE=$(curl -vf -u "${FORGEJO_USERNAME}:${FORGEJO_PASSWORD}" -H "Content-Type: application/json" --data "${data}" "https://${FORGEJO_FQDN}/api/v1/user/applications/oauth2" | jq -c)
jq -rn 'env.RESPONSE | fromjson | .client_id' | python -m keyring set ${USER} ${USER}.directus.auth.forgejo.client_id
jq -rn 'env.RESPONSE | fromjson | .client_secret' | python -m keyring set ${USER} ${USER}.directus.auth.forgejo.client_secret
unset RESPONSE
export OAUTH2_APPLICATION_NAME="MindsDB"
data=$(
cat "${NEW_OAUTH2_APPLICATION_YAML_PATH}" \
| sed -e "s/OAUTH2_APPLICATION_NAME/${OAUTH2_APPLICATION_NAME}/g" \
| python -c 'import sys, json, yaml; print(json.dumps(yaml.safe_load(sys.stdin)))'
)
export RESPONSE=$(curl -vf -u "${FORGEJO_USERNAME}:${FORGEJO_PASSWORD}" -H "Content-Type: application/json" --data "${data}" "https://${FORGEJO_FQDN}/api/v1/user/applications/oauth2" | jq -c)
jq -rn 'env.RESPONSE | fromjson | .client_id' | python -m keyring set ${USER} ${USER}.mindsdb.auth.forgejo.client_id
jq -rn 'env.RESPONSE | fromjson | .client_secret' | python -m keyring set ${USER} ${USER}.mindsdb.auth.forgejo.client_secret
unset RESPONSE
# TODO Add Application ID, etc. non secrets to init-complete.yaml
touch "${INIT_COMPLETE_JSON_PATH}"
fi
return 0
}
test -f "${INIT_YAML_PATH}"
set +e
check_forgejo_initialized_and_running
forgejo_initialized_and_running=$?
while [ "x${forgejo_initialized_and_running}" = "x0" ]; do
sleep 0.1
check_forgejo_initialized_and_running
forgejo_initialized_and_running=$?
done
set -e
echo "forgejo-first-time-init-complete";
cleanup_files
echo TODO Configure openid client_id and client_secret
python -m mindsdb --verbose --api=http --config="${MINDSDB_CONFIG_PATH}" &
MINDSDB_PID=$!
new_pid "${MINDSDB_PID}"
set +x
until find_listening_ports "${MINDSDB_PID}"; do sleep 0.01; done
set -x
MINDSDB_PORT=$(find_listening_ports "${MINDSDB_PID}")
export MINDSDB_CADDY_TARGET="127.0.0.1:${MINDSDB_PORT}"
if [[ "x${CADDY_USE_SSH}" = "x1" ]]; then
export MINDSDB_SOCK="${SSH_WORK_DIR}/${MINDSDB_FQDN}.sock"
ssh -o StrictHostKeyChecking=no -nT "${SSH_USER_AT_HOST}" rm -fv "${MINDSDB_SOCK}"
ssh -o StrictHostKeyChecking=no -nNT -R "${MINDSDB_SOCK}:${MINDSDB_CADDY_TARGET}" "${SSH_USER_AT_HOST}" &
MINDSDB_SSH_TUNNEL_PID=$!
new_pid "${MINDSDB_SSH_TUNNEL_PID}"
export MINDSDB_CADDY_TARGET="unix/${MINDSDB_SOCK}"
else
export MINDSDB_CADDY_TARGET="http://${MINDSDB_CADDY_TARGET}"
fi
create_or_update_route_protect_with_oidc "${CADDY_ADMIN_SOCKET}" "${MINDSDB_FQDN}" "${MINDSDB_CADDY_TARGET}" "${FORGEJO_FQDN}"
wait_for_and_populate_directus_admin_role_id_txt &
DIRECTUS_CONTAINER_ID=$(docker run \
--detach \
-e PUBLIC_URL="https://${DIRECTUS_FQDN}" \
-e TELEMETRY=false \
-e WEBSOCKETS_ENABLED=true \
-e WEBSOCKETS_REST_AUTH=strict \
-e WEBSOCKETS_GRAPHQL_AUTH=strict \
-e AUTH_DISABLE_DEFAULT=true \
-e AUTH_PROVIDERS="forgejo" \
-e AUTH_FORGEJO_DRIVER="openid" \
-e AUTH_FORGEJO_CLIENT_ID="$(python -m keyring get ${USER} ${USER}.directus.auth.forgejo.client_id)" \
-e AUTH_FORGEJO_CLIENT_SECRET="$(python -m keyring get ${USER} ${USER}.directus.auth.forgejo.client_secret)" \
-e AUTH_FORGEJO_ISSUER_URL="https://${FORGEJO_FQDN}/.well-known/openid-configuration" \
-e AUTH_FORGEJO_IDENTIFIER_KEY="email" \
-e AUTH_FORGEJO_REDIRECT_ALLOW_LIST="https://${DIRECTUS_FQDN}/auth/login/forgejo/callback" \
-e AUTH_FORGEJO_ALLOW_PUBLIC_REGISTRATION=true \
-e SECRET="$(head -n 99999 /dev/urandom | sha384sum - | awk '{print $1}')" \
--entrypoint sh \
-v "${HOME}/.local/directus_admin_role_id.txt:/directus/admin_role_id.txt:z" \
-v "${HOME}/.local/directus.sqlite3:/directus/database/database.sqlite:z" \
directus/directus \
-c \
'set -x && node cli.js bootstrap && while [ "x$(cat admin_role_id.txt)" = "x" ]; do sleep 0.01; done && export AUTH_FORGEJO_DEFAULT_ROLE_ID=$(cat admin_role_id.txt) && pm2-runtime start ecosystem.config.cjs')
new_docker_container_id "${DIRECTUS_CONTAINER_ID}"
docker logs -f "${DIRECTUS_CONTAINER_ID}" &
DIRECTUS_CONTAINER_LOGS_PID=$!
new_pid "${DIRECTUS_CONTAINER_LOGS_PID}"
DIRECTUS_CONTAINER_IP=$(docker inspect --format json "${DIRECTUS_CONTAINER_ID}" | jq -r '.[0].NetworkSettings.IPAddress')
export DIRECTUS_CADDY_TARGET="${DIRECTUS_CONTAINER_IP}:8055"
if [[ "x${CADDY_USE_SSH}" = "x1" ]]; then
export DIRECTUS_SOCK="${SSH_WORK_DIR}/${DIRECTUS_FQDN}.sock"
ssh -o StrictHostKeyChecking=no -nT "${SSH_USER_AT_HOST}" rm -fv "${DIRECTUS_SOCK}"
ssh -o StrictHostKeyChecking=no -nNT -R "${DIRECTUS_SOCK}:${DIRECTUS_CADDY_TARGET}" "${SSH_USER_AT_HOST}" &
DIRECTUS_SSH_TUNNEL_PID=$!
new_pid "${DIRECTUS_SSH_TUNNEL_PID}"
export DIRECTUS_CADDY_TARGET="unix/${DIRECTUS_SOCK}"
else
export DIRECTUS_CADDY_TARGET="http://${DIRECTUS_CADDY_TARGET}"
fi
create_or_update_route "${CADDY_ADMIN_SOCKET}" "${DIRECTUS_FQDN}" "${DIRECTUS_CADDY_TARGET}"
if [[ "x${CADDY_USE_SSH}" = "x1" ]]; then
kill "${CADDY_ADMIN_SOCK_SSH_TUNNEL_PID}"
fi
tail -F /dev/null
EOF
systemctl --user daemon-reload
systemctl --user enable forge.service
systemctl --user restart forge.service

IETF Specification Update: SCITT-Based Security for ActivityPub Using CBOR-LD

This document proposes an update to secure ActivityPub messages using SCITT statements encapsulated in CBOR-LD (Concise Binary Object Representation for Linked Data) and contained within Authenticated Chained Data Containers (ACDC). This approach replaces the current HTTP signature headers in ActivityPub with SCITT-compliant, cryptographically verifiable structures, using CBOR-LD for compact serialization.

1. Introduction

ActivityPub is a decentralized social networking protocol, commonly using HTTP signatures for authenticating messages. This document introduces an architecture to secure ActivityPub using SCITT (Supply Chain Integrity, Transparency, and Trust) statements, leveraging CBOR-LD for efficient and compact message serialization, and ACDC for chained, verifiable data containers. This update enhances security, integrity, and trust by eliminating HTTP signatures in favor of cryptographically secure, SCITT-based statements.

2. Terminology

  • ACDC (Authenticated Chained Data Container): A container that ensures the authenticity and integrity of data, chaining verifiable statements.
  • SCITT (Supply Chain Integrity, Transparency, and Trust): A framework for verifiable claims about data integrity and provenance, leveraging cryptographic proofs.
  • CBOR-LD: A compact binary format for Linked Data serialization.
  • ActivityPub: A decentralized social networking protocol using activities to communicate between actors.
  • SCITT Statement: A claim about an ActivityPub object, secured by cryptographic proofs.

3. CBOR-LD Overview

According to the CBOR-LD 1.0 specification【20†source】, CBOR-LD is a compact binary data format designed to efficiently serialize Linked Data using the JSON-LD ecosystem. CBOR-LD provides efficient compression schemes, achieving over 60% better compression ratios than traditional compression algorithms. This allows us to significantly reduce the size of serialized ActivityPub messages, making them more suitable for bandwidth-constrained environments.

The core of the CBOR-LD format revolves around replacing Linked Data terms with corresponding byte values, using a term codec map built from the associated JSON-LD contexts. This map compresses terms and values, enhancing both storage and transmission efficiency while preserving Linked Data semantics.

4. ActivityPub Structure with SCITT Statements

In this updated architecture, ActivityPub objects are serialized using CBOR-LD and secured with SCITT statements that provide cryptographically verifiable proofs of integrity and authenticity. This structure is then encapsulated in an ACDC container, providing an auditable chain of statements.

4.1. ActivityPub CBOR-LD Structure

The following CDDL definition outlines how an ActivityPub object is represented in CBOR-LD. It also includes SCITT statements to replace the HTTP signature header approach with cryptographically secure, verifiable proofs.

activitypub-container = {
    "id": tstr,                    ; Activity identifier (IRI)
    "type": "Activity",             ; Type of the activity
    "actor": actor,                 ; Actor performing the activity
    "object": object,               ; The object (post, note, etc.)
    "target": target,               ; The target of the activity (optional)
    "published": time,              ; Publication timestamp
    "scittStatements": [scitt-statement]  ; SCITT statements array
}

actor = {
    "id": tstr,                     ; Actor's unique identifier (IRI)
    "type": "Person" / "Organization",
    "name": tstr,                   ; Display name of the actor
    "url": tstr                     ; Actor's homepage URL
}

object = {
    "id": tstr,                     ; Object's unique identifier (IRI)
    "type": "Note" / "Article" / "Image" / "Video",
    "content": tstr,                ; Content of the object
    "mediaType": tstr               ; MIME type of the object (e.g., "text/plain")
}

target = {
    "id": tstr,                     ; Target's unique identifier (IRI)
    "type": "Person" / "Organization",
    "name": tstr,                   ; Display name of the target
    "url": tstr                     ; Target's homepage URL
}

scitt-statement = {
    "claim": claim,                 ; Claim data structure
    "proof": proof                  ; Cryptographic proof
}

claim = {
    "claimType": tstr,              ; Type of claim (e.g., "Integrity", "Authenticity")
    "description": tstr,            ; Human-readable description of the claim
    "contentHash": bstr,            ; Hash of the claimed content
    "signer": tstr                  ; Entity making the claim (e.g., actor's ID)
}

proof = {
    "signature": bstr,              ; Cryptographic signature for the claim
    "signingAlgorithm": tstr,       ; Algorithm used for signing (e.g., "Ed25519")
    "timestamp": time               ; Signature generation timestamp (Unix timestamp)
}

time = number ; Unix timestamp (seconds since epoch)
4.2. SCITT Statement Functionality

Each SCITT statement included in the ActivityPub object provides a claim and a proof. These are used to verify the authenticity and integrity of the object, replacing HTTP signature headers. SCITT statements are cryptographically verifiable and can be independently audited to ensure that the claims hold true, and the object has not been tampered with.

  • Claim: Contains the hashed content and a description of the claim type (e.g., integrity). The contentHash is calculated over the serialized ActivityPub object, ensuring its immutability after the claim is made.
  • Proof: A cryptographic signature that ties the claim to the signer (actor), providing non-repudiable evidence that the actor made the claim.

5. Transparency Service

SCITT statements, including their cryptographic proofs, can optionally be registered with a transparency service. This service provides an audit trail for each statement, ensuring that modifications or tampering attempts can be easily detected and traced.

The transparency service operates as a ledger where claims are recorded, providing immutable records for all signed activities. This enhances trust by making every interaction verifiable and traceable.

6. Security Considerations

By replacing HTTP signatures with SCITT statements, the following security benefits are achieved:

  1. Improved Integrity: SCITT statements ensure that the content cannot be modified without detection. The content hash and cryptographic signature provide proof of integrity.
  2. Non-repudiation: Actors cannot deny their participation in an activity once it has been cryptographically signed and recorded in the transparency service.
  3. Reduced Attack Surface: Eliminating HTTP signature headers simplifies the security model, focusing entirely on cryptographically verifiable proofs.

7. Privacy Considerations

Care must be taken to avoid exposing personally identifiable information (PII) within SCITT claims. The use of content hashes ensures that private information is not directly exposed, while still allowing for integrity verification. Actors can control which aspects of the activity they wish to make public or keep private by selectively hashing and signing certain components.

8. Conclusion

This document proposes a significant enhancement to the security of ActivityPub by using SCITT statements with CBOR-LD and ACDC to replace HTTP signatures. This approach ensures that every interaction is cryptographically verifiable, auditable, and secure, making decentralized social networking more trustworthy and resilient.

References

This updated specification leverages the principles and encoding techniques defined in the CBOR-LD 1.0 specification【20†source】 to provide a secure and efficient way to handle Linked Data in the context of decentralized social networking, while integrating SCITT for cryptographic assurance.
pdxjohnny added a commit to pdxjohnny/scitt-api-emulator that referenced this issue Sep 17, 2024
@pdxjohnny
JSON LLM Comms using github actions schems style workflows
29eb759 
Asciinema: https://asciinema.org/a/674296
Related: pdxjohnny/dotfiles#1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@pdxjohnny