Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not disputing that this change is a step in the right direction, but the implication that it solves roughly the same problem as the existing OpenPGP-based infrastructure is very misleading. [Edit: if you din't mean to imply this by your post then I apologize; it was not clear from how I read it.]

Same with the idea that you can "just apply a 10-line patch" without considering the background in documentation, tooling, and educating the community that such a change would require--it implies that the current rubygems maintainers are ignorant or lazy for not having done this easy fix already.

(I spoke at length on a PGP-based approach to this same problem at the 2012 Clojure Conj conference if you would like to talk about credentials: https://www.youtube.com/watch?v=sBSUIKMdQ4w)



I didn't claim it solves "roughly the same problem", only a very relevant subset of the problem (integrity) closely related to the unfortunate situation rubygems is in right now.

What you call background (docs, tooling, education) is an argument in favor of the simple approach, which is already implemented and just not enforced - in contrast to whipping up new infrastructure of significantly higher complexity from scratch.

Also I didn't imply the maintainers are ignorant or lazy, they were merely oblivious.

So I'll repeat: The PGP approach is obviously superior, but comes with serious complexity and implementation concerns (there is no native PGP-library in ruby). Consequently it might make sense to add basic security right now, in a minimally intrusive fashion, while a more complete solution is developed. This, by the way, is part of the discussion that the rubygems team is having right now[1].

[1] https://github.com/rubygems-trust/rubygems.org/wiki/Overview




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: