On Mon, 2008-12-08 at 20:19 +0100, Christof Glaser wrote: > >> 3. A security bug is found in a gem that Bob is using and Richard > >> wants > >> to install an even newer, patched version system-wide and have it > >> override Bob's version. > > #3 has a lesser priority for me than the other points. Richard could > sent an email announcing the newer version fixing the security bug to > his customers. I think it might create problems for customer's > installations if the hoster can upgrade gems that automatically > override a customer-specific version – you can never be quite sure if > it's 100% compatible and not possibly breaking customer's apps. The > longer I think about it, the more I'm convincing myself that this > looks like a hosting policy issue which should not be solved by > technical means. So Bob would be responsible for the security of gems > he installed himself, whereas he could rely on Richard if he used > system-wide gems. Rubygems lets you set dependencies. If Bob sets an = dependency, his version will always be used. If he sets something more flexible, the system-wide version can override. (But really, if a new version of the gem breaks things, that's either because either the upstream gem author didn't follow their versioning procedure or because the gem user didn't set the dependency properly.) Richard
Attachment:
signature.asc
Description: This is a digitally signed message part