Package-integriteit blijkt ongelijk; Go 1.27 hergebruikt HTTP/1-verbindingen slimmer

Trail of Bits zag bij een test van 25 package managers grote verschillen in bescherming tegen een gecompromitteerde pakketrepository. Go 1.27 pakt tegelijk een stille HTTP/1-prestatieval aan door kleine, ongelezen responsebodies begrensd op de achtergrond weg te lezen.

Ook interessant: Materialize beschrijft hoe het een lineair metadata-log boven PostgreSQL op READ COMMITTED bouwde na een metastabiel incident, met een Lean-4-model als extra controle. En ZXC 0.15 kiest nadrukkelijk voor snelle decompressie, niet voor snelle compressie.

Package managers controleren niet overal standaard wat ze downloaden

Trail of Bits testte 25 populaire package managers in een Docker-/mitmproxy-harness waarin een pakketrepository legitieme pakketten van kwaadaardige code voorziet. Volgens die proef verifieert minder dan de helft standaard een lockfile tegen manipulatie; alleen Go en vcpkg verifieerden in de geteste standaardroute de integriteit van ieder gedownload pakket. Cargo, npm, pnpm, uv, Poetry, SwiftPM en enkele andere managers doen dat volgens de tabel wanneer een lockfile aanwezig is. Voor pip, Conda, Gradle, NuGet en Pub zijn extra stappen nodig; voor diverse andere onderzochte managers ontbrak in die configuratie lockfile-integriteit.

De belangrijke nuance zit in wat precies is getest. Het gaat om één manager-versie, één pakket en één platform per route, met standaardcommando’s die volgens de auteur een redelijke quickstart weerspiegelen. Dat bewijst niet dat iedere installatie met een bepaalde manager manipuleerbaar is. Het laat wel zien dat een lockfile, of zelfs een hashveld, niet automatisch betekent dat een installatie bij een mismatch stopt. Het artikel noemt bijvoorbeeld Pub, dat volgens de proef bij een afwijking standaard de lockfile bijwerkt tenzij --enforce-lockfile wordt gebruikt.

Voor teams is dit een concrete CI- en releasecheck. Commit lockfiles waar de stack dat ondersteunt, maak installatie in CI expliciet onveranderlijk of frozen, en test een hashmismatch in de werkelijk gebruikte installatieopdracht. Kijk ook naar de herkomst van hashes en signatures: TLS beschermt transport naar de server, maar niet per se tegen een server die zelf verkeerde pakketbytes serveert. De inventarisatie is een onafhankelijk onderzoek, maar de classificaties blijven afhankelijk van versie, platform en gekozen configuratie.

Trail of Bits: methode, tabellen en beperkingen · Lobsters-discussie

Go 1.27 maakt ongebruikte HTTP/1-bodies begrensd herbruikbaar

De Go-standaardbibliotheek verandert in Go 1.27 het gedrag van net/http.Transport voor HTTP/1-responses waarvan code alleen de headers of status nodig heeft. Tot Go 1.26 betekende resp.Body.Close() met nog ongelezen bytes dat de verbinding niet hergebruikt kon worden. De volgende request moest dan vaak een nieuwe TCP- en TLS-verbinding opzetten.

Vanaf 1.27 probeert de transportlaag zo’n body zelf asynchroon leeg te lezen: maximaal 256 KB en maximaal 50 ms. Lukt dat, dan kan de verbinding terug naar de pool; lukt het niet, dan blokkeert het sluiten de applicatie niet eindeloos. Bij Connection: close slaat Go het leeghalen over, omdat hergebruik daar toch onmogelijk is. In Go’s eigen voorbeeld — honderd HTTP/1-requests zonder responsebody te lezen — daalt de looptijd op de geteste machine van circa 710 naar 150 ms.

Dat is vooral nuttig voor clients die met HTTP/1 werken en vaak alleen een statuscode of headers gebruiken. Het is geen algemene vijfvoudige versnelling: de winst hangt af van responsegrootte, latency, servergedrag en hoeveel verbindingen al hergebruikt worden. HTTP/2 heeft deze specifieke beperking niet, doordat streams daar gemultiplext zijn. Applicaties hoeven volgens Go niet langer zelf complexe drain-logica te kopiëren; sluit bodies wel nog steeds zodra ze niet meer nodig zijn.

Go: uitleg en nieuwe limieten · HN-discussie

Materialize vervangt SERIALIZABLE door een bewezen READ COMMITTED-ontwerp

Materialize beschrijft een incident in een self-managed installatie waarin metadata-operaties opliepen van milliseconden naar dertig seconden. De PostgreSQL-metadatawinkel had honderdduizenden SIRead-locks opgebouwd door transacties onder SERIALIZABLE; volgens de analyse maakte die lockgroei iedere volgende write duurder. De resulterende vertraging hield zichzelf in stand, ook nadat de tijdelijke trigger was verdwenen.

De oplossing is geen versoepelde consistentie-eis. Materialize herontwierp de metadata-opslag voor een lineair log boven PostgreSQL READ COMMITTED. Een shard wordt als aaneengesloten reeks sequencenummers behandeld; een compare-and-set controleert in één statement dat de verwachte voorganger bestaat en voegt de opvolger alleen toe als de primary key dat toelaat. Truncatie verwijdert uitsluitend een prefix, nooit de kop. Daarmee probeert het ontwerp de benodigde logeigenschappen te behouden zonder de SSI-kosten van SERIALIZABLE.

De makers melden in hun reproducer drie keer hogere write-throughput en een geleidelijker falen boven databasecapaciteit. Ze modelleerden bovendien PostgreSQL’s READ COMMITTED-gedrag in Lean 4 en bewezen daar dat het ontwerp lineariseerbaar is. Dat verhoogt het vertrouwen in de abstracte opzet, maar is geen algemene aanbeveling om eigen transactionele code van SERIALIZABLE naar READ COMMITTED te zetten: de correctheid rust hier op specifieke query’s en invarianten. De performancecijfers zijn ook eigen metingen op een beschreven RDS-opstelling.

Materialize: incident, queryontwerp en Lean-verificatie · Lobsters-discussie

ZXC 0.15 verplaatst werk van decoder naar encoder

ZXC 0.15.0 is een BSD-3-gelicentieerde C-compressiebibliotheek voor data die één keer wordt verpakt en veelvuldig wordt gelezen, zoals firmware, game-assets en applicatiebundels. De ontwerpkeuze: extra zoektijd, parsing en statistiekwerk bij compressie om een korte, SIMD-gerichte decoder te krijgen. De release noemt onder meer C-, Rust-, Python-, Node- en Go-koppelingen, optionele seek tables en per-block checksums.

De projectbenchmarks vergelijken op silesia.tar en een Apple M2 gelijksoortige compressieratio’s. Daar haalt ZXC op het standaardniveau 9.707 MB/s decompressie bij 46,65% van de oorspronkelijke grootte, tegen 4.774 MB/s voor LZ4 bij 47,60%. Op het hoogste niveau noemt de tabel 5.054 MB/s decode, maar slechts 9,71 MB/s encode. Dat laatste is de wezenlijke ruil: voor levels 6 en 7 is ZXC volgens de eigen cijfers veel trager met comprimeren dan LZ4 of Zstandard.

Dat maakt de library interessant wanneer decode-latency, batterijverbruik of gelezen bytes doorslaggevend zijn en artefacten vooraf kunnen worden gebouwd. Voor logs, tijdelijke data of iedere stroom die voortdurend opnieuw wordt gecomprimeerd, kan die encoderkost juist zwaarder wegen. De metingen zijn projectmetingen, wel met een genoemde lzbench-versie en reproduceerbare benchmarkroute; hermeet dus met eigen corpus, CPU, blockgrootte en distributie-eisen.

ZXC 0.15: formaat, API en benchmarks · Lobsters-discussie

Verder nog

• Crates opsplitsen als gerichte Rust-optimalisatie: uv-maker Charlie Marsh meldt dat het opsplitsen van de primaire Rust-crate van circa 46.000 naar 6.000 regels, verdeeld over veertien crates, de incrementele buildtijd in zijn omgeving met 30–40% verlaagde. Armin Ronacher werpt terecht de operationele keerzijde op: meer crates vergroten onder meer publicatie- en beheerfrictie. Dit is één praktijkmeting, geen algemene Cargo-regel; meet vooral schone én incrementele builds en houd releaseautomatisering mee in de afweging. Thread met de meting · reactie over crate-overhead