Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: C99
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Kevin R. Bulgrien via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 22 Sep 2022 10:02:04 -0500 (CDT)
As the following might be seen as an argument, bear in mind that my posts
are meant to applaud curl, libssh2, and openssl, and others, for advancing
my ability to mitigate insecurity because the people that contributed have
expended effort that put within my reach an ability to build a security
improvement for use on an old system.
I have heard on this list, that failure to speak up is one of the things
that justifies decisions going one way or another. I therefore choose to
speak up.
> On Wed, Sep 21, 2022 at 11:50:50AM -0700, Ben Greear via curl-library
> wrote:
>
>> My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
>> systems with old compilers...
>
> This certainly makes life easier for people who are forced to use
> ancient systems, but it doesn't come for free. curl developers are then
> stuck in a time warp from 33 years ago, a time when 79% of adults alive
> today weren't even born. None of the improvements in the language made
> in the subsequent one-third century are available to us to improve the
> development experience.
>
> Kevin's message highlights another issue; even if curl can be built on a
> 21-year-old compiler, lots of other packages can't. And in the world of
> the Internet of 2022, you can't rely on older packages because of
> security concerns. So, what's the point of begin able to compile the
> latest curl to get its security fixes when you're forced to use an
> outdated TLS library riddled with security issues, or run on a kernel
> that has been broken a dozen times over, or use a libc full of security
> holes?
>
> Moving to C18 (or C23) right now isn't on the table, since it does take
> a while for toolchains to get that support. But, at some point we're
> going to have to say that if people want the benefits of the latest
> curl, they're going to have to use a compiler made in the same
> millennium. One could go so far as to argue that keeping C89
> compatibility is irresponsibly encouraging users to stick with outdated
> dependencies with security issues and is therefore harmful to the
> Internet as a whole.
The logic here seems pretty self-serving. I mean, I guess that's fine in
some sense, but to somehow bend the irresponsibility of others in running
an old system into "our irresponsibility" when in fact, we are actually
finding a way to mitigate assumed "irresponsibility" by choosing to spend
effort on the behalf of others whether it is "convenient" or not. Calling
behavior "irresponsible" without bothering to listen to the whole story is,
well, quite potentially irresponsible in its own right. Frankly, I can be
a person that blasts other people, or, I can responsibly advocate for what
I see as better, and where I cannot change minds, I can still put sweat
behind my beliefs for the betterment of the world and relationships in
general. The point-of-view expressed has merit, but it seems that it
could bear some refinement.
By advocating for "our responsibility" to avoid backwards compatibility
because it "promotes irresponsibility", comes off to some of us as, well,
so sad to be you, a responsible person, because we are going to rip away
your ability to be responsible, because we despise the actions of others
and because it makes our lives easier. Mind you, having done these hard
things, I appreciate making lives easier, but I also greatly appreciate
the additional effort by others to make my life easier too.
As a responsible person, living in a world full of what I think of as
less-than-best decisions, I am going to put my energy into making the
best of what I find swirling around me, rather than focusing on letting
everyone know why they are irresponsible people and sitting back doing
nothing to contribute to what I see as a better way.
So essentially, if I follow the logic here, I am actually, an irresponsible
person because I have empowered someone to continue to run an old system -
as if I was irresponsible myself, even though, by doing what I am, there
has been a reduction in potential negative impact of a decision I have no
ultimate control over. So, yeah, I don't want any part of that kind of
thinking. I actually doubt that is what was intended, but that is how it
reads.
I can wall off the system by any number of means, but, ultimately, for a
system to be usable, it needs to have at least one communication mechanism
that is as secure as possible so it can communicate with gatekeeper systems.
I mentioned what I did, not provide fodder for people to take away tools
that let me mitigate risk, but to help them realize that their efforts have
helped me make the world a safer place. Please don't accuse someone that
patched libssh2, openssl 3.0.3, submitted patches to curl, and made this
thing, of actually being irresponsible for doing so without first engaging
at a level that can help you see what kind of person I actually am and what
I actually do with respect to placing pressure toward or away from good.
Mind you, I am not demanding that curl, or anyone else, act in my interests,
but please do not disparage people who are mindful of complexities in the
world and that are working in their own way, to raise a bar to better
height, even if the effort appears, from some vantage point, to be
piteously inadequate, or, irresponsible.
> I could actually go back and rewrite this e-mail to replace C89 with C99
> and make pretty close to the same arguments. C99 will be just a few
> months shy of a quarter century old by the time this proposal would kick
> in next year. Maybe the proposal should really be to switch directly to
> C11 (instead of C99), since it will already be 12 years old by the time
> of curl 8.0. That's probably too aggressive, though, since there are
> companies around today back-porting security fixes into software nearly
> that old, so it's harder to make the irresponsibility argument for that
> one.
The point, again, is to applaud the curl project for advancing my ability
to mitigate insecurity because they have expended effort that put this
within my reach, and to encourage a good feeling that they have helped
one person in an effort to be responsible.
I think the above is relatively reasonable to consider, and doesn't
really require my further engagement with respect to the project's
decision.
Date: Thu, 22 Sep 2022 10:02:04 -0500 (CDT)
As the following might be seen as an argument, bear in mind that my posts
are meant to applaud curl, libssh2, and openssl, and others, for advancing
my ability to mitigate insecurity because the people that contributed have
expended effort that put within my reach an ability to build a security
improvement for use on an old system.
I have heard on this list, that failure to speak up is one of the things
that justifies decisions going one way or another. I therefore choose to
speak up.
> On Wed, Sep 21, 2022 at 11:50:50AM -0700, Ben Greear via curl-library
> wrote:
>
>> My opinion is to stay conservative, for those wanting/required to build recent curl on ancient
>> systems with old compilers...
>
> This certainly makes life easier for people who are forced to use
> ancient systems, but it doesn't come for free. curl developers are then
> stuck in a time warp from 33 years ago, a time when 79% of adults alive
> today weren't even born. None of the improvements in the language made
> in the subsequent one-third century are available to us to improve the
> development experience.
>
> Kevin's message highlights another issue; even if curl can be built on a
> 21-year-old compiler, lots of other packages can't. And in the world of
> the Internet of 2022, you can't rely on older packages because of
> security concerns. So, what's the point of begin able to compile the
> latest curl to get its security fixes when you're forced to use an
> outdated TLS library riddled with security issues, or run on a kernel
> that has been broken a dozen times over, or use a libc full of security
> holes?
>
> Moving to C18 (or C23) right now isn't on the table, since it does take
> a while for toolchains to get that support. But, at some point we're
> going to have to say that if people want the benefits of the latest
> curl, they're going to have to use a compiler made in the same
> millennium. One could go so far as to argue that keeping C89
> compatibility is irresponsibly encouraging users to stick with outdated
> dependencies with security issues and is therefore harmful to the
> Internet as a whole.
The logic here seems pretty self-serving. I mean, I guess that's fine in
some sense, but to somehow bend the irresponsibility of others in running
an old system into "our irresponsibility" when in fact, we are actually
finding a way to mitigate assumed "irresponsibility" by choosing to spend
effort on the behalf of others whether it is "convenient" or not. Calling
behavior "irresponsible" without bothering to listen to the whole story is,
well, quite potentially irresponsible in its own right. Frankly, I can be
a person that blasts other people, or, I can responsibly advocate for what
I see as better, and where I cannot change minds, I can still put sweat
behind my beliefs for the betterment of the world and relationships in
general. The point-of-view expressed has merit, but it seems that it
could bear some refinement.
By advocating for "our responsibility" to avoid backwards compatibility
because it "promotes irresponsibility", comes off to some of us as, well,
so sad to be you, a responsible person, because we are going to rip away
your ability to be responsible, because we despise the actions of others
and because it makes our lives easier. Mind you, having done these hard
things, I appreciate making lives easier, but I also greatly appreciate
the additional effort by others to make my life easier too.
As a responsible person, living in a world full of what I think of as
less-than-best decisions, I am going to put my energy into making the
best of what I find swirling around me, rather than focusing on letting
everyone know why they are irresponsible people and sitting back doing
nothing to contribute to what I see as a better way.
So essentially, if I follow the logic here, I am actually, an irresponsible
person because I have empowered someone to continue to run an old system -
as if I was irresponsible myself, even though, by doing what I am, there
has been a reduction in potential negative impact of a decision I have no
ultimate control over. So, yeah, I don't want any part of that kind of
thinking. I actually doubt that is what was intended, but that is how it
reads.
I can wall off the system by any number of means, but, ultimately, for a
system to be usable, it needs to have at least one communication mechanism
that is as secure as possible so it can communicate with gatekeeper systems.
I mentioned what I did, not provide fodder for people to take away tools
that let me mitigate risk, but to help them realize that their efforts have
helped me make the world a safer place. Please don't accuse someone that
patched libssh2, openssl 3.0.3, submitted patches to curl, and made this
thing, of actually being irresponsible for doing so without first engaging
at a level that can help you see what kind of person I actually am and what
I actually do with respect to placing pressure toward or away from good.
Mind you, I am not demanding that curl, or anyone else, act in my interests,
but please do not disparage people who are mindful of complexities in the
world and that are working in their own way, to raise a bar to better
height, even if the effort appears, from some vantage point, to be
piteously inadequate, or, irresponsible.
> I could actually go back and rewrite this e-mail to replace C89 with C99
> and make pretty close to the same arguments. C99 will be just a few
> months shy of a quarter century old by the time this proposal would kick
> in next year. Maybe the proposal should really be to switch directly to
> C11 (instead of C99), since it will already be 12 years old by the time
> of curl 8.0. That's probably too aggressive, though, since there are
> companies around today back-porting security fixes into software nearly
> that old, so it's harder to make the irresponsibility argument for that
> one.
The point, again, is to applaud the curl project for advancing my ability
to mitigate insecurity because they have expended effort that put this
within my reach, and to encourage a good feeling that they have helped
one person in an effort to be responsible.
I think the above is relatively reasonable to consider, and doesn't
really require my further engagement with respect to the project's
decision.
-- Kevin R. Bulgrien -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-22