4 ms·

Compare and contrast with the Rails attr_accessible kerfuffle of last week, where it was generally held by (I think) the majority of commenters that the library

by telent 15y ago

Compare and contrast with the Rails attr_accessible kerfuffle of last week, where it was generally held by (I think) the majority of commenters that the library should not have provided this convenient feature or at least should have made it more difficult to enable. I'm right there with this "startling" (some would say "opinionated") position. And so is my C library, which complains at me every time I compile a program using getwd() ("my" as in the one I have installed here. I am making no ownership claim)

tptacek 15y ago
Huh? attr_accessible is the whitelist feature; the argument was that it should have been non-optional.
- telent 15y ago
  Indeed it is as you say. "attr_accessible kerfuffle" was my (apparently, and quite bizarrely, considered inflammatory) shorthand to refer to the whole episode. I'd edit the post to clarify, but it won't let me do that any more
hythloday 15y ago
Heh, I'm certainly not against static analysis and warnings. The library author is talking about not making locks re-entrant, though, which would mean that in the case where you accidentally try to use a lock that way, the program either crashes or deadlocks. That's the better solution?
nknight 15y ago
Yes. Contrast. Massive contrast. The Rails "kerfuffle" was about unnecessarily dangerous default settings affecting a widely-used (including in official tutorials) mechanism. To even get a recursive mutex in POSIX, you have to explicitly ask for one, they're not even mentioned in most (any?) tutorials, they don't pose any direct security threat, and unlike Rails, POSIX threads are not a common thing for brand-new developers to be using, much less in anything exposed to the public Internet.
- telent 15y ago
  I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over the encouragement of reliable programming practice. Why should it be considered a good thing for a Posix standard to take the same position? Ignore questions of reach and impact, the comparison is one of attitude not of effect. Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers
  - nknight 15y ago
    No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem. And since you want to argue based on SO, I'll just leave you with two bits of data from SO: http://stackoverflow.com/questions/tagged/pthreads http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions http://stackoverflow.com/questions/tagged/ruby-on-rails http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions
    - telent 15y ago
      Guess what? I consider that a bad thing too. But you're still reading things into my comment other than what I said. (1) Rails had insecure defaults which encourage bad programming (2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming. (3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library. That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.

by telent 15y ago

tptacek 15y ago

Huh? attr_accessible is the whitelist feature; the argument was that it should have been non-optional.

telent 15y ago
Indeed it is as you say. "attr_accessible kerfuffle" was my (apparently, and quite bizarrely, considered inflammatory) shorthand to refer to the whole episode. I'd edit the post to clarify, but it won't let me do that any more

hythloday 15y ago

Heh, I'm certainly not against static analysis and warnings. The library author is talking about not making locks re-entrant, though, which would mean that in the case where you accidentally try to use a lock that way, the program either crashes or deadlocks. That's the better solution?

nknight 15y ago

Yes. Contrast. Massive contrast. The Rails "kerfuffle" was about unnecessarily dangerous default settings affecting a widely-used (including in official tutorials) mechanism. To even get a recursive mutex in POSIX, you have to explicitly ask for one, they're not even mentioned in most (any?) tutorials, they don't pose any direct security threat, and unlike Rails, POSIX threads are not a common thing for brand-new developers to be using, much less in anything exposed to the public Internet.

telent 15y ago
I think you've jumped at a different parallel than the one I was trying to draw. It's considered a bad thing that Rails prioritised developer convenience over the encouragement of reliable programming practice. Why should it be considered a good thing for a Posix standard to take the same position? Ignore questions of reach and impact, the comparison is one of attitude not of effect. Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers
- nknight 15y ago
  No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem. And since you want to argue based on SO, I'll just leave you with two bits of data from SO: http://stackoverflow.com/questions/tagged/pthreads http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions http://stackoverflow.com/questions/tagged/ruby-on-rails http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions
  - telent 15y ago
    Guess what? I consider that a bad thing too. But you're still reading things into my comment other than what I said. (1) Rails had insecure defaults which encourage bad programming (2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming. (3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library. That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.