I think just discussing this is giving me some good info
and the thought in having is their should be a well maintained
doc somewhere that can lay out these specific issues
what is secure
what is the best choices currently to use
as far as gems etc there just need to be more of a backwards compatible nature to things, imo
again the very nature of ruby is so fast paced that methods go obsolete quite often from release to release
a site that used render calls becomes unusable when respond_to came into existence
take a designer who has no real knowledge of rails asked to reskin the site
trying to figure out why his Ajax calls aren't working
should the framework should warn of these inconsistencies ? probably
should the designer have to search through countless sites to find out that jquery is being used now instead of prototype? probably not
On[masked], at 13:25, Godfrey Chan <[address removed]> wrote:
For the compatibility problem in particular, you may try http://www.railsplugins.org/, but it's still community maintained and it's more or less a best effort thing.
For removing "stale" gems, I think the problem is the criteria would be impossible to define. Most gems doesn't go from maintained into unmaintained overnight. Usually, the developer faced a particular problem at hand, came up with a satisfying solution and shared it with the world. Then you moved on to different projects where the original problem you were trying to solve us no longer an issue for yourself, and quite naturally you don't spend much time maintaining the old gem anymore (and you wouldn't be the best person to do that anyways). Almost no one would label their gems abandoned. It's simply a matter of " I don't have time for this right now" or "It's not my priority at the moment".
On Sunday, February 3, 2013, Godfrey Chan wrote:
Oops. Resending with completed body.
It really depends on what evaluate, and what options do you have.
Doing security audits by experts is the only way to ensure your code (whether you wrote it or not) is (reasonably) secure. Most people are underqualified to do these sort of audits, myself included. Maintaining high security standard is very expensive.
For most projects, hiring a security expert to do regular security audit is in feasible. The next best thing you can do to approximate that is to rely on the experts in the community to review the key components (Ruby, Rails, etc) you rely on, and follow their recommendations as issues are discovered. (Subscribe to the security list if you haven't already.)
But then the problem is that the community is very constrained on (human) resources, and quite naturally old releases are getting less attention than the current ones. So if you are unable to move up to the current releases, and couldnt afford to hire your own reviewers, then your options are quite limited. You can probably learn some basic security principals and make sure your code and it's dependencies are not trivially exploitable, but beyond that I'm not sure it there's much else you could do.
If you are stuck on old, possibily unmainted versions, then you'd just have to bare with the risk of not getting audits/advisories/patches, and decide if that risk is more expensive than upgrading. Everyone says/would like to think that security is their top priority, but this is much easier said than done. Sometimes your application and the data it holds just isn't mission critical enough to justify the security-maintenance expense, and you'd just have to live with that.
So to reiterate, if you could afford it, it's always better to keep your dependencies up to date and run on actively maintained versions. So security-wise, Rails 3.2 is better than 3.1, and (oddly) 2.3 is better than 3.0 (but not for long); likewise, Ruby 1.9 is better than 1.8 - if that's what you're asking.
If you're asking "I'm stuck on an unmaintained version, what can I do?" Then I'm afraid the answer is not what you wanted to hear. Your best bet is to probably follow security advisories for maintained versions and try to determine if the version you're on is similarly affected and try to work out a similar patch. But then again, most people are under qualified to do that sort of stuff and it's not unlikely that you end up breaking something else in the process.
On Sunday, February 3, 2013, Clayton Cottingham wrote:
sure! who watch dogs the gems still in the system that are inactive, no longer useable etc? why arent they removed from the gem repos??
CPAN for perl does this sort of check, if a perl module fails it isnt allowed to be searched and used, but one can still download at their own peril, its just not available through cpan interface
moving to 3.2 isnt always a choice. clients are running what they are running and moving to a new version of rails is a daunting task for some and sometimes time and money are involved
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Godfrey Chan ([address removed]) from Vancouver Ruby Meetup Group.
To learn more about Godfrey Chan, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages
Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]