informapirata

2025-02-03 19:32:00

I Gruppi del Fediverso: un modo per incontrare altri utenti Mastodon, Friendica o Pixelfed in base ai loro interessi

Il Fediverso è un luogo fatto soprattutto di interazioni sociali ma rispetto ai social commerciali non è facilissimo trovare utenti che condividano i nostri stessi interessi. Ecco come giocarsi la carta dei “Gruppi”

informapirata.it/2025/02/03/i-…

#Calabria #Campania #comunità #Fediverso #Friendica #gruppi #Lemmy #Mastodon

informapirata.it/2025/02/03/i-…

I Gruppi del Fediverso: un modo per incontrare altri utenti Mastodon, Friendica o Pixelfed in base ai loro interessi

Il Fediverso è un luogo fatto soprattutto di interazioni sociali ma rispetto ai social commerciali non è facilissimo trovare utenti che condividano i…

^{informapirata}

Spcnet.it

2026-05-14 15:55:44

SimpleChat: un template Blazor provider-agnostico per chat AI con .NET 10 Aspire

Chi sviluppa applicazioni AI in .NET lo sa bene: ogni volta che si integra un LLM in un progetto Blazor, si finisce a riscrivere lo stesso boilerplate per connettere OpenAI, Azure OpenAI, Anthropic o Google. SimpleChat è un template open-source che risolve esattamente questo problema — un’applicazione Blazor Server + .NET 10 Aspire che gestisce quattro provider AI in modo intercambiabile, esponendo un unico IChatClient all’intera applicazione.

Il progetto è disponibile su GitHub: github.com/ADefWebserver/SimpleChat

Perché esiste SimpleChat

Il problema che SimpleChat risolve è concreto: ogni provider AI ha il proprio contratto REST, le proprie intestazioni e le proprie particolarità. OpenAI usa una API key e un base URL. Azure OpenAI richiede un endpoint, un deployment name e una versione API. Anthropic ha il proprio formato di richiesta e rifiuta il parametro temperature sui modelli Claude 4 con ragionamento. Google AI (Gemini) ha ancora un’altra struttura REST sotto generativelanguage.googleapis.com.

SimpleChat risolve tutto questo costruendo su Microsoft.Extensions.AI e centralizzando la logica di creazione del client in una sola classe: ChatClientFactory. Tutto il codice upstream non deve mai sapere quale provider è attivo.

Architettura del progetto

La soluzione Aspire è composta da tre progetti:

• SimpleChat — l’app web Blazor Server
• SimpleChat.AppHost — l’orchestratore Aspire
• SimpleChat.ServiceDefaults — OpenTelemetry condiviso, health check e resilienza

I componenti principali dell’applicazione sono:

• AIConfigurationService — legge la sezione AI della configurazione e scrive le modifiche dell’utente su disco
• ChatClientFactory — l’unico posto dove l’app conosce la differenza tra i provider; restituisce un IChatClient
• ChatService — orchestratore stateless che fa streaming delle risposte dall’IChatClient attivo
• AIModelService — chiama l’endpoint /models di ogni provider, con una lista di fallback

Il modello di configurazione

Tutta la configurazione AI vive in una sezione AI di appsettings.json:

{
  "AI": {
    "ActiveProvider": "OpenAI",
    "Providers": {
      "OpenAI": {
        "Enabled": true,
        "ApiKey": "",
        "Endpoint": "https://api.openai.com/v1",
        "DefaultModel": "gpt-4o-mini",
        "Models": ["gpt-4o-mini", "gpt-4o", "gpt-5-mini", "o4-mini"]
      },
      "AzureOpenAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "",
        "DeploymentName": "",
        "ApiVersion": "2024-10-21"
      },
      "Anthropic": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://api.anthropic.com",
        "DefaultModel": "claude-sonnet-4-20250514"
      },
      "GoogleAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://generativelanguage.googleapis.com",
        "DefaultModel": "gemini-2.5-flash"
      }
    },
    "Defaults": {
      "Temperature": 0.7,
      "MaxOutputTokens": 1024,
      "SystemPrompt": "You are a helpful assistant."
    }
  }
}

Questa struttura è il contratto. Per scambiare il layer di storage (database, Key Vault, browser storage, file share), basta modificare solo AIConfigurationService — nient’altro nell’app cambia.

La ChatClientFactory: un solo posto per tutta la logica provider

La factory è il cuore del template. Dopo che questo metodo ritorna, tutto il codice downstream vede solo un IChatClient:

public (IChatClient Client, string Model) Create(string providerKey)
{
    var key = NormalizeProviderKey(providerKey);
    var settings = _config.GetProvider(key);

    if (!settings.Enabled)
        throw new InvalidOperationException($"Provider '{providerKey}' is disabled.");

    IChatClient inner;
    string model;

    switch (key)
    {
        case "OpenAI":
            model = settings.DefaultModel ?? "gpt-4o-mini";
            var openAI = new OpenAIClient(
                new ApiKeyCredential(settings.ApiKey!),
                new OpenAIClientOptions { Endpoint = ... });
            inner = openAI.GetChatClient(model).AsIChatClient();
            break;

        case "AzureOpenAI":
            model = settings.DeploymentName!;
            var azure = new AzureOpenAIClient(
                new Uri(settings.Endpoint!),
                new AzureKeyCredential(settings.ApiKey!));
            inner = azure.GetChatClient(model).AsIChatClient();
            break;

        case "Anthropic":
            model = settings.DefaultModel ?? "claude-sonnet-4-20250514";
            inner = new AnthropicChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        case "GoogleAI":
            model = settings.DefaultModel ?? "gemini-2.5-flash";
            inner = new GoogleAIChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        default:
            throw new InvalidOperationException($"Unknown provider '{providerKey}'.");
    }

    return (inner, model);
}

Per Anthropic e Google AI, SimpleChat include client personalizzati (AnthropicChatClient e GoogleAIChatClient) che adattano le rispettive REST API all’interfaccia IChatClient di Microsoft.Extensions.AI — necessari perché questi provider non hanno ancora un pacchetto MEAI ufficiale.

Streaming e configurazione runtime

ChatService.StreamAsync restituisce un IAsyncEnumerable<string> di chunk di token. L’interfaccia utente fa lo streaming degli aggiornamenti nella bolla dell’assistente man mano che arrivano, e supporta un pulsante Cancel che interrompe la chiamata in corso.

Una delle funzionalità più interessanti è il cambio di provider e modello a runtime senza riavviare l’app. Il dropdown viene popolato dall’endpoint /models live di ogni provider. Il trucco tecnico è in Program.cs:

builder.Configuration.AddJsonFile(userOverlay, optional: true, reloadOnChange: true);
// ...
builder.Services.AddOptions<AIOptions>()
    .Bind(builder.Configuration.GetSection(AIOptions.SectionName));

reloadOnChange: true fa sì che salvare il file faccia scattare IOptionsMonitor<AIOptions>.OnChange, al quale il ChatPanel è sottoscritto — così il dropdown del provider si aggiorna senza ricaricare la pagina.

Gestione sicura delle chiavi API

In Development, le modifiche alla pagina Settings vengono scritte su appsettings.Development.json. In Production vengono scritte su un file separato appsettings.User.json che viene sovrapposto ad appsettings.json all’avvio — così le chiavi reali non devono mai essere committate nel repository.

private string WritablePath => _env.IsDevelopment()
    ? Path.Combine(_env.ContentRootPath, "appsettings.Development.json")
    : Path.Combine(_env.ContentRootPath, "appsettings.User.json");

Come usarlo come template per i propri agenti AI

Il vero valore di SimpleChat non è l’applicazione in sé, ma il pattern riutilizzabile che porta con sé. Quando si inizia una nuova app, si può puntare un agente AI di coding verso questo repository con l’istruzione: “implementa la configurazione di SimpleChat, ma salva le impostazioni AI in un database (o in un file JSON, o in Azure Key Vault, o dove mi dici).” Tutta la logica di incollaggio specifica per provider è già fatta.

Il contratto è semplice: l’agente deve implementare solo AIConfigurationService per leggere e scrivere lo stesso grafo di oggetti AIOptions. Nient’altro nell’app deve cambiare.

Conclusione

SimpleChat è un punto di partenza concreto per chiunque voglia costruire applicazioni AI con Blazor e .NET 10 Aspire senza dover reinventare ogni volta la ruota dell’integrazione multi-provider. L’architettura è intenzionalmente piccola e comprensibile: un frontend Blazor Server, un servizio di configurazione, una factory che produce un IChatClient, e un orchestratore di streaming leggero sopra. Il codice è aperto e modificabile per adattarsi a qualsiasi layer di storage.

Per chi lavora regolarmente con LLM in progetti .NET, avere questo template a disposizione può fare risparmiare ore di lavoro ripetitivo ad ogni nuovo progetto.

Fonte originale: SimpleChat: A Provider-Agnostic AI Chat Starter for Blazor di Michael Washington — via Morning Dew #4664

Dew Drop – May 8, 2026 (#4664) – Morning Dew by Alvin Ashcraft

Dew Drop – May 8, 2026 (#4664)

^{Alvin A. (Morning Dew by Alvin Ashcraft)}

Spcnet.it

2026-05-14 15:54:25

LINQ in C#: guida completa alle operazioni di aggregazione (Count, Sum, MinBy, MaxBy, Aggregate)

Le operazioni di aggregazione sono tra le più frequenti in qualsiasi applicazione .NET che lavora con collezioni di dati. LINQ mette a disposizione un toolkit completo: dagli operatori di base come Count e Sum, alle più potenti MinBy/MaxBy introdotte in .NET 6, fino ad Aggregate, il fold generico che permette di sostituire loop complessi con pipeline dichiarative. In questo articolo approfondiamo ogni operatore con esempi pratici, evidenziamo le trappole di performance più comuni e mostriamo come costruire aggregazioni efficienti anche in scenari avanzati.

Il modello di dominio

Tutti gli esempi utilizzano tre record che rappresentano un sistema di ordini e vendite:

public record Order(int Id, string CustomerId, string Status, decimal Total, DateTimeOffset PlacedAt);
public record Product(int Id, string Name, string Category, decimal Price, int StockLevel);
public record SalesData(string Region, string ProductId, int UnitsSold, decimal Revenue, DateTimeOffset Period);


Count e LongCount

Count() restituisce il numero di elementi come int. La versione con predicato conta solo gli elementi che soddisfano la condizione:

IEnumerable<Order> orders = GetOrders();

int total        = orders.Count();
int pendingCount = orders.Count(o => o.Status == "Pending");
int paidCount    = orders.Count(o => o.Status == "Paid");

Console.WriteLine($"Totale: {total}, In attesa: {pendingCount}, Pagati: {paidCount}");


Per sequenze con più di int.MaxValue elementi (circa 2,1 miliardi), usare LongCount() che restituisce long. Nella pratica, questo scenario si presenta principalmente in contesti di log aggregation o telemetria su larga scala.

La trappola di performance: Count vs Any

Questo è uno degli errori di performance più diffusi con LINQ. Quando si vuole verificare l’esistenza di almeno un elemento, molti sviluppatori usano Count() > 0 invece di Any():

IEnumerable<Order> orders = GetOrders();

// ❌ Count() valuta l'intera sequenza — O(n)
if (orders.Count(o => o.Status == "Pending") > 0)
{
    Console.WriteLine("Ci sono ordini in attesa.");
}

// ✅ Any() si ferma al primo match — O(1) nel caso migliore
if (orders.Any(o => o.Status == "Pending"))
{
    Console.WriteLine("Ci sono ordini in attesa.");
}


Any(predicate) cortocircuita non appena trova il primo elemento corrispondente. Count(predicate) deve valutare ogni elemento per produrre un conteggio accurato, anche quando la risposta a “esiste almeno un elemento?” sarebbe nota immediatamente. La differenza di performance è particolarmente evidente con sorgenti lazy, query EF Core o sequenze molto lunghe.

Stesso principio per il test di sequenza vuota:

// ❌ Enumera tutta la sequenza
if (orders.Count() == 0) { }

// ✅ Si ferma al primo elemento
if (!orders.Any()) { }


La regola da memorizzare: usare Any() per verifiche di esistenza, Count() solo quando serve il numero esatto.

Sum e Average

Sum(selector) e Average(selector) accettano un selettore per proiettare ogni elemento a un valore numerico prima di aggregare:

IEnumerable<Order> orders = GetOrders();

decimal totalRevenue = orders.Sum(o => o.Total);
decimal averageOrder = orders.Average(o => o.Total);

Console.WriteLine($"Fatturato totale: €{totalRevenue:F2}");
Console.WriteLine($"Ordine medio: €{averageOrder:F2}");


Importante: Average() lancia InvalidOperationException su una sequenza vuota. È buona pratica proteggersi con un controllo preventivo:

decimal? safeAverage = orders.Any()
    ? orders.Average(o => o.Total)
    : null;


Un esempio più articolato che combina GroupBy con Sum e Average per ottenere statistiche per regione geografica:

IEnumerable<SalesData> sales = GetSalesData();

var revenueByRegion = sales
    .GroupBy(s => s.Region)
    .Select(g => new
    {
        Region       = g.Key,
        TotalRevenue = g.Sum(s => s.Revenue),
        AverageUnits = g.Average(s => s.UnitsSold)
    })
    .OrderByDescending(x => x.TotalRevenue);

foreach (var row in revenueByRegion)
{
    Console.WriteLine($"{row.Region}: €{row.TotalRevenue:F0}, media {row.AverageUnits:F1} unità");
}


Min e Max

Min(selector) e Max(selector) restituiscono il valore scalare minimo o massimo — non l’elemento che lo contiene:

IEnumerable<Product> products = GetProducts();

decimal cheapest      = products.Min(p => p.Price);
decimal mostExpensive = products.Max(p => p.Price);

Console.WriteLine($"Range prezzi: €{cheapest:F2} — €{mostExpensive:F2}");


Il limite: se serve il prodotto più economico (non solo il suo prezzo), prima di .NET 6 si era costretti a enumerare la sequenza due volte:

// Prima di .NET 6 — due passaggi, potenziale bug con prezzi duplicati
decimal minPrice     = products.Min(p => p.Price);
Product? cheapestOld = products.FirstOrDefault(p => p.Price == minPrice);


Questo approccio ha un bug sottile: se più prodotti condividono il prezzo minimo, FirstOrDefault sceglie il primo trovato nell’ordine di iterazione, che potrebbe non essere quello desiderato. Inoltre itera la sequenza due volte.

MinBy e MaxBy: l’elemento, non il valore (.NET 6+)

MinBy(keySelector) e MaxBy(keySelector) restituiscono l’elemento che ha il valore minimo o massimo della chiave, in un singolo passaggio sulla sequenza:

// .NET 6+ — singolo passaggio, restituisce l'elemento
Product? cheapest      = products.MinBy(p => p.Price);
Product? mostExpensive = products.MaxBy(p => p.Price);

Console.WriteLine($"Più economico: {cheapest?.Name} a €{cheapest?.Price:F2}");
Console.WriteLine($"Più costoso: {mostExpensive?.Name} a €{mostExpensive?.Price:F2}");


Quando più elementi condividono la stessa chiave minima/massima, MinBy/MaxBy restituiscono il primo incontrato, coerentemente con la semantica di OrderBy().First().

Esempio reale: trovare il periodo di vendita con fatturato più alto e la regione con performance peggiore:

// Periodo con il singolo record di fatturato più alto
SalesData? topPeriod = sales.MaxBy(s => s.Revenue);
Console.WriteLine($"Periodo migliore: {topPeriod?.Region} — €{topPeriod?.Revenue:F2}");

// Regione con fatturato totale più basso
var revenueSummary = sales
    .GroupBy(s => s.Region)
    .Select(g => (Region: g.Key, Total: g.Sum(s => s.Revenue)));

(string Region, decimal Total) worstRegion = revenueSummary.MinBy(r => r.Total);
Console.WriteLine($"Regione con fatturato minore: {worstRegion.Region} (€{worstRegion.Total:F2})");


Aggregate: fold personalizzato

Aggregate è l’operatore più generale: accetta un valore seed e una funzione accumulatrice, piegando ogni elemento nel risultato accumulato. È il fold funzionale di LINQ, e può fare tutto ciò che i metodi specializzati fanno — e molto di più:

IEnumerable<Order> orders = GetOrders();

// Concatena gli ID degli ordini come stringa CSV
string orderList = orders.Aggregate(
    string.Empty,
    (acc, order) => string.IsNullOrEmpty(acc)
        ? order.Id.ToString()
        : $"{acc},{order.Id}");

Console.WriteLine($"ID ordini: {orderList}");


Caso pratico: calcolo del fattore di sconto combinato (moltiplicativo):

decimal[] discounts = [0.10m, 0.05m, 0.15m]; // 10%, 5%, 15%

// Il fattore risultante dopo l'applicazione di tutti gli sconti in sequenza
decimal combinedFactor = discounts.Aggregate(
    1.0m,
    (factor, discount) => factor * (1 - discount));

Console.WriteLine($"Fattore combinato: {combinedFactor:P2}"); // es. 72,54%


Aggregate con result selector

La variante a tre argomenti aggiunge una proiezione finale applicata al risultato accumulato dopo aver processato tutti gli elementi. Questo permette di calcolare la media in un singolo passaggio senza dover iterare due volte:

IEnumerable<SalesData> sales = GetSalesData();

decimal averageRevenue = sales.Aggregate(
    seed: (Total: 0m, Count: 0),
    func: (acc, s) => (acc.Total + s.Revenue, acc.Count + 1),
    resultSelector: acc => acc.Count > 0 ? acc.Total / acc.Count : 0m);

Console.WriteLine($"Fatturato medio: €{averageRevenue:F2}");


Aggregazioni multiple in un singolo passaggio

Calcolare più aggregazioni sulla stessa sequenza in modo ingenuo significa iterarla più volte. Per sorgenti costose — query su database, chiamate di rete, lettura di file — questo ha un impatto reale. La soluzione è usare Aggregate con un accumulatore composito che raccoglie tutti i valori contemporaneamente:

public record AggregateSummary(int Count, decimal Sum, decimal Min, decimal Max);

IEnumerable<Order> orders = GetOrders();

AggregateSummary summary = orders.Aggregate(
    new AggregateSummary(0, 0m, decimal.MaxValue, decimal.MinValue),
    (acc, order) => new AggregateSummary(
        acc.Count + 1,
        acc.Sum   + order.Total,
        Math.Min(acc.Min, order.Total),
        Math.Max(acc.Max, order.Total)));

decimal average = summary.Count > 0 ? summary.Sum / summary.Count : 0m;

Console.WriteLine($"Count:   {summary.Count}");
Console.WriteLine($"Somma:   €{summary.Sum:F2}");
Console.WriteLine($"Minimo:  €{summary.Min:F2}");
Console.WriteLine($"Massimo: €{summary.Max:F2}");
Console.WriteLine($"Media:   €{average:F2}");


Un passaggio, quattro valori. Questo pattern è particolarmente utile nei query handler CQRS in cui il risultato richiede più statistiche e la sorgente dati è un database o un servizio esterno.

TryGetNonEnumeratedCount (.NET 6)

Prima di calcolare aggregazioni che richiedono il conteggio, conviene verificare se è disponibile senza enumerare la sequenza:

IEnumerable<Order> orders = GetOrders();

if (orders.TryGetNonEnumeratedCount(out int count))
{
    Console.WriteLine($"Conteggio rapido: {count}");
    // Disponibile senza iterare — usabile per pre-allocazione o logging
}
else
{
    // Fallback: deve enumerare
    count = orders.Count();
}


TryGetNonEnumeratedCount restituisce true per List<T>, array, HashSet<T> e altri tipi che implementano ICollection<T>. Restituisce false per pipeline lazy, risultati di GroupBy e qualsiasi IEnumerable che deve essere valutato per conoscere la propria lunghezza.

Novità .NET 9: CountBy e AggregateBy

.NET 9 ha introdotto due nuovi operatori di aggregazione per chiave che migliorano i pattern basati su GroupBy:

IEnumerable<Order> orders = GetOrders();

// CountBy: conta gli elementi per chiave — più conciso di GroupBy + Count
var countByStatus = orders.CountBy(o => o.Status);
foreach (var (status, count) in countByStatus)
{
    Console.WriteLine($"{status}: {count} ordini");
}

// AggregateBy: aggregazione personalizzata per chiave
var totalByCustomer = orders.AggregateBy(
    keySelector: o => o.CustomerId,
    seed: 0m,
    func: (total, order) => total + order.Total);

foreach (var (customerId, total) in totalByCustomer)
{
    Console.WriteLine($"Cliente {customerId}: €{total:F2}");
}


Per aggregazioni per chiave in .NET 9+, preferire CountBy e AggregateBy rispetto a GroupBy seguito da aggregazione: il codice è più leggibile e spesso più efficiente.

Guida rapida alla scelta dell’operatore

• Verificare se esiste almeno un elemento → Any(predicate)
• Contare elementi → Count() / Count(predicate)
• Somma di valori proiettati → Sum(selector)
• Media di valori proiettati → Average(selector)
• Valore scalare minimo/massimo → Min(selector) / Max(selector)
• Elemento con chiave minima (.NET 6+) → MinBy(keySelector)
• Elemento con chiave massima (.NET 6+) → MaxBy(keySelector)
• Conteggio per chiave (.NET 9+) → CountBy(keySelector)
• Aggregazione personalizzata per chiave (.NET 9+) → AggregateBy(keySelector, seed, func)
• Fold generico con seed → Aggregate(seed, func)
• Fold generico con proiezione finale → Aggregate(seed, func, resultSelector)

Conclusione

Le operazioni di aggregazione LINQ coprono l’intero spettro delle necessità di riduzione dei dati. Conoscere la differenza tra Any e Count, sapere quando usare MinBy/MaxBy invece di un doppio passaggio, e saper costruire fold multi-valore con Aggregate sono competenze che migliorano sia le performance che la leggibilità del codice. Con l’aggiunta di CountBy e AggregateBy in .NET 9, il toolkit di aggregazione LINQ è oggi più completo che mai: vale la pena tenerlo presente come alternativa ai foreach loop ogni volta che si lavora con trasformazioni di collezioni.

Fonte: LINQ Aggregation in C#: Count, Sum, Min, Max, Average, and Aggregate — Dev Leader

LINQ Aggregation in C#: Count, Sum, Min, Max, Average, and Aggregate

Master LINQ aggregation in C# with Count, Sum, MinBy, MaxBy, and custom Aggregate, plus why Count vs Any matters for real-world .NET performance.

^{Nick Cosentino (Dev Leader)}

(in)sicurezza digitale

2026-05-14 15:53:26

FamousSparrow nel Caucaso: tre ondate di spionaggio cinese colpiscono il gas azero che alimenta l’Europa

Quando il 25 dicembre 2025 un processo silenzioso ha tentato di scrivere una web shell in una directory pubblica di un server Microsoft Exchange di un’azienda petrolifera azera, nessuno sapeva ancora che quello era l’inizio di un’operazione di cyberspionaggio in tre ondate. Il gruppo cinese FamousSparrow ha dimostrato una persistenza metodica e una sofisticazione tecnica che va ben oltre la semplice opportunismo: ha continuato a rientrare nello stesso sistema, cambiando ogni volta backdoor, per quasi due mesi. La ricerca di Bitdefender pubblicata il 13 maggio 2026 ricostruisce l’intera catena.

Un bersaglio di valore strategico nel Caucaso meridionale

L’Azerbaigian non è mai stato un paese secondario per la sicurezza energetica europea, ma la sua importanza è cresciuta esponenzialmente negli ultimi anni. Con la scadenza nel 2024 del transito del gas russo attraverso l’Ucraina e le successive interruzioni dello Stretto di Hormuz nel 2026, Baku si è trasformata in uno snodo critico per l’approvvigionamento energetico del continente. Chi controlla l’informazione che circola all’interno di quelle aziende ha accesso a dati di valore incalcolabile: prezzi di vendita futuri, capacità estrattive, negoziati contrattuali, infrastrutture fisiche.

È esattamente in questo contesto che Bitdefender Labs ha individuato un’intrusione plurifase attribuita con fiducia da moderata ad alta al gruppo FamousSparrow, noto anche come UAT-9244 e storicamente sovrapponibile a cluster come Earth Estries e Salt Typhoon — tutte denominazioni che orbitano intorno all’ecosistema dello spionaggio informatico legato allo stato cinese. L’obiettivo era un’azienda petrolifera e del gas azerbaigiana non nominata. L’operazione è durata dalla fine di dicembre 2025 alla fine di febbraio 2026.

Tre ondate, stesso ingresso: la tattica della porta sempre aperta

L’aspetto più rilevante dal punto di vista operativo è la persistenza attraverso lo stesso vettore iniziale nonostante i tentativi di bonifica. Gli attaccanti hanno sfruttato la catena ProxyNotShell (CVE-2022-41082 / CVE-2022-41040) su un server Microsoft Exchange esposto, una vulnerabilità che risale al 2022 ma che molte organizzazioni non hanno ancora patchato correttamente.

Il processo w3wp.exe è stato osservato tentare di scrivere una web shell in una directory pubblica del server Exchange il 25 dicembre 2025, avviando la prima ondata. Invece di cambiare punto di accesso quando il team difensivo ha tentato la remediation, FamousSparrow ha semplicemente sostituito la backdoor, dimostrando che la vulnerabilità non era stata effettivamente chiusa:

• Ondata 1 — Dicembre 2025: Deploy di Deed RAT (aka Snappybee), successore di ShadowPad, strumento condiviso tra molteplici gruppi di spionaggio cinesi. Caricato tramite DLL sideloading sul binario legittimo di LogMeIn Hamachi.
• Ondata 2 — Fine gennaio / inizio febbraio 2026: Sostituzione con TernDoor, un backdoor recentemente documentato in attacchi alle telecomunicazioni sudamericane nel 2024, mai visto prima nel Caucaso.
• Ondata 3 — Fine febbraio 2026: Ritorno a una variante modificata di Deed RAT, probabilmente aggiornata per eludere le firme generate dopo le prime rilevazioni.

L’arsenale tecnico: DLL sideloading di nuova generazione

Ciò che distingue questa campagna da molte altre operazioni APT è l’evoluzione della tecnica di DLL sideloading utilizzata per caricare Deed RAT. Il metodo tradizionale si limita a rimpiazzare una libreria legittima; la variante di FamousSparrow va oltre, sovrascrivendo due specifiche funzioni esportate all’interno della DLL malevola. Questo crea un meccanismo a doppio trigger che subordina l’esecuzione del loader di Deed RAT al flusso di controllo naturale dell’applicazione host — in questo caso il client Hamachi di LogMeIn.

Il risultato pratico è duplice: il processo appare legittimo agli strumenti di monitoring basati su firma, e l’analisi statica del binario non rivela comportamenti anomali fino all’esecuzione del secondo trigger. Un design che porta il segno di un gruppo con elevate capacità di sviluppo custom.

Deed RAT è un impianto modulare a plug-in, successore architetturale di ShadowPad, storicamente associato a gruppi come APT41, Bronze Atlas e altri cluster dell’ecosistema China-nexus. Supporta esecuzione di comandi, manipolazione del filesystem, tunneling di rete e caricamento dinamico di moduli aggiuntivi. TernDoor è invece un backdoor relativamente nuovo, scoperto per la prima volta nel contesto delle telecomunicazioni sudamericane: la sua comparsa in Azerbaigian suggerisce una condivisione di tooling tra operazioni geograficamente distinte.

Chi è FamousSparrow: storia di un gruppo nell’ombra

FamousSparrow è stato documentato per la prima volta da ESET nel 2021, quando veniva osservato sfruttare ProxyLogon contro hotel, studi legali e organizzazioni governative in cinque continenti. Da allora, il gruppo ha mantenuto un profilo basso, operando con tooling condiviso e sovrapposizioni tattiche con altri cluster China-nexus. La sua attribuzione rimane complessa proprio a causa di questa natura di “contractor” dell’ecosistema: usa strumenti come Deed RAT che circolano tra più gruppi, rendendo difficile tracciare confini netti tra operazioni distinte.

Bitdefender nota sovrapposizioni tattiche con Earth Estries (il gruppo noto per aver colpito le telecomunicazioni globali nel 2022-2024) e con Salt Typhoon, il cluster che nel 2024 aveva compromesso le infrastrutture di intercettazione legale di diversi carrier americani. Questa rete di attribuzioni incrociate riflette quella che gli analisti definiscono la “shared malware economy” del cyberspionaggio cinese: un ecosistema in cui strumenti, infrastrutture e accessi vengono riutilizzati tra operazioni con mandanti potenzialmente diversi.

Due righe per i difensori

Il caso azerbaigiano offre lezioni concrete per i team di sicurezza operanti in settori ad alto valore strategico. La prima, forse la più scomoda, è che un tentativo di remediation che non chiude completamente la vulnerabilità iniziale può essere peggio del non fare nulla: dà al team difensivo una falsa sensazione di sicurezza mentre l’avversario osserva e si riadatta. L’attaccante ha dimostrato di monitorare le azioni difensive e di rispondervi con una nuova backdoor.

Alcune raccomandazioni pratiche: verificare che ProxyNotShell (CVE-2022-41082 e CVE-2022-41040) sia effettivamente patchato attraverso validazione post-patch, non solo applicazione dell’aggiornamento; monitorare l’esecuzione di processi Exchange come w3wp.exe per attività di scrittura su filesystem inusuali; implementare detection per DLL sideloading tramite binari firmati di terze parti come strumenti di remote access legittimi; e adottare una strategia di threat hunting proattiva basata sui TTP di FamousSparrow anche dopo la chiusura di un incidente confermato.

Indicatori di Compromissione (IoC)

# Campagna FamousSparrow - Azerbaigian Oil & Gas (Dic 2025 - Feb 2026)
# Fonte: Bitdefender Labs / The Hacker News (13 maggio 2026)
## File IoC identificati
# Ondata 2 - TernDoor loader
MD5: 762f787534a891eca8aa9b41330b4108
Percorso: C:\ProgramData\USOShared\USOShared.exe
## Vettore di accesso iniziale
Vulnerabilità: ProxyNotShell
CVE: CVE-2022-41082 (RCE) / CVE-2022-41040 (SSRF)
Processo sfruttato: w3wp.exe (IIS Worker Process su Exchange)
## Tecniche MITRE ATT&CK
T1190 - Exploit Public-Facing Application (Exchange ProxyNotShell)
T1505.003 - Web Shell
T1574.002 - DLL Side-Loading (LogMeIn Hamachi binary)
T1027 - Obfuscated Files or Information
T1071 - Application Layer Protocol (C2)
## Malware families
Deed RAT (aka Snappybee) - modulare, successore di ShadowPad
TernDoor - backdoor, prima rilevato in telecomunicazioni SA 2024
## Nota ai defender
# Verificare presenza di web shell residue su:
# %ExchangeInstallPath%\FrontEnd\HttpProxy\
# %ExchangeInstallPath%\ClientAccess\

informapirata

2026-05-14 14:02:56

Il Ministero dell’Istruzione che ci Meritiamo (ma di cui non abbiamo bisogno)

Il comunicato ministeriale che annuncia le nuove Indicazioni Nazionali per i Licei è il risultato mediocre di un’elaborazione in cui i contenuti tecnici ministeriali sono stati passati attraverso un LLM con un prompt scritto con il culo
informapirata.it/2026/05/14/il…

Il Ministero dell’Istruzione che ci Meritiamo (ma di cui non abbiamo bisogno)

Il comunicato ministeriale che annuncia le nuove Indicazioni Nazionali per i Licei è il risultato mediocre di un'elaborazione in cui i contenuti tecnici…

^{informapirata}

(in)sicurezza digitale

2026-05-13 23:20:00

GitLab Act 2: il manifesto dell’AI agentica che promette il futuro e inquieta gli sviluppatori

Quando una piattaforma DevSecOps da miliardi di dollari decide di riscrivere la propria identità attorno agli agenti AI, non sta semplicemente annunciando una nuova roadmap di prodotto. Sta dichiarando che il modello stesso di sviluppo software che abbiamo conosciuto negli ultimi vent’anni è destinato a diventare obsoleto.

È questo il messaggio reale dietro GitLab Act 2, il lungo manifesto pubblicato da GitLab per spiegare la trasformazione interna dell’azienda nell’era dell’AI agentica. Un documento che, più che un post corporate, assomiglia a una dottrina industriale: il software costerà sempre meno produrlo, gli sviluppatori diventeranno supervisori di sistemi autonomi e le organizzazioni dovranno ripensare completamente struttura, processi e ruoli.

Il problema è che, dietro la retorica della “nuova era”, molti sviluppatori vedono qualcosa di molto diverso: una drastica razionalizzazione aziendale mascherata da inevitabile rivoluzione tecnologica.

La tesi di GitLab: il software sarà scritto dalle macchine

Nel manifesto, GitLab sostiene che l’AI generativa stia comprimendo il costo marginale della produzione software in modo paragonabile a quanto avvenuto nell’industria manifatturiera con l’automazione. La conseguenza, secondo l’azienda, non sarà una riduzione della domanda di software ma l’opposto: un’esplosione.

Se creare applicazioni diventa più economico, ogni azienda produrrà più software, più automazione, più integrazioni e più servizi interni. In questo scenario, il valore umano non sarà più nella scrittura manuale del codice ma nella definizione degli obiettivi, nella governance, nella sicurezza e nella supervisione degli agenti AI.

È una narrativa ormai dominante nella Silicon Valley: gli sviluppatori non spariranno, ma evolveranno in orchestratori di sistemi autonomi.

GitLab vuole posizionarsi esattamente al centro di questa transizione con la propria piattaforma “Duo Agent Platform”, immaginata come un layer operativo in cui agenti AI collaborano lungo l’intero ciclo DevSecOps: pianificazione, sviluppo, code review, security scanning, remediation, test e deployment.

Non più copiloti. Non più semplici assistenti. Ma entità autonome capaci di eseguire task complessi all’interno delle pipeline.

La ristrutturazione interna è il vero cuore del manifesto

La parte più interessante del documento non è però tecnologica. È organizzativa.

GitLab annuncia infatti una profonda trasformazione della propria struttura interna. L’azienda parla apertamente di riduzione dei livelli manageriali, team più piccoli e autonomi, maggiore automazione operativa e integrazione massiccia dell’AI nei processi decisionali.

I gruppi R&D verranno suddivisi in circa 60 unità snelle, progettate per muoversi più rapidamente e lavorare in parallelo insieme agli agenti AI. Nel manifesto si percepisce chiaramente un’influenza delle metodologie “founder mode” e delle moderne filosofie ultra-efficientiste adottate da molte aziende AI-first.

Tradotto dal linguaggio corporate: meno coordinamento umano, meno middle management e più automazione decisionale.

Ed è qui che la community ha iniziato a reagire in modo estremamente critico.

La critica principale: “state inseguendo l’hype”

Molti sviluppatori hanno interpretato Act 2 come il segnale definitivo che GitLab stia inseguendo il trend AI sacrificando progressivamente gli elementi che l’avevano resa popolare nella community engineering.

Nel forum ufficiale e su diverse discussioni tecniche, il malcontento è emerso rapidamente. Alcuni utenti accusano GitLab di aver trasformato la piattaforma in un contenitore di feature AI ancora immature mentre problemi storici di UX, performance e stabilità rimangono irrisolti.

Il timore più diffuso è che l’azienda stia vendendo una visione futuristica molto più avanzata della realtà tecnica attuale.

Ed effettivamente esiste un forte scollamento tra la narrativa dell’AI agentica e lo stato reale degli LLM moderni.

Per quanto impressionanti, gli agenti AI soffrono ancora problemi enormi in contesti enterprise:

• perdita di contesto su codebase estese;
• hallucinations in scenari complessi;
• incapacità di ragionamento affidabile multi-step;
• difficoltà nel comprendere architetture legacy;
• fragilità nelle decisioni di sicurezza;
• dipendenza da prompt engineering estremamente fragile.

Nel mondo DevSecOps questi limiti non sono marginali. Sono potenzialmente catastrofici.

Automatizzare una pipeline CI/CD è relativamente semplice. Delegare ad agenti AI remediation di vulnerabilità, code review o decisioni infrastrutturali in ambienti enterprise è un’altra storia.

Soprattutto quando si parla di sicurezza.

Il nodo cybersecurity: chi valida l’agente?

Dal punto di vista della cybersecurity, il manifesto di GitLab apre questioni enormi che nel documento vengono affrontate solo superficialmente.

Se gli agenti AI diventano parte attiva della supply chain software, diventano automaticamente anche una nuova superficie d’attacco.

Un agente che modifica codice, approva merge request o interagisce con pipeline CI/CD introduce rischi completamente nuovi:

• prompt injection nei workflow DevOps;
• poisoning dei contesti RAG;
• manipolazione degli agenti tramite issue o commenti malevoli;
• escalation di privilegi attraverso tool integration;
• generazione di codice vulnerabile apparentemente corretto;
• supply chain compromise mediata da AI.

La community security sta già osservando casi concreti di agenti AI manipolabili tramite input indiretti, specialmente quando connessi a repository, ticketing system o documentazione interna.

In pratica, il problema non è più soltanto “il codice è vulnerabile?”, ma anche:

“l’agente che ha preso la decisione era affidabile?”

È una differenza enorme.

GitLab sembra convinta che governance e supervisione umana saranno sufficienti a mitigare questi rischi. Ma molti esperti ritengono che l’industria stia sottovalutando drasticamente la complessità della sicurezza negli ecosistemi agentici.

Il sottotesto economico: fare di più con meno persone

C’è poi un altro elemento che ha generato parecchio nervosismo: il sospetto che “Act 2” sia soprattutto un piano di efficientamento.

Nel manifesto, GitLab evita accuratamente toni allarmistici sui posti di lavoro, ma il messaggio implicito è difficile da ignorare. Se gli agenti AI aumentano drasticamente la produttività, le aziende avranno bisogno di meno persone per svolgere gli stessi task.

Molti hanno letto il documento come la formalizzazione di una tendenza già evidente nel settore tech: usare l’AI come leva per comprimere organici, ridurre management intermedio e aumentare output per dipendente.

Ed è qui che la narrativa “visionaria” inizia a somigliare a qualcosa di molto più concreto: una ridefinizione radicale del rapporto tra capitale umano e automazione nel software engineering.

Un manifesto che racconta il futuro del settore

Al di là dell’hype e delle critiche, GitLab Act 2 resta un documento importante perché fotografa perfettamente il momento storico dell’industria software.

Per la prima volta una grande piattaforma DevSecOps non presenta l’AI come una feature aggiuntiva, ma come il fondamento operativo attorno a cui ridisegnare un’intera azienda.

La vera domanda non è se GitLab riuscirà o meno nella trasformazione.

La domanda è quante altre aziende seguiranno lo stesso modello nei prossimi 24 mesi.

Perché se Act 2 dovesse diventare il template organizzativo dell’era agentica, il cambiamento non riguarderà soltanto il modo in cui scriviamo codice.

Riguarderà il modo in cui verranno costruite le aziende tecnologiche stesse.

GitLab Act 2

A letter to our customers and our investors.

^{Bill Staples (about.gitlab.com)}

slowforward

2026-05-13 22:53:35

sospese le sanzioni contro francesca albanese

e aggiungo io: come sempre, non si deve certo allo scandaloso governo ytalyano, servetto dell’amerika e dello stato genocida, se giustizia finalmente arriva per la relatrice ONU, che ha l’unico torto di documentare una verità sotto gli occhi di tutti.
#Cisgiordania #dirittiUmani #FrancescaAlbanese #Gaza #genocidio #humanRights #Israele #Onu #Palestina #sanzioni #sospensioneDelleSanzioni #sospeseLeSanzioniControFrancescaAlbanese #USCourt #USA