Re: Maven Central Repository Bad Checksums
You should file tickets for Maven Central at [1] instead. /Anders [1] https://issues.sonatype.org/browse/MVNCENTRAL On Thu, Dec 2, 2010 at 15:21, Scott Parkerson s...@snortasprocket.netwrote: Once upon a time, I filed a JIRA at Codehaus: http://jira.codehaus.org/browse/MEV-641. Eleven months elapsed before someone finally fixed the checksum metadata to match the jar in the repository. Yesterday, I filed another pair of issues: MEV-675 and MEV-676. I was wondering if I have to wait another 11 months before they are addressed.[1] Who is handling these? Is there a labor shortage on handling these issues? Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. If there's a need, I'll volunteer to do just that. --sgp [1] Just kidding, naturally.
Re: Maven Central Repository Bad Checksums
On Dec 2, 2010, at 10:02 AM, Anders Hammar wrote: You should file tickets for Maven Central at [1] instead. [1] https://issues.sonatype.org/browse/MVNCENTRAL Sigh. This is what I get for not reading *closely* (and assuming that things were as they were 11 months ago). So Sonatype is in charge of housekeeping for Maven Central now? I'll close my issues on the Codehaus JIRA and re-open them on Sonatype's JIRA, then. Cheers, --sgp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. I don't think you want to automate fixing them, only detecting the problems. Because if/when an honestly bad (or compromised/hacked) jar lands in Central, you want to know about it, and not just assume it is correct and use that MD5, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. However, pgp signatures are for detecting compromised files. /Anders On Thu, Dec 2, 2010 at 17:58, Wayne Fay wayne...@gmail.com wrote: Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. I don't think you want to automate fixing them, only detecting the problems. Because if/when an honestly bad (or compromised/hacked) jar lands in Central, you want to know about it, and not just assume it is correct and use that MD5, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. But how does a bot know that the Jar was uploaded ok into Central? Its the same problem. The checksum should be generated by the original owner of the artifact and uploaded alongside it, and any deviations should be directed back to the owner to resolve. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
We do a little bit of sleuthing when resolving these types of issues to make sure the file hasn't been changed, which is why automatic correction isn't implemented. We are working on process to ensure that no new things come in this way. It can only happen today via the old rsync mechanisms and those are deprecated and will be disabled soon anyway. On Thu, Dec 2, 2010 at 2:45 PM, Wayne Fay wayne...@gmail.com wrote: I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. But how does a bot know that the Jar was uploaded ok into Central? Its the same problem. The checksum should be generated by the original owner of the artifact and uploaded alongside it, and any deviations should be directed back to the owner to resolve. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org