Git | Techlist.io

cloudflareApr 16, 20263 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Read original

Git Database Design TypeScript Cloudflare Workers+4

lineApr 10, 20264 min readCurated summary

Clearing Review Bottlenecks with AI - Transforming Review Culture with PR Review Support and Internal Workshops

Orchestration Guild member Fukuyama describes how Yahoo! Places addressed PR review bottlenecks by combining AI assistance with standardized processes and team culture. Reviews had become concentrated among a few engineers, creating delays and forcing a trade-off between speed and quality. The team introduced Claude Code–based screening reviews, then expanded the approach into a broader system for improving PR creation, review accuracy, and continuous improvement. ## PR Review Bottlenecks - In late 2024, review responsibilities were concentrated on the tech lead and one other engineer. - Reviewers were simultaneously implementing features and reviewing code, causing PR queues to grow. - The main problems were: - Authors could not move to their next tasks while waiting for reviews. - Review work consumed most of the day. - Large PRs had to be reviewed quickly, increasing the risk of missed bugs. - This created a single point of failure and exposed the trade-off between thoroughness and development speed. - The launch of a dedicated frontend team in early 2025 provided an opportunity to redesign the review process. ## Introducing AI Screening Reviews - The team first tried having AI summarize PR changes before review. - Although summaries made changes easier to understand, AI did not sufficiently reduce the work of tracing dependencies or identifying hidden problems. - Manually pasting prompts for every review also made the approach inconvenient, so it was abandoned after about two weeks. - The introduction of Claude Code in summer 2025 changed the situation because reusable custom commands eliminated repetitive prompt preparation. - AI screening reviews now perform an initial inspection before a human reviewer makes the final judgment. - This changes the process from “humans inspect everything” to a two-stage model: - AI analyzes the PR, its impact, coding conventions, and possible risks. - A human reviewer validates the analysis and makes the final decision. ## Claude Code Custom Review Commands The custom command requests that Claude Code: - Summarize the PR and its affected areas. - Explain the before-and-after changes for each file. - Check coding and naming conventions. - Investigate dependent files and broader codebase impact. - Identify potential bugs, security issues, performance problems, code smells, and unintended side effects. - Suggest concise, respectful review comments for the author. - Classify comments with labels such as `[must]`, `[want]`, `[imo]`, `[ask]`, `[nits]`, and `[info]`. - Determine whether additional tests are needed based on existing project practices. The command uses GitHub CLI operations such as: - `gh pr view --json title,body,files,url` - `gh pr diff` - `gh pr view --comments` - GitHub API calls for line-level comments - `gh pr checkout` when the relevant branch is not currently checked out The review procedure is deliberately structured: 1. Confirm the review requirements. 2. Understand the PR’s overall purpose and background. 3. Review each changed file in detail. 4. Investigate dependencies across the codebase. 5. Produce a final assessment and suggested comments. The same screening process can help both reviewers and PR authors. Reviewers use it to reduce preparation time and understand impact, while authors can run it before requesting review to fix likely issues in advance. ## Expanding Beyond AI Screening After seeing benefits from screening reviews, the team created a broader improvement framework spanning technology and team culture. It was organized around four connected goals: - Improving efficiency. - Establishing a foundation for review accuracy. - Building review-oriented team culture. - Creating a mechanism for continuous improvement. The approach treats review optimization as an ongoing cycle rather than a one-time tool deployment. ## Automating PR Creation The team also uses AI to reduce the effort required to create PRs. - Git operations such as branch creation, commits, and PR creation are automated. - AI analyzes the commit diff to generate: - A PR title. - A summary of the changes. - Background and motivation. - Other required PR template fields. - Standardized and more complete PR descriptions provide better context for both human reviewers and AI screening. - Improving PR quality at the creation stage also increases the accuracy and consistency of later reviews. ## Practical Recommendation AI should support—not replace—reviewer judgment. Teams should begin by standardizing the review workflow, encode that workflow in reusable AI commands, and measure whether review time, PR waiting time, and review quality improve. Combining AI screening with better PR context, dependency analysis, clear comment conventions, and continuous process refinement offers a more sustainable solution than relying on individual reviewers.

Read original

Git AI Database Design Web Development+4

dropboxMar 25, 20263 min readCurated summary

Reducing our monorepo size to improve developer velocity

Dropbox’s server monorepo grew to 87GB, making full clones take over an hour and threatening GitHub’s 100GB limit. The root cause was inefficient Git delta compression of internationalization files, not unusually large source files. By changing how the repository was repacked, Dropbox reduced it to about 20GB and cut clone times to under 15 minutes. ## Repository Size and Developer Velocity - The monorepo contains backend services and libraries used across Dropbox. - AI feature development often requires coordinated changes across ranking, retrieval, evaluation, and UI systems. - A full clone exceeded one hour at 87GB, slowing onboarding and affecting CI jobs that start from fresh clones. - Internal synchronization systems also processed more data, increasing timeout and reliability risks. - The repository grew by roughly 20–60MB per day, with occasional increases above 150MB. - At that rate, Dropbox expected to hit GitHub Enterprise Cloud’s 100GB hard limit within months. ## How Git Compression Caused the Growth - Git normally reduces storage by representing similar file versions as deltas rather than complete copies. - Its default file-matching heuristic considers only the final 16 characters of a path. - Dropbox’s i18n files used paths such as: - `i18n/metaserver/[language]/LC_MESSAGES/[filename].po` - Because the language component appears early in the path, Git often compared files from different languages instead of related versions of the same language. - Translation updates consequently produced oversized deltas and disproportionately large pack files. ## Testing `--path-walk` - Dropbox tested Git’s experimental `--path-walk` option during a local repack. - The option considers the full directory structure when selecting delta candidates. - A local repack reduced the repository from the low-80GB range to the low-20GB range, confirming that packing—not data volume—was the main issue. - GitHub could not use this approach because it conflicted with server-side optimizations such as bitmaps and delta islands. ## Why Server-Side Repacking Was Necessary - Local optimization cannot permanently change the packs GitHub generates for clones and fetches. - GitHub dynamically constructs transfer packs based on what each client needs. - Dropbox’s mirror experiment showed that an aggressive repack could reduce the repository from 84GB to 20GB: - `git repack -adf --depth=250 --window=250` - The repack took approximately nine hours. - Dropbox worked with GitHub Support to apply a compatible server-side solution. - Larger `window` and `depth` values make Git search more thoroughly for compression opportunities, trading increased repack time for smaller storage and transfer sizes. ## Results - Repository size fell from 87GB to approximately 20GB—a 77% reduction. - Clone time dropped from more than an hour to under 15 minutes. - The work reduced pressure on GitHub’s repository size limit and improved the performance of developer and CI workflows. Dropbox’s experience shows that monorepo growth can result from repository layout interacting poorly with Git’s compression heuristics. When large repositories exhibit abnormal growth, teams should inspect pack-file behavior and consider server-side repacking rather than focusing only on removing large files.

Read original

Git Database Design CI/CD Github+4

lineFeb 13, 20263 min readCurated summary

Claude Code Action: Platformizing AI Code

LINE NEXT transformed Claude Code from an individual productivity tool into an organization-wide code review platform integrated with GitHub Actions. The goal was to reduce review-quality variation, standardize policies, and make AI feedback part of the existing pull request workflow. Its central design separates simple repository-level invocation from centrally managed execution, prompts, permissions, and infrastructure. ## Why AI Code Review Needed to Be Platformized - As LINE NEXT’s services and repositories grew, human code review quality varied according to each reviewer’s experience and preferences. - Developers were already using Claude Code locally, but individual usage created several problems: - Inconsistent review criteria and perspectives - No organization-wide quality process - AI feedback disconnected from pull request workflows - Difficulty providing new employees with a consistent review experience - DevOps therefore treated the issue as a decentralized quality-process problem rather than merely a tooling problem. ## Why GitHub Actions and Claude Code - GitHub Actions was already the foundation for CI/CD and automation across LINE NEXT repositories. - It allowed the team to: - Apply a common workflow repository by repository - Centrally manage execution environments and permissions - Avoid requiring each service team to build additional infrastructure - Claude Code Action integrated directly with pull requests: - Developers could trigger reviews with an `@claude` mention. - Results appeared as GitHub comments or PR reviews. - Developers did not need to learn a separate interface. - A shared GitHub App Runner environment provided consistent execution and centralized security controls. ## Centralized Caller–Executor Architecture - Service repositories act as **callers**: - They invoke the standard workflow. - They provide only basic parameters such as service name and review type. - A centrally managed DevOps repository acts as the **executor**: - Stores prompts and review personas - Defines review policies and priorities - Manages permissions and authentication - Contains the actual execution logic - This design makes AI review an organization-wide platform capability rather than a separate configuration maintained by every project. ### Benefits of Central Control - **Consistent quality:** Central prompts and personas ensure common review depth, tone, security checks, stability checks, and priorities. - **Faster adoption:** New repositories need only add the standard workflow and specify a few parameters. - **Improved governance:** GitHub Apps, centrally managed secrets, and shared runners make it possible to track who accessed which code and with what permissions. - **Lower operational overhead:** Service teams use the platform without managing AI infrastructure themselves. ## Handling Fork-Based Pull Requests - The official Claude Code Action initially assumed that a PR branch existed in the base repository’s `origin`. - For pull requests created from forks, this caused failures such as: ```text couldn't find remote ref ``` - The original implementation fetched and checked out the branch by name: ```text git fetch origin <branch> git checkout <branch> ``` - This failed because fork branches exist in the external repository, not necessarily in the base repository. - From a platform perspective, this was a structural limitation because it blocked external contributors and collaboration repositories. - The proposed direction was to redesign the execution flow rather than simply add an exception, using GitHub’s special pull-request reference: ```text refs/pull/<PR number>/head ``` This approach allows the workflow to retrieve the actual pull request head commit regardless of whether the PR originated from the main repository or a fork.

Read original

Git Database Design Kubernetes CI/CD+4

gitlabFeb 2, 2026Original article

What’s new in Git 2.53.0? (opens in new tab)

Git 2.53.0 introduces significant performance and maintenance improvements, specifically targeting large repositories and complex history rewriting workflows. Key updates include compatibility between geometric repacking and partial clones, as well as more granular control over commit signatures during imports. These enhancements collectively move Git toward more efficient repository management and better data integrity for modern development environments. ## Geometric Repacking Support with Promisor Remotes * Git utilizes repacking to consolidate loose objects into packfiles, with the "geometric" strategy maintaining a size-based progression to minimize the computational overhead found in "all-into-one" repacks. * Previously, geometric repacking was incompatible with partial clones because it could not correctly identify or manage "promisor" packfiles, which contain the metadata for objects expected to be backfilled from a remote. * The 2.53.0 release enables geometric repacking to process promisor packfiles separately, preserving the promisor marker and preventing the tool from crashing when used within a partial clone repository. * This fix removes a major blocker for making the geometric strategy the default repacking method for all Git repositories. ## Preserving Valid Signatures in git-fast-import(1) * The `git-fast-import` tool, a backend for high-volume data ingestion and history rewriting, previously lacked the nuance to handle commit signatures during partial repository edits. * A new `strip-if-invalid` mode has been added to the `--signed-commits` option to solve the "all-or-nothing" problem where users had to choose between keeping broken signatures or stripping valid ones. * This feature allows Git to automatically detect which signatures remain valid after a rewrite and only strip those that no longer match their modified commits. * This provides a foundation for tools like `git-filter-repo` to preserve the chain of trust for unchanged commits during migration or cleaning operations. ## Expanded Data in git-repo-structure * The `structure` subcommand of `git-repo`, intended as a native alternative to the `git-sizer` utility, now provides deeper insights into repository scaling. * The command now reports the total inflated size and actual disk size of all reachable objects, categorized by type: commits, trees, blobs, and tags. * These metrics are essential for administrators managing massive repositories, as they help identify which object types are driving disk consumption and impacting performance. These updates reflect Git’s continued focus on scalability and developer experience, particularly for organizations managing massive codebases. Users of partial clones and repository migration tools should consider upgrading to 2.53.0 to leverage the improved repacking logic and more sophisticated signature handling.

Git Database Design Open Source Git Fast Import+3

datadogOct 21, 20253 min readCurated summary

Detecting malicious pull requests at scale with LLMs

Datadog built an LLM-powered security reviewer, BewAIre, to examine every pull request for malicious intent as AI-assisted development increases code volume and reviewer fatigue. Unlike traditional static analysis, the system evaluates the design and likely purpose of changes, not just known syntactic patterns. In testing, it achieved over 99.3% accuracy with a 0.03% false-positive rate and now operates in production. ## Why Conventional Review Is Struggling - Datadog processes nearly 10,000 pull requests per week across internal and external repositories, with volume growing as coding assistants become commonplace. - More changes increase the attack surface and make subtle attacks harder to notice. - Reviewers, linters, and scanners can be overwhelmed by verbose or repetitive AI-generated code. - Static analysis is effective at identifying known bad patterns but generally lacks understanding of developer intent. - Legitimate security-sensitive changes, such as permission-model updates, can resemble malicious behavior. ## The tj-actions/changed-files Attack - An attacker used a compromised personal access token belonging to `tj-actions-bot` to modify `index.js`. - The injected Python code extracted secrets and other sensitive information from a GitHub Actions runner’s process memory. - Base64 encoding concealed both the malicious code reference and output written to build logs. - The commit was made to look like a legitimate `renovate[bot]` update. - Version tags were redirected to the malicious commit, allowing the compromise to spread quickly. - Even protected branches, two-person reviews, and other standard controls could miss an attack disguised as a routine dependency or maintenance change. ## BewAIre’s LLM-Based Review Pipeline - **Ingestion:** Collects pull requests merged into the default branch across Datadog repositories. - **Preprocessing:** Normalizes each pull request, extracts its diff, and adds metadata such as the author and repository type. - **Inference:** Sends the code changes and contextual information to an LLM to reason about intent and classify the change as benign or malicious. - **Security signals:** Converts each verdict into a Datadog security signal that appears in internal dashboards and can trigger alerts or pages for security engineers. - Each finding includes a written explanation of why the change may be malicious. ## Improving Accuracy and Limiting Noise - Datadog used prompt engineering and data tuning to improve the model’s ability to distinguish malicious behavior from legitimate changes. - Suppression rules were added for known-safe patterns. - Testing on a curated, balanced dataset of hundreds of malicious and benign pull requests produced: - More than 99.3% overall accuracy. - More than 93.5% balanced accuracy. - A 0.03% false-positive rate. - The team also designed the system to address model degradation caused by context limits and continuously evaluated it against real-world attacks, including the tj-actions and Nx incidents. ## Production Deployment - BewAIre reviews Datadog pull requests in real time and is already deployed across the company’s repositories. - The system is available in Preview to Static Code Analysis customers. - Its purpose is to add scalable, intent-focused detection without imposing stricter manual review requirements that could slow development. Datadog’s approach suggests that LLMs can complement—not replace—static analysis and human investigation by providing continuous, intent-aware security review at large scale.

Read original

Git Large Language Models Prompt Engineering Code Review+4

lineAug 8, 2025Original article

Sharing the workflow of a 3rd (opens in new tab)

This blog post outlines a structured nine-step workflow designed to enhance development efficiency and improve the code review experience within a collaborative team environment. By emphasizing pre-implementation simulation, task visualization through Jira, and proactive self-feedback, the author demonstrates how breaking work into manageable, reviewer-friendly units leads to more predictable and reliable software delivery. The core conclusion is that prioritizing "reviewability" through small, logical increments fosters team trust and reduces technical debt. ### Strategic Planning and Simulation * Begin by thoroughly reviewing requirements and simulating the feature’s behavior, focusing specifically on data flow, state management, and edge cases. * Proactively communicate with stakeholders to clarify ambiguities and suggest user experience improvements before any code is written. * Draft high-level diagrams or flowcharts to map out how data points interact and where specific logic should reside, ensuring a solid architectural foundation. ### Task Visualization and Collaborative Alignment * Organize features into Jira Epics and decompose them into granular tickets that include estimated effort and dependencies. * Sync with teammates early—specifically between workflow design and ticket creation—to align on technical direction and prevent significant rework during the final review stage. * Ensure ticket titles are concise and descriptive to allow teammates to understand the project's progress at a glance. ### PoC-Driven Iteration and Self-Feedback * Conduct Proof of Concept (PoC) or prototyping to validate assumptions and identify unforeseen technical challenges before committing to a final implementation. * Perform self-feedback by checking the volume of code changes; the author suggests a 400-line threshold, beyond which a ticket should be split into sub-tasks to maintain clarity. * Use tools like `git diff` or temporary PR branches to review your own work from the perspective of a reviewer, identifying parts of the code that may be difficult to digest. ### Implementation and Documentation for Reviewers * Commit code in small, meaningful increments with clear messages, following a logical sequence such as defining interfaces before their actual implementations. * Draft Pull Requests (PRs) using standardized templates that include the purpose of the change, affected features, and developer test results. * Include visual aids, such as videos or screenshots, for complex UI changes or intricate workflows to reduce the cognitive load on the reviewer. ### Future Process Refinement * Improve the accuracy of project timelines by strictly recording actual time spent on tickets compared to original estimates in Jira. * Analyze the delta between "Estimated" and "Actual" time to better understand personal development velocity and refine future scheduling. Adopting this systematic approach helps developers transition from simply "writing code" to managing a complete technical lifecycle. For teams prioritizing code quality, implementing a line-count threshold for PRs and scheduling early-stage technical alignment sessions can significantly reduce "review fatigue" and streamline the path to production.

Git Github Code Review Jira+4

slackApr 14, 20253 min readCurated summary

Optimizing Our E2E Pipeline

Slack optimized its monorepo E2E pipeline by avoiding frontend rebuilds when a pull request contains no frontend changes. Using `git diff` to detect relevant changes and serving recent frontend artifacts from S3 through an internal CDN, the team reduced build frequency by 60% and cut end-to-end pipeline time from roughly 10 minutes to 2 minutes. The changes also lowered storage and compute costs and improved test reliability. ## The Cost of Unnecessary Frontend Builds - Slack’s E2E pipeline validates frontend, backend, database, and service changes before merging into `main`. - Previously, every run rebuilt the frontend, even when a pull request changed only backend or unrelated files. - A typical pipeline included: - About 5 minutes for the frontend build - Deployment to QA - More than 200 E2E tests taking another 5 minutes - With hundreds of pull requests merged daily, redundant builds caused: - Thousands of unnecessary builds each week - Nearly a gigabyte of S3 data per build - Terabytes of duplicate stored artifacts - Significant developer and cloud-compute costs ## Conditional Frontend Builds - Slack used `git diff` with three-dot notation to compare the checked-out branch against `main`. - If frontend files had changed, the pipeline ran a new frontend build. - If no frontend changes were detected, the build step was skipped. - Git analyzed the repository’s more than 100,000 tracked files in only a few seconds. ## Reusing Prebuilt Assets - When a new build was unnecessary, the pipeline located a recent frontend build already stored in AWS S3. - The selected artifact was still in production, ensuring the E2E tests used sufficiently current frontend assets. - An internal CDN served those assets to the QA environment. - S3 naming and asset-management conventions made it possible to find an appropriate artifact in under three seconds on average. ## Results and Additional Benefits - Frontend build frequency fell by 60%. - Average E2E pipeline time dropped from about 10 minutes to 2 minutes. - Monthly savings included hundreds of hours of compute and developer waiting time. - S3 usage decreased by several terabytes per month. - Test flakiness reached its lowest measured level, partly because asset delivery became more consistent. - The work also exposed legacy systems and generated a backlog of future maintenance improvements. Slack’s experience demonstrates that pipelines should not automatically repeat expensive steps when their inputs have not changed. Detecting affected files and reusing trustworthy build artifacts can substantially improve speed, reliability, and cost without requiring a wholesale rewrite of the CI/CD system.

Read original

Git CI/CD Monorepo Cdn+4

figmaDec 7, 20233 min readCurated summary

Enforcing Device Trust on Code Changes | Figma Blog

Figma built a custom system to ensure that code merged into GitHub release branches originates from trusted, company-managed devices. Standard SSO, WebAuthn, dual-control approvals, and GitHub’s “Verified” commit status did not sufficiently protect against compromised tokens, SSH keys, or sessions. The team instead combined short-lived Okta Device Trust certificates with X.509/S/MIME Git commit signing. ## Protecting Production Release Branches - GitHub release branches are the source of truth for production deployments and therefore a high-value attack target. - Figma requires dual control for pull requests: the author and another engineer must approve changes. - GitHub access is protected by SSO and WebAuthn 2FA. - These controls do not fully address compromised: - Personal access tokens - OAuth tokens - SSH keys - Existing GitHub sessions ## Problems with GitHub Commit Verification - GitHub’s commit verification can provide a “Verified” status without proving that the commit came from a trusted company device. - Engineers’ personal GPG keys are outside Figma’s control and cannot be tied to a specific managed laptop. - Commits created through GitHub’s web interface or API may be signed with GitHub’s own web-flow GPG key. - An attacker using a compromised OAuth app, session, token, or SSH key could potentially create commits that GitHub marks as verified. - Building an internal verification system gives Figma more control over what qualifies as a trusted change and avoids manually monitoring every credential type. ## Okta Device Trust Certificates - Figma’s Endpoint Security Baseline includes requirements such as: - Current browser versions - The latest macOS version - Active malware protection - Figma issues X.509 device certificates to company-managed MacBooks through an Amazon Private Certificate Authority. - Certificates are distributed using JAMF and renewed every 15 days. - Each certificate attests that the device met the security baseline when the certificate was issued. - Okta Identity Engine uses these certificates to enforce device trust for sensitive services including AWS, Stripe, and Snowflake. - Because the certificates can sign data, Figma can also use them to attest to actions outside Okta. ## Signing Git Commits with Device Certificates - Figma investigated using its device trust certificates to sign Git commits through S/MIME. - GitHub’s `smimesign` utility supports X.509-based commit signing on macOS and Windows. - It uses certificates and private keys stored in the macOS Keychain or Windows Certificate Store. - Git can be configured with: ```sh git config commit.gpgsign true git config gpg.format x509 git config gpg.x509.program smimesign git config user.signingkey <your_x509_key_id> ``` - This approach initially presented a usability problem: certificates—and therefore signing keys—change every 15 days when device trust certificates renew. - The excerpt ends as Figma begins describing how it planned to dynamically select the latest signing key so engineers would not need to update their Git configuration manually. Figma’s approach strengthens commit verification by linking code signatures to short-lived certificates issued only to compliant, company-managed devices. This is more meaningful than relying solely on GitHub’s generic “Verified” status, though the provided excerpt does not include the final implementation details.

Read original

Git Github Okta Device Trust X509 Certificates+4