Home
last modified time | relevance | path

Searched +hist:2 +hist:d93db6e (Results 1 - 2 of 2) sorted by relevance

/Couchbase_C_Client_v3.0/tools/
H A DCMakeLists.txtdiff 2bd72b20 Tue Apr 01 21:37:18 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> fix typo in tools/CMakeLists

Change-Id: Icf350ef48a3dca2e12e543097325ec5bc9fc1193
Reviewed-on: http://review.couchbase.org/35166
Reviewed-by: Matt Ingenthron <matt@couchbase.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
diff 2d93db6e Wed Feb 05 18:45:46 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Bundle PDB/EXP files with CMake windows install

Change-Id: I8c0c0f87d290d4b269fb74e755f346a85c59cbe0
Reviewed-on: http://review.couchbase.org/33274
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
diff 2d93db6e Wed Feb 05 18:45:46 UTC 2014 Mark Nunberg <mnunberg@haskalah.org> Bundle PDB/EXP files with CMake windows install

Change-Id: I8c0c0f87d290d4b269fb74e755f346a85c59cbe0
Reviewed-on: http://review.couchbase.org/33274
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: Mark Nunberg <mnunberg@haskalah.org>
/Couchbase_C_Client_v3.0/
H A DCMakeLists.txtdiff fadbd4d1 Wed Sep 22 16:11:06 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.2.2

Change-Id: If697f9cb0f6d387928d935a6786f86ab064225a3
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/162115
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff f463b2ef Mon Apr 26 14:30:23 UTC 2021 Sergey Avseyev <sergey.avseyev@gmail.com> Update release meta for 3.1.2

Change-Id: I709a7ff749e34f327bbc3b73a22af0ce61620eff
Reviewed-on: http://review.couchbase.org/c/libcouchbase/+/152097
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 9249c3cf Wed Jun 13 09:11:35 UTC 2018 Sergey Avseyev <sergey.avseyev@gmail.com> CCBC-943: Implement option to dump TCP packets

This change introduces new cmake option, which will
force library to report all incoming/outgoing TCP packets on
TRACE log level. It renders the bytes in Base64 encoding.

Also there is simple extraction tool, which beautifies
packet traces, and could be used like this:

cbc cat -vvv foo bar 2>&1 | tools/extract-packets.rb

Change-Id: I9c65a1932b80438d49739b9d4983a8f8e4f72cf7
Reviewed-on: http://review.couchbase.org/95544
Reviewed-by: Ellis Breen <ellis.breen@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 40ff8088 Mon Apr 09 12:18:52 UTC 2018 Guillaume Molleda / Amadeus IT Group <gmolleda@amadeus.com> CCBC-685: Implementation of SCRAM-SHA authentication mechanism

Please refer to RFC 5802 for a complete description of the SCRAM-SHA
authentication sequence.

Basically, the purpose is to base the authentication on exchanges of
proofs of identity rather than passwords (in clear text or not). Proofs
are hashed using a salted password (the salt being provided by the
server) and random nonces (unique to the session), so that only peers
knowing the secret password can acknowledge them.

The authentication is performed in five steps.

Step 1: the client sends the username and his nonce (unique to this
session).

Step 2: the server returns its nonce (concatenated with the client's
nonce), the salt and an iteration count (used when computing the
salted password).

Step 3: the client computes the client's proof from a combination of the
password, the salt, the iteration count and the previous
messages (cf RFC 5802 for the complete details). It is sent back
to the server.

Step 4: the server verifies the validity of the client's proof and
generates its own proof based also on the password, the salt,
the iteration count and a concatenation of previous messages.
This proof is replied to the client as acknowledgement of the
authentication.

Step 5: the client can verify the validity of the server's proof. The
authentication is successful.

Three versions of SCRAM-SHA algorithm are currently available:
SCRAM-SHA1, SCRAM-SHA256 and SCRAM-SHA512, the difference being on the
strength of the hashing. SCRAM-SHA512 is considered as more secure now,
so it is used as default by this implementation.

This implementation was tested over a Couchbase cluster 4.6.2
(enterprise version).

Here is a real example of SCRAM-SHA512 authentication exchange made
between the mininal example and the 4.6.2 cluster (captured using
tcpdump):

Msg 1 (client->server):
n,,n=test,r=0c0d2b1a62de9318

Msg 2 (server->client):
r=0c0d2b1a62de9318660590ff26368002,s=bGkVWZUpi3OgnkzskW+8YlB7LyFrwETeWI+1seQ+0Y4oP4/FditP6DE/oQ0qdrSKFC4VVlkkSaW34EyhGHzEzA==,i=4096

Msg 3 (client->server):
c=biws,r=0c0d2b1a62de9318660590ff26368002,p=f3UTCdYt5pgb5LvkZsdM97crONf7+k8iFZP5/26Z8pIB75I/++L/Vy5FMfAsSDaLNiAo00bzpSz3SFZ9qzR3yw==

Msg 4 (server->client):
v=i6R3vC0ul0V4XW/jIC1dtayEGPeYBVudp1ay8Ai9R9Mup96B2aP8weU58+C2orgWKPRW0IWGPUMXIW7py/Sfrw==

Proofs and salt are encoded in Base64.

Other examples can be found in the unit tests (t_scram.cc file).

Please note that we rely on OpenSSL for the implementation of SHA, HMAC
and PBKDF2 algorithms. If OpenSSL is not linked (or if OpenSSL doesn't
implement PBKDF2), then SCRAM-SHA* authentication mecanisms are disabled
(only CRAM-MD5 and PLAIN will be used).

Change-Id: I4353e791c5e773b8c2fe31b335a05b10d9d499c8
Reviewed-on: http://review.couchbase.org/92497
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
diff 2ffd3ec1 Wed Nov 23 16:24:17 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> SDKRFC-13/CCBC-752: Implement error map support

This implements error map support. The error map is a mapping of more
specialized errors to more generic attributes within the server. The
error map would therefore allow the server to return more detailed error
codes without worrying that a client has a special implementation to
handle that specific code.

The following features have been added:

- Send the XERROR flag on HELLO
- Load and parse the error map
- LCB_CNTL_ENABLE_ERRMAP and/or enable_errmap to enable this feature.
- Update to new Mock which supports the error map and XERROR

Note that the error map functionality is disabled by default, since
sending the XERROR flag tells the server we know how to handle the error
map entirely (including disconnects and retries). Error map will become
the default once the proper behaviors have been defined.

Change-Id: I3c5fbad983d3304eff9396ed7f9939d477720ce4
Reviewed-on: http://review.couchbase.org/70872
Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
Tested-by: Mark Nunberg <mark.nunberg@couchbase.com>
diff 0fb123d8 Fri Jan 30 23:35:02 UTC 2015 Mark Nunberg <mnunberg@haskalah.org> CCBC-566: DNS SRV support

This adds DNS SRV lookups for bootstrapping. This is provided in two
forms:

1. When there is only a single hostname with no port. This is called
implicit lookup
2. When the scheme `couchbase+dnssrv://` is used. This is an explicit
mode and is considered internal to the library.

In both cases the input hostname will be selected and attempted for a DNS SRV
query. If it succeeds, then the hosts use for the query will be
returned. If the query fails, implicit mode will continue, using the
hostname as a couchbase node, whereas explicit mode will fail. Explicit
mode is useful for debugging the dns srv feauture itself.

Currently support depends on either Windows (which works "out of the
box") and libbind/libresolv, which come bundled with glibc on both OS X
and Linux. This may fail to function on very ancient systems; in which
event these routines are stubbed out with no-op equivalents.

Change-Id: I0d54b63c1e6cef64e5a09280343e9aba24ed7a80
Reviewed-on: http://review.couchbase.org/46177
Reviewed-by: Brett Lawson <brett19@gmail.com>
Tested-by: buildbot <build@couchbase.com>
diff 2acd7da3 Tue Aug 30 18:29:16 UTC 2016 Mark Nunberg <mnunberg@haskalah.org> CCBC-718: add SUBDOC_F_MKDOCUMENT and GET_COUNT

This adds the GET_COUNT and MKDOC options. `GET_COUNT` retrieves the
number of items in an array or dictionary; MKDOC is another flag (like
MKDIR_P) which will create the document if it does not exist.

This commit also includes tests for the features, alongside an upgrade
to a newer CouchbaseMock version

Change-Id: I1fd5a9a910d37f9933f80b0297864683e9572bbd
Reviewed-on: http://review.couchbase.org/67213
Tested-by: buildbot <build@couchbase.com>
Reviewed-by: Brett Lawson <brett19@gmail.com>

Completed in 35 milliseconds