DEV Community: uknowWho

Automating SBOM Generation and Vulnerability Analysis

uknowWho — Tue, 30 Sep 2025 02:26:23 +0000

What is SBOM?

SBOM (Software Bill of Materials) = the ingredient label of software.
It lists all parts *(open-source libraries, frameworks, dependencies, versions, licenses) * that make up an app or system.

Real-Life Example

Think of food packaging: you buy bread, and the label says “contains wheat, soy, nuts.”

In software, SBOM is that label: “contains React v18, Log4j v2.14, OpenSSL 1.1.1.”

If wheat is recalled (or Log4j is hacked), you know exactly which bread (or software) is risky.

Why Automating SBOMs Matters in 2025

In the U.S., Executive Order 14028 has made SBOMs mandatory for software vendors selling to federal agencies. In Europe, the NIS2 Directive and EU Cyber Resilience Act emphasize transparent software inventories. Across APAC, markets like Japan and Singapore are also aligning with SBOM-driven security standards.

By automating SBOM generation and vulnerability scanning:

🇺🇸 U.S. teams can meet NTIA and CISA requirements.
🇪🇺 EU developers stay ahead of compliance with Cyber Resilience mandates.
Global enterprises ensure cross-border trust in their software supply chains.

The Workflow in Action

Github actions workflow triggers on pushes, pull requests, or manual runs. It automatically:

Generates an SBOM in CycloneDX format
Scans for vulnerabilities with Grype
Uploads artifacts for compliance and audit readiness

name: Supply chain security scan

on:
  push:
    branches: [main]
    paths:
      - '**/*.rs'
      - Cargo.toml
      - Cargo.lock
      - scripts/security-scan.sh
      - .github/actions/security-scan/**
      - .github/workflows/security-scan.yml
  pull_request:
    paths:
      - '**/*.rs'
      - Cargo.toml
      - Cargo.lock
      - scripts/security-scan.sh
      - .github/actions/security-scan/**
      - .github/workflows/security-scan.yml
  workflow_dispatch:

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Generate SBOM and scan for vulnerabilities
        uses: ./.github/actions/security-scan
        with:
          bom-file: shadowmap-bom.json
          report-file: grype-report.json
          fail-on: medium
          enable-reachability-analysis: true

      - name: Upload scan artifacts
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: shadowmap-security-scan
          path: |
            shadowmap-bom.json
            grype-report.json
          if-no-files-found: error

This ensures that every commit and pull request is scanned for vulnerabilities before entering the main branch.

In Action:
Press enter or click to view image in full size

The Custom Composite Action
To keep the workflow modular and reusable, the security logic is packaged as a composite GitHub Action.

name: "ShadowMap Security Scan"
description: "Generate a CycloneDX SBOM and scan it with Grype"
inputs:
  bom-file:
    description: "Filename for the generated CycloneDX SBOM"
    required: false
    default: "bom.json"
  report-file:
    description: "Optional JSON file to store Grype results"
    required: false
    default: ""
runs:
  using: "composite"
  steps:
    - uses: dtolnay/rust-toolchain@stable
    - name: Ensure cargo-cyclonedx is installed
      shell: bash
      run: |
        if ! cargo cyclonedx --version >/dev/null 2>&1; then
          cargo install cargo-cyclonedx --locked
        fi
    - name: Ensure grype is installed
      shell: bash
      run: |
        if ! command -v grype >/dev/null 2>&1; then
          curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin
        fi
    - name: Run security scan
      shell: bash
      run: |
        ARGS=("${{ inputs.bom-file }}")
        if [[ -n "${{ inputs.report-file }}" ]]; then
          ARGS+=("${{ inputs.report-file }}")
        fi
        ./scripts/security-scan.sh "${ARGS[@]}

This ensures cargo-cyclonedx and grype are available, then delegates the heavy lifting to the custom script.

The Security Scan Script
The script scripts/security-scan.sh handles SBOM generation and vulnerability scanning.

#!/usr/bin/env bash
set -euo pipefail
BOM_FILENAME="${1:-bom.json}"
REPORT_FILENAME="${2:-}" # optional second arg for JSON report
if [[ "$BOM_FILENAME" = /* ]]; then
  BOM_PATH="$BOM_FILENAME"
else
  BOM_PATH="$PWD/$BOM_FILENAME"
fi
BOM_DIR="$(dirname "$BOM_PATH")"
BOM_BASENAME="$(basename "$BOM_PATH")"
case "$BOM_BASENAME" in
  *.json) BOM_EXTENSION="json" ;;
  *.xml)  BOM_EXTENSION="xml" ;;
  *)      BOM_EXTENSION="json"
          BOM_BASENAME="$BOM_BASENAME.json"
          BOM_PATH="$BOM_DIR/$BOM_BASENAME"
          ;;
esac
BOM_STEM="${BOM_BASENAME%.*}"
if [[ -z "$BOM_STEM" ]]; then
  echo "SBOM filename must include a base name (got '$BOM_BASENAME')." >&2
  exit 1
fi
if [[ -n "$REPORT_FILENAME" ]]; then
  if [[ "$REPORT_FILENAME" = /* ]]; then
    REPORT_PATH="$REPORT_FILENAME"
  else
    REPORT_PATH="$PWD/$REPORT_FILENAME"
  fi
  REPORT_DIR="$(dirname "$REPORT_PATH")"
  mkdir -p "$REPORT_DIR"
else
  REPORT_PATH=""
fi
command_exists() { command -v "$1" >/dev/null 2>&1; }
if ! command_exists cargo; then
  echo "cargo is required to generate the SBOM." >&2
  exit 1
fi
if ! cargo cyclonedx --version >/dev/null 2>&1; then
  echo "cargo-cyclonedx is not installed. Install it with: cargo install cargo-cyclonedx" >&2
  exit 1
fi
if ! command_exists grype; then
  echo "grype is not installed. Install it with: curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sudo sh -s -- -b /usr/local/bin" >&2
  exit 1
fi
# Generate the SBOM
mkdir -p "$BOM_DIR"
GENERATED_NAME="$BOM_STEM.$BOM_EXTENSION"
GENERATED_PATH="$PWD/$GENERATED_NAME"
rm -f "$GENERATED_PATH"
cargo cyclonedx \
  --format "$BOM_EXTENSION" \
  --spec-version 1.5 \
  --all-features \
  --override-filename "$BOM_STEM"
if [[ ! -f "$GENERATED_PATH" ]]; then
  echo "cargo-cyclonedx did not produce $GENERATED_PATH" >&2
  exit 1
fi
if [[ "$GENERATED_PATH" != "$BOM_PATH" ]]; then
  mv "$GENERATED_PATH" "$BOM_PATH"
fi
echo "Generated SBOM at $BOM_PATH"
# Scan SBOM with Grype
if [[ -n "$REPORT_PATH" ]]; then
  grype "sbom:$BOM_PATH" -o json --file "$REPORT_PATH"
  echo "Stored vulnerability report at $REPORT_PATH"
else
  grype "sbom:$BOM_PATH"
fi

This script enforces strict validation, generates a CycloneDX SBOM, and scans it with Grype. If a report file is provided, results are stored in JSON for further analysis.

Benefits for Developers and Security Teams

🔎 Full transparency of dependencies, including transitive Rust crates.
⚡ Faster incident response when new CVEs are disclosed.
📊 Audit-ready reports for compliance across U.S., EU, and APAC.
🛡️ Reduced supply chain risk by embedding checks directly into CI/CD.

FAQs

Q: What is an SBOM in Rust development?

A: An SBOM is a Software Bill of Materials — a list of all dependencies in your Rust project, generated automatically with cargo-cyclonedx.

Q: How does ShadowMap scan for vulnerabilities?

A: It uses Grype, a vulnerability scanner, to analyze the SBOM and report security risks.

Q: Can ShadowMap integrate with global compliance standards?

A: Yes. It supports CycloneDX and SPDX, aligning with NTIA (U.S.), NIS2 (EU), and APAC security frameworks.

Q: Is ShadowMap only for Rust projects?

A: While optimized for Rust, the workflow structure can be extended to other ecosystems.

Conclusion

Dependencies power every Rust project, but they can also open the door to attacks. ShadowMap Security Scan closes that gap by integrating SBOM generation, vulnerability scanning, and artifact management directly into your GitHub Actions pipeline.

Here's a video overview of the above :

👉 Inspired by insights from Salem B., we built and shared this framework with the community.
👉 If you are serious about DevSecOps, start integrating SBOMs and vulnerability scans into your pipelines today.
👉 Want the bigger picture? Check out our earlier write-up on ShadowMap here: Read the documentation

The Art of Hacky Code: From Clean to Compressed Through AI Prompting

uknowWho — Tue, 02 Sep 2025 20:54:20 +0000

In coding, there are two worlds. Clean, enterprise-grade code that’s safe and predictable. And raw, compressed, hacker-style code that bends the rules and gets results fast.

Most developers think you have to pick a side. But with AI, you don’t. You can take clean, verbose code and flip it into sleek, compressed, lightning-fast implementations — without losing functionality.

This is about writing code that’s not just smart, but unfairly effective.

The Starting Point: Enterprise-Style IoT Data Converter
Our journey began with a typical enterprise IoT data transformation requirement as part of the Deloitte Job simulation exercise. We needed to convert between different JSON formats for device data:

Input Format 1 (Flat Structure):

{
    "deviceID": "dh28dslkja",
    "deviceType": "LaserCutter",
    "timestamp": 1624445837783,
    "location": "japan/tokyo/keiyō-industrial-zone/daikibo-factory-meiyo/section-1",
    "operationStatus": "healthy",
    "temp": 22
}
Target Output (Structured):

{
    "deviceID": "dh28dslkja",
    "deviceType": "LaserCutter",
    "timestamp": 1624445837783,
    "location": {
        "country": "japan",
        "city": "tokyo",
        "area": "keiyō-industrial-zone",
        "factory": "daikibo-factory-meiyo",
        "section": "section-1"
    },
    "data": {
        "status": "healthy",
        "temperature": 22
    }
}

Phase 1: Clean Code Implementation
Initially, following clean code principles, the implementation was verbose and explicit:

def convertFromFormat1(jsonObject):
    # Validate input
    if not isinstance(jsonObject, dict):
        raise ValueError("Input must be a dictionary")

    # Check required fields
    required = ["deviceID", "deviceType", "timestamp", "location"]
    for field in required:
        if field not in jsonObject or jsonObject[field] is None:
            raise KeyError(f"Missing required field: '{field}'")

    # Parse location string into structured object
    location_parts = [part.strip() for part in jsonObject["location"].split('/') if part.strip()]
    location = {
        "country": location_parts[0] if len(location_parts) > 0 else "unknown",
        "city": location_parts[1] if len(location_parts) > 1 else "unknown", 
        "area": location_parts[2] if len(location_parts) > 2 else "unknown",
        "factory": location_parts[3] if len(location_parts) > 3 else "unknown",
        "section": location_parts[4] if len(location_parts) > 4 else "unknown"
    }

    # Extract sensor data (exclude device metadata fields)
    metadata_fields = {"deviceID", "deviceType", "timestamp", "location"}
    sensor_data = {}
    for key, value in jsonObject.items():
        if key not in metadata_fields:
            if key == "operationStatus":
                sensor_data["status"] = value
            elif key == "temp":
                sensor_data["temperature"] = value
            else:
                sensor_data[key] = value

    # Build result
    result = {
        "deviceID": jsonObject["deviceID"],
        "deviceType": jsonObject["deviceType"],
        "timestamp": jsonObject["timestamp"],
        "location": location,
        "data": sensor_data
    }

    return result
Stats: 35+ lines, highly readable, follows enterprise standards.

Phase 2: The Compression Strategy
The Prompting Technique
The key to successful code compression through AI prompting lies in progressive refinement:

Start with working code — Ensure functionality before optimizing
Use specific language — “make it hacky”, “compress this”,“act like a hacker”
Iterative refinement — Address errors and edge cases progressively
Request explanations — Ask for comments to understand the compressed logic
Critical Prompting Phrases
“possible more shorten lines of the code . act like a hacker”
“dont make them all separate function put them into singular one”
“find better way then the above”“now make this one hacky way . remember to add comments”

Phase 3: The Compressed Result
Through iterative AI-assisted compression, the 35-line function became:

def convertFromFormat1(j):
    # Validate dict type and check all required fields exist and are not None in one mega line
    if not isinstance(j, dict) or any(f not in j or j[f] is None for f in ["deviceID", "deviceType", "timestamp", "location"]): raise ValueError("Invalid input")
    # Split location string by '/', strip whitespace, filter empties
    l = [p.strip() for p in j["location"].split('/') if p.strip()]
    # Field mapping dictionary for sensor data normalization
    m = {"operationStatus": "status", "temp": "temperature"}
    return {
        "deviceID": j["deviceID"], "deviceType": j["deviceType"], "timestamp": j["timestamp"],
        # Zip location parts with keys, pad with "unknown" if missing parts, slice to exactly 5 items
        "location": dict(zip(["country", "city", "area", "factory", "section"], (l + ["unknown"] * 5)[:5])),
        # Extract non-metadata fields, apply field mapping, build sensor data dict
        "data": {m.get(k, k): v for k, v in j.items() if k not in {"deviceID", "deviceType", "timestamp", "location"}}
    }

Stats: 6 functional lines, 83% size reduction, maintained functionality.

Key Compression Techniques Discovered

Variable Name Minimization jsonObject → j location_parts → l field_mappings → m
Conditional Chain Compression # Before: Multiple if statements

if not isinstance(jsonObject, dict):
    raise ValueError("Input must be a dictionary")
for field in required:
    if field not in jsonObject:
        raise KeyError(f"Missing field: {field}")

After: Single conditional with any()

if not isinstance(j, dict) or any(f not in j or j[f] is None for f in required): 
    raise ValueError("Invalid input")

Dictionary Construction Magic

# Before: Explicit conditionals
location = {
    "country": location_parts[0] if len(location_parts) > 0 else "unknown",
    "city": location_parts[1] if len(location_parts) > 1 else "unknown",
    # ... more repetition
}

After: Zip with padding

"location": dict(zip(["country", "city", "area", "factory", "section"], 
                    (l + ["unknown"] * 5)[:5]))

Comprehension Optimization

# Before: Loop with conditionals
sensor_data = {}
for key, value in jsonObject.items():
    if key not in metadata_fields:
        if key == "operationStatus":
            sensor_data["status"] = value
        elif key == "temp":
            sensor_data["temperature"] = value
        else:
            sensor_data[key] = value

After: Dictionary comprehension with mapping

"data": {m.get(k, k): v for k, v in j.items() 
         if k not in {"deviceID", "deviceType", "timestamp", "location"}}

Advanced Technique: Format 2 Implementation
The second format required timestamp conversion and nested object handling:

def convertFromFormat2(j):
    # Validate all required fields and nested device object in one line
    if not isinstance(j, dict) or any(f not in j or j[f] is None for f in ["device", "timestamp", "data"]) or not isinstance(j["device"], dict) or any(k not in j["device"] for k in ["id", "type"]): raise ValueError("Invalid input")
    # Convert ISO timestamp to unix if string, keep as-is if already number
    ts = int(datetime.fromisoformat(j["timestamp"].rstrip('Z')).timestamp() * 1000) if isinstance(j["timestamp"], str) else j["timestamp"]
    # Build location dict using dict comprehension with get() for missing fields
    loc_keys = ["country", "city", "area", "factory", "section"]
    return {
        "deviceID": j["device"]["id"], "deviceType": j["device"]["type"], "timestamp": ts,
        "location": {k: j.get(k, "unknown") for k in loc_keys},  # Extract location fields or default to "unknown"
        "data": j["data"]  # Copy data object as-is
    }

The Debugging Dance: When Compression Breaks
Common Pitfalls and Solutions

Type System Conflicts

Problem: Trying to slice a dictionary

"location": dict(zip(keys, values))[:5] # ❌ Can't slice dict

Solution: Slice the list first

"location": dict(zip(keys, (values + ["unknown"] * 5)[:5])) # ✅

Operator Precedence Issues

Problem: Wrong operator precedence

l + ["unknown"] * 5[:5] # ❌ Slices the number 5, not the list

Solution: Use parentheses

(l + ["unknown"] * 5)[:5] # ✅
Best Practices for AI-Assisted Code Compression

Progressive Refinement Start with working, verbose code Compress incrementally Test after each compression step
Strategic Prompting Use action-oriented language: “compress”, “minify”, “make hacky” Request specific constraints: “single function”, “fewer lines” Ask for explanations: “add comments to explain”
Error Handling Strategy When compression introduces bugs:

Share the exact error message
Ask for “alternative hacky ways”
Request specific fixes: “fix the return statement”

Comment Integration Request comments for complex compressed logic Use inline comments for particularly dense sections Explain the “black magic” for future maintainability When to Use Hacky Code Appropriate Scenarios

Competitive Programming: Where brevity and speed matter

Prototyping: Quick proof-of-concepts

Code Golf: Minimizing character count

Learning Exercise: Understanding Python’s advanced features
When to Avoid

Production Systems: Where maintainability is crucial

Team Environments: Where code readability affects collaboration

Complex Logic: Where compression obscures business logic

Critical Systems: Where debugging ease is paramount
Performance Implications

Interestingly, compressed code often performs better:

Metrics Comparison:

Lines of Code: 83% reduction (35 → 6 lines)

Function Calls: Fewer intermediate variables and function calls

Memory Usage: Reduced temporary object creation

Readability: Significantly decreased (trade-off)

_Conclusion: _The Art of Balanced Compression

AI-assisted code compression reveals the tension between readability and efficiency. Through strategic prompting and iterative refinement, we can transform verbose enterprise code into compact, functional implementations.

The key insights:

AI excels at mechanical transformations — Converting loops to comprehensions, merging conditionals
Progressive prompting works best — Build complexity incrementally
Comments are crucial — Compressed code needs explanation
Know your trade-offs — Compression sacrifices readability for brevity
The Developer’s Choice
The question isn’t whether to write clean or hacky code, but when to use each approach. AI-assisted development gives us the power to rapidly explore both extremes, letting us choose the right tool for the right context.

With develop skills with AI assistance, code becomes more like clay — shapeable, moldable, and optimizable for the specific needs of the moment.

“The best code is not the most beautiful or the most compressed, but the most appropriate for its purpose and audience.”

Further Reading
Python Code Golf Techniques
Competitive Programming Optimization Strategies
When Clean Code Principles Don’t Apply

About the Author: This exploration emerged from real AI-assisted development sessions, demonstrating practical techniques for code transformation through strategic prompting and iterative refinement.

EV OTA: How Merkle Trees Shrink Firmware Downloads by 95% (with Rust PoC)

uknowWho — Mon, 18 Aug 2025 17:59:08 +0000

TL;DR — Stop shipping whole pies when you only changed a slice. Split firmware into chunks, hash them, combine into a Merkle tree, sign the root, and ship only changed chunks + short proofs. Expect ~10–95% savings depending on change rate and chunking strategy. Includes a production checklist, a Rust PoC, and a Streamlit lab to visualize proofs

🌍 Why This Matters

Electric Vehicles (EVs) are more software-defined than ever. Over-the-air (OTA) updates keep them safe, efficient, and evolving. But firmware updates are huge — often hundreds of MBs — clogging cellular networks and frustrating drivers.

Enter Merkle trees, a blockchain-inspired data structure that slashes firmware update bandwidth by up to 95% while ensuring cryptographic integrity.

🌳 The Problem with Traditional Firmware Updates

EV firmware often exceeds 500 MB.

Updating requires downloading the entire binary, even if only 1% changed.

This wastes bandwidth, increases downtime, and risks bricking vehicles if interrupted.

✅ Why Merkle Trees Work

Merkle trees allow EVs to:

Split firmware into small chunks (e.g., 4–16 KB).
Hash each chunk, then build a tree of hashes.
Verify integrity via a root hash, signed by the OEM.

Only re-download chunks that changed, instead of the full firmware.

🖼️ Merkle Tree in One Picture

🦀 Rust PoC (Compact Merkle Root Signing)

Rust makes the integrity check fast and memory-safe:

use sha2::{Sha256, Digest};

fn hash_chunk(data: &[u8]) -> Vec<u8> {
    Sha256::digest(data).to_vec()
}

fn combine_hashes(left: &[u8], right: &[u8]) -> Vec<u8> {
    let mut hasher = Sha256::new();
    hasher.update(left);
    hasher.update(right);
    hasher.finalize().to_vec()
}

🐍 Python Streamlit Lab (Hands-On EV Firmware Simulator)

Here’s a full production-grade interactive simulator you can run locally to explore OTA update efficiency.

👉 Save as ev_firmware_sim.py and run with:

streamlit run ev_firmware_sim.py

Your provided code (integrated as-is, with docs & error handling):

EV OTA Firmware Update Simulator with Merkle Tree Integrity

Run: streamlit run ev_firmware_sim.py

use anyhow::{Context, Result};
use ed25519_dalek::{Signer, SigningKey, Verifier, VerifyingKey, Signature};
use rand::rngs::OsRng;
use sha2::{Digest, Sha256};
use std::fs::File;
use std::io::{Read, Write};
use std::path::Path;

const CHUNK_SIZE: usize = 4 * 1024 * 1024; // 4 MB

type Hash32 = [u8; 32];

fn sha256_bytes(data: &[u8]) -> Hash32 {
    let mut h = Sha256::new();
    h.update(data);
    h.finalize().into()
}

fn hash_pair(left: &Hash32, right: &Hash32) -> Hash32 {
    let mut h = Sha256::new();
    h.update(left);
    h.update(right);
    h.finalize().into()
}

fn leaf_hashes_from_file(path: &str, chunk_size: usize) -> Result<Vec<Hash32>> {
    let mut f = File::open(path).with_context(|| format!("open {}", path))?;
    let mut buf = vec![0u8; chunk_size];
    let mut hashes = Vec::new();
    loop {
        let n = f.read(&mut buf)?;
        if n == 0 { break; }
        hashes.push(sha256_bytes(&buf[..n]));
    }
    Ok(hashes)
}

fn build_merkle_root(mut level: Vec<Hash32>) -> Hash32 {
    if level.is_empty() { return sha256_bytes(b""); }
    while level.len() > 1 {
        if level.len() % 2 == 1 {
            let last = *level.last().unwrap();
            level.push(last);
        }
        let mut next = Vec::with_capacity(level.len()/2);
        for i in (0..level.len()).step_by(2) {
            next.push(hash_pair(&level[i], &level[i+1]));
        }
        level = next;
    }
    level[0]
}

fn gen_proof(mut level: Vec<Hash32>, mut idx: usize) -> Vec<Hash32> {
    let mut proof = Vec::new();
    while level.len() > 1 {
        if level.len() % 2 == 1 {
            let last = *level.last().unwrap();
            level.push(last);
        }
        let mut next = Vec::with_capacity(level.len()/2);
        for i in (0..level.len()).step_by(2) {
            let left = level[i];
            let right = level[i+1];
            if i == idx || i+1 == idx {
                proof.push(if i == idx { right } else { left });
                idx = next.len();
            }
            next.push(hash_pair(&left, &right));
        }
        level = next;
    }
    proof
}

fn verify_proof(leaf: &Hash32, mut idx: usize, proof: &[Hash32], expected_root: &Hash32) -> bool {
    let mut cur = *leaf;
    for sib in proof {
        cur = if idx % 2 == 0 { hash_pair(&cur, sib) } else { hash_pair(sib, &cur) };
        idx /= 2;
    }
    &cur == expected_root
}

fn ensure_demo_file(path: &str, size_mb: usize) -> Result<()> {
    if Path::new(path).exists() { return Ok(()); }
    println!("Creating demo firmware: {} ({} MB)", path, size_mb);
    let mut f = File::create(path)?;
    let block = 1024; // 1 KB
    for i in 0..(size_mb * 1024) {
        let mut buf = vec![0u8; block];
        for (j, b) in buf.iter_mut().enumerate() { *b = ((i + j) % 251) as u8; }
        f.write_all(&buf)?;
    }
    Ok(())
}

fn main() -> Result<()> {
    // 1) Demo artifact
    let demo = "demo_firmware.bin";
    ensure_demo_file(demo, 16)?; // 16 MB

    // 2) Leaves and root
    let leaves = leaf_hashes_from_file(demo, CHUNK_SIZE)?;
    println!("Leaf count: {}", leaves.len());
    let root = build_merkle_root(leaves.clone());
    println!("Merkle root: {}", hex::encode(root));

    // 3) Root signing (toy keys; in prod these come from HSM/TPM)
    let mut csprng = OsRng;
    let sk = SigningKey::generate(&mut csprng);
    let vk: VerifyingKey = sk.verifying_key();

    let metadata = b"v=1.2.3;ts=2025-08-18"; // include anti-rollback data
    let mut to_sign = Vec::new();
    to_sign.extend_from_slice(&root);
    to_sign.extend_from_slice(metadata);
    let sig: Signature = sk.sign(&to_sign);
    vk.verify(&to_sign, &sig).expect("signature must verify");
    println!("Signed root with metadata: {} bytes", to_sign.len());

    // 4) Simulate a changed chunk and proof verification against old root
    let changed_idx = 0usize.min(leaves.len()-1);
    let proof = gen_proof(leaves.clone(), changed_idx);
    let ok = verify_proof(&leaves[changed_idx], changed_idx, &proof, &root);
    println!("Proof OK against current root? {}", ok);
    assert!(ok);

    // Pretend chunk changed: new leaf hash fails against old root
    let mut mutated = leaves[changed_idx];
    mutated[0] ^= 0xFF;
    let ok2 = verify_proof(&mutated, changed_idx, &proof, &root);
    println!("Proof OK after mutation (should be false)? {}", ok2);
    assert!(!ok2);

    Ok(())
}

This simulator lets you:

Visualize firmware chunks and their hashes
Modify a chunk (simulate tampering)
Auto-generate Merkle proofs
Verify chunk integrity vs. root hash

🔬 Why This Matters for Production

OEMs can cut update costs (bandwidth is $$).
Drivers see faster, safer updates.
Merkle proofs ensure no tampering between server and vehicle.**
Less network load = less energy.**

📖 References

📢 Share This!

If you found this useful, share with your engineering team, OEM colleagues, or EV cybersecurity groups

Tauri Framework: Code-First Deep Dive : E1

uknowWho — Sun, 22 Jun 2025 10:40:08 +0000

Architecture Overview
Tauri follows a multi-process architecture where the frontend (WebView) and backend (Rust) run in separate processes, communicating through secure IPC channels.

┌─────────────────┐ IPC Bridge ┌─────────────────┐
│ Frontend │ ◄──────────────► │ Backend │
│ (WebView) │ │ (Rust Core) │
│ │ │ │
│ - HTML/CSS/JS │ │ - System APIs │
│ - UI Logic │ │ - File I/O │
│ - User Events │ │ - Network │
└─────────────────┘ └─────────────────┘

Project Setup & Configuration

Initialize Tauri Project

Install Tauri CLI

cargo install tauri-cli

Create new project

cargo tauri init

Or with existing frontend

npm create tauri-app@latest

Core Configuration (tauri.conf.json)

{
  "build": {
    "beforeDevCommand": "npm run dev",
    "beforeBuildCommand": "npm run build",
    "devPath": "http://localhost:3000",
    "distDir": "../dist"
  },
  "package": {
    "productName": "MyTauriApp",
    "version": "0.1.0"
  },
  "tauri": {
    "allowlist": {
      "all": false,
      "fs": {
        "all": false,
        "readFile": true,
        "writeFile": true,
        "createDir": true,
        "scope": ["$APPDATA/myapp/*", "$HOME/Documents/*"]
      },
      "dialog": {
        "all": false,
        "open": true,
        "save": true
      },
      "shell": {
        "all": false,
        "execute": true,
        "sidecar": true,
        "scope": [
          {
            "name": "my-script",
            "cmd": "python",
            "args": ["./scripts/my-script.py"]
          }
        ]
      }
    },
    "security": {
      "csp": "default-src 'self'; connect-src ipc: https:; script-src 'self' 'unsafe-inline'"
    },
    "windows": [
      {
        "fullscreen": false,
        "resizable": true,
        "title": "My Tauri App",
        "width": 1200,
        "height": 800,
        "minWidth": 800,
        "minHeight": 600
      }
    ]
  }
}

Rust Backend Structure (src-tauri/src/main.rs) 🔧 Top-level Setup and Imports

#![cfg_attr(not(debug_assertions), windows_subsystem = "windows")]

What it does:
This conditional attribute hides the console window on Windows only in release builds (not(debug_assertions)).

Why it matters:
Makes your app feel like a native GUI app (no terminal popping up).

use tauri::{Manager, State, Window};
use std::sync::Mutex;
use serde::{Deserialize, Serialize};
tauri::{Manager, State, Window}:

Manager:
Allows managing app state, windows, emitting events, etc.
State: For passing shared state (like a database or counter).
Window:
Interface to a specific app window.
std::sync::Mutex: Thread-safe mutable access to shared data.
serde::{Deserialize, Serialize}: Lets you serialize/deserialize structs (needed to pass state/data between Rust and JS).
📦 AppState Struct

#[derive(Debug, Serialize, Deserialize)]
struct AppState {
    counter: Mutex<i32>,
    user_data: Mutex<Vec<String>>,
}

AppState: A globally managed struct holding:
counter: shared, mutable counter.
user_data: a list of user-provided strings.
Mutex<>: Ensures safe concurrent access from multiple threads.
Derives Serialize/Deserialize: So it can be passed to/from the frontend.

impl Default for AppState {
    fn default() -> Self {
        Self {
            counter: Mutex::new(0),
            user_data: Mutex::new(Vec::new()),
        }
    }
}

Implements Default for AppState, allowing you to easily instantiate it via AppState::default() during app startup.

🚀 Main Function — Tauri App Lifecycle
fn main() {

App Builder Initialization tauri::Builder::default() Starts configuring your Tauri app with default settings.
Manage Global State .manage(AppState::default())

Injects your AppState struct into Tauri’s dependency injection system so it can be accessed in commands (via State)

       .invoke_handler(tauri::generate_handler![
            greet,
            increment_counter,
            get_counter,
            read_config_file,
            write_config_file,
            get_system_info,
            emit_custom_event
        ])

Registers backend Rust commands callable from the frontend (via window.TAURI.invoke).
These functions (e.g. greet, increment_counter, etc.) should be defined in your Rust code elsewhere.

Setup Hook

.setup(|app| {
    let app_handle = app.handle();

Runs once when the app starts.
You get the app_handle to manage app state, windows, etc.

Ensure App Data Directory Exists

            let app_data_dir = app.path_resolver()
                .app_data_dir()
                .expect("Failed to get app data directory");

            if !app_data_dir.exists() {
                std::fs::create_dir_all(&app_data_dir)?;
            }

Gets the path to the platform-specific app data directory (e.g., ~/Library/Application Support/MyApp).
If it doesn’t exist, creates it.
Useful for storing config files, logs, etc.

Complete Setup

Ok(()) })

Return Ok(()) to signal setup success.

Run the App

.run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Loads Tauri’s runtime context (from tauri.conf.json).
Boots the app.
If anything goes wrong, logs an error.
🔁 System Overview: Visual Breakdown

🧠 Business & Dev Benefits

IPC Communication Patterns

Command Pattern (Frontend → Backend) Rust Backend Commands:

Imagine you’re building a desktop app with Tauri. You want the frontend (JavaScript) to talk to Rust for real work: counting clicks, processing data, etc.

Tauri gives you a secure channel (invoke) to call Rust functions from the frontend. These Rust functions are called commands. They can do logic, manage state, and return results.

🌟 SECTION 1: Understanding #[command]

[command]

This is a macro provided by Tauri.
It tells Tauri:
“Hey, this Rust function is safe to be called from JavaScript!”

So if your frontend JS does:

await invoke("greet", { name: "Alice" });

Tauri will look for a Rust function annotated with #[command] and named greet. ✅

🧠 1. greet Function — The Hello World of Commands

#[command]
async fn greet(name: String) -> Result<String, String> {
    Ok(format!("Hello, {}! You've been greeted from Rust!", name))
}

🧠 What’s going on here?

🔁 Flow:
JS sends a string "Alice" → passed as name
Rust formats it → returns "Hello, Alice! ..."
If error occurred, return Err("some error")
💡 Analogy: JS is placing a phone call to Rust. #[command] answers, and the function returns a spoken reply.

🧠 2. increment_counter

#[command]
async fn increment_counter(state: State<'_, AppState>) -> Result<i32, String> {
    let mut counter = state.counter.lock().unwrap();
    *counter += 1;
    Ok(*counter)
}

🔍 Let’s decompose this Feynman-style:
🧱 state: State<'_, AppState>

Think of State as a shared box passed around the app.
Inside the box: a Mutex named counter.
'_' is just shorthand for a lifetime (safe borrow).
🧲 lock().unwrap()
You want to open the box and get mutable access.
Since it’s protected by a Mutex, you must lock() it.
If locking fails (e.g. deadlock), unwrap() panics (for simplicity here).
🧠 Mutation
*counter += 1;
Dereferences the mutex-guarded value, adds 1.
📤 Return the new counter value
“Hey JS, the counter is now: 7”

🧠 3. get_counter

#[command]
async fn get_counter(state: State<'_, AppState>) -> Result<i32, String> {
    let counter = state.counter.lock().unwrap();
    Ok(*counter)
}

Same idea, but read-only access.
Lock the mutex and return the inner value.
🧠 Analogy: You’re peeking inside a locked chest (read-only), not modifying it.

🧠 4. process_data
This one is more complex, so let’s Feynman it step-by-step.

#[command]
async fn process_data(
    data: Vec<String>,
    options: ProcessOptions,
    state: State<'_, AppState>
) -> Result<ProcessResult, String> {`

🧩 What are the inputs?
data: A list of strings from the frontend (e.g., ["hi", "hello", "world"])
options: Some settings from frontend (how to process)
state: Global app state, holds user_data
🧠 Step 1: Process the input list

let processed = data.iter()
    .filter(|item| item.len() > options.min_length)
    .map(|item| item.to_uppercase())
    .collect();

Loop through all the strings:
Only keep those with length > min_length
Convert them to UPPERCASE
Example:
Input: ["hi", "hello", "world"], min_length = 2 → Output: ["HELLO", "WORLD"]
🧠 Step 2: Update Shared State

let mut user_data = state.user_data.lock().unwrap();
user_data.extend(processed.clone());
Lock the global user_data vector (mutex).

Append the new results to it.
🧠 Step 3: Return a result struct

Ok(ProcessResult {
    processed,
    total_count: user_data.len(),
    timestamp: chrono::Utc::now().timestamp(),
})

Return:

The processed strings
Total number of strings saved in global state
Current UTC timestamp (useful for logging/metrics)
🧠 5. Data Structures

#[derive(Deserialize)]
struct ProcessOptions {
    min_length: usize,
    max_items: Option<usize>,
}

Deserialize = frontend can send this struct
Example JS object:
{
min_length: 3,
max_items: null
}

#[derive(Serialize)]
struct ProcessResult {
 processed: Vec<String>,
 total_count: usize,
 timestamp: i64,
}

Serialize = can send this back to frontend
Returned as JSON object like:
{
  "processed": ["HELLO", "WORLD"],
  "total_count": 7,
  "timestamp": 1723462781
}

🧠 Summary: Big Picture Mental Mode

Frontend TypeScript Integration:

// src/lib/tauri-api.ts
import { invoke } from '@tauri-apps/api/tauri';
🔄 What does invoke() do?

It lets JS/TS call a Rust function marked with #[command].
You pass:

A command name as a string ("increment_counter")
A payload (object containing parameters)
Think of it like calling a function in another language via a “network wire” inside your computer.

🧠 Part 1: Understanding the TauriAPI Class
export class TauriAPI {
This is a wrapper class. It wraps the low-level invoke() calls into readable, clean, typed functions.

🧱 Let’s go method-by-method
🧠 greet(name: string): Promise

return await invoke('greet', { name });
Calls Rust’s greet function.
Sends { name: "Alice" }
Rust returns "Hello, Alice!"
Fully type-safe: we tell TypeScript what kind of value is coming back.
JS hands Rust a note with your name, and Rust replies with a greeting.

🧠 incrementCounter()

return await invoke<number>('increment_counter');

Calls Rust’s increment_counter
No arguments
Rust locks a shared counter, increments it, and returns new value
It’s like clicking a tally clicker. Rust holds the clicker securely; you ask it to click once and tell you the total.

🧠 getCounter()
return await invoke('get_counter');
Calls Rust’s get_counter to read current count
No side-effects, just reads
Returns i32 from Rust (number in TS)
Analogy: You’re asking Rust, “Hey, what’s the number on the clicker right now?”

🧠 processData(data: string[], options: ProcessOptions)
return await invoke<ProcessResult>('process_data', {
  data,
  options: {
    min_length: options.minLength,
    max_items: options.maxItems,
  }
});

🧬 Dissecting the Arguments
Sends two things to Rust:

data: an array of strings
options: an object shaped like ProcessOptions, but converted to Rust naming style (snake_case)
data: Vec,
options: ProcessOptions // where min_length, max_items are field names
You’re giving Rust a bunch of data and some instructions:
“Keep only long items. UPPERCASE them. Track the result in global memory. Also, tell me the timestamp.”

🧠 Part 2: TypeScript Interfaces
🔍 ProcessOptions


export interface ProcessOptions {
  minLength: number;
  maxItems?: number;
}

JS representation of Rust’s ProcessOptions
Optional maxItems means it can be undefined, just like Option in Rust
These are the settings you pass to Rust to tweak how the data is processed.

🔍 ProcessResult

export interface ProcessResult {
  processed: string[];
  totalCount: number;
  timestamp: number;
}

JS version of the ProcessResult Rust struct

Includes:

Transformed data
Number of total entries in global memory
When the processing occurred
🎨 Part 3: React Component — CounterComponent
💡 Purpose
This UI shows:

The current count
A button to increment the counter
Uses React hooks (useState, useEffect)
🔬 Deconstructing it
const [count, setCount] = useState(0);
const [loading, setLoading] = useState(false);
count: Holds the current number from Rust
loading: Button shows spinner when async call is in progress
🧠 handleIncrement — Clicking the button

const handleIncrement = async () => {
  setLoading(true);
  try {
    const newCount = await TauriAPI.incrementCounter();
    setCount(newCount);
  } catch (error) {
    console.error('Failed to increment:', error);
  } finally {
    setLoading(false);
  }
};

When the button is clicked:
Show spinner
Call Rust to increment
Set the new value into state
Hide spinner
You’re telling Rust: “Count one up.” When it replies, update your screen.


🔁 useEffect — on first load
useEffect(() => {
  TauriAPI.getCounter().then(setCount);
}, []);
On mount ([] = run once):

Ask Rust for current count
Show it
Think of this like bootstrapping your React app with the server-side state from Rust.

🖼️ Render:

return (
  <div className="counter">
    <h2>Count: {count}</h2>
    <button onClick={handleIncrement} disabled={loading}>
      {loading ? 'Loading...' : 'Increment'}
    </button>
  </div>
);

Shows the current count
Button says:

“Increment” when idle
“Loading…” when it’s waiting on Rus
🧠 Concept Map: JavaScript → Tauri → Rust

🧠 Summary: What You’ve Built

Event Pattern (Backend → Frontend) Rust Event Emission:

A Tauri backend command that:

Runs a long task in the background (without freezing the UI)
Sends progress updates to the frontend every step
Notifies when it’s complete
Like a pizza oven that updates the UI on how many slices it’s baked so far. 🍕

// src-tauri/src/events.rs

use tauri::{command, Manager, Window};
use serde::Serialize;

✅ The Data Structure — ProgressUpdate

#[derive(Serialize, Clone)]
struct ProgressUpdate {
    current: u32,
    total: u32,
    message: String,
}

Let’s deconstruct:

[derive(Serialize, Clone)]

Serialize: Makes this struct convertible to JSON (so it can be sent to the JS frontend)
Clone: Allows the struct to be copied easily in memory
Think of this as adding a “JSON jacket” and “photocopier” to your data structure so it can be broadcast to the frontend and reused.

struct ProgressUpdate
Rust’s way of defining a data container, like a JS object { current, total, message }
current: u32 // how far we are
total: u32 // the total goal
message: String // optional human-readable message

🚀 The Async Command — start_long_task #[command] async fn start_long_task(window: Window) -> Result<(), String> { #[command] Tauri magic. Tells Tauri: “Hey, this is callable from the JavaScript side!”

async fn
This is an asynchronous function in Rust, meaning it can:

Wait
Sleep
Yield to other tasks
Without blocking the whole app
Like saying: “This function may take a while — let it cook in the background.”

window: Window
This is Tauri’s handle to the UI window (like a messenger line to the frontend)

Think of it as a walkie-talkie to the JavaScript world.

-> Result<(), String>
It returns:

Ok(()) if successful
Err(String) if it fails (with a human-readable error)

🧠 Spawn Background Work

let window_clone = window.clone();
tokio::spawn(async move {
    ...
});
window.clone()

We clone the window because tokio::spawn moves ownership into another thread.
Rust doesn’t allow two owners by default — but cloning safely gives another copy.
“We photocopy the walkie-talkie so our background task can still talk to the frontend.”

tokio::spawn(async move { ... })
Spawns a new green thread using Tokio (Rust’s async runtime)
Runs in the background, without blocking the main thread
Like launching a robot that bakes the pizza while we continue chatting.

🔁 Simulate Work + Emit Progress
for i in 1..=100 {
tokio::time::sleep(Duration::from_millis(50)).await;
for i in 1..=100
Loop from 1 to 100 inclusive
Each i represents one step of progress
tokio::time::sleep(...)
Pauses 50ms per step to simulate a long task
await lets other work happen during the sleep
Like baking 1 pizza slice every 50ms
📡 Emit a Progress Event

let progress = ProgressUpdate {
    current: i,
    total: 100,
    message: format!("Processing item {}/100", i),
};

window_clone.emit("task-progress", &progress)?;

We create a ProgressUpdate instance with:

current = i
total = 100
a message string
emit("task-progress", &progress)
Sends an event to the JS frontend
task-progress is the event name (frontend listens to this!)
&progress is the data — converted to JSON because of Serialize
Think of it like Rust yelling to JS:
“Hey! I’m at 37 out of 100! Here’s your update!”

.map_err(...)

If emitting fails, convert the error into a string so we can bubble it back cleanly.

🎉 Emit Final Completion Event
window_clone.emit("task-complete", "Task finished successfully!")?;
When loop is done, send one last signal: “I’m done!”
JS receives this and can show a toast or stop a loading bar.
📤 Top-Level Function Still Returns Immediately
Ok(())
Important: start_long_task() returns right after spawning the task.
You don’t wait for the task to complete here.
“Start the baking robot and return immediately — the robot will keep updating us as it cooks.”
📡 Manual Event Emission — emit_custom_event

#[command]
async fn emit_custom_event(window: Window, event_name: String, payload: String) -> Result<(), String> {
    window.emit(&event_name, payload)?;
    Ok(())
}

This is a utility command that lets JS trigger any custom event on itself.

JS calls this with:

await invoke("emit_custom_event", { event_name: "ping", payload: "Pong from backend" });

It’s like letting the frontend trigger backend-powered frontend events for flexibility.

Frontend Event Handling:

This is what you’re building:

A listener system that reacts to messages (called events) like:

“a task is progressing…”
“a task is complete!”
“something went wrong!”
A React hook that listens to these events and gives live updates to your UI. It’s like setting up walkie-talkies between a worker (Rust, backend, etc.) and a dashboard (React). When the worker yells “Hey! I finished slice 5!”, the dashboard updates the progress bar.

Now let’s get into more detail work

🔍 First: Understanding the Interfaces

export interface ProgressUpdate {
  current: number;
  total: number;
  message: string;
}

This defines the shape of a progress update — like a schema or a “form” it must fill.

Think of this like:

✅ current: What slice are we at?

✅ total: How many total slices are expected?

✅ message: A human-readable update like "Now slicing 5/100"

🔊 EventHandler.listenToProgress()
static async listenToProgress(callback: (progress: ProgressUpdate) => void)
This function listens to progress updates and runs your callback function every time a new one comes in.

Under the hood:

const unlisten = await listen<ProgressUpdate>('task-progress', (event) => {
  callback(event.payload);
});

listen: Listens for messages tagged "task-progress" that must follow the ProgressUpdate structure.
event.payload: The actual message content.
Then it returns:

return unlisten;
Which is a function you can call later to stop listening.

🧠 Think of it as subscribing to a channel, and you get back a remote that lets you mute it.

✅ listenToCompletion()
Same idea but simpler — just listens for when the task is complete:

static async listenToCompletion(callback: (message: string) => void)
Listens to 'task-complete'
Runs your callback with a string (e.g., "done!")
🛠️ setupGlobalEventListeners()
static async setupGlobalEventListeners(): Promise void>>
This sets up miscellaneous event listeners, like:

'system-event': Might log version updates, metadata, etc.
'error': Something went wrong.
Each one returns an unlistener that you store in a Map, like:

unlisteners.set('error', errorUnlisten);
Later, if you want to clean everything up, you can just call each stored function.

🧠 Think of this like setting up house alarms and storing the off switches in a labeled box.

🔁 useTaskProgress() (React Hook)
This lets a React component automatically track progress and know when the task is complete.

Code breakdown :

const [progress, setProgress] = useState<ProgressUpdate | null>(null);
const [isComplete, setIsComplete] = useState(false);

Two states:

progress: How far we’ve gone.
isComplete: Has the task finished?

Inside useEffect:
let progressUnlisten: (() => void) | null = null;
let completeUnlisten: (() => void) | null = null;

Create two unlisten holders so we can clean up later.

progressUnlisten = await EventHandler.listenToProgress(setProgress);
completeUnlisten = await EventHandler.listenToCompletion(() => {
  setIsComplete(true);
  setProgress(null);
});

We connect to those event channels and tell them what to do:

🧹 Then this part cleans up when the component unmounts:

return () => {
  progressUnlisten?.();
  completeUnlisten?.();
};

🧠 Mental Model Summary
Imagine:

🔍 First-Principles Breakdown
Why use events?

Because you want to decouple the producer (Rust/backend) from the consumer (UI). Instead of the UI constantly asking, “are we done yet?”, it waits passively for updates.

Why store unlisten functions?

Because you want full cleanup control. React components mount/unmount, and without cleanup, you’ll get memory leaks or duplicate listeners.

Why use a hook?

It makes the logic reusable, declarative, and idiomatic in React. Any component can just useTaskProgress() and instantly get the live state.

Security & Sandboxing
[App Launch]
└► initSecurityPlugin(app)
└ sets up global listener for "tauri://created"

[Window Created]
└► global listener triggers
└► window.setTitle("Secure Tauri App")

[Frontend JS]
└► invoke("security|validate_content_security", content)
└► Rust runs command
└ Dangerous pattern check
└► returns boolean → allowed?

[Result]
└► True = content is safe
└► False = content rejected

Content Security Policy (CSP)

// src-tauri/src/security.rs

use tauri::{
    plugin::{Builder, TauriPlugin},
    Runtime, Manager, AppHandle
};

🔐 1. init_security Plugin — High-Level Purpose

pub fn init_security<R: Runtime>() -> TauriPlugin<R> {
    Builder::new("security")
        .setup(|app| {
            app.listen_global("tauri://created", |event| {
                // set window title
 -           });
            Ok(())
        })
        .build()
}

What it does: Defines a Tauri plugin named "security".
Why it’s needed: Plugins modularize cross-cutting functionality (security, protocols, etc.) github.com+15tauri.app+15tauri.app+15.
.setup(...) hook: Called during app initialization—here we add a global listener for "tauri://created".

⚙️ 2. app.listen_global("tauri://created", ...)
Event purpose: Fired when any window is created.
Listener callback: Allows modifying window properties — like setting the title.

Under the hood:

Tauri registers this callback before GUI windows appear. When window creation occurs, Tauri invokes this function globally
Thread-safety nuance: listen_global isn't thread-safe across contexts—fine for setup usage tauritutorials.com+5github.com+5tauri.app+5.
⚙️ 2. app.listen_global("tauri://created", ...)
Event purpose: Fired when any window is created.
Listener callback: Allows modifying window properties — like setting the title.

Under the hood:

Tauri registers this callback before GUI windows appear. When window creation occurs, Tauri invokes this function globally

Thread-safety nuance: listen_global isn't thread-safe across contexts—fine for setup usage

🧩 3. window.set_title(...)
Purpose:
Provides secure control over the window title from Rust.
Why it’s relevant:
Using the "tauri://created" global event ensures centralized title enforcement, avoiding race conditions and messy frontend overrides.
🛡️ 4. validate_content_security


#[tauri::command]
:contentReference[oaicite:15]{index=15}
    :contentReference[oaicite:16]{index=16}
    :contentReference[oaicite:17]{index=17}
        :contentReference[oaicite:18]{index=18}
            :contentReference[oaicite:19]{index=19}
        }
    }
    Ok(true)
}

What it does: A Tauri command to validate JavaScript content against suspicious CSP patterns.
Why it’s needed: To avoid injecting unsafe inline scripts or dangerous schemes that could bypass CSP.
Best practices:

Run this check in Rust, not frontend, to avoid tampering.
Ensure patterns are comprehensive (e.g., consider , event-hander attributes, etc.), and keep updated alongside your CSP config
🔍 5. Under-the-Hood: How It All Works

🧠 First-Principles Insight
Modularity: Packaging security logic into a plugin separates concerns and avoids polluting app setup.
Event-centric design: Reacting to tauri://created allows central control of windows—titlebars, CSP, etc.—aligning with modern secure app design.
Command-level CSP checks: Instead of trusting frontend input, run validation in Rust to maintain trust boundaries.
Declarative defense: Your code acts as a security guard — enforcing rules both at the boundary (input sanitization) and infrastructure (CSP injections).
Some Enhancement Recommendation (AI Suggestion) :

Unlisten on shutdown: Although global, consider plugin cleanup for long-lived apps.
Whitelist rules: Instead of rejecting on any pattern, whitelist allowed content for better security postures.
Access control: Export commands under security prefix—invoke('security|validate_content_security').

File System Scoping { "tauri": { "allowlist": { "fs": { "scope": [ "$APPDATA/myapp/", "$HOME/Documents/MyApp/", "$RESOURCE/templates/**" ] } } } } File System Operations
Advanced File Operations

// src-tauri/src/file_operations.rs
use tauri::{command, AppHandle, Manager};
use std::path::PathBuf;
use serde::{Deserialize, Serialize};

Frontend File Management

// src/lib/file-manager.ts
import { open, save } from '@tauri-apps/api/dialog';
import { readTextFile, writeTextFile, createDir } from '@tauri-apps/api/fs';
import { TauriAPI } from './tauri-api';
Imports essential Tauri APIs for

File dialogs: Opening and saving files via native OS dialogs (open, save).
File system operations: Reading, writing files, and creating directories (readTextFile, writeTextFile, createDir).
Includes a custom wrapper module (TauriAPI) to:

Simplify and centralize Tauri-specific functionality.
Provide a cleaner, more maintainable interface for frontend file operations.
Sets the foundation for seamless file management (open/save, read/write, directory creation) in a desktop app built with Tauri.

State Management What’s Going On Here? When you want to build a desktop app using Tauri, and you want to keep user preferences, cache, and session data in memory so they can be easily read/written from the frontend.

Think of it like:

🧠 AppState: a brain that stores current preferences, recent files, and some in-memory data.
🗝️ Tauri commands: remote controls (JavaScript frontend) calling Rust functions.
🧵 Mutex and Arc: ways to safely share and lock data when multiple parts of the app (threads) want to look inside the brain.
🏗️ 1. Struct Breakdown

#[derive(Debug)]
pub struct AppState {
    pub preferences: Arc<Mutex<UserPreferences>>,
    pub cache: Arc<Mutex<HashMap<String, String>>>,
    pub session_data: Arc<Mutex<HashMap<String, serde_json::Value>>>,
}

What’s happening?
AppState is a struct — a "box" to group multiple things together.
It stores:

preferences: your app's settings (UserPreferences)
cache: quick in-memory key-value store (like a tiny dictionary)
session_data: session-related data, like cookies or current user info
Why Arc>?
Arc: Atomically Reference Counted — allows multiple parts of the program to share the same data.
Mutex: Mutual Exclusion — lets only one thread at a time read or write data. Like a bathroom lock 🚪.
TL;DR: We’re sharing the same data between multiple parts of the app, but locking it so only one person writes at a time.

🏗️ 2. Default Implementation

impl Default for AppState {
    fn default() -> Self {
        Self {
            preferences: Arc::new(Mutex::new(UserPreferences::default())),
            cache: Arc::new(Mutex::new(HashMap::new())),
            session_data: Arc::new(Mutex::new(HashMap::new())),
        }
    }
}

What’s happening?
If someone says “Give me a blank AppState,” this is how we make one:

Fresh preferences (UserPreferences::default())
Empty cache and session data (empty hash maps)
Think of this as a fresh user logging into the app for the first time.

🔌 3. Tauri Commands (frontend can call these)
These functions are callable from your JavaScript frontend through Tauri. They all use state: State<'_, AppState> to access the shared app state.

📜 get_preferences

#[tauri::command]
pub async fn get_preferences(state: State<'_, AppState>) -> Result<UserPreferences, String> {
    let prefs = state.preferences.lock()
        .map_err(|e| format!("Failed to lock preferences: {}", e))?;
    Ok(prefs.clone())
}

Lock the preferences (like turning the bathroom key).
Clone the UserPreferences to return it (so we don’t give the actual inner one).
If the lock fails (some thread panicked), we return an error.
🛠️ update_preferences

#[tauri::command]
pub async fn update_preferences(state: State<'_, AppState>, new_prefs: UserPreferences) -> Result<(), String> {
    let mut prefs = state.preferences.lock()
        .map_err(|e| format!("Failed to lock preferences: {}", e))?;
    *prefs = new_prefs;
    Ok(())
}

Lock preferences.
Overwrite the old preferences with the new ones.
Return success.
📁 add_recent_file

#[tauri::command]
pub async fn add_recent_file(state: State<'_, AppState>, file_path: String) -> Result<(), String> {
    let mut prefs = state.preferences.lock()
        .map_err(|e| format!("Failed to lock preferences: {}", e))?;

    prefs.recent_files.retain(|f| f != &file_path);
    prefs.recent_files.insert(0, file_path);
    prefs.recent_files.truncate(10);
    Ok(())
}

Breakdown:
Get lock on preferences.
Remove file if already in recent list (to avoid duplicates).
Add it to the front (most recent at top).
Only keep 10 items in the list (like a “Most Recently Used” list).
🧠 cache_set

#[tauri::command]
pub async fn cache_set(state: State<'_, AppState>, key: String, value: String) -> Result<(), String> {
    let mut cache = state.cache.lock()
        .map_err(|e| format!("Failed to lock cache: {}", e))?;
    cache.insert(key, value);
    Ok(())
}

Lock the cache.
Insert a new key-value.
Simple dictionary update.
🔍 cache_get

#[tauri::command]
pub async fn cache_get(state: State<'_, AppState>, key: String) -> Result<Option<String>, String> {
    let cache = state.cache.lock()
        .map_err(|e| format!("Failed to lock cache: {}", e))?;
    Ok(cache.get(&key).cloned())
}

Lock the cache.
Get value if it exists.
Return a clone of it (not a reference).
🧩 Putting It All Together

🔁 Bonus: Safety + Performance
Arc> is not the most performant, but it’s easy and safe for Tauri apps.
If needed, you can later use RwLock (read-write locks) or even actors for better performance.

Frontend State Management

// src/lib/state-manager.ts
import { invoke } from '@tauri-apps/api/tauri';
🔧 1. The UserPreferences Interface
export interface UserPreferences {
  theme: string;
  language: string;
  autoSave: boolean;
  recentFiles: string[];
}

💡 What is it?
An interface defines the shape of an object.

🧠 Why does it exist?
To describe what a user’s preferences look like. It’s like a contract — if a variable claims to be UserPreferences, it must have:

theme → text like "dark" or "light"
language → text like "en" or "bn"
autoSave → true or false
recentFiles → list of filenames
🏛️ 2. The Singleton StateManager Class
export class StateManager {
private static _instance: StateManager;
💡 What is this?
A singleton. There should be only one instance of StateManager in your whole app.

private _preferences: UserPreferences | null = null;
private _cache: Map = new Map();
_preferences: stores the latest loaded preferences.
_cache: a key-value memory store, like a tiny in-memory database.

🧠 Why?
Instead of fetching preferences from Tauri every time, it keeps a local copy and cache, making the app faster.

🚪 3. Accessing the Singleton

static getInstance(): StateManager {
  if (!StateManager._instance) {
    StateManager._instance = new StateManager();
  }
  return StateManager._instance;
}

💡 What’s happening?
This lazy-creates the singleton. If it’s not made yet, make it. Otherwise, reuse it.

📦 4. Loading Preferences (Lazy Fetch)

async loadPreferences(): Promise<UserPreferences> {
  if (!this._preferences) {
    this._preferences = await invoke<UserPreferences>('get_preferences');
  }
  return this._preferences;
}

invoke calls the Rust backend command get_preferences.
Only fetches once, then reuses.
🧼 5. Updating Preferences

async updatePreferences(prefs: UserPreferences): Promise<void> {
  await invoke('update_preferences', { newPrefs: prefs });
  this._preferences = prefs;
}

This updates both:

Backend Rust state (AppState)
Local cached copy (this._preferences)
🗂️ 6. Managing Recent Files

async addRecentFile(filePath: string): Promise<void> {
  await invoke('add_recent_file', { filePath });
  if (this._preferences) {
    this._preferences.recentFiles = [
      filePath,
      ...this._preferences.recentFiles.filter(f => f !== filePath)
    ].slice(0, 10);
  }
}

🔁 What’s going on?
Sends update to backend.
Locally adjusts recent files:
Removes duplicates
Adds newest to top
Keeps only the last 10
🧠 7. Cache Set/Get (with Local Mirror

async cacheSet(key: string, value: any): Promise<void> {
  const serialized = JSON.stringify(value);
  await invoke('cache_set', { key, value: serialized });
  this._cache.set(key, value);
}

value is converted to string because the Rust backend expects a String.
Then saved both in backend and local memory.

async cacheGet<T>(key: string): Promise<T | null> {
  if (this._cache.has(key)) {
    return this._cache.get(key);
  }
  const cached = await invoke<string | null>('cache_get', { key });
  if (cached) {
    const parsed = JSON.parse(cached);
    this._cache.set(key, parsed);
    return parsed;
  }
  return null;
}

First tries to get from memory.
If not found, asks backend and updates local memory.
Deserializes JSON string from backend into JS object.
🧼 8. Cache Clear

clearCache(): void {
  this._cache.clear();
}

Local memory only. Doesn’t affect backend.

🧠 9. React Context API Integration
Now we’re building the React global state system.

interface StateContextType {
  preferences: UserPreferences | null;
  updatePreferences: (prefs: UserPreferences) => Promise<void>;
  addRecentFile: (path: string) => Promise<void>;
  cacheGet: <T>(key: string) => Promise<T | null>;
  cacheSet: (key: string, value: any) => Promise<void>;
}

🧠 Why?
To inject global access to state across components using React’s context.

🌐 10. Provider Component

export const StateProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [preferences, setPreferences] = useState<UserPreferences | null>(null);
  const stateManager = StateManager.getInstance();

💡 What’s happening?
Initializes state
Grabs singleton
On mount (useEffect), loads preferences:

useEffect(() => {
  stateManager.loadPreferences().then(setPreferences);
}, []);

🔄 11. Update + Recent Files

const updatePreferences = async (prefs: UserPreferences) => {
  await stateManager.updatePreferences(prefs);
  setPreferences(prefs);
};
const addRecentFile = async (path: string) => {
  await stateManager.addRecentFile(path);
  if (preferences) {
    setPreferences({
      ...preferences,
      recentFiles: [path, ...preferences.recentFiles.filter(f => f !== path)].slice(0, 10)
    });
  }
};

Reconciles local UI state with backend state.

🌐 12. Providing Context

<StateContext.Provider value={{
  preferences,
  updatePreferences,
  addRecentFile,
  cacheGet: stateManager.cacheGet.bind(stateManager),
  cacheSet: stateManager.cacheSet.bind(stateManager)
}}>
  {children}
</StateContext.Provider>`
Passes down the actions and current state via context to the whole app.

🧠 13. Hook for Consumers
`export const useAppState = () => {
  const context = useContext(StateContext);
  if (!context) {
    throw new Error('useAppState must be used within StateProvider');
  }
  return context;
};

💡 What’s this?
A simple hook for any component to access the global state safely.

Reference :

Handling File Dialogs
File System Plugin
Tauri 2.0 | Tauri

Stay tuned for next episode for the rest. In between subscribe us in medium and subsctack and follow us on youtube

Tauri #DesktopApps #FileManagement #FileSystem #OpenSource #JavaScript #NativeDialogs #CrossPlatform

Quantum Compiting Slides

uknowWho — Sun, 02 Feb 2025 12:12:44 +0000

Check out this Pen I made!

Deref Coercion: Rust’s Polite Butler

uknowWho — Mon, 30 Dec 2024 21:48:44 +0000

Imagine you’re hosting a fancy dinner. You’re a bit lazy (understandable), and instead of grabbing the plates yourself, you shout to your butler, Rust:

“Hey, Rust! Could you pass me the lasagna in that weird silver box?”

Rust doesn’t even blink. He doesn’t say, “You need to first open the box to get to the lasagna!” Nope. Rust just opens the box and hands you the lasagna because that’s how Deref coercion works.

Example 1: The Simple Case
Rust’s deref coercion is essentially about peeling the layers off. Let’s look at this example:

struct MyBox<T>(Box<T>);
impl<T> Deref for MyBox<T> {
    type Target = T;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}
// Usage
let x = MyBox(Box::new(5));
let y = &x;  // type: &MyBox<i32>
let z = &*x; // type: &i32

Here’s what happens:

You’ve got a MyBox – it’s a wrapper around Rust’s built-in Box, which in turn holds the value 5. You want to use the value inside MyBox like you’d use an i32. Instead of unwrapping layer by layer, you just say, “Hey Rust, make this work.”
Rust complies, invoking deref() under the hood.

Real World Analogy: The Gift Box

Think of MyBox as a fancy box wrapped with shiny paper. Inside is a gift (like an integer). With deref coercion, you don’t need to fumble with unwrapping or scissors – Rust automagically reveals the gift when you ask for it.

Without deref coercion, you’d feel like a kid on Christmas with no nails and no scissors — awkward and frustrated.

Why Deref Coercion Matters: Saving Mental Energy
Without deref coercion, you’d write something clunky:

let s = String::from("hello");
takes_str(&(*s)[..]);
(*s) means, “Dereference the String.”
[..] converts it to a &str.
With deref coercion, it’s just:

takes_str(&s);

Rust says, “Don’t worry, I know what you mean!” and handles it behind the scenes.

Rust is like that smart friend who completes your sentences, but without being annoying.

Example 2: Chaining Coercions

Rust can peel multiple layers like an onion. Take this:

fn takes_str(s: &str) {}
let text = Rc::new(String::from("hello"));
takes_str(&text); // Coerces: &Rc<String> -> &String -> &str
Here’s what happens:

Rc is a smart pointer wrapping a String.
The compiler goes, “Hmm, the function wants a &str. Let me help.”

Rust uses Deref twice:

First, &Rc becomes &String.
Then, &String becomes &str.

Mutable Deref: The Hulk Smash Moment
Sometimes, you don’t just want to look at the value inside a smart pointer. You want to change it.

Enter DerefMut:

pub trait DerefMut: Deref {
    fn deref_mut(&mut self) -> &mut Self::Target;
}
// Example
let mut boxed = Box::new(5);
*boxed = 6; // Uses DerefMut

Here, boxed isn’t a metaphorical Hulk Smash—it’s an actual mutation. Rust allows it because Box implements DerefMut, saying, *“Fine, you can mutate the value inside me, but be careful.”**

Rust’s DerefMut: Like Hulk, but it won’t smash the town unless you ask nicely (and it’s type-safe).

Performance Intuition
The best part? Deref coercion is zero-cost at runtime. It’s all resolved during compile time. So when you ask Rust to deref for you, it’s like telling your butler to prep the lasagna before the guests arrive.

Advanced Intuition: Composability
Imagine a Matryoshka doll:
The outer layer is an Rc.
Inside, you find a String.
Deeper still, you uncover a &str.
With deref coercion, Rust peels these layers seamlessly, like a magician pulling a never-ending scarf from a hat.

“Ta-da! And now, it’s a &str! Magic!” ✨

Implementation Mechanics:
Behind the Curtains Rust doesn’t rely on magic; it uses the Deref trait:

pub trait Deref {
    type Target;
    fn deref(&self) -> &Self::Target;
}

The Target type defines what the pointer “unwraps” to.
The deref function does the actual unwrapping.
When you use *pointer or pass a pointer to a function expecting its Target type, Rust calls deref() behind the scenes.

Think of Deref as Rust’s backstage crew. They’re silent, invisible, but crucial for a flawless performance.

Why This Design?
Ergonomics: You don’t have to worry about unwrapping layers manually.
Safety: Rust guarantees all coercions are type-safe.
Flexibility: You can implement Deref for your custom types to make them behave intuitively.
Benefits
Reduces boilerplate code by eliminating explicit dereferencing
Improves code readability by handling conversions automatically
Enables flexible API design where functions can accept multiple reference types
Reference

In essence, Rust’s deref coercion is a powerful mechanism that automatically traverses a chain of references, elegantly converting from one type to another through the Deref trait, allowing smart pointers like Box, Rc, and Arc to behave transparently like the data they wrap while maintaining memory safety and zero-cost abstractions. To end it with a joke :

Deref coercion is like autocorrect: It fixes your mistakes. But unlike autocorrect, it doesn’t turn your “String” into “Sting.”

SmartPointers #RustPatterns #RustLang #RustProgramming #RustDev #ZeroCost #CodeDesign

Glam Up My Markup: Winter Solstice Submission

uknowWho — Wed, 18 Dec 2024 19:22:32 +0000

This is a submission for Frontend Challenge - December Edition, Glam Up My Markup: Winter Solstice

What I Built

This project is a dynamic and visually engaging landing page titled "Winter Solstice: Celestial Rhythms", celebrating the winter solstice and its global significance. The page is crafted with a focus on:

Adaptive design: A light and dark mode that responds to the user's system preferences.

Interactive content: A custom-built canvas-based solstice visualization.

Accessibility: Enhanced keyboard focus styles and thoughtful tooltip interactions.

Global storytelling: Sections highlight solstice-related science, traditions, and cultural celebrations worldwide.

My goal was to create a landing page that blends aesthetic appeal, educational content, and seamless user interaction.

Demo
Here’s the live demo: Winter Solstice: Celestial Rhythms
👉

Screenshots:

Desktop Dark Mode:

Mobile Light Mode:

Journey Process

I approached this challenge with a focus on both aesthetics and functionality. My process involved:

Designing the structure: Starting with semantic HTML for clarity and accessibility.

Theming: Utilizing CSS custom properties (--variables) to implement a responsive, adaptive color palette.

Dynamic interactions: Adding hover effects and a smooth animation for the solstice visualization using the element.

Responsive design: Ensuring the layout adapts elegantly to various screen sizes.

Enhancing accessibility: Including tooltips, focus-visible styles, and keyboard-friendly navigation.
What I Learned

How to create a dynamic visualization using the API.
Advanced usage of CSS custom properties for theming and light/dark mode adaptations.
Techniques for building accessible tooltips and smooth-scroll navigation.

Proud Moments

The solstice visualization: Animating Earth's orbit and tilt in real-time gave life to the page.

Accessibility improvements: The project is not only visually appealing but also keyboard and screen-reader-friendly.

Next Steps

Expand interactivity: Add more celestial events to the visualization (e.g., equinoxes).

Localization: Translate content into multiple languages for broader accessibility.

Open collaboration: Make this project open source for contributions and education.

Generative AI Reloaded Ensuring security in your Website: A Journey of Security and Vulnerability

uknowWho — Thu, 12 Dec 2024 14:15:03 +0000

When you're building something on the web, like a portfolio or any project, you want to make sure nobody can break in or mess with it. Think of your portfolio like a little house on the internet. You want it to look nice, but you also want to keep out burglars, vandals, and unwanted guests. So, let’s go through some smart security measures we can use to protect our “house.”

1. Content Security Policy (CSP) – The Bouncer at the Door
Imagine your portfolio is a nightclub. You’ve got a cool design, some music, and everything looks great. But, you don’t want just anyone walking in off the street. You want to make sure only trusted people and services are allowed in.

Content Security Policy (CSP) is like a bouncer at the door. The bouncer checks the guest list and says, "Hey, you're on the list, you can come in. But if you’re not on the list, you’re staying out."

In the code, CSP looks like this:

<meta http-equiv="Content-Security-Policy" content="default-src 'self' https://fonts.googleapis.com; style-src 'self' 'unsafe-inline';">
Here’s what it does:`

default-src 'self': The bouncer says, "Only resources from the same place your website is hosted are allowed in." So, if your website is on example.com, it won't allow anything from outside unless you specifically say so.

https://fonts.googleapis.com: You’re saying, "Okay, it's cool for fonts to come from Google’s font library." Fonts are like your club’s music—necessary for the vibe, but you don’t want any random tunes being played.

style-src 'self' 'unsafe-inline': This allows stylesheets to come from your website, and lets you use inline styles (like personal decorations), even though this could technically be dangerous. Sometimes, though, it's necessary, like having a DJ play live music.

Why is CSP Important?
Just like your club needs a bouncer to keep unwanted people out, CSP helps to stop bad things (like malicious scripts or hacks) from getting into your website.

2. X-Frame-Options – Preventing Sneaky Tricks
Now, let’s say someone from another club decides to try and fool your customers into clicking on something they didn’t mean to. They could put your website inside a frame on their website and trick people into thinking they’re clicking on something safe when, in reality, they’re not.

X-Frame-Options is like a bouncer who says, "Nope! You can’t set up a trick frame with my club." In technical terms:

<meta http-equiv="X-Frame-Options" content="DENY">
DENY: This means "no one can display my site inside an iframe on their site, ever!" It’s like saying, “Nobody can pretend to be me.”

Why is it Important?
This is protection against clickjacking, where sneaky people try to fool your website’s visitors into clicking on the wrong things. With DENY, no one can put your website in a frame and trick users into making mistakes.

3. X-Content-Type-Options – Keeping Things in Order
Okay, imagine you’re making a cake for a party, and you’ve got all sorts of ingredients like flour, sugar, and eggs. If someone swaps out your ingredients with something like, say, dirt or paint, that’s not going to be good.

MIME sniffing is like the ingredients check. Sometimes, browsers try to figure out the content type of a file by looking inside it. But sometimes that can be dangerous, because a file might look like an image, but really be a script that can cause trouble.

X-Content-Type-Options is like telling the browser, "Just trust the label on the package. If it says it's an image, treat it like an image, not a hidden script."

In the code:

<meta http-equiv="X-Content-Type-Options" content="nosniff">

nosniff: This tells the browser not to guess what a file might be. If a file says it’s an image, treat it like an image—no questions asked.

Why is it Important?
This prevents attackers from uploading a file that might seem harmless (like an image), but actually contains malicious code. It forces the browser to follow the rules, keeping everything in order.

4. Input and Output Sanitization – Cleaning Up the Mess
Now, imagine a guest walks into your club and says, **“Hey, I want to bring in my own drink.” **But instead of a nice bottle of water, they sneak in something dangerous, like a bottle of firecracker fuel! That’s bad for everyone.

Input sanitization is like a security guard who checks what people are trying to bring in. They’ll make sure that nothing dangerous can slip through. If someone tries to bring in something suspicious, it gets tossed out.

Code Example

`
function sanitizeInput(input) {
return input.replace(/[<>]/g, '').slice(0, 100); // Only allow safe characters and limit the input length
}

function sanitizeOutput(output) {
if (typeof output !== 'string') return '';
return output.replace(/<(?!\/?(a|p|ul|li)\b)[^>]+>/gi, ''); // Strip away any dangerous HTML
}
`

sanitizeInput: This removes anything potentially harmful, like < or >, which could be used for malicious purposes (like injecting a harmful script). It also limits the input length to prevent overloads.

- sanitizeOutput:
**This makes sure that any data you send back to the page (like messages or results) doesn’t contain dangerous tags that could cause harm.`

Why is Sanitization Important?

Just like how we don’t want anyone sneaking in dangerous drinks, we don’t want dangerous input from users that could break our site or steal data. Sanitization ensures everything stays safe, clean, and proper.

5. Rate Limiting – Keeping Things Under Control

Now, imagine if too many people tried to get into the club all at once. The line would get too long, and the whole event would become a mess. That’s where rate limiting comes in. It’s like having a bouncer who only lets a few people in at a time, preventing overcrowding.

Here’s how the code does it:


const rateLimiter = {
  lastCommand: 0,
  minDelay: 500, // milliseconds
  check: function() {
    const now = Date.now();
    if (now - this.lastCommand < this.minDelay) return false; // Don’t let them in too quickly
    this.lastCommand = now;
    return true;
  }
};

lastCommand: Tracks when the last request was made.

minDelay: This ensures that there’s a 500ms gap between each command. It’s like saying, “No rushing! Wait for your turn.”

Why is Rate Limiting Important?
Rate limiting helps stop people from overloading your site with too many requests. It’s a simple way to prevent Denial-of-Service (DoS) attacks, where someone tries to bring down your site by flooding it with requests.

Conclusion – Keeping Your Website Safe, Like a Well-Run Club
All these security measures are like the precautions you’d take to keep your club safe, fun, and enjoyable for everyone. You’ve got your bouncer at the door (CSP), your anti-sneaky tricks measures (X-Frame-Options), your ingredient-checking system (MIME sniffing), your cleaning staff (input/output sanitization), and your line controller (rate limiting). With these measures in place, your website is a safe and welcoming place for everyone, no matter what.

So, next time you're creating a web project, think of these measures like your club’s safety rules. And remember: a well-secured site is a happy site!

Check my medium and substack for more : https://www.medium.com/@md.abir1203 /

SoftwareDevelopment #Webdev #GenerativeAI #Websecurity #Vulnerability #BugBounties

Gen AI Sheniagans : Prompt Engineering with Principles

uknowWho — Tue, 13 Feb 2024 10:52:12 +0000

In our rapidly changing world, the use of Generative AI is increasing daily. As an advocate for open-source technology and making learning accessible to all, I am eager to share the methods and principles I employ daily to create effective prompts. These strategies are designed to simplify and streamline your workflow process..

Before jumping into conclusions let’s get into the definition of Prompt Engineering and Thinking Principles that could be leveraged with any Large Language Models like gpt4/bard/opensource large language models.

Prompt Engineering

Prompt Engineering involves crafting precise questions or commands for AI models like GPT-4, BARD, or open-source alternatives to elicit specific, helpful responses. It enhances your interaction with AI for tasks such as email composition, content creation, or information retrieval.

GPT-4 Output

Bard / Gemini Output

From the above we can see both of the principles when adopted to create a low code platform gives a step by step understanding and process. It also give a person on what to work on and how to expand their mind. Feel free to write in the comments what prompts have you used to get better output.

For further collaborative projects feel free to connect to me in linkedin

Work Cited :

[[ Prompt Engineering ]]
[[ Prompting Guide ]]

42born2code #growthmindset #learningbydoing #firstprinciple #SoftwareEngineering