Spcnet.it

2026-05-12 15:14:00

.NET Aspire 13.3: tutte le novità della release

.NET Aspire 13.3 è disponibile, e nonostante siano passate soltanto cinque settimane dalla versione 13.2, questa release porta con sé novità di rilievo: un nuovo skill per l’onboarding assistito da agente, risultati strutturati dai comandi delle risorse, log del browser direttamente nell’orchestratore, e — finalmente — supporto di prima classe a Kubernetes e AKS tramite Helm.

In questo articolo analizziamo le funzionalità più importanti di Aspire 13.3, con esempi pratici per i team che già usano Aspire in produzione o che vogliono iniziare.

Aspireify: onboarding assistito da agente

Una delle novità più interessanti di Aspire 13.3 è il nuovo skill Aspireify, pensato per semplificare l’integrazione di applicazioni esistenti in Aspire. Chi ha già seguito le sessioni AspiriFridays sa bene quanto possa essere laborioso il processo di “aspirificazione”: capire quali servizi sono presenti, quali porte usano, quali variabili d’ambiente sono dipendenze reali e come mappare i servizi Docker Compose verso le integrazioni Aspire native.

Il nuovo skill risolve esattamente questo problema. Quando aspire init crea lo scheletro dell’AppHost in un’applicazione esistente, Aspireify guida l’agente di coding attraverso un workflow strutturato per completare il lavoro:

• Ispeziona il repository e comprende come l’applicazione è già strutturata
• Mappa le configurazioni esistenti (es. DATABASE_URL) usando WithEnvironment() invece di riscrivere la configurazione
• Preserva le porte hardcoded quando necessario, chiedendo all’utente nei casi ambigui
• Se esiste già un Docker Compose, lo analizza prima di aggiungere nuove risorse

Il principio guida è chiaro: minimizzare le modifiche al codice esistente. L’agente si adatta all’applicazione, non viceversa.

Risultati strutturati dai comandi delle risorse

In Aspire 13.3, i comandi delle risorse possono restituire risultati strutturati al chiamante. Testo e JSON ora fluiscono attraverso il modello, gRPC, backchannel, UI del dashboard, CLI e strumenti MCP.

Questo significa che i comandi possono restituire risposte in markdown formattato — non solo “sì, è andato a buon fine”. Il dashboard integra tutto questo con un nuovo notification center nell’header, dove i risultati dell’esecuzione appaiono come notifiche con timestamp, rendering markdown e un’azione “View response” per l’output completo.

Tra le novità specifiche:

• I comandi HTTP possono restituire il corpo della risposta, esposto via CLI, dashboard e SDK poliglotti generati
• Il comando di rebuild delle risorse restituisce l’output del build come dati di testo strutturati, leggibili da strumenti e agenti senza dover fare scraping dei log
• Le integrazioni di terze parti possono aggiungere comandi che restituiscono risultati significativi invece di cambiare solo stato in background

Browser logs: Aspire vede anche il frontend

La nuova API WithBrowserLogs() collega una risorsa browser tracciata a qualsiasi risorsa con un endpoint. Aspire avvia Chromium usando una pipe CDP privata (invece di un endpoint TCP debug esposto), poi trasmette log della console, richieste di rete ed errori nel log stream della risorsa:

// C# AppHost
var frontend = builder.AddViteApp("frontend", "../frontend")
    .WithHttpEndpoint(port: 3000)
    .WithBrowserLogs();

// TypeScript AppHost
const frontend = await builder.addViteApp("frontend", "../frontend")
    .withHttpEndpoint({ port: 3000 })
    .withBrowserLogs();

La funzionalità è disponibile tramite il nuovo pacchetto prerelease Aspire.Hosting.Browsers. Un comando del dashboard permette di configurare scope, browser e modalità user data a runtime, mentre un comando screenshot salva PNG come artefatti locali durevoli.

Dal punto di vista degli agent workflow, questo è particolarmente potente: l’agente può eseguire l’app, ispezionare i log del browser, catturare cosa è cambiato, correggere il codice, riavviare la risorsa e continuare — senza che lo sviluppatore debba incollare screenshot nella chat.

TypeScript, Python e Java AppHost verso la GA

Aspire 13.2 aveva introdotto l’authoring TypeScript AppHost. In 13.3, il lavoro continua su tutte e tre le piattaforme:

• TypeScript, Python e Java AppHost espongono ora il set completo di extension method di Aspire.Hosting
• Le API sono state rese più idiomatiche per ogni linguaggio: metodi come addProject, withEnvironment e withReference sono consolidati per leggere naturalmente
• Python si aggiunge come nuovo generatore di codice AppHost
• Java AppHost ora supporta union, optional/nullability, callback e un nuovo template “Empty (Java AppHost)”
• Il nuovo diagnostico ASPIREEXPORT013 individua ID di capability duplicati a compile time

Kubernetes e AKS: finalmente supporto di prima classe

La novità più attesa della release è senza dubbio il supporto Kubernetes come deployment target di prima classe. Aspire aveva già un’ottima storia per Azure Container Apps e Docker Compose; ora Kubernetes entra nel club.

Il nuovo pacchetto Aspire.Hosting.Azure.Kubernetes aggiunge AddAzureKubernetesEnvironment(), con cui è possibile definire cluster AKS, node pool, tier SKU, cluster privati e Azure Container Insights direttamente dall’AppHost:

// C# AppHost
var aks = builder.AddAzureKubernetesEnvironment("prod-aks")
    .WithHelm();

builder.AddCSharpApp("api", "../api")
    .PublishTo(aks);

// TypeScript AppHost
const aks = await builder.addAzureKubernetesEnvironment("prod-aks")
    .withHelm();

await builder.addCsharpApp("api", "../api")
    .publishTo(aks);

aspire deploy usa Helm sotto il cofano, e il nome del namespace e della release sono configurabili con WithHelm(). Sono disponibili anche routing dichiarativo Ingress e Gateway API con AddIngress() e AddGateway(), inclusa configurazione di route, TLS, hostname e class. Per il teardown, aspire destroy esegue helm uninstall automaticamente — niente più script di pulizia manuali in un README.

Altre novità rilevanti

Aspire 13.3 include molte altre migliorie degne di nota:

• EF Core migration management: sei comandi (Update Database, Drop Database, Reset Database, Add Migration, Remove Migration, Get Database Status) accessibili da dashboard e CLI, con esecuzione automatica all’avvio dell’AppHost in sviluppo locale
• Azure networking: Azure Front Door, Network Security Perimeters, endpoint privati per Azure OpenAI e Foundry, ACR privato, e upgrade HTTPS automatici per App Service
• JavaScript publishing: tre nuovi modelli di pubblicazione — PublishAsStaticWebsite(), PublishAsNodeServer() e PublishAsNpmScript() — con integrazione dedicata AddNextJsApp()
• CLI: rilevamento automatico di Bun, Yarn e pnpm da lockfile; aspire dashboard standalone senza AppHost; aspire docs api per sfogliare la reference API dal terminale
• Estensione VS Code: CodeLens e gutter icon nei file AppHost, Simple Browser integrato per il dashboard, workspace auto-restore
• Docker Compose: supporto Podman tramite rilevamento automatico del runtime

Breaking changes da conoscere prima dell’aggiornamento

Prima di aggiornare, è importante verificare la sezione dei breaking changes ufficiale se si usano:

• Startup hook Kubernetes/Docker Compose/AKS
• Endpoint di gestione degli emulator
• Il server MCP del dashboard
• Il template starter Python
• Output name di Azure network

Come aggiornare

Se si usa già Aspire, l’aggiornamento è semplice:

aspire update --self

Per chi parte da zero:

aspire init

oppure visitare get.aspire.dev per installare la CLI.

Conclusione

Aspire 13.3 consolida la piattaforma su tutti i fronti: l’onboarding diventa più semplice grazie ad Aspireify, l’osservabilità raggiunge il browser con WithBrowserLogs(), il supporto multi-linguaggio avanza verso la GA, e Kubernetes entra ufficialmente come target di deployment. Per i team .NET che operano su Kubernetes o AKS, questa è probabilmente la release più attesa degli ultimi mesi.

Fonte: What’s New in Aspire 13.3 — Maddy Montaquila, Microsoft Aspire Blog (7 maggio 2026)

What's New in Aspire 13.3

Aspire 13.3 is here with the Aspireify skill, command results, browser logs, Kubernetes and AKS deployment, and more.

^{Maddy Montaquila (Aspire Blog)}

Spcnet.it

2026-05-12 14:33:48

MCP Server con Node.js: da un sistema di note su file a MySQL

Cos’è il Model Context Protocol e perché interessa ai developer Node.js

I modelli di linguaggio sono bravi a ragionare e conversare, ma da soli non possono eseguire operazioni reali sui tuoi sistemi. Possono suggerire query SQL o chiamate API, ma non possono farle girare concretamente. Il Model Context Protocol (MCP) risolve questo limite: fornisce ai modelli AI un modo strutturato per interagire con i tuoi strumenti, dai database ai file, fino alle API esterne. Invece di generare testo su ciò che dovrebbe accadere, il modello può invocare funzioni che lo fanno davvero accadere.

In pratica, questo apre la strada a strumenti come chatbot che creano e cercano voci nel database, assistenti AI che interrogano tool interni o attivano workflow, e agenti che leggono file, eseguono comandi e restituiscono risultati reali.

In questo tutorial imparerai a costruire il tuo primo MCP server da zero con Node.js e TypeScript: partiremo da un sistema di note basato su file per capire i concetti fondamentali, poi passeremo a un backend MySQL per mostrare come un LLM possa guidare operazioni deterministiche. Entro la fine avrai un server MCP funzionante pronto per essere collegato al client AI che preferisci.

Come funziona MCP

MCP segue un modello client-server: l’applicazione AI fa da client, il tuo codice gira come server. In una configurazione tipica, il client (Claude Desktop, Claude Code, Cursor, ecc.) si interpone tra l’utente e il tuo server, inoltrandogli le richieste e restituendogli i risultati. Il modello stesso non chiama mai direttamente il tuo server: quando l’utente manda un messaggio, il client condivide col modello la lista dei tool esposti dal tuo server. Il modello decide quale tool chiamare (e con quali argomenti), il client esegue la chiamata e rimanda il risultato al modello.

Utente → Client MCP → Modello AI → Tool selezionato → Server MCP → Risposta

Prerequisiti

Per seguire questo tutorial ti serviranno:

• Node.js 18+
• Familiarità di base con TypeScript
• Un client compatibile con MCP per il test (Claude Desktop, Claude Code, Cursor, ecc.)
• MySQL installato localmente (solo per la sezione avanzata con database)

Costruire il server MCP: sistema di note su file

Iniziamo creando un nuovo progetto Node.js. Questo sarà un sistema di note basato su file, utile per comprendere i concetti prima di introdurre un database.

mkdir mcp-notes && cd mcp-notes
npm init -y

Installa le dipendenze necessarie: l’SDK MCP per costruire il server, Zod per la validazione degli input e TypeScript per la type safety:

npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

Apri il package.json e aggiungi "type": "module" (l’SDK MCP usa i moduli ES) e gli script di build e start:

{
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

Crea un file tsconfig.json nella root del progetto:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Scrivere il server

Crea il file src/index.ts con il codice base del server:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import fs from "fs/promises";
import path from "path";
import { z } from "zod";

const NOTES_DIR = path.join(process.cwd(), "notes");
await fs.mkdir(NOTES_DIR, { recursive: true });

const server = new McpServer({
  name: "mcp-notes",
  version: "1.0.0",
});

// I tool verranno aggiunti qui

const transport = new StdioServerTransport();
await server.connect(transport);

Questo è un MCP server completo e funzionante: crea la directory delle note, inizializza il server e lo connette tramite stdio per comunicare con un client MCP.

Aggiungere i tool

Ogni tool definisce una singola azione che il modello può compiere. Include nome, descrizione, schema di input e una funzione handler. Aggiungiamo i tre tool fondamentali: creazione, lettura e lista delle note.

server.tool(
  "create_note",
  "Create a new note with a given title and content",
  {
    title: z.string().min(1).describe("The note title"),
    content: z.string().min(1).describe("The body of the note"),
  },
  async ({ title, content }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    const filepath = path.join(NOTES_DIR, filename);
    try {
      await fs.access(filepath);
      return {
        content: [{ type: "text", text: `Error: note "${title}" already exists.` }],
        isError: true,
      };
    } catch {}
    await fs.writeFile(filepath, content, "utf-8");
    return { content: [{ type: "text", text: `Note "${title}" created.` }] };
  }
);

server.tool(
  "read_note",
  "Read the content of a note by its title",
  { title: z.string().min(1).describe("The title of the note to read") },
  async ({ title }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    try {
      const content = await fs.readFile(path.join(NOTES_DIR, filename), "utf-8");
      return { content: [{ type: "text", text: content }] };
    } catch {
      return {
        content: [{ type: "text", text: `Error: note "${title}" not found.` }],
        isError: true,
      };
    }
  }
);

server.tool(
  "list_notes",
  "List all available notes",
  {},
  async () => {
    const files = await fs.readdir(NOTES_DIR);
    const notes = files.filter(f => f.endsWith(".txt")).map(f => f.replace(".txt", ""));
    if (notes.length === 0) return { content: [{ type: "text", text: "No notes found." }] };
    return { content: [{ type: "text", text: notes.join("\n") }] };
  }
);

Testare il server con Claude Desktop

Compila il progetto con npm run build. Poi apri il file di configurazione di Claude Desktop:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Aggiungi il server sotto la chiave mcpServers:

{
  "mcpServers": {
    "mcp-notes": {
      "command": "node",
      "args": ["/percorso/del/progetto/mcp-notes/dist/index.js"],
      "cwd": "/percorso/del/progetto/mcp-notes"
    }
  }
}

Riavvia Claude Desktop e prova con prompt come: “Crea una nota chiamata standup con gli aggiornamenti di oggi” oppure “Elenca tutte le mie note”.

Passare a MySQL: dati strutturati per uso reale

Il sistema basato su file funziona bene per comprendere i fondamentali, ma ha limiti evidenti. Passare a MySQL mette in luce un pattern importante nel design MCP: il modello decide quale azione intraprendere, ma il tuo codice rimane responsabile di come quella azione viene eseguita. Quando il modello chiama search_notes, non genera né esegue SQL da solo: il tuo handler gestisce l’operazione in modo controllato, con query parametrizzate.

Installa il driver MySQL:

npm install mysql2

Crea il database e la tabella:

CREATE DATABASE mcp_notes;
USE mcp_notes;
CREATE TABLE notes (
  id INT AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(255) UNIQUE NOT NULL,
  content TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

La versione MySQL del tool create_note inserisce una riga invece di scrivere un file e gestisce i duplicati intercettando l’errore ER_DUP_ENTRY. La versione di search_notes permette ricerche full-text su titoli e contenuti — una funzionalità che con i file richiederebbe un codice molto più complesso.

server.tool(
  "search_notes",
  "Search notes by keyword across titles and content",
  { query: z.string().min(1).describe("Keyword or phrase to search for") },
  async ({ query }) => {
    const like = `%${query}%`;
    const [rows] = await pool.execute<mysql.RowDataPacket[]>(
      "SELECT title, created_at FROM notes WHERE title LIKE ? OR content LIKE ? ORDER BY created_at DESC",
      [like, like]
    );
    if (rows.length === 0) {
      return { content: [{ type: "text", text: `No notes found matching "${query}".` }] };
    }
    return { content: [{ type: "text", text: rows.map(r => `- ${r.title} (${r.created_at})`).join("\n") }] };
  }
);

Principi per progettare buoni tool MCP

Un tool MCP che funziona in fase di test può fallire in produzione se il modello fraintende quando o come usarlo. Alcune regole pratiche:

• Descrizioni esplicite: frasi come “Gestisce le note” sono troppo vaghe. Usa descrizioni che spiegano chiaramente cosa fa il tool e quando va usato.
• Singola responsabilità: ogni tool deve fare una sola cosa. Strumenti troppo “jolly” costringono il modello a indovinare l’intento.
• Errori azionabili: usa isError: true con messaggi che guidano il modello su come riprovare: "Note non trovata. Usa list_notes per vedere quelle disponibili."
• Boundary sicuri: mai interpolazione diretta dell’input utente in SQL o comandi shell. Usa sempre query parametrizzate.

Conclusione

Costruire un MCP server con Node.js e TypeScript è sorprendentemente accessibile grazie all’SDK ufficiale. Il pattern che hai imparato in questo tutorial — definire tool con schema Zod, gestire gli errori con isError e connettere il server via stdio — si scala facilmente a scenari più complessi: integrazione di API REST, automazione di workflow, connessione di agenti AI a sistemi legacy.

Il codice completo del tutorial è disponibile su GitHub.

Fonte: How to build your first MCP server with Node.js — LogRocket Blog (Elijah Asaolu, 5 maggio 2026)

How to build your first MCP server with Node.js - LogRocket Blog

Learn how to build an MCP server with Node.js, from a simple file-based setup to a MySQL-backed system for real-world AI tool integration.

^{Elijah Asaolu (LogRocket Blog)}

(in)sicurezza digitale

2026-05-12 14:32:22

Il primo zero-day costruito con l’AI: Google sventava un attacco di massa con exploit generato da LLM

Si parla di:
Toggle

Per la prima volta nella storia documentata della cybersecurity, un gruppo criminale ha utilizzato un modello di intelligenza artificiale per identificare una vulnerabilità zero-day sconosciuta e trasformarla in un exploit funzionante, pianificando di impiegarla in un evento di compromissione di massa. Google Threat Intelligence Group (GTIG) ha svelato la scoperta l’11 maggio 2026, descrivendo quella che potrebbe essere un punto di svolta nell’evoluzione delle capacità offensive dei threat actor.

La scoperta: un exploit scritto da un LLM

Il team GTIG di Google ha identificato uno script Python contenente un exploit per una vulnerabilità zero-day in un popolare strumento open source di amministrazione web. La falla, un bypass dell’autenticazione a due fattori (2FA), permetteva a un attaccante in possesso di credenziali valide di aggirare completamente il secondo fattore di autenticazione, aprendo la strada a un accesso non autorizzato su larga scala.

Ciò che ha immediatamente attirato l’attenzione degli analisti non era tanto la vulnerabilità in sé, quanto le caratteristiche stilistiche e strutturali del codice che la implementava. Lo script presentava una serie di indizi inequivocabili della sua origine artificiale:

• Docstring educativi estremamente dettagliati: ogni funzione era accompagnata da commenti esplicativi esaustivi, in uno stile tipico degli output di Large Language Model addestrati su repository di codice open source e documentazione tecnica.
• Un punteggio CVSS “allucinato”: lo script includeva una valutazione CVSS autogenerata ma non corrispondente a nessuna voce esistente nel National Vulnerability Database — un errore tipico di un modello che genera informazioni plausibili ma non verificate.
• Formato Pythonic “da manuale”: la struttura pulita, la classe _C per i colori ANSI, i menu di aiuto dettagliati e la coerenza stilistica riflettono il pattern caratteristico degli output di modelli come GPT-4 o Gemini quando invitati a scrivere strumenti di sicurezza.

GTIG ha valutato con alta confidenza che un modello di AI sia stato utilizzato sia per scoprire la vulnerabilità che per costruire l’exploit, pur non avendo prove che il modello specifico impiegato fosse Gemini di Google.

La natura della vulnerabilità: logica semantica, non memoria

Uno degli aspetti più rilevanti della scoperta riguarda la tipologia della vulnerabilità stessa. Non si trattava di un classico bug di memory corruption (buffer overflow, use-after-free) né di un problema di input sanitization — le categorie che i fuzzer tradizionali e gli strumenti SAST (Static Application Security Testing) sono progettati per individuare.

La falla era invece un difetto logico semantico ad alto livello: un’assunzione di trust codificata nella logica di enforcement del 2FA, che permetteva a un flusso di autenticazione specifico di saltare la verifica del secondo fattore. Questo tipo di vulnerabilità richiede una comprensione profonda della logica applicativa e dei suoi presupposti impliciti — un dominio in cui i modelli di linguaggio di grandi dimensioni, addestrati su enormi corpus di codice e documentazione, mostrano capacità emergenti superiori agli strumenti di analisi statica convenzionali.

La scoperta conferma ciò che molti ricercatori ipotizzavano ma temevano di veder concretizzato: i modelli AI possono identificare classi di vulnerabilità che sfuggono sistematicamente agli strumenti automatizzati tradizionali.

L’evento pianificato: compromissione di massa sventata

Secondo GTIG, il threat actor aveva pianificato di utilizzare l’exploit in un mass exploitation event — un attacco opportunistico su larga scala verso tutti i sistemi vulnerabili esposti su internet. La proactive discovery da parte di Google ha permesso di interrompere la catena prima che l’exploit venisse utilizzato in produzione.

Google ha lavorato con il vendor del software colpito per la divulgazione responsabile della vulnerabilità e il rilascio di una patch correttiva, senza rivelare pubblicamente il nome dello strumento interessato per limitare il rischio di sfruttamento da parte di altri attori durante la finestra di patching.

Il quadro più ampio: AI e cybercrime state-sponsored

L’incidente non è isolato: il report GTIG del maggio 2026 documenta una tendenza sistematica all’adozione di strumenti AI da parte di gruppi APT nation-state. In particolare:

• Cina: operatori state-linked stanno sperimentando sistemi AI per la vulnerability hunting automatizzata e il probing di target — essenzialmente automatizzando il processo di ricognizione e identificazione delle superfici di attacco.
• Corea del Nord (APT45): il gruppo sta utilizzando AI per processare migliaia di exploit check in bulk e arricchire il proprio toolkit, accelerando significativamente i tempi di sviluppo di nuove capacità offensive.
• Gruppi criminali non-state: come dimostrato da questo episodio, anche attori privi di risorse statali hanno ormai accesso a capacità di sviluppo exploit AI-assisted tramite modelli commerciali o open source.

Il democratizzazione degli strumenti AI abbassa significativamente la barriera tecnica per lo sviluppo di exploit sofisticati, storicamente appannaggio di gruppi con risorse e competenze elevate.

Due righe per i difensori

Questa scoperta accelera un dibattito che era rimasto per lungo tempo teorico: se gli attaccanti usano AI per trovare vulnerabilità, i difensori devono adottare gli stessi strumenti con ancora maggiore urgenza. Alcune considerazioni pratiche:

• Rivedere i programmi di bug bounty per includere vulnerabilità logiche e di flusso che i tool tradizionali non rilevano, premiando i ricercatori umani e AI-assisted che identificano difetti semantici.
• Implementare AI-assisted code review nel ciclo di sviluppo, in particolare per la logica di autenticazione e autorizzazione — le aree dove i difetti semantici sono più probabili e più gravi.
• Monitorare i pattern di accesso MFA con particolare attenzione ai bypass del secondo fattore, anche in presenza di credenziali valide.
• Aggiornare tempestivamente tutti gli strumenti di amministrazione web esposti su internet, indipendentemente dalla loro percezione come “strumenti minori”.

Il primo zero-day AI-generated documentato in natura non segna la fine di un’era, ma l’inizio di una nuova fase nella corsa agli armamenti digitali. Le organizzazioni che non integreranno AI nei propri processi di difesa si troveranno strutturalmente svantaggiate rispetto a avversari che già la impiegano sistematicamente per attaccare.

Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access | Google Cloud Blog

Explore GTIG's 2026 report on how adversaries leverage AI for zero-day exploits, autonomous malware, and industrial-scale cyber operations.

^{Google Threat Intelligence Group (Google Cloud Blog)}

Giulio Cavalli

2026-05-12 08:09:20

Quindici colpi contro una nave umanitaria che aveva appena soccorso novanta persone, due svenute. La motovedetta che spara è italiana: l'ha consegnata Roma a...

left.it/2026/05/12/spari-libic…

(il mio #buongiorno per @left_rivista)

Spari libici su Sea-Watch, le motovedette sono donate dall’Italia: concorso esterno anche in tentato omicidio

Quindici colpi contro una nave umanitaria che aveva appena soccorso novanta persone, due svenute. La motovedetta che spara è italiana: l’ha consegnata Roma a Tripoli col memorandum del 2017, l’…

^{Giulio Cavalli (Left)}

Destinazione Stelle

2026-05-11 07:34:51

Quiz del lunedì. A che cosa servono le manovre di “fionda gravitazionale” (gravity assist)?

Appuntameno a domani per la discussione delle risposte, non suggerite e non cercate su internet!

#QuizTime
@astronomia