HTTPS Support Launching Now | Hacker News Reader

HTTPS Support Launching Now

central.sonatype.org

62 pointskarlmdavis18 comments

This is Sonatype's response to the earlier "How to take over the computer of any Java (or Clojure or Scala) developer" concerns and discussion [1]. I'm very relieved they've fixed the big problem there, as having so much infrastructure reliant on plain HTTP was a giant hack waiting to happen.

[1] https://news.ycombinator.com/item?id=8099713

I've got to say, it is definitely refreshing to see a company just quickly give a mea culpa and fix the problem rather than doubling down and arguing about the reasons for the problem to have existed in the first place. I definitely have more respect for them for doing this (even if they should have been doing it all along, at least it's a correct response to the criticism).

They do blame the reason they didn't do it on the lack of demand from the users.

> extremely short turnaround time

Come on, please. Sonatype had HTTPS intentionally only for Nexus/Artifactory/… users since at least 2007.

Except that this does not really give you that much security. Maybe only in the transport, but certainly not verification of content.

HTTPS (or SSL/TLS for that matter) only verifies the identity of the server the content is coming from. Since users can upload stuff to repositories on Sonatype, there is no verification of content whatsoever.

A naive workaround of this is to use PGP signed content. This would work, if users actually verified the PGP signature through a third channel. Either using web of trust, or some other means of getting a verification that the PGP key actually belongs to the developer.

Failing that, HTTPS is just snake-oil security here.

No measure taken in isolation will give you "that much security". As you say, validating the identity of the artifact signer is an extremely important and oft-missed measure, but that should not lead one to conclude that transport layer security (both confidentiality and server authentication) is unimportant or "snake oil".

I will give you that web PKI sucks, but I would rather have a bit more assurance (even if imperfect) that the site I'm pulling artifacts from is indeed the one I intended to retrieve them from, even if I have a good signature + signer verification mechanism in place.

Thanks guys for the great work!

Is it enough? http://blog.bintray.com/2014/08/04/feel-secure-with-ssl-thin...

The author seems to forget that a key server makes no validation assurances, it just hosts said key.

There are various other flaws in it and he doesn't seem to understand how the PGP WoT works...

The author of what?

Presumably the post you just linked to

Which based on the blog author and the HN username, is himself.

Well, in that case @iancarroll didn't read the post. What he claims I don't understand is exactly what the post says.

I think @iancarroll is pointing out that you seem to be conflating signature and identity verification. They are different concerns, yet both are both necessary for secure software distribution.

Fine if you reject web-of-trust style identity verification, but your notion of "web identity verification" is not in any way a good substitute for code signature verification. What if someone compromises your hosted repository? Unless your artifact were already cryptographically signed, no amount of identity verification is going to help you.

That's very true. That's why Bintray has both "web identity verification" and pgp signing, while Maven Central gives you signing only, without a way to really identify the author.

Fwiw, Bintray requires the private key and passphrase to do the signing. This isn't really proper key handling and has been pointed out before.

Brian, how ignorant of you (again). The docs on signing are public, you could read before spreading FUD.

Public shaming works!

Reply on news.ycombinator.com