use pekko 1.1.2 #615
use pekko 1.1.2 #615
Conversation
build.sbt
Outdated
| @@ -22,6 +22,7 @@ import com.lightbend.paradox.apidoc.ApidocPlugin.autoImport.apidocRootPackage | |||
| sourceDistName := "apache-pekko-http" | |||
| sourceDistIncubating := false | |||
|
|
|||
| ThisBuild / resolvers += Resolver.ApacheMavenSnapshotsRepo | |||
There was a problem hiding this comment.
The point of sbt-pekko-build and our classes built on it like PekkoCoreDependency.scala is to allow us to test with snapshot versions of our modules. This has proved invaluable in the past.
Without this resolver setup - which you will find in most other Pekko build files - this snapshot build support breaks and then we don't need sbt-pekko-build anymore and might as well remove all the build config overhead that it adds.
There was a problem hiding this comment.
I agree it's useful to be able to test against artifacts in the snapshots repo, but I'm not sure I'm a fan of having it enabled by default even when not testing snapshots - it adds some overhead, makes error messages harder to read, and is a possible attack vector.
Could we have it but commented-out, so we can easily enable it when the situation calls for it?
There was a problem hiding this comment.
- We have this resolver enabled in most other Pekko repos.
- You can't get a snapshot into repository.apache.org unless you have access to Apache credentials.
- The only snapshots we use are Pekko snapshots
- So that means the risk is not that other ASF committers will attack us - they have to be a member of the Pekko PMC because it is my understanding that only Pekko PMC members have access to write Pekko snapshots - I must admit to being a bit unclear as how ASF Infra have set up our GitHub projects in terms of what Apache user it uses for CI publishes to repository.apache.org but I hope that it is a Pekko specific user as opposed to a user who can write snaphots jars for any Apache project.
There was a problem hiding this comment.
I've created pjfanning/sbt-pekko-build#16 - I think have explicit checks at release time is better than having our branches always set up to ban snapshot dependencies.
There was a problem hiding this comment.
looks like sbt-pekko-build actually has some internal smarts that add the snapshot resolver if you use non-default system properties to enable testing with snapshots (eg -Dpekko.build.pekko.version=main).
There was a problem hiding this comment.
👍 Good that we could remove it and that it is not enabled by default. I agree here with Arnout, regardless of potential measurements to limit a potential security problem, adding custom resolvers in the maven/sbt landscape is a big risk which you don't want to push onto every developer working with a repository by default. Since the maven universe has basically no effective mechanism to check against malicious dependencies (or limit the exposure e.g. by checking signatures, or restricting resolvers to certain artifacts), it is not enough to limit against known attack vectors but it is important to also limit the attack surface itself.
No description provided.