I also think a phase parallel rollout would be more useful, also consider lots of projects still won't upgrade to java 8 because they want to maintain backwards compatibility.
1. maven 3.7.0 add support for list of hashes, valid list, warning list and banned list 2. maven 3.7.0 add sha-2 and sha-3 support 3. maven 3.7.0 generates md5, sha1, sha2 and sha3 by default 4. maven 3.7.0 warns if no sha-2 or sha-3 exists and having to use md5 or sha1 for validation 5. maven 4.0.0 stops generating md5 and sha1 hashes by default, users can still opt for then to be generated 6. maven 4.0.0 error if no sha-2 or sha-3 exists and having to use md5 or sha1 for validation, user can still opt for then to be warning i tried working out how to add sha-2 support about 5 years ago as a pull request but it didn't go very far I also think we need to change maven central to more like a debian repo setup, core and 3rd party, with a new repo for each major release, or are repo based upon the min version of java, so java 9, 10, 12, 13, 14, 15, 16, 18, 19, etc could be dropped 3-6 months after that version of java is out of support. Maybe something else that needs to be considered, as as nothing gets removed from maven central, in another 5 or 10 years we might have jars that won't ever get used again. John On Sun, 31 May 2020 at 19:42, Michael Osipov <micha...@apache.org> wrote: > > Am 2020-05-31 um 18:46 schrieb Maarten Mulders: > > Hi, > > > > It's great to see support for more secure hashing algorithms coming. > > > > At the risk of suggesting something that is already there, or is just > > not feasible... Wouldn't it be possible to have a smoother transition by > > allowing multiple hashes at the same time? > > > > When resolving, if there is a SHA-2 hash we use that for validation. > > Otherwise, we use SHA-1 or MD5. We might log a warning about the fact > > that a deprecated hashing algorithm is used. That way, repo managers > > wouldn't necessarily need to re-hash all their content. On the other > > hand, it might slow down the adoption of SHA-2 for content hashing. > > We already have multiple hashes in parallel and Resolver will traverse > until no hash is found or the first one has failed. > > > On May 31, 2020, at 17:19, Robert Scholte wrote: > > > >> hi, > >> > >> I would be great if Sonatype could lead this request. > >> It seems like a similar process compared to the TLSv1.2 requirement > >> and the drop of http > >> They have the best overview in how to handle the switch to different > >> hashes. > >> You can already start with #1, but until then I would be careful with #2 > >> > >> thanks, > >> Robert > >> > >> On 31-5-2020 16:58:58, Michael Osipov <micha...@apache.org> wrote: > >> Folks, > >> > >> I have been recently (indirectly) approached by Mark Thomas for the > >> Tomcat committers that he wants to provide SHA-2 hashes for all uploaded > >> Tomcat artifacts in Central. Since Nexus 2.14.18 supports this properly > >> for validation, I have picked up MRESOLVER-56 and asked for testing. > >> > >> I'd like also to discuss two proposals for the Maven community: > >> 1. Introduce SHA-2 support in Maven Resolver 1.4.3 which will go into > >> Maven 3.7.0 > >> 2. Deprecate MD5 and SHA-1 with that release and make them obsolete with > >> Maven 4.0 and Maven Resolver 2.0 which will include package change also. > >> > >> Those proposals have the following greater implications: > >> 1. > >> * Certain repo managers might reject hashes, they don't know. As did > >> Nexus on repository.a.o. > >> * This will incur two more requests with each upload and download. In > >> the latter, it will fail with 404 because most repo managers won't have > >> SHA-2 hashes. So fails Central for now. (will be solved with 2.) > >> > >> 2. > >> * All repo managers will need to > >> ** rehash all current content to provide SHA-2 hashes > >> ** Require SHA-2 hashes to be uploaded > >> ** Reject MD5 and SHA-1 hashes > >> * Old tools will fail because MD5 and SHA-1 hashes are gone: > >> ** Uploads will be rejected > >> ** Strict download validation will fail > >> > >> Please comment. I will also provide a draft PR soon. > >> I can cast two formal votes if required. > >> > >> Michael > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
