SiliconForge

Documentation for SiliconForge 0.1.2.

Home / Docs / Install SiliconForge

Install SiliconForge

Applies to SiliconForge 0.1.2 · Updated . Check platform limits.

Before this task: Choose your platform and first task →

Install a verified native application, open a local project, then check its included engineering tools and configure only missing requirements. AI account and isolation setup are separate steps. A download is not a subscription or a toolchain qualification.

If you are setting up for the first time, follow the installation-to-first-result checklist. After installation, the two-file stream-register exercise gives you an expected passing result and a deliberate failure to compare.

Before downloading

You need a graphical desktop, permission to install applications and storage for the application and projects. Keep project data outside the installation folder. Read the commercial terms before use.

  • Linux AMD64: x86-64 CPUs, including compatible Intel processors. AMD64 does not describe your graphics card.
  • Linux ARM64: AArch64 CPUs. The current launcher requires glibc 2.39 or newer; an ARM processor alone is insufficient.
  • Windows: the signed Windows x64 installer. Release qualification targets Windows 11 x64; do not infer Windows ARM or older-Windows support.

Use Downloads for current files and publication metadata. Published application packages include engineering tools. Check the inventory for your platform and keep included tools with that runtime. The Engineering Tool Pack is not offered as a separate download; do not install duplicate tools just because a standalone pack is unavailable.

Verify before running

  1. Download the application plus its checksum and signature information from the same platform release entry.
  2. Compare the full SHA-256 digest with the published digest. Stop on a mismatch; downloading again is safer than bypassing verification.
  3. Verify provenance too: follow the Linux signature procedure below for the scheme declared by that release, or inspect the Windows Authenticode signature. A checksum detects different bytes; a valid signature also identifies the signer under its trust policy.
  4. Keep the application version, installer filename and checksum for recovery. Match the verification material to that exact downloaded file.

Third-party notices and source

For SiliconForge 0.1.1 or an older 0.1.0 download, use the source records for that exact version, platform and file. The source catalog lists published package-to-archive associations. You do not need these source archives to install or run the application. Keep the matching notices and inventory with any copy you retain.

Verify a Linux release

Open Verify this download on the selected download card and save its .sig.json release record. Use the verification format for the file you downloaded. A record with linux_signing.scheme equal to minisign uses the Minisign steps below. The published 0.1.0 Linux archives use Sigstore: their records contain verification.bundle_json and linux_signing.identity, but do not include a scheme field. Use the separate 0.1.0 procedure below; a missing scheme is not permission to skip verification. Do not select a verifier just from the operating system or reuse another release's checksum.

  1. For minisign, download the exact artifact and its adjacent <artifact-name>.minisig detached signature from the same release. The release record also carries the signature in verification.signature_text.
  2. Obtain the published SiliconForge Linux public key over the trusted website and save it as minisign.pub. Establish trust before the first verification: compare it with a previously trusted copy, the packaging/linux/minisign.pub file in a separately trusted source checkout, or a fingerprint confirmed through an established publisher channel. A new website download alone is not an independent key check. Save the confirmed key outside the downloads directory as $HOME/.config/siliconforge/minisign.pub and keep it for future updates; do not overwrite it with each release. The adjacent .minisign.pub file and verification.public_key_text must match that expected key; an arbitrary key supplied only with a signature does not establish the publisher.
  3. With a separately installed verifier from the Minisign project, run the commands below from the download folder. Replace only the example artifact filename with the exact name you downloaded.
artifact="SiliconForge-0.1.1-linux-amd64.tar.gz"
trusted_key="$HOME/.config/siliconforge/minisign.pub"
sha256sum "$artifact"
minisign -Vm "$artifact" -x "$artifact.minisig" -p "$trusted_key"

Expected result: the full SHA-256 matches the selected release, and Minisign reports a valid signature using the expected key. A missing signature, unexpected key or verification error is a stop condition. Obtain a fresh matching download or ask support; never switch keys merely to make a check pass. Verify unexpected key changes through an established trusted channel before installing.

A Minisign signature does not imply an OIDC identity, Fulcio certificate, transparency-log entry or trusted timestamp. A signer-supplied date in a signed comment is not an independent timestamp. Minisign cannot verify a Sigstore bundle; use the next section for 0.1.0. Keep all verification material for the exact release you retained.

Verify a published Linux 0.1.0 archive

Install Cosign through the official Sigstore installation guide. These commands also need Python 3. Save the archive and its matching .sig.json release record in the same directory. The example uses AMD64; for ARM64, change the artifact filename to SiliconForge-0.1.0-linux-arm64.tar.gz. If you retained an older download filename, use that actual filename instead; the signed bytes have not changed.

Compare the archive checksum with its download entry first. Then extract the embedded public bundle and verify it using Cosign's trusted Sigstore roots and the exact expected signer and issuer below. Do not replace those expected identities with arbitrary values read from a downloaded record, or trust a replacement root just because it accompanies a signature.

artifact="SiliconForge-0.1.0-linux-amd64.tar.gz"
python3 - "$artifact.sig.json" "$artifact.sigstore.json" <<'VERIFY_BUNDLE'
import json, sys
from pathlib import Path
record = json.loads(Path(sys.argv[1]).read_text())
bundle = record["verification"]["bundle_json"]
json.loads(bundle)  # Check JSON syntax; this is not signature verification.
Path(sys.argv[2]).write_text(bundle + "\n")
VERIFY_BUNDLE
cosign verify-blob "$artifact" --bundle "$artifact.sigstore.json" \
  --certificate-identity "https://github.com/denisbeau/siliconforge/.github/workflows/linux-artifact-signing.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Expected result: Cosign exits successfully and reports that the signature is verified. Extracting the JSON bundle is not verification. Cosign may need network access to obtain trusted verification metadata. On any certificate, identity, log-proof, network or signature failure, stop and contact support; do not add flags that skip identity, certificate or transparency-log checks. Keep the original archive, release record and extracted bundle. See the Sigstore verification explanation.

Install on Linux

In a terminal, check the host and hash the exact downloaded file. Replace the example filename with your downloaded filename:

uname -m
getconf GNU_LIBC_VERSION
sha256sum "$HOME/Downloads/SiliconForge-0.1.1-linux-amd64.tar.gz"
  1. After signature verification, extract an archive into a new user-owned directory. If the release entry provides an AppImage instead, make that verified AppImage executable and run it; do not treat it as a tar archive.
  2. Open the extracted runtime folder in your file manager and launch AppRun. The optional terminal equivalent is ./AppRun from that folder. Keep runtime/, core/, manifests and bundled tools together; moving just AppRun breaks the installation.
  3. Use the welcome window to open Subscription…, Create new project…, Try first project… or Open project folder…. Opening or viewing an existing project does not require a new purchase.

Expected result: one native SiliconForge window opens with the selected project. The application uses embedded Python; installing a random host Python package is not a fix for an incomplete signed runtime.

Install on Windows

PowerShell can inspect the downloaded installer without launching it:

Get-FileHash "$HOME\Downloads\SiliconForge-0.1.1-windows-x64.exe" -Algorithm SHA256
Get-AuthenticodeSignature "$HOME\Downloads\SiliconForge-0.1.1-windows-x64.exe" |
  Format-List Status,StatusMessage,SignerCertificate
  1. Use the real downloaded filename, compare the hash and check the signature is valid and belongs to the publisher identified by the release. Do not bypass a signature or malware warning.
  2. Run the installer, then launch SiliconForge from the Start menu.
  3. Choose a project outside the install directory. For isolated AI execution and engineering checks, follow the dedicated Windows WSL setup. Do not expose host drives or replace isolation with an unrestricted shell.

Why does Edge say the installer is not commonly downloaded?

A new release can trigger an Edge download-reputation warning even when its signature is valid. This warning is separate from antivirus detection; it does not by itself establish that a file is safe or malicious. Signature verification does not remove a reputation warning.

  1. Check that you downloaded from https://siliconforge.space/download. Compare the downloaded file's SHA-256 checksum with the exact release entry, not another version.
  2. Check the installer's Digital Signatures tab or the PowerShell command above. The signature must be valid and identify Denis Miclea as publisher.
  3. Do not disable protection or override a warning to make installation work. If your normal security policy prevents proceeding, stop and contact support with the release name, Windows and browser versions, and exact warning.

If the checksum differs, the signature is invalid or antivirus detects a threat, do not install. Those are separate failures, not the uncommon-download warning described here. Never send credentials or private project files in a support report. See Microsoft's explanation of SmartScreen reputation; signing does not guarantee a warning-free download.

Linux password storage

Activation and saved provider credentials use your desktop's password store. On Ubuntu, install libsecret-tools through your system package manager if it is missing. The application uses its secret-tool helper and an unlocked Secret Service-compatible keyring. A helper that is missing and a keyring that is locked are different problems.

  1. Use your regular graphical login, not a root terminal or a headless SSH session.
  2. Open your desktop password manager and unlock the login keyring. Keep its password protection enabled.
  3. Reopen Subscription… in SiliconForge and retry the same activation or refresh. Do not buy another subscription to fix password storage.

On a managed workstation, ask its administrator to enable the approved desktop password-store integration. Do not put activation credentials in project files, substitute a plaintext store or disable security to make activation work. You can still open the application and view your projects while fixing credential storage.

AI execution has a separate runtime and sandbox setup. Restricted Linux systems may require administrator configuration for the exact reviewed external executable; Windows uses the supported isolated WSL route. Installing the app does not remove these operating-system boundaries.

Activate before new engineering work

In Settings → Usage & cost → Desktop subscription, activate the intended installation online. Existing subscribers should refresh their subscription, not purchase again. Confirm the paid-through date before disconnecting. Paid local operations work offline through that verified term; opening, viewing, exporting and recovery remain available after expiry. See activation, renewal and offline access.

If the window does not open

Record the release, OS, architecture, launch method and exact error. An architecture mismatch requires a different artifact. On ARM64, a glibc error requires a supported host, not deleting the launcher's check. An incomplete runtime requires a new verified download. Missing HDL tools do not mean the application installation failed. Preserve the old install and project before making changes.

Next: first project, engineering tools, AI access, or startup diagnosis.

Ubuntu 24.04 engineering readiness

Opening the desktop and executing isolated engineering checks are separate readiness steps. Ubuntu 24.04 may require an explicit administrator setup before the first check. Follow the supported Ubuntu sandbox setup and the shipped docs/engineering/ubuntu-sandbox.md. No global security setting needs to be disabled and the app must not run as root. After setup, log out and back in, refresh tool readiness and run a small check before an AI execution.

Need help? Report an issue. Include your application version; never include credentials.