date:20200813

[SSSD] [sssd PR#5272][opened] WIP! responder_utils: GetUserGroups() returns SYSDB_PRIMARY_GROUP_GIDNUM

2020-08-13 Thread ikerexxe

   URL: https://github.com/SSSD/sssd/pull/5272
Author: ikerexxe
 Title: #5272: WIP! responder_utils: GetUserGroups() returns 
SYSDB_PRIMARY_GROUP_GIDNUM
Action: opened

PR body:
"""
This is work in progress!

There was a mismatch between the information provided by NSS and IFP
interfaces. nss_protocol_fill_initgr() returned
SYSDB_PRIMARY_GROUP_GIDNUM, but GetUserGroups() didn't. This commit
makes GetUserGroups() also return SYSDB_PRIMARY_GROUP_GIDNUM value.

Resolves:
https://github.com/SSSD/sssd/issues/4569
"""

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5272/head:pr5272
git checkout pr5272
From a2c166ea1c30b9b3fefabc49cce52c6ef825cc52 Mon Sep 17 00:00:00 2001
From: ikerexxe 
Date: Thu, 13 Aug 2020 09:13:33 +0200
Subject: [PATCH] responder_utils: GetUserGroups() returns
 SYSDB_PRIMARY_GROUP_GIDNUM

There was a mismatch between the information provided by NSS and IFP
interfaces. nss_protocol_fill_initgr() returned
SYSDB_PRIMARY_GROUP_GIDNUM, but GetUserGroups() didn't. This commit
makes GetUserGroups() also return SYSDB_PRIMARY_GROUP_GIDNUM value.

Resolves:
https://github.com/SSSD/sssd/issues/4569
---
 src/responder/common/responder_utils.c | 40 --
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/src/responder/common/responder_utils.c b/src/responder/common/responder_utils.c
index 9141026e77..e536fadc94 100644
--- a/src/responder/common/responder_utils.c
+++ b/src/responder/common/responder_utils.c
@@ -210,6 +210,7 @@ struct resp_resolve_group_names_state {
 
 static void resp_resolve_group_done(struct tevent_req *subreq);
 static errno_t resp_resolve_group_next(struct tevent_req *req);
+static errno_t resp_resolve_group_trigger_request(struct tevent_req *req, const char *attr_name);
 static errno_t resp_resolve_group_reread_names(struct resp_resolve_group_names_state *state);
 
 struct tevent_req *resp_resolve_group_names_send(TALLOC_CTX *mem_ctx,
@@ -275,6 +276,7 @@ resp_resolve_group_needs_refresh(struct resp_resolve_group_names_state *state)
 
 static errno_t resp_resolve_group_next(struct tevent_req *req)
 {
+//TODO: delete unused variables
 struct cache_req_data *data;
 uint64_t gid;
 struct tevent_req *subreq;
@@ -286,15 +288,35 @@ static errno_t resp_resolve_group_next(struct tevent_req *req)
&& !resp_resolve_group_needs_refresh(state)) {
 state->group_iter++;
 }
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: state->group_iter %d\n", state->group_iter);
 
 if (state->group_iter >= state->initgr_res->count) {
 /* All groups were refreshed */
 return EOK;
 }
 
-/* Fire a request */
+if(state->group_iter == 0) {
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: state->group_iter is 0\n");
+if(resp_resolve_group_trigger_request(req, SYSDB_PRIMARY_GROUP_GIDNUM) != EAGAIN) {
+DEBUG(SSSDBG_CRIT_FAILURE, "Unable to check SYSDB_PRIMARY_GROUP_GIDNUM\n");
+}
+}
+
+return resp_resolve_group_trigger_request(req, SYSDB_GIDNUM);
+}
+
+static errno_t resp_resolve_group_trigger_request(struct tevent_req *req, const char *attr_name)
+{
+struct cache_req_data *data;
+uint64_t gid;
+struct tevent_req *subreq;
+struct resp_resolve_group_names_state *state;
+
+state = tevent_req_data(req, struct resp_resolve_group_names_state);
+
 gid = ldb_msg_find_attr_as_uint64(state->initgr_res->msgs[state->group_iter],
-  SYSDB_GIDNUM, 0);
+  attr_name, 0);
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: gid %ld\n", gid);
 if (gid == 0) {
 return EINVAL;
 }
@@ -318,6 +340,7 @@ static errno_t resp_resolve_group_next(struct tevent_req *req)
 return ENOMEM;
 }
 
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: before request gid %ld\n", gid);
 tevent_req_set_callback(subreq, resp_resolve_group_done, req);
 return EAGAIN;
 }
@@ -385,6 +408,19 @@ resp_resolve_group_reread_names(struct resp_resolve_group_names_state *state)
 return ret;
 }
 
+DEBUG(SSSDBG_FATAL_FAILURE, "my_log: state->initgr_named_res->msgs[0]->num_elements %d\n",
+state->initgr_named_res->msgs[0]->num_elements);
+int count = 0;
+while(count < state->initgr_named_res->msgs[0]->num_elements) {
+DEBUG(SSSDBG_FATAL_FAILURE, "my_log: count %d, state->initgr_named_res->msgs[0]->elements[].name %s, state->initgr_named_res->msgs[0]->elements[count].num_values %d, state->initgr_named_res->msgs[0]->elements[count].values->data %s\n", 
+count,
+state->initgr_named_res->msgs[0]->elements[count].name,
+state->initgr_named_res->msgs[0]->elements[count].num_values,
+state->initgr_named_res->msgs[0]->elements[count].values->data);
+
+count++;
+}
+
 return EOK;
 }
 
___
sssd-devel mailing list -- sssd-devel@lists.fedorah

[SSSD] [sssd PR#5272][synchronized] WIP! responder_utils: GetUserGroups() returns SYSDB_PRIMARY_GROUP_GIDNUM

2020-08-13 Thread ikerexxe

   URL: https://github.com/SSSD/sssd/pull/5272
Author: ikerexxe
 Title: #5272: WIP! responder_utils: GetUserGroups() returns 
SYSDB_PRIMARY_GROUP_GIDNUM
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5272/head:pr5272
git checkout pr5272
From 7c5966366da8a06abcee5e73a43e907c032001eb Mon Sep 17 00:00:00 2001
From: ikerexxe 
Date: Thu, 13 Aug 2020 09:13:33 +0200
Subject: [PATCH] responder_utils: GetUserGroups() returns
 SYSDB_PRIMARY_GROUP_GIDNUM

There was a mismatch between the information provided by NSS and IFP
interfaces. nss_protocol_fill_initgr() returned
SYSDB_PRIMARY_GROUP_GIDNUM, but GetUserGroups() didn't. This commit
makes GetUserGroups() also return SYSDB_PRIMARY_GROUP_GIDNUM value.

Resolves:
https://github.com/SSSD/sssd/issues/4569
---
 src/responder/common/responder_utils.c | 49 --
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/src/responder/common/responder_utils.c b/src/responder/common/responder_utils.c
index 9141026e77..09a28815c6 100644
--- a/src/responder/common/responder_utils.c
+++ b/src/responder/common/responder_utils.c
@@ -27,6 +27,8 @@
 #include "responder/common/cache_req/cache_req.h"
 #include "util/util.h"
 
+static bool is_primary_group_request;
+
 static inline bool
 attr_in_list(const char **list, size_t nlist, const char *str)
 {
@@ -210,6 +212,7 @@ struct resp_resolve_group_names_state {
 
 static void resp_resolve_group_done(struct tevent_req *subreq);
 static errno_t resp_resolve_group_next(struct tevent_req *req);
+static errno_t resp_resolve_group_trigger_request(struct tevent_req *req, const char *attr_name);
 static errno_t resp_resolve_group_reread_names(struct resp_resolve_group_names_state *state);
 
 struct tevent_req *resp_resolve_group_names_send(TALLOC_CTX *mem_ctx,
@@ -222,6 +225,8 @@ struct tevent_req *resp_resolve_group_names_send(TALLOC_CTX *mem_ctx,
 struct tevent_req *req;
 errno_t ret;
 
+is_primary_group_request = true;
+
 req = tevent_req_create(mem_ctx, &state, struct resp_resolve_group_names_state);
 if (req == NULL) {
 DEBUG(SSSDBG_CRIT_FAILURE, "tevent_req_create() failed\n");
@@ -275,6 +280,7 @@ resp_resolve_group_needs_refresh(struct resp_resolve_group_names_state *state)
 
 static errno_t resp_resolve_group_next(struct tevent_req *req)
 {
+//TODO: delete unused variables
 struct cache_req_data *data;
 uint64_t gid;
 struct tevent_req *subreq;
@@ -286,15 +292,34 @@ static errno_t resp_resolve_group_next(struct tevent_req *req)
&& !resp_resolve_group_needs_refresh(state)) {
 state->group_iter++;
 }
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: state->group_iter %d\n", state->group_iter);
 
 if (state->group_iter >= state->initgr_res->count) {
 /* All groups were refreshed */
 return EOK;
 }
 
-/* Fire a request */
+if(state->group_iter == 0 && is_primary_group_request == true) {
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: state->group_iter is 0\n");
+return resp_resolve_group_trigger_request(req, SYSDB_PRIMARY_GROUP_GIDNUM);
+} else {
+return resp_resolve_group_trigger_request(req, SYSDB_GIDNUM);
+}
+}
+
+static errno_t resp_resolve_group_trigger_request(struct tevent_req *req,
+  const char *attr_name)
+{
+struct cache_req_data *data;
+uint64_t gid;
+struct tevent_req *subreq;
+struct resp_resolve_group_names_state *state;
+
+state = tevent_req_data(req, struct resp_resolve_group_names_state);
+
 gid = ldb_msg_find_attr_as_uint64(state->initgr_res->msgs[state->group_iter],
-  SYSDB_GIDNUM, 0);
+  attr_name, 0);
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: gid %ld\n", gid);
 if (gid == 0) {
 return EINVAL;
 }
@@ -318,6 +343,7 @@ static errno_t resp_resolve_group_next(struct tevent_req *req)
 return ENOMEM;
 }
 
+DEBUG(SSSDBG_CRIT_FAILURE, "my_log: before request gid %ld\n", gid);
 tevent_req_set_callback(subreq, resp_resolve_group_done, req);
 return EAGAIN;
 }
@@ -338,7 +364,11 @@ static void resp_resolve_group_done(struct tevent_req *subreq)
 /* Try to refresh the others on error */
 }
 
-state->group_iter++;
+if(state->group_iter == 0 && is_primary_group_request == true) {
+is_primary_group_request = false;
+} else {
+state->group_iter++;
+}
 state->needs_refresh = true;
 
 ret = resp_resolve_group_next(req);
@@ -385,6 +415,19 @@ resp_resolve_group_reread_names(struct resp_resolve_group_names_state *state)
 return ret;
 }
 
+DEBUG(SSSDBG_FATAL_FAILURE, "my_log: state->initgr_named_res->msgs[0]->num_elements %d\n",
+state->initgr_named_res->msgs[0]->num_elements);
+int count = 0;
+while(count < state->initgr_named_res->msgs[0]->num_elements) {
+

[SSSD] [sssd PR#5262][comment] DN with white spaces

2020-08-13 Thread sumit-bose

  URL: https://github.com/SSSD/sssd/pull/5262
Title: #5262: DN with white spaces

sumit-bose commented:
"""
Hi Tomas,

there is `ldap_dn_normalize()` in OpenLDAP. Can you check if something like

ldap_dn_normalize(dn_str, LDAP_DN_FORMAT_LDAP,  &sanitized_dn_str, 
LDAP_DN_FORMAT_LDAPV3);

does remove the space as well? A wrapper function would still be nice so that 
we can get the result as talloc'ed string?

bye,
Sumit
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/5262#issuecomment-673413612
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#5264][+Waiting for review] Utils: White space replace with another character

2020-08-13 Thread elkoniu

  URL: https://github.com/SSSD/sssd/pull/5264
Title: #5264: Utils: White space replace with another character

Label: +Waiting for review
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#5257][comment] git-template: add tags to help with release notes automation

2020-08-13 Thread pbrezina

  URL: https://github.com/SSSD/sssd/pull/5257
Title: #5257: git-template: add tags to help with release notes automation

pbrezina commented:
"""
I don't insist on any specific format. I chose `:tag:` because it is being used 
in [ReST format](https://docutils.sourceforge.io/docs/ref/rst/roles.html) so it 
is something common. Iker is right, `#` can't be used because it is interpreted 
as comment by git so it will not be added to the message. `[]` is widely used 
in debug messages which are often part of commit message, `<>` are widely used 
in shell and in output of many programs which we often append to the commit 
message so in both cases, collisions (even though unlikely) or confusion may 
happen.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/5257#issuecomment-670055330
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#5271][synchronized] Translations update from Weblate

2020-08-13 Thread weblate

   URL: https://github.com/SSSD/sssd/pull/5271
Author: weblate
 Title: #5271: Translations update from Weblate
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5271/head:pr5271
git checkout pr5271
From 375430c8fbab870dbf6b12075234236db092de68 Mon Sep 17 00:00:00 2001
From: Weblate 
Date: Thu, 13 Aug 2020 18:10:12 +0200
Subject: [PATCH] Translated using Weblate (Ukrainian)

Currently translated at 89.9% (647 of 719 strings)

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd-master/uk/

Translated using Weblate (Czech)

Currently translated at 88.9% (633 of 712 strings)

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd-master/cs/

Translated using Weblate (Polish)

Currently translated at 100.0% (719 of 719 strings)

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd/pl/

Translated using Weblate (French)

Currently translated at 99.0% (712 of 719 strings)

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd/fr/

Update translation files

Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd/

Update translation files

Updated by "Update LINGUAS file" hook in Weblate.

Translation: SSSD/sssd
Translate-URL: https://translate.fedoraproject.org/projects/sssd/sssd/
---
 po/LINGUAS |   1 +
 po/cs.po   | 979 +++--
 po/fr.po   |  19 +-
 po/pl.po   |  49 +--
 po/uk.po   |  33 +-
 5 files changed, 563 insertions(+), 518 deletions(-)

diff --git a/po/LINGUAS b/po/LINGUAS
index 526cd57b8a..b24d1d1b42 100644
--- a/po/LINGUAS
+++ b/po/LINGUAS
@@ -21,3 +21,4 @@ uk
 zh_CN
 zh_TW
 
+cs
diff --git a/po/cs.po b/po/cs.po
index 7e1ead143c..4a9c8f5bc8 100644
--- a/po/cs.po
+++ b/po/cs.po
@@ -1,20 +1,22 @@
 # Zdenek , 2017. #zanata
 # Pavel Borecki , 2018. #zanata
 # Pavel Borecki , 2019. #zanata
+# Pavel Brezina , 2020.
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: sssd-devel@lists.fedorahosted.org\n"
-"POT-Creation-Date: 2020-06-17 22:51+0200\n"
-"PO-Revision-Date: 2019-08-31 07:00-0400\n"
-"Last-Translator: Pavel Borecki \n"
-"Language-Team: Czech\n"
+"POT-Creation-Date: 2020-07-24 13:05+0200\n"
+"PO-Revision-Date: 2020-08-12 10:01+\n"
+"Last-Translator: Pavel Brezina \n"
+"Language-Team: Czech \n"
 "Language: cs\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2\n"
-"X-Generator: Zanata 4.6.2\n"
+"Plural-Forms: nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2;\n"
+"X-Generator: Weblate 4.1.1\n"
 
 #: src/config/SSSDConfig/sssdoptions.py:20
 #: src/config/SSSDConfig/sssdoptions.py:21
@@ -66,8 +68,8 @@ msgstr ""
 #: src/config/SSSDConfig/sssdoptions.py:32
 msgid ""
 "When SSSD switches to offline mode the amount of time before it tries to go "
-"back online will increase based upon the time spent disconnected. This value"
-" is in seconds and calculated by the following: offline_timeout + "
+"back online will increase based upon the time spent disconnected. This value "
+"is in seconds and calculated by the following: offline_timeout + "
 "random_offset."
 msgstr ""
 
@@ -137,8 +139,8 @@ msgstr "Konkrétní pořadí domén ve které je hledat"
 
 #: src/config/SSSDConfig/sssdoptions.py:52
 msgid ""
-"Controls if SSSD should monitor the state of resolv.conf to identify when it"
-" needs to update its internal DNS resolver."
+"Controls if SSSD should monitor the state of resolv.conf to identify when it "
+"needs to update its internal DNS resolver."
 msgstr ""
 
 #: src/config/SSSDConfig/sssdoptions.py:54
@@ -159,7 +161,7 @@ msgstr ""
 "Délka časového limitu aktualizace mezipaměti položek na pozadí (v sekundách)"
 
 #: src/config/SSSDConfig/sssdoptions.py:61
-#: src/config/SSSDConfig/sssdoptions.py:112
+#: src/config/SSSDConfig/sssdoptions.py:115
 msgid "Negative cache timeout length (seconds)"
 msgstr "Délka časového limitu záporné mezipaměti (v sekundách)"
 
@@ -229,34 +231,52 @@ msgstr "Jak dlouho budou záznamy mezipaměti v paměti platné"
 
 #: src/config/SSSDConfig/sssdoptions.py:75
 msgid ""
+"Size (in megabytes) of the data table allocated inside fast in-memory cache "
+"for passwd requests"
+msgstr ""
+
+#: src/config/SSSDConfig/sssdoptions.py:76
+msgid ""
+"Size (in megabytes) of the data table allocated inside fast in-memory cache "
+"for group requests"
+msgstr ""
+
+#: src/config/SSSDConfig/sssdoptions.py:77
+msgid ""
+"Size (in megabytes) of the data table allocated inside fast in-memory cache "
+"for initgroups requests"
+msgstr ""
+
+#: src/config/SSSDConfig/sssdoptions.py:78
+msg

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread dpward

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

dpward commented:
"""
@alexey-tikhonov I think you are getting a few things confused here.

The FIPS requirement you referenced is for **cryptographic** hashes. This pull 
request did not change _cryptographic_ hashing behavior. Instead, it changed 
how an OCSP request _identifies_ a certificate that the OCSP responder needs to 
validate. That is independent of which algorithm is used to _cryptographically 
sign_ the OCSP response that is returned (or optionally, the OCSP request that 
is sent).

In addition, some OCSP responders (including Microsoft's) implement RFC 5019, 
which places additional restrictions on how OCSP is used. In particular, 
[Section 2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that 
for OCSP requests,
```
   Clients MUST use SHA1 as the hashing algorithm for the
   CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So the change here actually breaks compatibility with RFC 5019 responders 
out-of-the-box. The fact that this hashing algorithm is configurable in SSSD is 
fine, but the default should be changed back to SHA-1. Again, this is not a 
_cryptographic_ hash.

---

As an aside, you might wish to add the [Preferred Signature Algorithms 
extension](https://tools.ietf.org/html/rfc6960#section-4.4.7) to outgoing OCSP 
requests instead.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread dpward

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

dpward commented:
"""
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.

The FIPS requirement you referenced is for **cryptographic** hashes. For 
example: an [OCSP response 
message](https://tools.ietf.org/html/rfc6960#section-2.2) contains a "signature 
computed across a hash of the response", which involves the use of a private 
key.

The change made here did not affect _cryptographic_ hashes. An OCSP request 
message needs to specify the issuing CA for the certificate in question. Rather 
than send the full distinguished name in plain text, it is sent in the form of 
a hash (think `sha1sum`). This change made it possible to choose the hash 
algorithm.

Now, note that some OCSP responders (including Microsoft's) implement RFC 5019, 
which places restrictions on how OCSP is used. [Section 
2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that for OCSP 
requests,
```
   Clients MUST use SHA1 as the hashing algorithm for the
   CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So using hash algorithms other than SHA-1 here breaks compatibility with RFC 
5019-compliant responders, which may refuse to even process the request (as we 
are in fact seeing).

The algorithm should remain a configuration option, but the default should be 
reverted to SHA-1, which satisfies RFC 5019 in case that is what the OCSP 
responder implements. Again: this is not being used to produce a 
_cryptographic_ hash.

(Also note that when SSSD is built with NSS support, the default algorithm is 
already SHA-1, because others are unsupported.)
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread dpward

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

dpward commented:
"""
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.

The FIPS requirement you referenced is for **cryptographic** hashes. For 
example: an [OCSP response 
message](https://tools.ietf.org/html/rfc6960#section-2.2) contains a "signature 
computed across a hash of the response", which involves the use of a private 
key.

However, the hashes that are affected by this pull request are not used in a 
_cryptographic_ manner. To obtain the status of a certificate, an [OCSP request 
message](https://tools.ietf.org/html/rfc6960#section-2.1) needs to specify the 
issuing CA for that certificate. Rather than sending the full distinguished 
name as a (plain text) string, the hash of the DN is sent instead. With this 
pull request, that hash algorithm can be chosen.

Now, note that some OCSP responders (including Microsoft's) implement RFC 5019, 
which places restrictions on how OCSP is used. [Section 
2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that for OCSP 
requests,
```
   Clients MUST use SHA1 as the hashing algorithm for the
   CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So using hash algorithms other than SHA-1 here breaks compatibility with RFC 
5019-compliant responders, which may refuse to even process the request (as we 
are in fact seeing).

The algorithm should remain a configuration option, but the default should be 
reverted to SHA-1, which satisfies RFC 5019 in case that is what the OCSP 
responder implements. (Also note that when SSSD is built with NSS support, the 
default algorithm is already SHA-1, because others are unsupported.)
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread dpward

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

dpward commented:
"""
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.

The FIPS requirement you referenced is for **cryptographic** hashes. For 
example: an [OCSP response 
message](https://tools.ietf.org/html/rfc6960#section-2.2) contains a "signature 
computed across a hash of the response", which involves the use of a private 
key.

However, the hashes that are affected by this pull request are not used in a 
_cryptographic_ manner. To obtain the status of a certificate, an [OCSP request 
message](https://tools.ietf.org/html/rfc6960#section-2.1) needs to specify the 
issuing CA for that certificate. Rather than sending the full distinguished 
name as part of the request, a hash is sent instead. (The first paragraph of 
[section 4.1.2](https://tools.ietf.org/html/rfc6960#section-4.1.2) adds 
context.) With this pull request, that hash algorithm can be chosen.

Now, note that some OCSP responders (including Microsoft's) implement RFC 5019, 
which places restrictions on how OCSP is used. [Section 
2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that for OCSP 
requests,
```
   Clients MUST use SHA1 as the hashing algorithm for the
   CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So using hash algorithms other than SHA-1 here breaks compatibility with RFC 
5019-compliant responders, which may refuse to even process the request (as we 
are in fact seeing).

The algorithm should remain a configuration option, but the default should be 
reverted to SHA-1, which satisfies RFC 5019 in case that is what the OCSP 
responder implements. (Also note that when SSSD is built with NSS support, the 
default algorithm is already SHA-1, because others are unsupported.)
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread dpward

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

dpward commented:
"""
@alexey-tikhonov @sumit-bose I think you are getting a few things confused here.

The FIPS requirement you referenced states it is for **cryptographic** hashes. 
For example: an [OCSP response 
message](https://tools.ietf.org/html/rfc6960#section-2.2) contains a "signature 
computed across a hash of the response", which involves the use of a private 
key. RFC 6960 discusses the security considerations when [choosing the response 
signing algorithm](https://tools.ietf.org/html/rfc6960#section-5.1).

However, the hashes that are affected by this pull request are not used in a 
_cryptographic_ manner. To obtain the status of a certificate, an [OCSP request 
message](https://tools.ietf.org/html/rfc6960#section-2.1) needs to specify the 
issuing CA for that certificate. Rather than sending the full distinguished 
name as-is, its hash is computed and that is sent in the request instead. (The 
first paragraph of [section 
4.1.2](https://tools.ietf.org/html/rfc6960#section-4.1.2) adds context.) With 
this pull request, that hash algorithm can be chosen.

Now, some OCSP responders — including Microsoft's — implement RFC 5019, which 
places restrictions on how OCSP is used. [Section 
2.1.1](https://tools.ietf.org/html/rfc5019#section-2.1.1) states that for OCSP 
requests,
```
   Clients MUST use SHA1 as the hashing algorithm for the
   CertID.issuerNameHash and the CertID.issuerKeyHash values.
```
So using hash algorithms other than SHA-1 here breaks compatibility with RFC 
5019-compliant responders, which may refuse to even process the request (as we 
are in fact seeing).

The issuer hash algorithm should remain a configuration option, but the default 
should be reverted to SHA-1, which satisfies RFC 5019. Note that SHA-1 is 
already the default algorithm when SSSD is built with NSS support, rather than 
OpenSSL support.
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673709907
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

2020-08-13 Thread sumit-bose

  URL: https://github.com/SSSD/sssd/pull/837
Title: #837: p11_child: make OCSP digest configurable

sumit-bose commented:
"""
Hi @dpward ,

thanks for pointing to https://tools.ietf.org/html/rfc5019#section-2.1.1, so 
the default should be switched back to SHA-1. I will check if this works as 
expected even if the client is switched into FIPS mode.

@alexey-tikhonov, shall we reopen this ticket or do you prefer a new one?

bye,
Sumit
"""

See the full comment at 
https://github.com/SSSD/sssd/pull/837#issuecomment-673889511
___
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org

[SSSD] [sssd PR#5272][opened] WIP! responder_utils: GetUserGroups() returns SYSDB_PRIMARY_GROUP_GIDNUM

[SSSD] [sssd PR#5272][synchronized] WIP! responder_utils: GetUserGroups() returns SYSDB_PRIMARY_GROUP_GIDNUM

[SSSD] [sssd PR#5262][comment] DN with white spaces

[SSSD] [sssd PR#5264][+Waiting for review] Utils: White space replace with another character

[SSSD] [sssd PR#5257][comment] git-template: add tags to help with release notes automation

[SSSD] [sssd PR#5271][synchronized] Translations update from Weblate

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

[SSSD] [sssd PR#837][comment] p11_child: make OCSP digest configurable

12 matches

Site Navigation

Mail list logo

Footer information