sbp commented on issue #397: URL: https://github.com/apache/tooling-trusted-releases/issues/397#issuecomment-3647783501
5.2.2 asks that we validate all file types, including inside archives, when they are uploaded. The specific wording is "when the application accepts a file", so the question is whether we accept a file when we add it to a revision to perform checks on, i.e. whether it is considered added before we perform the checks. If so, then we would have to perform the checks before displaying the files to the user. It might not make sense, at first glance, to not show the user the files that they've uploaded, but if their credentials have been compromised then uploaded files may not be as they expect. We also make a user's uploaded files available to all other users of the system, so a compromised user can affect others. We should consider having two phases of validation. We could do immediate scans on uploads before presenting to any user, including the uploading user, for simple checking with very little chance of false positives, such as verifying magic bytes of archive formats. This would also help to fight accidental corruption. Afterwards we could perform more kinds of file validation in the checking phase. We could also more clearly show in the interface when checks on files are still running, and perhaps display more prominently the provenance of uploaded files. The vast majority of artifacts at the ASF have been ZIP or TAR based, but as we migrate towards allowing binary artifacts in ATR we will receive more and more complex types. In addition to the standard magic bytes detector in the upload phase, therefore, we could also run [Magika](https://github.com/google/magika), which is fast but heuristic, on lesser known file types, and quarantine files if Magika reports any issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
