On 10/21/2013 01:14 PM, Daniel Stenberg wrote:
> On Mon, 21 Oct 2013, Christian Grothoff wrote:
>
> First, stop the top-posting please.

Eh, I've always hit "reply" in Icedove, so this should not create top-posts.

>> Is it common that nobody responds in a timely fashion to patches sent
>> to this list? I'd really like to know if this patch is now going to
>> be accepted, or if we have to do something else to get access to SSL
>> certificates.
>
> You only replied to the last response in this thread just *now* (40
> minutes after this email in fact) - it hasn't had a chance to grow stale
> yet. While the discussion is ongoing about a change/patch it doesn't
> make sense to merge a version that might change.

Actually, I did send the reply first on Oct 16th at 12:34am, but somehow
that response did not make it to the mailing list, and after Jeffrey
Walton pointed this out to me in a private mail in response to my
"rant", I reposted the message today.

> A common procedure for users of open source projects that want something
> done in the upstream project is to make it and use it locally while
> you're upstreaming it.

I am. However, I want to avoid making a software release and telling
people to apply some patch to some dependency to make it work.

> That way you get testing of the feature before it
> gets merged officially and you won't have to wait for anyone upstream to
> do the work. Sure, the risk is that what gets merged is something
> slightly different than what you're using but that's the price you need
> to be prepared for.
>
> You whining on the project will not help AT ALL. Trust me, I do the best
> I can already without whining. I think that goes for most of the people
> involved in this project. And elsewhere.
>
> If you want things to go faster, then make things even easier for us and
> remove even more obstacles; add tests and documentation already without
> us asking for it, provide the patches in trimmed and accurate git
> format-patch syntax etc. And if possible, get more support from other
> people that can testify about your feature's greatness and necessity.
>

I did add documentation (to the man page), and generated the Git patch
using the instructions from your documentation on how to contribute.

As to the necessity, have you read the news on how many CAs have been
compromised recently? Do no other cURL clients see the need to possibly
perform extended validation outside of the pure X.509 specification
(i.e. RFC 6962, Certificate Patrol (Firefox add-on), DANE (DNSSEC),
Covergence (Marlinspike))? Implementing _any_ of those alternatives
requires access to the certificates, which cURL today makes impossible.

So does anyone else on this list care about good security (ok, within
the limits set by TLS)? If so, please let Daniel know that access to
certificate data might be a good thing. If you don't care about
security, please turn of your computer now ;-).

-Christian
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-21