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
