Since we are starting a new ecosystem of libraries that is meant to live long, I wonder if we can put in some security mechanism as improvement. Currently the JAR ecosystem’s security leans on transport security via HTTPS. Sonatype OSS requires GPG signatures, but it’s not a universal requirement, and I don’t think people actually do anything with the signatures.
The TASTY ecosystem I propose should build the notion of GPG signature in, for example as part of the file header. This information should be used by the tooling on important checkpoints, for example the first time you downloaded the file, or when you re-compile the file to bytecode. For development purposes, this check might be disabled, but I think it would be safer if the default behavior is that we check the fidelity of the TASTY files.
This could even be done within the existing Tasty spec. Tasty is an open format. A Tasty file consists of a number of sections, which each have a name. A GPG signature could be defined as one of these sections.
I think the trickier bit is always the hierarchy of trust. @odersky if we embed a GPG signature within the Tasty format, what does the verification? Presumably the compiler? How does the compiler decide something is or is not valid?
I think the trickier bit is always the hierarchy of trust. @odersky if we embed a GPG signature within the Tasty format, what does the verification? Presumably the compiler? How does the compiler decide something is or is not valid?
I don’t know. I am not sufficiently informed to have a qualified opinion on this. So other people should hash this out.
I don’t think tasty is the correct level of granularity to look at for solving distribution security problem. No one is going to distribute individual .tasty files, instead they’ll distribute jars like they’ve always done, but some of these jars may contain tasty files in addition or instead of classfiles, but in the end you need to trust the whole jar (and all of its dependencies too).
Presumably the compiler? How does the compiler decide something is or is not valid?
Maybe it’s at the layer of JAR resolution, like Coursier.
ssh asks you
The authenticity of host 'example.com (192.168.22.2)' can't be established.
RSA key fingerprint is 5c:00:46:26:31:22:d4:23:e4:11:cd:41:43:0e:fb:02.
Are you sure you want to continue connecting (yes/no)? yes
If there’s a build level include- and exclude-list, that could be used to alert newly added unknown signature.
That’s only secure for “trust on first use” type models though, which are designed to prevent MiTM attacks on point-to-point systems like SSH. There are two problems here as it relates to Maven though. First, the dependency ecosystem is massively branching, and extremely multi-latteral. Even if we wanted to go with trust-on-first use, the number of prompts that users would have to pass through would be HUUUUUUUGE, particularly the first time they run a build. This alone kills it as an idea, since users would just hit “enter” a zillion times without actually thinking about it, and who could blame them? Second, dependencies are something which are added and removed quite frequently outside your control (particularly transitive dependencies), meaning that “first use” isn’t even a definite point in time.
I don’t think this is an intractable issue. First, we are dealing with O(library publishers), not O(artifacts). Plus, there has to be a 80:20 rule happening with the usage histogram of Java or Scala libraries. There are many exceptions, but many of the Java libraries are often wrapped in a Scala library, so if there’s a centrally maintained seed of public keys containing most frequently occurring keys, the users at the leaf would need to verify just the long tail of other things.
To prevent weird transitive dependency doing bad things, yes/no popping up for unknown transitive dependency author would be good thing. At that point, the end user can either verify themselves (e.g. oh look Netty just added some library foo 1.0), or update the centrally maintained list.
This is an interesting idea. I wonder what the use case is of signing individual TASTY files? Is it already solved by signing the container they come distributed in? In principle can someone who cares about this issue use the GPG signatures that already exist in maven central?