couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KlausTrainer <>
Subject [GitHub] couchdb pull request: Support `fail_if_no_peer_cert` ssl option
Date Wed, 14 May 2014 09:50:53 GMT
Github user KlausTrainer commented on a diff in the pull request:
    --- Diff: etc/couchdb/local.ini ---
    @@ -66,6 +66,8 @@
     ;password = somepassword
     ; set to true to validate peer certificates
     verify_ssl_certificates = false
    +; Set to true to fail if the client does not send a certificate. Only used if verify_ssl_certificates
is true.
    +fail_if_no_peer_cert = false
    --- End diff --
    On 05/13/2014 06:00 PM, Alexander Shorin wrote:
    > I understand the position "RTFM First", but that's the actual problem
    > of all configurations: you're reading the config, you're don't
    > understand what the options actually does, you're going to google
    > (nobody reads the docs) to find the answer or to ML to ask the same
    > question again.
    I agree, we should definitely try to give good explanations in the
    documentation.  Creating high-quality documentation is one way to get
    people to actually read the documentation ;)
    > Name should reflect the behaviour clearly. "Fail" is good for Erlang
    > since "Let it crash!", […]
    You're mixing up different things here.  This is not about the Erlang
    "let it crash" philosophy.  Are we talking here about the `ssl`
    configuration section, and the corresponding section in the
    documentation which is captioned "Secure Socket Level Options"?  Isn't
    it clear from the context that this is not about Erlang/OTP principles?
    I updated the documentation to make it more clear that this is about the
    TLS/SSL handshake.  The purpose of such a handshake is to establish a
    TLS/SSL session.  If the server decides that it doesn't want to
    establish a session because the client does not send a certificate, it
    will send a "handshake failure" alert message and close the connection,
    which means that the handshake "failed".  Using the term "fail" in that
    context is not something made up by me or by the people who created the
    ssl application with that very "fail_if_no_peer_cert" option, it's the
    technical terminology that has been introduced in the respective RFCs,
    and which is actually used by the people who are talking about that
    > […] but CouchDB wouldn't actually "fail" because of empty client
    > certificate: it will just reject such requests and keep going.
    I agree that this makes a difference, at least for us.  However, end
    users usually don't care if the server is actually running or not when
    their browser can't establish a connection it, as their experience is
    exactly the same: the server is "down"; something "failed", apparently.
    > I understand the reasons why you picked such name, but I feel that it
    > could be better. Or at least comment should clarify what the "fail"
    > actually stands for.
    I checked again and updated the section in the documentation to make it
    more clear what the configuration does.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message