- Navios
- 23 de setembro de 2026 às 02:35 UTC
- Autor
- Kamo
- Enviar
- d1a8762
/download carregou o arquivo inteiro em um byte[] através do ImageService.downloadDocument antes servindo-o; /bulk-download construiu todo o ZIP (ou PDF fundido) como um byte[] em DocumentPrepareService antes de responder; os uploads funcionam até 3 GB contra os ~1,4 GB deste serviço heap, e /bulk-download's 100-id cap não tinha limite de tamanho atrás dele — 100 documentos sem tampa poderiam pedir centenas de gigabytes em um único pedido. buildZip também escreveu Img.fileName diretamente para um ZipEntry sem higienização, então um documento renomeado para algo como **************************** (nome do ficheiro é controlado pelo utilizador — texto livre, alterado via /update/filename/{imgId}) produziu um arquivo cuja entrada, aberta por um extrator que não em si mesmo proteger contra zip-slip, escreve fora do diretório alvo em qualquer OS está fazendo o extracção. - /download now streams via MinIOStorageService.openRange + StreamingResponseBody, exatamente como /stream já fez, em vez de buffering o arquivo inteiro. (Drops ImageService.downloadDocument's dl-first/dl-último efeito colateral de contabilidade — confirmado morto por grep: nada na infraestrutura Java nunca lê Img.dlFirstDate/dlLastDate, apenas as escreve. A auditoria separada ImgLogDownload linha via registroDownloadEvent, que é lido de volta pelo painel de download-história, é inalterada.) - /Bulk-download dedupes solicitados ids antes da tampa 100-id e do trabalho por item. - /bulk-download recusa outright (400) uma vez que os documentos selecionados' combinado Img.fileSize passes 500 MB, em vez de tentar a fusão/zip e arriscar um OOM — recusado, não silenciosamente truncado, porque completude é o ponto de uma grande EXPORTAÇÃO. - buildZip higieniza todos os nomes de entrada para o seu segmento de caminho final (splitting em ambos / e \, desde o extrator pode estar em um sistema operacional que este servidor não controla), fechando o gap zip-slip. NOT DONE, relatado como uma lacuna conhecida: buildZip/mergePdfs ainda constroem seu resultado como um byte[] antes de responder em vez de transmiti-lo diretamente para a resposta HTTP — a tampa de 500 MB agora que limita isso a um teto conhecido (desde o limite), mas não é eliminado. Convertê-los para escrever em um chamador-fornecido OutputStream iria deixar /bulk-download stream também; diferido porque ele altera as assinaturas públicas do DocumentPrepareService, ondulando em três arquivos de teste existentes (mocks currently stub the byte[]-returning methods), para uma gravidade MEDIUM, já Resto — uma chamada de âmbito deliberado, não um descuido. Novos testes: **************************** (7 casos para sanitizeZipEntryName) e três casos adicionado ao ImagingControllerMediaAssocTest (streaming-not-buffering, id dedupe, the size cap). Verificado por mutação: revertendo ImagingController.java para seu estado pré-fixo transforma os três novos casos de controlador vermelho; revertendo sanitizeZipEntryName para `nome de retorno;` gira 5 dos 7 zip-slip Casos vermelhos (o 6o, um nome de arquivo normal já seguro, não é afetado corretamente de qualquer forma). Suíte completa: 741 testes verdes (era 731; +10 novos).