cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: SMTP: compatibility concerns with bug #1389

From: Jacob Champion <jacob.champion_at_ni.com>
Date: Wed, 20 Aug 2014 11:19:51 -0500

Hi Daniel,

On 8/19/2014 4:18 PM, Daniel Stenberg wrote:
>> From what I can tell from the previous conversations [2] on the topic,
>> the official statement seems to be that any SMTP client that wasn't
>> setting CURLOPT_UPLOAD was buggy. I'm fine with that, if that's the
>> answer (and we'll be adding CURLOPT_UPLOAD to our new client code).
>> But as someone looking in from the outside, it seems like it was sort
>> of a retroactive decision -- especially since the libcurl SMTP
>> examples didn't have it either.
>
> What's a bug and what's an ABI/API breakage often leads to a judgement
> call. We discuss it, we take a decision and we move on. Sometimes not
> everyone agree on the way we dealt with a specific issue.

Do you have a gut feel for which way that judgment call typically goes,
specifically for CURLOPT compatibility? Or is it truly case-by-case? And
are those discussions just something we need to keep an eye out for on
the curl-library list, or do they happen somewhere else?

>> Put another way: How do I ensure that our current libcurl client code
>> (HTTP, SMTP, or otherwise) does not contain other bugs of this nature,
>> so that we won't break in the future because of a missing CURLOPT?
>
> You participate on the mailing list when such issues occur and you speak
> up your mind if you disagree with the direction in which we're going. Or
> you help us write up more test cases that make sure we maintain certain
> behaviors. And you file bug reports when you find bugs and problems.

Okay! Well then, here are our/my two cents. (Keeping in mind that we are
only one client out of the thousands you have, and we haven't
contributed any patches back yet, and that discussions of "bug
compatibility" can get contentious...)

Typically we'll follow the strategy of "write the smallest amount of
code that works", to reduce maintenance and make it harder to write
cargo cult code. So, for example, if libcurl example code contains
fifteen CURLOPT settings to do task X, but we can do it with ten -- and
if the documentation doesn't make those other five seem like they're
necessary -- that's what we'd do. I'm certainly rethinking that strategy
now, but that's where we were coming up to this point. I'd be surprised
if there weren't at least a few other clients out there who think the
same way.

So for us, retroactively adding CURLOPTs to the "minimum list" required
for any given task is an API break. And in our ideal world, that would
never happen without an SONAME change. But I'm trying to recalibrate
that expectation into something more in line with what the library's
actual policy is; hence my earlier questions.

(Just to be clear: I'm not trying to say that you should support code
that relies on undefined behavior, or code that explicitly disobeys
libcurl documentation. I also think that compatibility breaks are
perfectly acceptable when it comes to security vulnerabilities, if it
means that applications in the wild become safer. I don't think this
particular case falls under any of these categories.)

All that aside, _if_ one of these breaks is necessary, we'd really like
to have a big red flag put into the upgrade notes. Bonus points if
clients are given a way to easily revert the behavior (patchset,
#define) but I have no idea how common these sorts of breaks are, so I
don't know if that's a reasonable request.

It'd also be nice to have a baseline guarantee of _some_ level of
functional compatibility, in addition to the current API and ABI
guarantees. Even something like "libcurl will not break the example code
emitted by past versions of the curl executable, except in critical
situations such as security vulnerabilities" would go a long way to help
us avoid situations like this.

> We're (without me being able to speak for anyone else besides myself of
> course) determined to keep doing a great product but we of course depend
> on people to actually make sure it stays this way.

For what it's worth, we think it's a great product, and has been for
some time now. Thanks for your work on it, and for your quick response!

Jacob Champion
LabVIEW R&D
National Instruments
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-08-20