4 ms·

Which, as the authors show in section 7.1 and 7.2 of their paper, many PHP developers, like the authors of the Amazon Flexible Payments Service SDK and the PayP

by rolux 14y ago

Which, as the authors show in section 7.1 and 7.2 of their paper, many PHP developers, like the authors of the Amazon Flexible Payments Service SDK and the PayPal Payments Standard SDK, will happily override with true.

grannyg00se 14y ago
You would have to read the docs to find the parameter you wish to overwrite would you not? I don't see how the curl behaviour can be faulted. If you are overwriting a default you are responsible. And you are reading the docs anyway.
- rolux 14y ago
  Of course the developers are at fault here, but good API design would be to not invite developers to mess things up. When designing the Curl API, it should have been obvious that VERIFYHOST is likely be set incorrectly, especially once it's used in languages that coerce true to 1.
- tptacek 14y ago
  This is like saying any API is reasonable as long as it's documented. If you read the example, they found numerous examples of people who clearly weren't intending to disable SSL certificate validation who nonetheless overrode that default.
  - grannyg00se 14y ago
    No, not any API. But if the defaults err on the side of caution, which is the case here, and the non-default documentation is complete and coherent, I think that's pretty good. I don't think I would call this situation unreasonable, though I do agree that it could be improved.
- barrkel 14y ago
  There's a simple concept that one should bear in mind when designing APIs: "pit of success" (credit to Rico Mariani). That is, failure should take effort. Dangerous options should be more laborious to express. The happy path should be the most concise and straightforward path.
  - grannyg00se 14y ago
    I would say that by having the default be the safer option, the API is in line with that philosophy. It takes more effort to override the default and shoot yourself in the foot. Granted, it could be better. I guess that strange option could be a completely separate command parameter with a very obvious name. Then again, it's such a strange behaviour, maybe it just shouldn't even be an option at all.
    - crawfordcomeaux 14y ago
      The effort it takes to do something that's unsafe should be laborious and not simply require adding a single line of code. This API doesn't fit with the philosophy because it takes a negligible amount of work to walk down the unsafe path.
- danielweber 14y ago
  Many times as a developer I have followed other people's example code. And if I see someone's code say curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE); I and any normal developer is going to think "oh, this is important, I'd better make sure to leave it in there." Configuration audits aren't as expensive as code audits, but they are still expensive.

by rolux 14y ago

grannyg00se 14y ago

You would have to read the docs to find the parameter you wish to overwrite would you not? I don't see how the curl behaviour can be faulted. If you are overwriting a default you are responsible. And you are reading the docs anyway.

rolux 14y ago
Of course the developers are at fault here, but good API design would be to not invite developers to mess things up. When designing the Curl API, it should have been obvious that VERIFYHOST is likely be set incorrectly, especially once it's used in languages that coerce true to 1.
tptacek 14y ago
This is like saying any API is reasonable as long as it's documented. If you read the example, they found numerous examples of people who clearly weren't intending to disable SSL certificate validation who nonetheless overrode that default.
- grannyg00se 14y ago
  No, not any API. But if the defaults err on the side of caution, which is the case here, and the non-default documentation is complete and coherent, I think that's pretty good. I don't think I would call this situation unreasonable, though I do agree that it could be improved.
barrkel 14y ago
There's a simple concept that one should bear in mind when designing APIs: "pit of success" (credit to Rico Mariani). That is, failure should take effort. Dangerous options should be more laborious to express. The happy path should be the most concise and straightforward path.
- grannyg00se 14y ago
  I would say that by having the default be the safer option, the API is in line with that philosophy. It takes more effort to override the default and shoot yourself in the foot. Granted, it could be better. I guess that strange option could be a completely separate command parameter with a very obvious name. Then again, it's such a strange behaviour, maybe it just shouldn't even be an option at all.
  - crawfordcomeaux 14y ago
    The effort it takes to do something that's unsafe should be laborious and not simply require adding a single line of code. This API doesn't fit with the philosophy because it takes a negligible amount of work to walk down the unsafe path.
danielweber 14y ago
Many times as a developer I have followed other people's example code. And if I see someone's code say curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE); I and any normal developer is going to think "oh, this is important, I'd better make sure to leave it in there." Configuration audits aren't as expensive as code audits, but they are still expensive.