https://gradle.com/ logo
Join Slack
Powered by
I noticed that when using dependency verification,...
# community-support
d
I noticed that when using dependency verification, my plugins are all unsigned (reason="Artifact is not signed"). Is that due to that being the case, or do I have to do something special for signatures to be fetched for plugins? For example these are all unsigned: gradle-license-report-2.5.jar, gradle-license-report-2.5.pom, com.github.jk1.dependency-license-report.gradle.plugin-2.5.pom and same applies to more high profile ones like shadowjar, jib etc. Are they really not signed?
Usually artifacts are browsable via here: https://mvnrepository.com/artifact/com.github.johnrengelman.shadow/com.github.johnrengelman.shadow.gradle.plugin/8.1.1 But for plugins they usually just end up on jfrog artifactory with a 404.
Copy code
{
  "errors": [
    {
      "status": 404,
      "message": "children items not found on all virtual repos"
    }
  ]
}
v
Keep in mind the "Repositories" line. mvnrepository.com is just an indexing service indexing Maven repositories. The link you shared is only available in the "EEA SK" repository and there it is obviously broken, so you should maybe report that to this repository and / or mvnrepository.com
d
Question remains. Are plugins not signed?
v
The next thing to report to mvnrepository.com is, that it shows outdated information. If you switch to the "Gradle Plugins" tab of the shadow plugin, it looks like the latest version on the plugin portal is 7.1.2, while in reality also the 8.1.1 is available there
But you cannot generally say "plugins are signed or not", that depends on the plugin author.
If they are published to Maven Central, they are signed because MC does not accept unsigned publication.
Plugins that are only available on the plugin portal - probably most - are not necessarily signed, but could be.
Or rather, the plugin marker artifiact's POM is not signed.
d
Is there any reason gradle plugins aren't required to be signed? Think that's the requirement for maven repository?
v
It's the requirement for Maven Central, not for a Maven repository in general
d
Right central is what I was thinking of.
v
As to why, probably because it is easier to setup publishing when not needing to sign. Just a guess though 🙂
d
Hmmm... vague recollection of some post processing of some manifest incompatible with signing. Was a couple of years ago since I checked this.
v
Who post-processes what?
d
Not sure, don't recall. Think it was something with how plugins are placed on gradle plugin portal. But don't recall. Vague recollection of Vladimir Sitnikov mentioning something of this, but it was likely 3 years ago since I last went down this hole.
> easier to setup publishing But not if you take the complete picture into account. By not having signed plugins, that needs to fall back to either whitelisting, or manually updating checksums every release. Thus saving some minute from the maintainer, and adding some minutes to each user. Multiplication can produce powerful numbers.
v
I'm not aware of any post-processing done.
But not if you take the complete picture into account
I don't object, just assuming what the reasoning could have been.
👍 1
It is also one of the reasons why JCenter was popular even though it was unreliable and buggy. Because it was easier to publish to it than to Maven Central mainly because you did not have to setup signing including generating a key and so on.
d
Maybe I'm mixing this up with the jcenter weirdness.
v
Yes, JCenter sometimes processed things it proxied from Maven Central and by thus voided some checksums and similar.
t
Bintray/JCenter did sometimes rewrite POMs: https://github.com/gradle/gradle/issues/15406 That broke dependency verification as a whole, whether signed or not, as it changed the checksum.
d
Right, that was where that memory was from. Ok, so I guess it's just the way it is as long as gradle portal doesn't require signed releases then.
So I guess nudging various projects.
v
And / or nudging Gradle to require it if you really think it should 🙂 Doesn't hurt to suggest it, even though you might get a no.
d
It should require it for plugins, or retire the dependency verification feature. This middle ground is bad.
v
As I said, tell them 🙂
👍 1
t
Dependency verification with checksums only can be useful too (serves a different purpose though) We use it with customers where I want to make sure they get the exact same set of dependencies, byte-for-byte, as the ones we use for development, when they ask us to push code to their repos and they build projects in their own infrastructure.
d
Agree, but the usefulness will diminish from the flamewars that arise of how annoying it is to not press merge on dependabot PRs
So current strategy accepting signature alone with local keyring. Annoying to add new, but easy to bump, and aws codeartifact for getting the same each time.
3 Views
Open in Slack
PreviousNext
Powered by