+1, we also do this in Apache Shiro [1]
and the aspectj-maven-plugin (mojohaus) [2].
We don't reuse workflows yet, but what you have is just great!
Thanks!
- Ben
[1]:
https://github.com/apache/shiro/blob/df2f5481260bd778226473a658d237c047b7e840/.github/workflows/maven.yml
[2]:
We had a discussion on slack about having a first build such as only
ubuntu/jdk1,8 before running all the matrix and holding a lot of nodes from
the Apache org..
This PR definitely does not do this! So I don't understand why this has
been merged!
Remember (as far I understand) nodes are shared
If you use trusted checksum catalogs, shoes, reference hashes or stuff this can
be used for integrity protection (if the checksum catalogs are integrity
protected), and for this you indeed have to use strong hashes. However this is
not directly related to the maven artifact hash files and
Am 2021-10-13 um 16:19 schrieb Mickael Istria:
On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov wrote:
Hi Mickael,
Hi Michael,
this is an overly complex topic I'd like to explain.
First of all Wagon is not involved in this. It does the physical
transport. The payload is opaque. SHA, MD5
Hello,
i see two mixed topics in this discussion - verifying artifact transfer
integrity and verifying that the downloaded artifact is really the one
expected from the security perspective. The latter does not have anything
to do with Maven Central or any other repository. Checksums in
On Thu, Oct 14, 2021 at 10:36 AM Romain Manni-Bucau
wrote:
> I agree with Bernd, checksums are there to validate the consistency of the
> artifact, nothing linked to security.
>
Ensuring user gets a consistent artifact as desired -and not a malicious
forged one- is 1 aspect of security.
On
Hi,
I agree with Bernd, checksums are there to validate the consistency of the
artifact, nothing linked to security.
On central the security side is provided by the asc file which is
sufficient if you trust only allowed releasers keys in practise, pretending
you are a releaser will be quite hard
On Wed, Oct 13, 2021 at 8:41 PM Bernd Eckenfels
wrote:
> There is no Security risk with weaker checksums since the checksums are
> not used for security. An attacker who messes with your binaries can also
> mess with the checksum files.
In our case, we have the checksum files that are served
