# signing Published articles for signing. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## VoIP, VPN, and the Build System Behind Them DevFeed: [VoIP, VPN, and the Build System Behind Them]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-09-04T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Virtual Private Network](), [cross-platform](), [API](), [iOS](), [Android](), [Java](), [Framework](), [Extension]() Tags: [android](), [apis](), [build](), [build-system](), [extension](), [integration](), [java](), [native](), [packages](), [platform](), [signing](), [vpn]() ### AI overview Codename One adds native call-management and VPN APIs for iOS and Android. Its builders generate the required platform services, frameworks, permissions, delegates, and separately signed extension targets based on the Java packages an application uses. ### Source excerpt Codename One adds native call management and VPN APIs, while its builders generate the platform services, frameworks, permissions, and extension plumbing only when an application uses them. ## Proven, not promised: Chainguard Containers achieves SLSA Build Level 3 DevFeed: [Proven, not promised: Chainguard Containers achieves SLSA Build Level 3]() Original publisher: [Read original article]() Published: 2026-08-17T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [chainguard containers](), [supply-chain-security](), [software bill of materials](), [Security]() Tags: [chainguard](), [chainguard-containers](), [provenance](), [sbom](), [security](), [signing](), [slsa](), [software-supply-chain-security](), [supply-chain]() ### AI overview Chainguard says Coalfire independently assessed the Chainguard Containers build and release system as meeting SLSA Build Level 3 requirements. The article describes hardened, isolated builds, separately managed signing, provenance generation, and signed SBOMs for releases. ### Source excerpt Coalfire independently assessed Chainguard Containers at SLSA Build Level 3, validating hardened builds, provenance, and supply chain integrity. ## \[webapps\] Duplicati 2.2.0.3 - JWT Signing Key Leak DevFeed: [\[webapps\] Duplicati 2.2.0.3 - JWT Signing Key Leak]() Original publisher: [Read original article]() Author: Gabriel Rodrigues Published: 2026-08-17T00:00:00Z Content type: article Language: en Sources: [Exploit-DB.com RSS Feed]() Topics: [JSON Web Tokens](), [Exploit]() Tags: [exploit](), [jwt](), [leak](), [multiple](), [platform](), [signing](), [webapps]() ### AI overview An exploit listing identifies a JWT signing key leak in Duplicati 2.2.0.3 and describes it as a web application exploit for multiple platforms. ### Source excerpt Duplicati 2.2.0.3 - JWT Signing Key Leak ## How Trail of Bits helps verify the integrity of your Signal chats DevFeed: [How Trail of Bits helps verify the integrity of your Signal chats]() Original publisher: [Read original article]() Author: "Tjaden Hess" Published: 2026-08-11T17:30:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [client](), [servers](), [Cloudflare](), [App]() Tags: [audits](), [cloudflare](), [cryptography](), [devices](), [external](), [open-source](), [safety](), [server](), [signing](), [verification]() ### AI overview The article explains how Trail of Bits helps verify the integrity of Signal chats through Automatic Key Verification. The system uses external auditors, globally consistent public-key maps, Merkle trees, and signed tree heads to make mismatches harder to conceal. Signal clients currently require signatures from auditors operated by Signal, Cloudflare, and Trail of Bits. ### Source excerpt Every Signal chat starts the same way: the client asks the Signal server for the public key associated with your contact's phone number. But how do you know the server gave you the right key? A compromised server could provide a false public key, allowing the client to encrypt messages to an attacker rather than the intended recipient. Until now, the only way to detect such malfeasance was to verify safety numbers with your contact in person or over a trusted channel. Signal recently launched an alternative: Automatic Key Verification, a feature that helps validate that your chats are secure without requiring direct safety number comparison. Trail of Bits built and operates one of the three auditors that make this system trustworthy. Our auditor, which is an independent implementation written from scratch, continuously checks that the Automatic Key Verification system behaves honestly. How key verification works Automatic Key Verification is a form of "key transparency" that makes mismatch attacks harder to hide by creating a globally consistent view of the set of public keys associated with each phone number. The Signal app now performs a periodic self-check to ensure that all keys stored in the global map for your account belong to your devices. If the app is unable to verify the log, or finds that not all keys are expected, the user is presented with a warning that "Automatic Key Verification is currently unavailable for your device." Automatic Key Verification may also be unavailable for other reasons, as outlined in Signal's documentation. What our auditor does Automatic Key Verification depends on external auditors. Trail of Bits helps this system function by providing external verification that the user ↔ public key map is globally consistent and well formed, and does not hide any entries. Each time a new entry is added, we update our local copy of the map, stored as a Merkle tree. Periodically, we sign the head of the tree using a signing key that only we kn ## Podman Container Tools Grows DevFeed: [Podman Container Tools Grows]() Original publisher: [Read original article]() Author: mheon Published: 2026-08-10T18:18:27Z Content type: article Language: en Sources: [blog.podman.io]() Topics: [podman](), [Buildah](), [Skopeo](), [GitHub](), [Cloud Native Ecosystem]() Tags: [api](), [buildah](), [ci](), [cloud-native](), [cncf](), [github](), [images](), [io](), [podman](), [podman-machine](), [python](), [releases](), [signing](), [skopeo](), [storage](), [uncategorized]() ### AI overview The Podman 6.0 release moves Podman, Buildah, and Skopeo into a new GitHub organization owned by the Cloud Native Computing Foundation. Additional repositories, including podman-machine-os and container-libs, are joining the project, while further moves for podman-py, project websites, utility repositories, Netavark, and Aardvark-dns are planned or under consideration. ### Source excerpt As part of the Podman 6.0 release, we've moved Podman, Buildah, and Skopeo into a new GitHub organization owned by the Cloud Native Computing Foundation (CNCF). For most people, the most visible part of this is that the old repositories in the github.com/containers organization now redirect to https://github.com/podman-container-tools, but we've also made some other changes [...] ## Announcing a Trillion Dollar Security grant for WEBCAT DevFeed: [Announcing a Trillion Dollar Security grant for WEBCAT]() Original publisher: [Read original article]() Author: Ethereum Foundation Access Cluster Published: 2026-08-05T00:00:00Z Content type: release Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Security](), [Open Source](), [browsers](), [Front end](), [Firefox]() Tags: [announce](), [browsers](), [ethereum](), [firefox](), [front-end](), [funding-coordination](), [open-source](), [security](), [signing](), [supply-chain-attacks](), [web-applications]() ### AI overview The Ethereum Foundation's Trillion Dollar Security initiative announced a grant to the Freedom of the Press Foundation to support continued development of WEBCAT, an open source tool that enables browsers to verify whether code served by enrolled websites matches code published by their developers. The grant will also support bringing this protection to Ethereum wallets and apps. ### Source excerpt The Ethereum Foundation's Trillion Dollar Security (1TS) initiative is proud to announce a grant allocation to Freedom of the Press Foundation (FPF) to support the continued development of WEBCAT. WEBCAT is an open source tool that lets browsers verify that code served by an enrolled website matches what its developers... ## Enable Your SAML Requesting App for Cross App Access DevFeed: [Enable Your SAML Requesting App for Cross App Access]() Original publisher: [Read original article]() Author: Alisa Duncan Published: 2026-07-17T05:00:00Z Content type: tutorial Language: en Sources: [Okta Developer]() Topics: [OAuth 2.0](), [Authorization](), [JSON Web Tokens](), [OpenID connect (OIDC)](), [API](), [AI Agent]() Tags: [api](), [authorization](), [claude](), [cross-app-access](), [digital-signature](), [identity](), [idp](), [implementation](), [jwt](), [oauth](), [oauth-2-0](), [oidc](), [openid-connect](), [payload](), [saml](), [signing](), [sso](), [xaa]() ### AI overview This guide explains how SAML-federated applications can use Cross App Access (XAA) to connect to third-party applications without migrating to OpenID Connect. It covers exchanging a SAML assertion for an OAuth refresh token, an ID-JAG, and an access token, along with token validation and Okta configuration. ### Source excerpt If you currently federate enterprise customers using Security Assertion Markup Language (SAML) and want to connect with third-party applications without migrating to OpenID Connect (OIDC), this Cross App Access (XAA) guide is for you. The Identity Assertion Authorization Grant specification, the basis of XAA, was originally designed with OIDC in mind. To use it in SAML applications, you must accommodate specific security and uniqueness requirements. This guide details what you need to support and how to make resource requests to a third-party app using XAA. Table of Contents How XAA in SAML works XAA implementation checklist for SAML-federated applications Request the refresh token Request the ID-JAG token Request the access token Handle token expiration Making cross-application requests from your SAML app securely Configure your XAA SAML Requesting App in Okta Register and configure the AI Agent in Okta Test the SAML 2.0 app Validate the XAA connection end-to-end Learn more about Cross App Access, SAML, and OAuth 2.0 How XAA in SAML works When an agent (like one running in Claude) needs API access, it presents an Identity Assertion Authorization Grant (ID-JAG). The ID-JAG is a short-lived JSON Web Token (JWT) issued by the Identity Provider (IdP) for your app's user. You exchange the ID-JAG token for an access token to the resource application you're connecting with. The sequence diagram shown below describes the SAML XAA flow and how your application fits in. You'll handle the flow in two parts: where your application requests the ID-JAG from the IdP using a refresh token, and where your app requests the access token from the ID-JAG from the third-party resource app's authorization server. XAA implementation checklist for SAML-federated applications Follow the guide in this section to support XAA in your SAML application when your app connects to a third-party resource application. The XAA flow places the burden of token validation onto the IdP and the resource ap ## Codename One's Certificate Wizard Becomes a Standalone App Using App Store Connect API Keys DevFeed: [Codename One's Certificate Wizard Becomes a Standalone App Using App Store Connect API Keys]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-07-11T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [iOS](), [API keys](), [Authentication](), [Development]() Tags: [api](), [app](), [apple](), [authentication](), [certificates](), [desktop](), [ios](), [release](), [signing]() ### AI overview Codename One's certificate wizard has been rewritten as a standalone desktop app for iOS developers. It replaces Apple ID login with an App Store Connect API key for managing certificates, bundle IDs, devices, provisioning profiles, and push keys. ### Source excerpt The certificate wizard is now a standalone desktop app that authenticates with an App Store Connect API key instead of your Apple ID login. ## How to import multiple iOS signing certificates to CI DevFeed: [How to import multiple iOS signing certificates to CI]() Original publisher: [Read original article]() Author: Marco Gomiero Published: 2026-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Marco Gomiero]() Topics: [GitHub Actions](), [certificates](), [iOS](), [ci]() Tags: [app-store](), [apple](), [certificates](), [ci](), [distribution](), [github](), [github-actions](), [how-to](), [ios](), [secrets](), [signing]() ### AI overview A tutorial explaining how to export multiple iOS signing certificates, combine them into a certificate file, encode it with base64, and store it as a GitHub secret for use in GitHub Actions. ### Source excerpt Some time ago, I shared the GitHub Actions workflow that I use for deploying the iOS version of FeedFlow to the App Store. How to publish a Kotlin Multiplatform iOS app on App Store with GitHub Actions One step of that CI job is setting up the required certificates for signing the app: Apple Development and Apple Distribution. In the past, it was possible to extract these two certificates from the local Keychain by selecting them and using the Export 2 items... option. ## Custom OIDC Token Audiences DevFeed: [Custom OIDC Token Audiences]() Original publisher: [Read original article]() Author: Bel Curcio Published: 2026-06-23T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [OpenID connect (OIDC)](), [Vercel](), [JSON Web Tokens](), [Authentication](), [Security](), [API](), [Low Latency]() Tags: [api](), [authentication](), [jwks](), [low-latency](), [oidc](), [security](), [signing](), [tokens](), [tracing](), [vercel](), [verification]() ### AI overview Vercel now supports custom audiences for OIDC tokens. Deployments can exchange a Vercel-issued token for one targeting a specific downstream service, enabling secure service-to-service authentication with third-party providers. ### Source excerpt Vercel's OIDC issuer (oidc.vercel.com) now supports custom audiences. Deployments can request OIDC tokens with a specific audience claim, enabling secure service-to-service authentication with third-party providers. Why custom audiences? Vercel OIDC tokens are issued with a fixed audience (https://vercel.com/{owner}). While most cloud providers don't require a specific audience value, using a unique audience per provider is a security best practice. If a provider is compromised, an attacker cannot replay the token against a different provider - the mismatched aud claim will cause verification to fail. This new service makes it easy to mint provider-specific tokens without managing additional infrastructure. How it works When a Vercel deployment runs, it receives an OIDC token signed by Vercel. The new exchange service accepts this token and returns a new one signed with the same key, but with an updated audience (aud) claim targeting your downstream service. The exchanged token: Preserves all original claims (project, environment, owner, expiration) Sets the iss (issuer) to https://oidc.vercel.com/{owner}, scoped to the team that owns the deployment Includes an act (actor) claim with the original token's audience and issued-at time, providing an auditable delegation chain Updates the aud to the requested downstream audience Updates the iat (issued-at) to the current timestamp, reflecting when the new token was created You can optionally pass a jti (JWT ID) to assign a unique identifier to the exchanged token. This is useful for auditing and tracing token usage across services - for example, correlating a specific token exchange with downstream API calls in your logs. Downstream services verify the exchanged token using the public key available at https://oidc.vercel.com/{owner}/.well-known/jwks. Both the signing key and the token exchange endpoint are replicated across all Vercel regions, ensuring low-latency token exchange regardless of where the deployment is runn ## Vercel CLI now supports signing blob URLs DevFeed: [Vercel CLI now supports signing blob URLs]() Original publisher: [Read original article]() Author: Agustin Falco Published: 2026-06-22T00:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [Command-line interface](), [Vercel](), [JSON]() Tags: [cli](), [json](), [signing](), [update](), [vercel]() ### AI overview Vercel CLI now supports generating signed Vercel Blob URLs and standalone signed tokens, with scoped operations, expiration controls, upload constraints, and structured JSON output. ### Source excerpt You can now generate signed URLs for Vercel Blob directly from the Vercel CLI. A signed URL is a scoped URL with a set expiration time that lets you perform a single operation on a specific object. Each URL is scoped to one operation (get, head, put, or delete), one pathname, and a custom expiry of up to 7 days. Update the Vercel CLI to version 5.14.5 to get started. Generate a presigned URL in one command Use the new vercel blob presign command to sign a URL for a single operation, for example to provide short-lived access to a private file or to allow your users to upload images of a certain size and content type. By default it issues a signed GET URL: Scope it to an upload with content-type and size constraints Control how long the URL stays valid with --valid-for (for example 15m, 1h, 7d) or an absolute --valid-until timestamp. Pass --json to get the result, operation, and expiry as structured output for scripting. Issue a standalone signed token Use vercel blob signed-token when you want to separate signed token generation from URL generation, for example to restrict write access to your private blob store while your agent investigates an issue. You can then feed the resulting delegation and client-signing tokens into vercel blob presign: Update to the latest version of the Vercel CLI and run vercel blob presign --help to see all available options. Learn more about signed URLs for Vercel Blob in the documentation. Read more ## Eliminating Kubernetes Image Signature Replication DevFeed: [Eliminating Kubernetes Image Signature Replication]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2026-06-05T00:00:00Z Content type: article Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [Replication](), [container images](), [Routing (disambiguation)](), [Latency](), [Google]() Tags: [cloud](), [container-images](), [cosign](), [kubernetes](), [latency](), [manifest](), [oidc](), [registry](), [replication](), [route](), [routing](), [sha256](), [signing](), [verify]() ### AI overview This article explains how Kubernetes eliminated replication of image signatures across 22 regional registries. Because signatures are small and regional latency is negligible, archeio now routes signature requests to a canonical registry while image layers continue using geo-routing. ### Source excerpt The image promoter rewrite laid the groundwork for simplifying how Kubernetes delivers container image signatures. One of the rewrite phases (Phase 6) separated image signing from signature replication into distinct pipeline stages. This follow-up covers the next step: eliminating signature replication entirely. The problem After promoting container images to registry.k8s.io, the promoter signs them using cosign with keyless (OIDC) signatures. These signatures are stored as OCI artifacts alongside the images, tagged with the convention sha256-.sig and sha256-.att. The registry.k8s.io domain is backed by archeio , a thin redirector that routes container image requests to the nearest regional Google Artifact Registry backend. When a user in Europe pulls an image, archeio redirects them to europe-west2-docker.pkg.dev; a user in Asia gets redirected to asia-east1-docker.pkg.dev, and so on across 22 regional backends. This geo-routing is great for image layers, where download locality matters for performance. But it created a problem for signatures: if the promoter only wrote a signature to one region, cosign verify would fail for users redirected to any other region. The solution was a dedicated replication pipeline that copied every .sig and .att tag to all 22 regional backends. This pipeline ran as a periodic Prow job every 2 hours on weekdays, performing thousands of API calls per run: listing tags across all repositories, diffing what existed where, and copying the missing signatures. The insight Signatures and attestations are small metadata artifacts, typically a few kilobytes each. Unlike image layers where geo-locality provides meaningful download performance improvements, fetching a signature from a non-local region adds negligible latency. The entire replication pipeline existed to optimize for a latency difference that users would never notice. The solution Instead of replicating signatures everywhere, archeio was taught to route signature req ## Clear Signing: Making Transaction Approvals Safer on Ethereum DevFeed: [Clear Signing: Making Transaction Approvals Safer on Ethereum]() Original publisher: [Read original article]() Author: Hester Bruikman Published: 2026-05-12T00:00:00Z Content type: release Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Security](), [Blockchain](), [App]() Tags: [blockchain](), [developers](), [ethereum](), [format](), [security](), [signing](), [standard]() ### AI overview An Ethereum Working Group has launched Clear Signing, an open standard intended to help wallets present human-readable, structured descriptions of transaction effects. The approach includes ERC-7730, a descriptor registry, verification through independent reviews and attestations, and tools for wallet and developer adoption. ### Source excerpt An Ethereum Working Group consisting of wallet developers, security firms and the Ethereum Foundation's Trillion Dollar Security Initiative today launched an open standard designed to end blind signing -- a structural flaw that has contributed to billions in user losses, including the Bybit hack. Ethereum Foundation's Trillion Dollar Security Initiative... ## My brave new code-signing world DevFeed: [My brave new code-signing world]() Original publisher: [Read original article]() Published: 2026-04-25T18:12:29Z Content type: opinion Language: en Sources: [Chris Wellons]() Topics: [Azure](), [Security](), [Code](), [Claude](), [Microsoft](), [Command-line interface]() Tags: [ai](), [alternatives](), [azure](), [claude](), [cli](), [cost](), [cpp](), [crypto](), [github](), [security](), [signing]() ### AI overview The article describes the author's move to code-sign Windows releases using Azure Artifact Signing and custom infrastructure called aas-sign. It discusses the cost, regional identity-verification requirement, difficult Azure portal experience, AI-assisted setup, and alternatives involving Azure CLI, Jsign, and SignTool.exe. ### Source excerpt The new w64devkit release two weeks ago is the first to be code-signed with my identity, verified by Microsoft's certificate chain. Currently only the release packaging is signed -- the self-extracting archive and its payload -- but I will soon code-sign individual EXEs and DLLs within the distribution. In fact, all Windows builds of my project releases have been code-signed the past two weeks, including dcmake, and so should everything going forward. My signing identity builds reputation with each download, so users will have an easier time with SmartScreen, and security software generally. Azure Artifact Signing creates the actual signature, but the rest is done with new infrastructure I built myself, aas-sign. As is often the case, the existing options were deficient for my needs, so I had to build it myself. This code-signing is not free, and simply having aas-sign on hand, or using the GitHub Actions action, is insufficient. You must be serious enough to spend US$10/month for the Azure subscription. After that you are subjected to the labyrinth that is the Azure portal, the most confusing UI I've ever used. Luckily we live in an age of wonders, and I could describe to Claude in Chrome what I wanted and it would happen (Sonnet works better than Opus for this). It took as much time to figure out Azure as I spent creating a fully-functional, native debugger front-end. Clear your schedule if you're going to try it yourself. If it weren't for AI assistance I would have given up. The one-time setup process is only open to North America, and involves sharing identify documents (i.e. driver's license) with Microsoft. Unlike the rest of Azure, that part was streamlined and fairly painless. Between the cost and this requirement, this is a niche space. However, if this is your niche, aas-sign is currently the best software available. It's the tool Microsoft should have written, but didn't due to ongoing institutional failures. The alternatives are a pair of tools: Azure CLI ## Keycloak Federated Client Authentication with External Identity Providers DevFeed: [Keycloak Federated Client Authentication with External Identity Providers]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2026-01-26T00:00:00Z Content type: tutorial Language: en Sources: [Keycloak Blog]() Topics: [Keycloak](), [Authentication](), [JSON Web Tokens](), [openid](), [SPIFFE](), [Kubernetes](), [trust]() Tags: [authentication](), [idm](), [jwt](), [kerberos](), [keycloak](), [kubernetes](), [ldap](), [lookup](), [openid](), [openid-connect](), [saml](), [signing](), [spiffe](), [sso](), [token](), [verify]() ### AI overview Keycloak's federated client authentication lets OpenID Connect clients authenticate through external identity providers such as OpenID Connect, SPIFFE, and Kubernetes. The article explains trust relationships, JWT claims, token verification, and how this can reduce the need for client-managed secrets in some environments. ### Source excerpt Keycloak has from day one supported identity brokering, allowing users to authenticate via an external OpenID Connect or SAML 2.0 identity provider. With federated client authentication it is now possible to authenticate OpenID Connect clients through external identity providers as well. Depending on the environment the clients is running in this can eliminate the need for managing secrets for clients altogether. A number of cloud vendors for example support injecting tokens automatically for workloads, Kubernetes have support for service accounts, and last but not least there is SPIFFE that can be leveraged in most environments. How does federated client authentication work? The first step to setting up federated client authentication is to define a trust relationship between Keycloak and the external identity providers. This is done by creating a new identity provider in the realm. Keycloak currently has three types of identity providers that support federated client authentication: OpenID Connect SPIFFE Kubernetes Clients can retrieve a token from the external identity providers that the client can then use to authenticate with Keycloak. In many cases clients can retrieve these tokens automatically through workload identity capabilities enabled for particular environments. Let's look at an example decoded JWT that can be used to authenticate a client: { "iss" : "https://my-external-idp" "aud" : [ "http://my-keycloak/realms/myrealm" ], "exp" : 1769149961, "iat" : 1769149661, "sub" : "client-id-in-my-external-idp" } The most relevant claims are iss, aud and sub. Keycloak uses the iss claim to identity the external party that issued the token as well as retrieving the external parties signing keys to verify the token. The aud claim is to make sure the token was issued to be used by Keycloak and not other applications. It is important that this contains a single audience that uniquely identifies Keycloak as the target audience, as leaking this token to other parties ## Automatically Signing a Windows EXE with Azure Trusted Signing, dotnet sign, and GitHub Actions DevFeed: [Automatically Signing a Windows EXE with Azure Trusted Signing, dotnet sign, and GitHub Actions]() Original publisher: [Read original article]() Author: Scott Hanselman Published: 2025-11-28T19:31:25Z Content type: tutorial Language: en Sources: [Scott Hanselman]() Topics: [Azure](), [GitHub Actions](), [Windows]() Tags: [azure](), [dotnet](), [dotnetcore](), [github-actions](), [signing](), [windows]() ### AI overview A tutorial on signing a Windows executable with Azure Trusted Signing, dotnet sign, and GitHub Actions. It describes cloud-based certificate management, CI/CD integration, prerequisites, and approximate pricing for small projects. ### Source excerpt Mac Tahoe (in Beta as of the time of this writing) has this new feature called Edge Light that basically puts a bright picture of an Edge Light around your screen and basically uses the power of OLED to give you a virtual ring light. So I was like, why can't we also have nice things? I wrote (vibed, with GitHub Copilot and Claude Sonnet 4.5) a Windows Edge Light App (source code at https://github.com/shanselman/WindowsEdgeLight and you can get the latest release here https://github.com/shanselman/WindowsEdgeLight/releases or the app will check for new releases and autoupdate with Updatum). However, as is with all suss loose executables on the internet, when you run random stuff you'll often get the Window Defender 'new phone, who dis' warning which is scary. After several downloads and no viruses or complaints, my executable will eventually gain reputation with the Windows Defender Smart Screen service, but having a Code Signing Certificate is said to help with that. However, code signing certs are expensive and a hassle to manage and renew. Someone told me that Azure Trusted Signing was somewhat less of a hassle - it's less, but it's still non-trivial. I read this post from Rick (his blog is gold and has been for years) earlier in the year and some of it was super useful and other stuff has been made simpler over time. I wrote 80% of this blog post, but since I just spent an hour getting code signing to work and GitHub Copilot was going through and logging everything I did, I did use Claude 4.5 to help organize some of this. I have reviewed it all and re-written parts I didn't like, so any mistakes are mine. Azure Trusted Signing is Microsoft's cloud-based code signing service that: No hardware tokens - Everything happens in the cloud Automatic certificate management - Certificates are issued and renewed automatically GitHub Actions integration - Sign during your CI/CD pipeline. I used GH Actions. Kinda Affortable - About $10/month for small projects. I would like ## Signing Git commits and tags with SSH DevFeed: [Signing Git commits and tags with SSH]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2025-11-19T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Git](), [ssh](), [ECDSA](), [ed25519]() Tags: [dsa](), [ecdsa](), [ed25519](), [git](), [rsa](), [signing](), [ssh]() ### AI overview The article explains that Git commits and tags can be signed with SSH keys instead of GPG. It states that Ed25519, ECDSA, and RSA keys are supported, while DSA keys are not. ### Source excerpt You can sign Git commits and tags with SSH keys instead of GPG. ## Why building from source matters DevFeed: [Why building from source matters]() Original publisher: [Read original article]() Published: 2025-11-13T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [open-source-security](), [Security](), [Open Source](), [Software](), [Library](), [Compiler](), [virtual machines]() Tags: [binaries](), [building](), [building-from-source-approach](), [chainguard](), [chainguard-containers](), [chainguard-libraries](), [chainguard-open-source](), [chainguard-os](), [chainguard-vms](), [dependency](), [engineering](), [open-source](), [sealed](), [security](), [signing](), [source](), [supply-chain](), [trust]() ### AI overview Chainguard explains why building software from upstream source code can improve control and traceability in software supply chains. The article describes compiling packages and dependencies in a hermetic, network-isolated environment, then signing and attesting the resulting artifacts. ### Source excerpt Chainguard SVP of Engineering Dustin Kirkland discusses why Chainguard builds every package, library, and image directly from source and why the approach works. ## S1ngularity - What Happened, How We Responded, What We Learned DevFeed: [S1ngularity - What Happened, How We Responded, What We Learned]() Original publisher: [Read original article]() Author: Juri Strumpflohner Published: 2025-09-05T00:00:00Z Content type: article Language: en Sources: [Juri Strumpflohner]() Topics: [GitHub Actions](), [npm](), [malicious packages](), [Security](), [Exploit](), [incident](), [Command-line interface](), [Local AI](), [Claude]() Tags: [claude](), [cli](), [exploit](), [gemini](), [github](), [github-actions](), [incident](), [local-ai](), [malicious-packages](), [npm](), [nx](), [reporting](), [security](), [signing]() ### AI overview Nx describes how attackers exploited a GitHub Actions injection vulnerability to steal its npm publishing token and publish malicious Nx packages. The packages ran post-install scripts that searched for sensitive data and uploaded results to public GitHub repositories. The article also details containment, communication, investigation, and security hardening measures. ### Source excerpt Malicious Nx packages were published to npm via GitHub Actions exploit. Learn what happened and how we enhanced security measures. ## Securely Signing WebAssembly Components with Cosign (OIDC) DevFeed: [Securely Signing WebAssembly Components with Cosign (OIDC)]() Original publisher: [Read original article]() Author: Liam Randall Published: 2025-09-02T00:00:00Z Content type: tutorial Language: en Sources: [wasmCloud Blog]() Topics: [WebAssembly](), [sigstore](), [GitHub Container Registry](), [OpenID connect (OIDC)](), [Rust](), [Command-line interface](), [Authentication](), [Security]() Tags: [authentication](), [cli](), [cosign](), [github-container-registry](), [integrity](), [oci-registry](), [oidc](), [registry](), [security](), [signing](), [sigstore](), [supply-chain](), [supply-chain-security](), [verify](), [wasi](), [wasm-components](), [wasmcloud](), [webassembly](), [webassembly-wasmcloud-security-cosign-oidc-signing-oci-registry-supply-chain-security-wasi-wasm-comp]() ### AI overview A tutorial showing how to build a Rust-based WebAssembly component, sign it with Sigstore Cosign using OIDC identity, push it to GitHub Container Registry, and verify it before execution. ### Source excerpt Build, sign, and verify WebAssembly component artifacts using Sigstore's cosign with OIDC identity--secure, registry-native signatures for wasmCloud. ## Malware-Resistant Python without the Guesswork DevFeed: [Malware-Resistant Python without the Guesswork]() Original publisher: [Read original article]() Published: 2025-08-01T00:00:00Z Content type: opinion Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard libraries for python](), [chainguard libraries](), [Security](), [chainguard](), [Open Source](), [Malware]() Tags: [chainguard-libraries](), [chainguard-libraries-for-python](), [malicious-packages](), [malware](), [num2words](), [provenance](), [pypi](), [python](), [reproducibility](), [sbom](), [secure-packages](), [security](), [signing](), [slsa](), [supply-chain]() ### AI overview The article presents Chainguard Libraries for Python as a way to reduce malware and software supply chain risks in Python package consumption. It describes rebuilding packages from upstream source in an isolated, reproducible SLSA Level 2 environment, and publishing signed SBOMs and provenance information. ### Source excerpt The recent compromise of the num2words package never made it into Chainguard Libraries for Python. Get the breakdown from the team on our packages you can trust. ## This Shit is Hard: SLSA L3 and Beyond DevFeed: [This Shit is Hard: SLSA L3 and Beyond]() Original publisher: [Read original article]() Published: 2025-07-31T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [supply-chain-security](), [chainguard](), [Containers](), [Security]() Tags: [chainguard](), [chainguard-containers](), [compliance](), [containers](), [provenance](), [security](), [security-engineering](), [signing](), [slsa](), [software-supply-chain](), [software-supply-chain-security]() ### AI overview Chainguard explains how it uses SLSA to strengthen software supply chain security, support customer compliance, and build trust in hardened container images. The article focuses on SLSA Build Level 3, especially isolated build execution and tamper-resistant provenance attestations with signing secrets separated from build and test processes. ### Source excerpt Chainguard goes through all the necessary steps to make things SLSA 3 compliant. Get the details on how we do it. ## New Maven Central signing key and snapshot location DevFeed: [New Maven Central signing key and snapshot location]() Original publisher: [Read original article]() Author: Jake Wharton Published: 2025-06-13T00:00:00Z Content type: release Language: en Sources: [Cash App Code Blog]() Topics: [Maven Central](), [Maven](), [Publishing](), [Open Source]() Tags: [end-of-life](), [maven-central](), [open-source-artifacts](), [public-key](), [release](), [server-android](), [signing](), [snapshot](), [snapshots](), [verification]() ### AI overview Cash App migrated its open source artifact publishing to Sonatype's new platform after OSSRH reached end of life. The change introduces a company-wide GPG signing key and moves snapshot builds to the Central Portal Snapshot repository. ### Source excerpt In response to Sonatype announcing the end-of-life for OSSRH, we have migrated to their new publishing platform for our open source artifacts. This is otherwise a transparent change for those who consume these artifacts from Maven Central, but there are two related changes which might affect your builds. ## Forging Ahead in Federal Compliance: Chainguard's FIPS 140-3 and 186-5 Milestones DevFeed: [Forging Ahead in Federal Compliance: Chainguard's FIPS 140-3 and 186-5 Milestones]() Original publisher: [Read original article]() Published: 2025-06-06T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [container images](), [Security](), [Testing](), [interoperability]() Tags: [chainguard](), [chainguard-containers](), [chainguard-fips](), [compliance](), [container-images](), [cryptographic](), [digital-signature](), [ed25519](), [federal-compliance](), [federal-information-processing-standards](), [fedramp](), [fips](), [fips-140-3](), [fips-validation](), [nist](), [openssl](), [security](), [signing](), [standards](), [validation]() ### AI overview Chainguard FIPS container images are being upgraded to support current FIPS 140-3 and FIPS 186-5 standards, including OpenSSL with FIPS 140-3 validation and Ed25519 signing support. ### Source excerpt Chainguard FIPS images have been upgraded to start using the OpenSSL project 3.1.2 module with FIPS 140-3 validation. Learn more about what this means. [Next page]()