On Thu, Jul 9, 2020 at 12:00 AM Ernie Rael <err...@raelity.com> wrote:
> On 7/8/2020 6:48 PM, Tim Boudreau wrote: > > Isn’t that security threat the reason JAR signing was invented? > > I've heard that all, or almost all, plugin portal nbm's are self-signed. > > How does that affect the security implications? > > I've also heard that PP3 doesn't require jar signing; see > https://issues.apache.org/jira/browse/NETBEANS-2331 Absolutely there are issues with the fact that code-signing certificates are expensive. FWIW, I sign the NBMs I distribute with my timboudreau.com certificate - which is *not* a code-signing certificate, so the build generates a warning that the signature will only be valid for a short time. Curiously, the IDE reports them as self-signed, which is wrong. I think it would be great if large organizations such as the ASF could pressure or work with the LetsEncrypt folks to offer code-signing certificates - it is ridiculous that they cost more than an ordinary SSL cert. As for what security signing offers, it offers exactly the same thing as HTTPS does: You can verify that the bits are the same bits that the author signed, unmodified. Just as with HTTPS, that does not tell you that the author is trustworthy - that is up to you - it just tells you that the author is who you think it is and the bits are what you think they are. Limiting the universe to a single plugin portal does *absolutely nothing* to change the security situation. Whether you have one portal *full of self-signed nbms* or 10,000 portals *full of self-signed nbms*, the situation is exactly the same. The *really, really right way* to solve this is to fix the situation with code-signing certificates (and make it less of a PITA to use them - I seriously think most tools and APIs for working with encryption are intentionally obfuscated, and Java's support for encryption made that even worse by inventing new abstruse and wholly unnecessary concepts to make it even more initimidating - whether that's due to governments not wanting people to use encryption, or because being a cryptographer is mutually incompatible with understanding usability I leave as an exercise to the reader). That said, since we're unlikely to change the situation with regard to code-signing certs worldwide any time soon, Jesse's suggestion in the bug linked above is the more reasonable way to go: As long as signature information is downloaded via HTTPS from the same origin as the NBM, and the receiver knows how to verify the bits with it, the HTTPS connection is solving the "am I being man-in-the-middled" problem, and that's the only thing the certificate in JAR signing adds to the picture. The IDE just needs to enforce that the signature must by downloaded from the same domain using the same HTTPS cert as the NBM. There's no reason to limit the places NBMs can be downloaded from to Maven Central - just define the metadata (which could *be* the same as the gpg signatures Maven uses) and have the code that downloads it enforce the same-domain requirement, so that anyone running an update server can provide signatures. -Tim
