- Spegnimento
- 23 settembre 2026 alle ore 02:35 UTC
- Autore
- Kamo
- Impegno
- d1a8762
/download ha caricato l'intero file in un byte[] tramite ImageService.downloadDocument prima servire; /bulk-download ha costruito l'intero ZIP (o unito PDF) come un byte[] in DocumentPrepareService prima di rispondere; gli upload arrivano fino a 3 GB contro il servizio ~1.4 GB heap, e /bulk-download 100-id cap non aveva limite di dimensione dietro di esso — 100 documenti non recuperati potrebbero chiedere centinaia di gigabyte in una sola richiesta. buildZip ha anche scritto Img.fileName direttamente in una ZipEntry senza risanamento, quindi un documento rinominato a qualcosa come Non e' vero. (fileName è controllato dall'utente — libero testo, modificato tramite /update/filename/{imgId}) ha prodotto un archivio il cui ingresso, aperto da un estrattore che non stessa guardia contro zip-slip, scrive al di fuori della directory di destinazione su quale altro sistema operativo sta facendo Estrazione. - /download ora stream via MinIOStorageService.openRange + StreamingResponseBody, esattamente come /stream già fatto, invece di buffering l'intero file. (Drops ImageService.downloadDocument's dl-first/dl-last bookkeeping effetto collaterale — confermato morto da grep: niente nel backend Java mai legge Img.dlFirstDate/dlLastDate, solo mai li scrive. L'audit ImgLogDownload separato riga via recordDownloadEvent, che è letto indietro dal pannello di download-storia, è invariato.) - /bulk-download dedupes richiesto ids prima del tappo 100-id e il lavoro per-item. - /bulk-download rifiuta outright (400) una volta che i documenti selezionati combinato Img.fileSize passa 500 MB, piuttosto che tentare la fusione/zip e rischiare un OOM — rifiutato, non silenziosamente troncato, perché la completezza è il punto di una massa EXPORT. - costruireZip sanitizza ogni nome di entrata al suo segmento di percorso finale (splitting su entrambi / e \, dal l'estrattore può essere su un sistema operativo questo server non controlla), chiudendo il gap zip-slip. NON DONE, segnalato come un gap noto: costruireZip/mergePdfs ancora costruire il loro risultato come un byte[] prima di rispondere piuttosto che trasmetterlo direttamente alla risposta HTTP — il tappo di 500 MB ora limiti che a un soffitto noto (sotto il limite di unbounded), ma non è eliminato. Convertirli in scrivere in un caller-fornito OutputStream avrebbe permesso /bulk-download flusso troppo; differito perché modifiche DocumentPrepareService firme pubbliche, rippling in tre file di test esistenti (mocchi attualmente stub il byte[]-ritorno metodi), per un MEDIUM-severity, già incappato rimanente — una chiamata di portata deliberata, non una supervisione. Nuovi test: Non e' vero. (7 casi per sanitizeZipEntryName) e tre casi aggiunto a ImagingControllerMediaAssocTest (streaming-not-buffering, id dedupe, la taglia cap). Mutation-checked: reverting ImagingController.java al suo stato prefisso gira i tre nuovi controller Casi rosso; reverting sanitizeZipEntryName a `return name; ` gira 5 del 7 zip-slip casi rossi (il 6, un nome di file ordinario già sicuro, è correttamente inalterato in entrambi i modi). Suite completa: 741 test verdi (era 731; +10 nuova).