From freeipa-github-notification at redhat.com Mon Jan 2 06:48:19 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Mon, 02 Jan 2017 07:48:19 +0100 Subject: [Freeipa-devel] [freeipa PR#209][synchronized] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Author: Akasurde Title: #209: Enumerate available options in IPA installer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/209/head:pr209 git checkout pr209 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-209.patch Type: text/x-diff Size: 1150 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 2 07:06:04 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 2 Jan 2017 08:06:04 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> On 19.12.2016 12:13, Sumit Bose wrote: > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: >> I agree with *almost* everything Sumit said. See my inline comments below. >> >> On 16.12.2016 11:53, Sumit Bose wrote: >>> On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: >>>> Hi, >>>> >>>> I have started a feature description for the Certificate Identity Mapping at >>>> the following location: >>>> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >>>> >>>> This is a first step, focusing on the interface we would like to provide. It >>>> still contains open questions, some of which are linked to the corresponding >>>> design on SSSD side: >>>> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >>>> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >>>> >>>> Comments, concerns and suggestions are welcome. Thanks! >>> >>> Hi Flo, >>> >>> thank you very much for setting up the page. >>> >>> My comments are mostly about the commands. >>> >>> certmappingconfig-mod: >>> >>> * --enable=Boolean: if this option is 'False' SSSD will basically show >>> the current behavior and just look up the certificates directly. But I >>> wonder if the option is needed at all because not adding any mapping >>> rules would have the same effect. >>> >>> What is the scope here, only the IPA domain, or all trusted domains as >>> well? If it is for trusted domains as well will the certmappingrule-* >>> commands and user-{add/remove}-certmapping return an error? >>> >>> So, in general I see an overlap with the mapping rules and I think it >>> would be clearer to drop this option and do the lookups according to >>> the mapping rules. >>> >>> * --prompt-username=Boolean: the description implies that this option is >>> synonymous to 1:1 mapping, but it is not. On Linux authentication in >>> most cases use a user name either by directly asking (e.g. /bin/login) >>> or using the current user name (e.g. sudo). So, according to its name >>> it would only control if gdm is allowed to ask for an (optional) user >>> name. >>> >>> If the option is renamed to e.g. --force-1-to-1-mapping to really >>> enforce a 1:1 mapping then it would make sense to derived to gdm >>> behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to >>> ask for a user name and if it is not enforced then it makes sense to >>> offer and optional user name input field. >>> >>> * --enable-username-mismatch=Boolean: I think this option can be >>> dropped. My test so far show that if a non-matching hint is given on a >>> Windows client authentication fails. >>> >>> * --alternate-attribute=STRING: I think this option isn't needed as >>> well. For IPA server-side we should decide on an attribute name and >>> add it to the schema for user objects. On the client side the >>> attribute name can be taken from the mapping rule.A >>> >>> >>> certmappingrule.*: >>> >>> * ISSUERDN: it looks like you want to use issuerName here. In >>> certificateRecord it it used with LDAP ordering and I would prefer >>> LDAP ordering at all points where we have a choice. Unfortunately in the >>> issuer-subject mapping AD dictates X.500 ordering. >> >> LDAP ordering should indeed be preferred, as it is used everywhere else in >> IPA. We can convert to/from X.500 ordering where necessary, when possible. >> >>> >>> * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in >>> the example? My intention in the SSSD design-page was to specify the >>> domain (as in DNS domain/IPA domain/trusted domain) where the matching >>> user should be searched. Different domains might certificates from >>> different issuers and some domains might not even use certificates. >>> With this information SSSD does not have to search any domain trusted >>> by IPA from a given certificate, but look only at domains listed here >>> (the attribute should be a multi-value one). >>> >>> There are objects in the LDAP tree for each trusted domain which are >>> used by SSSD so using a DN syntax would be valid here. >> >> We use domain names rather than DNs to refer to domains everywhere else in >> the framework. I don't think this place should be an exception. > > I'm fine with domain names as well. In fact I didn't thought of using > DNs for this before I read DOMAINDN on the design page. > >> >>> >>> * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search >>> filters should just be a special kind of mapping rules. I can image in >>> syntax like: . I >>> think the difficult part with the LDAP filters will to define sensible >>> templates. >> >> I'm not sure I understand. Could you please elaborate a little bit? > > A LDAP search filter which would cover the AD behavior would look like: > > (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) > > where > > %A: must be replaced with the issuer of the certificate in X.500 order > %B: must be replaced with the subject of the certificate in X.500 order > > it would be possible of course to use a specific template here which > would generate the complete search attribute value. > > %C: must be replaced by the principal from AD's SAN > szOID_NT_PRINCIPAL_NAME > %D: must be replaced with only then name component (the part before the > realm) of the principal from szOID_NT_PRINCIPAL_NAME > > As %C and %D imply this filter will only work for certificates which > have szOID_NT_PRINCIPAL_NAME but for those it must be used to be > compatible with AD. For certificates without > > (altSecurityIdentities=%A%B) > > is sufficient. It is possible to select the right filter with matching > rules. Right. > > So we have to find suitable names for the %A, %B, %C and %D templates > and also allow different representations (e.g. LDAP or X.500 order for > DNs). I would personally prefer if we used Python-style formatting strings for the templates, I find them much more pleasant to work with than C-style formatting strings. The filter which covers AD behavior could be written as: (|(altSecurityIdentities={issuer_dn!x500}{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name})) > >> >>> But as long as we keep the general mapping rule syntax >>> flexible the LDAP filter rules can be added in a later version. >> >> IMHO it should be the other way round and LDAP filters should be implemented >> first, as they offer all the flexibility we need (all of the other fields >> can be easily implemented on top of LDAP filters) and are by default >> extensible without having to update servers and clients. > > In general I agree, as long we can find a suitable scheme to handle the > templates to add content from the certificate in a specific format to > the search filters. > > But from the user/admin perspective there should be special rules for > common use-cases which do not require to know too much details about > certificates and LDAP trees. E.g. for AD (either via direct or indirect > integration) there should be a rule which just does all which > AD would do depending on the certificate type. For IPA something like > might be a good start for handling external > certificates which do not contain user specific data which can be mapped > to user object because the syntax is already known from AD. This could be handled in the IPA plugin by converting from the user-friendly representation to LDAP filter template internally when a mapping rule is added or modified. > >> >>> >>> * enable/disable: I think this is a good idea and would be consistent >>> with other rules like HBAC and sudo >>> >>> * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be >>> better to not add this option and only implement the >>> 'user-{add/remove}-certmapping' commands >>> >>> * user-{add/remove}-certmapping: you say '... almost any type of mapping, >>> or a more user-friendly API ...'. I would not say 'or' but 'and' and >>> implement both >>> >>> * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I >>> think both are note needed, see above >>> >>> * altSecurityIdentities: I would prefer to use a different name and OID. >>> Using the same definition as AD would imo imply that it can be used in >>> the same way as in AD. But e.g. AD also supports other content like >>> KERBEROS:alternative_user_principal at AD.DOMAIN which we will not >>> support. >>> >>> * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is >>> general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since >>> the issuer DN in general will not be a DN from the local LDAP tree I >>> think the UTF-8 version fits better. >> >> I think it's worth mentioning that if the attribute used DN syntax and >> matching, we wouldn't have to worry about normalizing the issuer name before >> searching for it, as DS would do that for us. > > Good point, but I think the main use case for this attribute is on the > client side to determine if a rule should be applied to a certificate or > not. So I guess LDAP searches with this attribute would be rare because > the client will load all rules in one run. > >> >>> >>> * nsslapd-certmap-basedn, see DOMAINDN above >>> >>> * altSecurityIdentities example: X.500 ordering is used by AD here and >>> unfortunately I think we have to adopt it at least for this specific >>> usage, here is an ldapsearch output from AD: >>> >>> altSecurityIdentities: >>> X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC >>> =ad,CN=Users,CN=t u,E=test.user at email.domain >>> altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate >>> AuthorityDC >>> =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co >>> m,CN=Sumit Bose Sumit Bose >>> >>> * Certificate Mapping Administrators or re-use Certificate >>> Administrators: I would prefer a new 'Certificate Mapping >>> Administrators' >>> >>> * Users can manage their own X.509 certificate mappings? I'm not sure >>> here, at the first glance I would say no. How are OTP tokens handled? >>> Maybe this would be a candidate for certmappingconfig-* option? >> >> I think a better question is "How is userCertificate handled?" >> >> Anyway, self-service permissions can be enabled/disabled, so there is really >> no need for a new certmappingconfig option. > > Yes, this makes sense. > > bye, > Sumit >> >>> >>> That's all :-) >>> >>> bye, >>> Sumit >>> >> >> >> -- >> Jan Cholasta -- Jan Cholasta From jcholast at redhat.com Mon Jan 2 08:16:00 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 2 Jan 2017 09:16:00 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> Message-ID: <7c2b7f9b-dfd4-0108-4d8f-5a14286afdaa@redhat.com> On 16.12.2016 09:34, Florence Blanc-Renaud wrote: > On 12/06/2016 04:39 PM, Florence Blanc-Renaud wrote: >> Hi, >> >> I have started a feature description for the Certificate Identity >> Mapping at the following location: >> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >> >> This is a first step, focusing on the interface we would like to >> provide. It still contains open questions, some of which are linked to >> the corresponding design on SSSD side: >> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >> >> >> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >> >> >> >> Comments, concerns and suggestions are welcome. Thanks! >> >> Flo. >> > > Hi, > > the design page for Certificate Identity Mapping [1] has been updated > with a schema proposal and an example of configuration data. > > Please share your comments, concerns, suggestions before January 7, so > that we can finalize the API and start the implementation. > Thanks, > Flo. 1) I'm not fan of host-mod --certmapping-prompt-username. IMO it would be better to base this on group membership, which would allow automember to be used. A possible solution would be to introduce a CoS-based policy object, similar to pwpolicy, but for hosts: certmappolicy-mod [HOSTGROUP] --prompt-username=Boolean certmappolicy-add HOSTGROUP --prompt-username=Boolean certmappolicy-del HOSTGROUP HOSTGROUP can be ommited in certmappolicy-mod, in which case the default policy is modified. This would allow removing --prompt-username and --enable-local-prompt-policy from certmappingconfig. 2) Nitpick: could we please rename certmapping* to certmap*? Not only would it be quicker to type in the command line, but also named consistently with selinuxusermap. -- Jan Cholasta From jcholast at redhat.com Mon Jan 2 08:18:47 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 2 Jan 2017 09:18:47 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> Message-ID: On 18.10.2016 07:34, Jan Cholasta wrote: > On 17.10.2016 16:50, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> On 13.10.2016 18:52, Sumit Bose wrote: >>>> ===== Issuer specific matching ===== >>>> Although the MIT Kerberos rules allow to select the issuer of a >>>> certificate there are use cases where a more specific selection is >>>> needed. E.g. if there are some default matching rules for all issuers >>>> and some other issuer specific rules where the default rules should >>>> not apply. To make this possible with the above scheme the default >>>> rules must have an clause which matches all but the issuer >>>> with the specific rules. Writing regular-expressions to not match a >>>> specific string or a list of strings is at least error-prone if not >>>> impossible. >>>> >>>> To make it easier to define issuer specific rules and default rules at >>>> the same time and optional issuer string can be added to the rule to >>>> indicate that for the given issuer only those rules should be >>>> considered. Given the use-case I think it is acceptable to require >>>> that the full issuer must be specified here in LDAP order (see below) >>>> and case-sensitive matching is used. >>> >>> This could also be solved by adding priority to rules - if two rules >>> match, the one with higher priority (the issuer specific rule) is >>> preferred over the one with lower priority (the default rule). IMO this >>> is better than an optional issuer string as it offers greater >>> flexibility. >> >> The use cases I've seen haven't had to do with priority, though that >> would be a nice enhancement, but with only allowing certificates issued >> by a specific CA to be allowed (this is pretty common in web servers). >> Being able to say "only do the matching on certificates issued by foo" >> is valuable. > > Sure, I'm not suggesting that matching by issuer should be removed, only > that rule precedence should not be determined by the issuer field setting. > Bump. Sumit, what is your opinion on this? -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Jan 2 08:47:33 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 02 Jan 2017 09:47:33 +0100 Subject: [Freeipa-devel] [freeipa PR#298][+rejected] ipaldap: handle binary encoding option transparently In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/298 Title: #298: ipaldap: handle binary encoding option transparently Label: +rejected From freeipa-github-notification at redhat.com Mon Jan 2 08:53:51 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Mon, 02 Jan 2017 09:53:51 +0100 Subject: [Freeipa-devel] [freeipa PR#209][synchronized] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Author: Akasurde Title: #209: Enumerate available options in IPA installer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/209/head:pr209 git checkout pr209 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-209.patch Type: text/x-diff Size: 1150 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 2 09:40:02 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 02 Jan 2017 10:40:02 +0100 Subject: [Freeipa-devel] [freeipa PR#350][comment] spec file: revert to the previous Release tag In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/350 Title: #350: spec file: revert to the previous Release tag stlaz commented: """ I also appreciate the dist information, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/350#issuecomment-269950104 From freeipa-github-notification at redhat.com Mon Jan 2 09:40:06 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 02 Jan 2017 10:40:06 +0100 Subject: [Freeipa-devel] [freeipa PR#350][+ack] spec file: revert to the previous Release tag In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/350 Title: #350: spec file: revert to the previous Release tag Label: +ack From freeipa-github-notification at redhat.com Mon Jan 2 11:04:08 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 02 Jan 2017 12:04:08 +0100 Subject: [Freeipa-devel] [freeipa PR#350][comment] spec file: revert to the previous Release tag In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/350 Title: #350: spec file: revert to the previous Release tag HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/eb1f05d598d821f8e7eb5b8cfe606f570052f263 """ See the full comment at https://github.com/freeipa/freeipa/pull/350#issuecomment-269958484 From freeipa-github-notification at redhat.com Mon Jan 2 11:04:09 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 02 Jan 2017 12:04:09 +0100 Subject: [Freeipa-devel] [freeipa PR#350][closed] spec file: revert to the previous Release tag In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/350 Author: HonzaCholasta Title: #350: spec file: revert to the previous Release tag Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/350/head:pr350 git checkout pr350 From freeipa-github-notification at redhat.com Mon Jan 2 11:04:10 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 02 Jan 2017 12:04:10 +0100 Subject: [Freeipa-devel] [freeipa PR#350][+pushed] spec file: revert to the previous Release tag In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/350 Title: #350: spec file: revert to the previous Release tag Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 2 12:27:10 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 02 Jan 2017 13:27:10 +0100 Subject: [Freeipa-devel] [freeipa PR#362][opened] Clarify meaning of --domain and --realm in installers Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Author: stlaz Title: #362: Clarify meaning of --domain and --realm in installers Action: opened PR body: """ This is my take on original https://github.com/freeipa/freeipa/pull/352. I hope I fixed all the mentioned issues + I added some missing articles. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/362/head:pr362 git checkout pr362 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-362.patch Type: text/x-diff Size: 15640 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 2 16:08:26 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 02 Jan 2017 17:08:26 +0100 Subject: [Freeipa-devel] [freeipa PR#362][synchronized] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Author: stlaz Title: #362: Clarify meaning of --domain and --realm in installers Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/362/head:pr362 git checkout pr362 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-362.patch Type: text/x-diff Size: 15639 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 2 16:11:54 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 02 Jan 2017 17:11:54 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: martbab commented: """ Bump for review. """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-269991386 From freeipa-github-notification at redhat.com Tue Jan 3 02:04:57 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 03 Jan 2017 03:04:57 +0100 Subject: [Freeipa-devel] [freeipa PR#355][synchronized] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Author: frasertweedale Title: #355: Set up DS TLS on replica in CA-less topology Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/355/head:pr355 git checkout pr355 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-355.patch Type: text/x-diff Size: 4208 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 02:51:01 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 03 Jan 2017 03:51:01 +0100 Subject: [Freeipa-devel] [freeipa PR#355][synchronized] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Author: frasertweedale Title: #355: Set up DS TLS on replica in CA-less topology Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/355/head:pr355 git checkout pr355 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-355.patch Type: text/x-diff Size: 4231 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 04:19:19 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 03 Jan 2017 05:19:19 +0100 Subject: [Freeipa-devel] [freeipa PR#362][comment] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Title: #362: Clarify meaning of --domain and --realm in installers frasertweedale commented: """ All of my comments from #352 were addressed. @stlaz you were the only other person to review #352 and request changes, so I assume you have addressed those too, in which case: ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/362#issuecomment-270050075 From freeipa-github-notification at redhat.com Tue Jan 3 06:56:45 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 07:56:45 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ * Dogtag certificates and RA certificate renewal is broken: ``` ca-error: Server at "https://vm-226.abc.idm.lab.eng.brq.redhat.com:8443/ca/agent/ca/profileProcess" replied: 1: You did not provide a valid certificate for this operation ``` This is because certmonger's `/usr/libexec/certmonger/dogtag-ipa-renew-agent-submit` expects an `ipaCert` in `/etc/httpd/alias`. * CA-less server install fails: ``` [13/21]: publish CA cert [error] CalledProcessError: Command '/usr/bin/certutil -d /etc/httpd/alias -L -n ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA -a' returned non-zero exit status 255 ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR Command '/usr/bin/certutil -d /etc/httpd/alias -L -n ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA -a' returned non-zero exit status 255 ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` ``` 2017-01-03T05:21:43Z DEBUG Starting external process 2017-01-03T05:21:43Z DEBUG args=/usr/bin/certutil -d /var/lib/ipa/radb -L -n ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA -a 2017-01-03T05:21:43Z DEBUG Process finished, return code=255 2017-01-03T05:21:43Z DEBUG stdout= 2017-01-03T05:21:43Z DEBUG stderr=certutil: Could not find cert: ABC.IDM.LAB.ENG.BRQ.REDHAT.COM IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found ``` If I work around the above, it fails further down with: ``` trying https://vm-058-236.abc.idm.lab.eng.brq.redhat.com/ipa/json Forwarding 'schema' to json server 'https://vm-058-236.abc.idm.lab.eng.brq.redhat.com/ipa/json' No valid Negotiate header in server response The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270059781 From freeipa-github-notification at redhat.com Tue Jan 3 07:20:18 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 08:20:18 +0100 Subject: [Freeipa-devel] [freeipa PR#209][comment] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Title: #209: Enumerate available options in IPA installer HonzaCholasta commented: """ Works for me, although you should probably keep the changes to `ipa-ca-install` from the original patch (using the `argparse` format, of course). """ See the full comment at https://github.com/freeipa/freeipa/pull/209#issuecomment-270061547 From freeipa-github-notification at redhat.com Tue Jan 3 08:10:08 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 03 Jan 2017 09:10:08 +0100 Subject: [Freeipa-devel] [freeipa PR#363][opened] ipaclient: schema cache: Handle malformed server info data gracefully Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Author: dkupka Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Action: opened PR body: """ As a part of CLI schema cache some data about each previously contacted server are stored in simple JSON file. The file may get corrupted and became undecodable for various reasons (parallel access, file system error, tampering). Since the data are not necessary we should just warn an continue. https://fedorahosted.org/freeipa/ticket/6578 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/363/head:pr363 git checkout pr363 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-363.patch Type: text/x-diff Size: 1680 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 08:32:04 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 03 Jan 2017 09:32:04 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates tomaskrizek commented: """ @frasertweedale I ran into this issue when I created 100 users with different user certificates: ``` for i in {300..400}; do ipa user-add "test$i" --first T --last T; openssl req -new -newkey rsa:1024 -days 365 -nodes -keyout "private$i.key" -out "cert$i.csr" -subj "/CN=test$i"; ipa cert-request "cert$i.csr" --principal "test$i" ; done ``` Please let me know if you are able to reproduce the issue in this way. It might be possible some unrelated issues may be the cause here. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270068629 From freeipa-github-notification at redhat.com Tue Jan 3 08:34:24 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 03 Jan 2017 09:34:24 +0100 Subject: [Freeipa-devel] [freeipa PR#363][synchronized] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Author: dkupka Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/363/head:pr363 git checkout pr363 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-363.patch Type: text/x-diff Size: 1602 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 08:38:41 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 09:38:41 +0100 Subject: [Freeipa-devel] [freeipa PR#363][comment] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully HonzaCholasta commented: """ Can the corruption also happen for schema files? """ See the full comment at https://github.com/freeipa/freeipa/pull/363#issuecomment-270069386 From freeipa-github-notification at redhat.com Tue Jan 3 08:42:37 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 03 Jan 2017 09:42:37 +0100 Subject: [Freeipa-devel] [freeipa PR#363][comment] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully dkupka commented: """ @HonzaCholasta Yes, it can happen but it is already handles correctly: https://github.com/freeipa/freeipa/blob/master/ipaclient/remote_plugins/schema.py#L387 """ See the full comment at https://github.com/freeipa/freeipa/pull/363#issuecomment-270069845 From freeipa-github-notification at redhat.com Tue Jan 3 08:47:02 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 09:47:02 +0100 Subject: [Freeipa-devel] [freeipa PR#363][comment] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully HonzaCholasta commented: """ @dkupka, ok, see inline comment. """ See the full comment at https://github.com/freeipa/freeipa/pull/363#issuecomment-270070395 From freeipa-github-notification at redhat.com Tue Jan 3 09:02:51 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 03 Jan 2017 10:02:51 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions martbab commented: """ Can somebody take over the review of this PR please? """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-270072446 From freeipa-github-notification at redhat.com Tue Jan 3 09:15:31 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 03 Jan 2017 10:15:31 +0100 Subject: [Freeipa-devel] [freeipa PR#363][synchronized] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Author: dkupka Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/363/head:pr363 git checkout pr363 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-363.patch Type: text/x-diff Size: 1581 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 09:20:02 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 03 Jan 2017 10:20:02 +0100 Subject: [Freeipa-devel] [freeipa PR#209][synchronized] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Author: Akasurde Title: #209: Enumerate available options in IPA installer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/209/head:pr209 git checkout pr209 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-209.patch Type: text/x-diff Size: 2905 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 11:11:41 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 03 Jan 2017 12:11:41 +0100 Subject: [Freeipa-devel] [freeipa PR#209][synchronized] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Author: Akasurde Title: #209: Enumerate available options in IPA installer Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/209/head:pr209 git checkout pr209 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-209.patch Type: text/x-diff Size: 2905 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 11:12:07 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 03 Jan 2017 12:12:07 +0100 Subject: [Freeipa-devel] [freeipa PR#363][synchronized] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Author: dkupka Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/363/head:pr363 git checkout pr363 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-363.patch Type: text/x-diff Size: 1635 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 11:50:55 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 03 Jan 2017 12:50:55 +0100 Subject: [Freeipa-devel] [freeipa PR#361][synchronized] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Author: martbab Title: #361: This PR implements a number of improvements for our Travis CI: Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/361/head:pr361 git checkout pr361 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-361.patch Type: text/x-diff Size: 10048 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 11:54:13 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 12:54:13 +0100 Subject: [Freeipa-devel] [freeipa PR#209][+ack] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Title: #209: Enumerate available options in IPA installer Label: +ack From freeipa-github-notification at redhat.com Tue Jan 3 11:55:22 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 12:55:22 +0100 Subject: [Freeipa-devel] [freeipa PR#209][comment] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Title: #209: Enumerate available options in IPA installer HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/80c0e5cb8d689cf1ec6a883d2c7000f9dadbf7d8 """ See the full comment at https://github.com/freeipa/freeipa/pull/209#issuecomment-270099403 From freeipa-github-notification at redhat.com Tue Jan 3 11:55:24 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 12:55:24 +0100 Subject: [Freeipa-devel] [freeipa PR#209][+pushed] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Title: #209: Enumerate available options in IPA installer Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 3 11:55:25 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 03 Jan 2017 12:55:25 +0100 Subject: [Freeipa-devel] [freeipa PR#209][closed] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Author: Akasurde Title: #209: Enumerate available options in IPA installer Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/209/head:pr209 git checkout pr209 From freeipa-github-notification at redhat.com Tue Jan 3 12:48:15 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 03 Jan 2017 13:48:15 +0100 Subject: [Freeipa-devel] [freeipa PR#355][comment] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology tomaskrizek commented: """ I re-tested the most recent change in domlvl1. ldapssl is turned on both for CA-less replica install and CA-full replica install. I also created a ticket for the above mentioned behavior. https://fedorahosted.org/freeipa/ticket/6577 """ See the full comment at https://github.com/freeipa/freeipa/pull/355#issuecomment-270107325 From freeipa-github-notification at redhat.com Tue Jan 3 12:48:22 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 03 Jan 2017 13:48:22 +0100 Subject: [Freeipa-devel] [freeipa PR#355][+ack] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology Label: +ack From freeipa-github-notification at redhat.com Tue Jan 3 13:18:23 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 03 Jan 2017 14:18:23 +0100 Subject: [Freeipa-devel] [freeipa PR#209][comment] Enumerate available options in IPA installer In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/209 Title: #209: Enumerate available options in IPA installer Akasurde commented: """ @HonzaCholasta Thanks for your help and reviews. """ See the full comment at https://github.com/freeipa/freeipa/pull/209#issuecomment-270112277 From freeipa-github-notification at redhat.com Tue Jan 3 13:40:14 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 03 Jan 2017 14:40:14 +0100 Subject: [Freeipa-devel] [freeipa PR#364][opened] Client-only builds with --disable-server Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Author: tiran Title: #364: Client-only builds with --disable-server Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6517 Simple approach to reduce dependencies for client only builds. I simply wrapped all daemon, init and install dependencies in AM_COND_IF(). I'm open to suggestions. Let the bike shedding begin! """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/364/head:pr364 git checkout pr364 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-364.patch Type: text/x-diff Size: 15620 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 14:18:54 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 03 Jan 2017 15:18:54 +0100 Subject: [Freeipa-devel] [freeipa PR#365][opened] Silence pylint import errors of ipaserver in ipalib and ipaclient Message-ID: URL: https://github.com/freeipa/freeipa/pull/365 Author: tiran Title: #365: Silence pylint import errors of ipaserver in ipalib and ipaclient Action: opened PR body: """ In client-only installations the ipaserver package is not available. Additional guards prevent pylint to complain about missing ipaserver package. https://fedorahosted.org/freeipa/ticket/6468 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/365/head:pr365 git checkout pr365 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-365.patch Type: text/x-diff Size: 1799 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 16:59:11 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 03 Jan 2017 17:59:11 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ Why is dogtag-ipa-renew-agent-submit part of the certmonger package ? And how do we fix it now ? """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270163719 From freeipa-github-notification at redhat.com Tue Jan 3 17:08:23 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Tue, 03 Jan 2017 18:08:23 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code rcritten commented: """ You can specify the nickname using -n/--nickname. You'll probably also want to set --cafile=/etc/ipa/ca.crt, --dbdir=/etc/httpd/alias and sslpinfile=/etc/httpd/alias/pwdfile.txt to maintain current behavior. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270165993 From freeipa-github-notification at redhat.com Tue Jan 3 17:10:36 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 03 Jan 2017 18:10:36 +0100 Subject: [Freeipa-devel] [freeipa PR#366][opened] Use pytest conftest.py Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: opened PR body: """ Let's replace some ugly hacks with proper pytest conftest.py hooks. Test initialization of ipalib.api is now handled in pytest_cmdline_main(). Pytest plugins, markers and ignores are also moved into conftest.py. Additional guards make it possible to run tests without ipaserver installed. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-366.patch Type: text/x-diff Size: 6467 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 3 17:34:46 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 03 Jan 2017 18:34:46 +0100 Subject: [Freeipa-devel] [freeipa PR#366][synchronized] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-366.patch Type: text/x-diff Size: 7375 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 01:34:10 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 04 Jan 2017 02:34:10 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @tomaskrizek yes, I can reproduce with your steps. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270274050 From freeipa-github-notification at redhat.com Wed Jan 4 02:48:22 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 04 Jan 2017 03:48:22 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @tomaskrizek @HonzaCholasta it looks like the problem is: 1. subsearches are conducted in order: 1. `_cert_search` (if `'certificate' in options` add key to result and "seal" it) 2. `_ca_search` (actually perform the search against Dogtag, via `ra.find`) 3. `_ldap_search` (look for local entries that have given cert in their `userCertificate` attr. 2. Due to raising of search limit internally within `ra.find`, for this sub-search, `sub_complete = True` always. 3. ~line 1477: ```python if sub_complete: sizelimit = None ... ``` This causes the next sub-search (`_ldap_search`) to be carried out with the *default* size limit (100). 4. If there are > 100 entries with the `(userCertificate=*)`, this search will be truncated, and this result is carried across to the final result. The cert search from Dogtag is not truncated, but the search for entries to use to filter the result may have been truncated. The simplest way to resolve this is (I think) to forcibly execute `_ldap_search` with `sizelimit=0`. IMO `_ldap_search` should also be avoided or short-circuited if none of the owner-flitering options to `cert-find` are given. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270283124 From freeipa-github-notification at redhat.com Wed Jan 4 02:49:12 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 04 Jan 2017 03:49:12 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @tomaskrizek @HonzaCholasta it looks like the problem is: 1. subsearches are conducted in order: 1. `_cert_search` (if `'certificate' in options` add key to result and "seal" it) 2. `_ca_search` (actually perform the search against Dogtag, via `ra.find`) 3. `_ldap_search` (look for local entries that have given cert in their `userCertificate` attr. 2. Due to raising of search limit internally within `ra.find`, `_ca_search` will return `sub_complete = True` always. 3. ~line 1477: ```python if sub_complete: sizelimit = None ... ``` This causes the next sub-search (`_ldap_search`) to be carried out with the *default* size limit (100). 4. If there are > 100 entries with the `(userCertificate=*)`, this search will be truncated, and this result is carried across to the final result. The cert search from Dogtag is not truncated, but the search for entries to use to filter the result may have been truncated. The simplest way to resolve this is (I think) to forcibly execute `_ldap_search` with `sizelimit=0`. IMO `_ldap_search` should also be avoided or short-circuited if none of the owner-flitering options to `cert-find` are given. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270283124 From freeipa-github-notification at redhat.com Wed Jan 4 03:10:27 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 04 Jan 2017 04:10:27 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @tomaskrizek @HonzaCholasta it looks like the problem is: 1. subsearches are conducted in order: 1. `_cert_search` (if `'certificate' in options` add key to result and "seal" it) 2. `_ca_search` (actually perform the search against Dogtag, via `ra.find`) 3. `_ldap_search` (look for local entries that have given cert in their `userCertificate` attr. 2. Due to raising of search limit internally within `ra.find`, `_ca_search` will return `sub_complete = True` always. 3. ~line 1477: ```python if sub_complete: sizelimit = None ... ``` This causes the next sub-search (`_ldap_search`) to be carried out with the *default* size limit (100). 4. If there are > 100 entries with the `(userCertificate=*)`, this search will be truncated, and this result is carried across to the final result. The cert search from Dogtag is not truncated, but the search for entries to use to filter the result may have been truncated. The simplest way to resolve this is (I think) to forcibly execute `_ldap_search` with `sizelimit=0`. IMO `_ldap_search` should also be avoided or short-circuited if none of the owner-flitering options to `cert-find` are given. (edit to note: this will not find certs that are in IPA LDAP but not in Dogtag, which is guess is the wrong behaviour..? So I think we just have to have sizelimit=0. I am concerned about performance impact of cert-find with many principals with certs set... but that is a separate issue). """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270283124 From freeipa-github-notification at redhat.com Wed Jan 4 03:12:29 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 04 Jan 2017 04:12:29 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @tomaskrizek @HonzaCholasta it looks like the problem is: 1. subsearches are conducted in order: 1. `_cert_search` (if `'certificate' in options` add key to result and "seal" it) 2. `_ca_search` (actually perform the search against Dogtag, via `ra.find`) 3. `_ldap_search` (look for local entries that have given cert in their `userCertificate` attr. 2. if no explicit `sizelimit` is requested, and if there are > 100 entries with `(userCertificate=*)`, `_ldap_search` will be truncated, and this result is carried across to the final result. The cert search from Dogtag is not truncated, but the search for entries to use to filter the result may have been truncated. The simplest way to resolve this is (I think) to forcibly execute `_ldap_search` with `sizelimit=0`. IMO `_ldap_search` should also be avoided or short-circuited if none of the owner-flitering options to `cert-find` are given. (edit to note: this will not find certs that are in IPA LDAP but not in Dogtag, which is guess is the wrong behaviour..? So I think we just have to have sizelimit=0. I am concerned about performance impact of cert-find with many principals with certs set... but that is a separate issue). """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270283124 From freeipa-github-notification at redhat.com Wed Jan 4 05:25:27 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 04 Jan 2017 06:25:27 +0100 Subject: [Freeipa-devel] [freeipa PR#179][synchronized] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Author: Akasurde Title: #179: Fix for handling CalledProcessError in authconfig Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/179/head:pr179 git checkout pr179 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-179.patch Type: text/x-diff Size: 3190 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 07:58:09 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 08:58:09 +0100 Subject: [Freeipa-devel] [freeipa PR#362][+ack] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Title: #362: Clarify meaning of --domain and --realm in installers Label: +ack From freeipa-github-notification at redhat.com Wed Jan 4 08:53:32 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 09:53:32 +0100 Subject: [Freeipa-devel] [freeipa PR#367][opened] Remove nsslib from IPA Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: opened PR body: """ This batch of patches removes NSSConnection along with the whole ipapython.nsslib from IPA and replaces it with more standard httplib.HTTPSConnection. NSSConnection was causing a lot of trouble in the past because it is apparently very fragile when it comes to nss library initialization. On top of that, when NSSConnection is used to set up an HTTPS connection in FIPS, it always requires a password to NSS database as NSS apparently tries to create a temporary private key and store it to the database even though client authentication is not required in the SSL connection. TODO (will require changes in certmonger/dogatg.c): - [ ] we may probably remove ipaCert from /etc/httpd/alias and stop tracking it with certmonger - [ ] once ^- is done, track /var/lib/ipa/ra-agent.pem in certmonger instead https://fedorahosted.org/freeipa/ticket/5695 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 50848 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 08:55:15 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 09:55:15 +0100 Subject: [Freeipa-devel] [freeipa PR#367][edited] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: edited Changed field: body Original value: """ This batch of patches removes NSSConnection along with the whole ipapython.nsslib from IPA and replaces it with more standard httplib.HTTPSConnection. NSSConnection was causing a lot of trouble in the past because it is apparently very fragile when it comes to nss library initialization. On top of that, when NSSConnection is used to set up an HTTPS connection in FIPS, it always requires a password to NSS database as NSS apparently tries to create a temporary private key and store it to the database even though client authentication is not required in the SSL connection. TODO (will require changes in certmonger/dogatg.c): - [ ] we may probably remove ipaCert from /etc/httpd/alias and stop tracking it with certmonger - [ ] once ^- is done, track /var/lib/ipa/ra-agent.pem in certmonger instead https://fedorahosted.org/freeipa/ticket/5695 """ From freeipa-github-notification at redhat.com Wed Jan 4 09:27:29 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 10:27:29 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates stlaz commented: """ @frasertweedale if `_ldap_search` is performed with correct filters, `sizelimit=0` is not the correct solution at least for CLI which should either follow the `sizelimit` argument if set or the records size limit in ipa config. It is only correct for WebUI which I believe should be setting `sizelimit=0` and if it's not, I'd be looking for the bug there. I tried to briefly go through the cert plugin code but it's a bit messy so my only hope is that the correct filter is indeed used there. On the way through it, though, I found something that seems like another size limit bug: https://github.com/freeipa/freeipa/blob/master/ipaserver/plugins/cert.py#L1306 -> which will not set our "unlimited" if `sizelimit` is set to 0. Also from there, if `sizelimit` is not set, we should go with ipa config sizelimit rather than having the magic do its trick somewhere else, right? Then the proposed value in options.get() could go away (be set in the cert.py module instead). """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270328738 From freeipa-github-notification at redhat.com Wed Jan 4 09:51:07 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 10:51:07 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: stlaz commented: """ I assume the licence headers did not break the automember tests so this could be pushed. Just a brief question: would it be reasonable to get the line number of "========= FAILURES =========" and tail the "$CI_TRAVIS_LOG" from the end to it? """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270333276 From freeipa-github-notification at redhat.com Wed Jan 4 09:53:34 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 10:53:34 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 50871 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 10:00:31 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 11:00:31 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA tiran commented: """ * Ticket 5695 looks wrong, it's about ```FreeIPA on FIPS enabled systems```. * Are customers fine with the fact that FreeIPA clients will no longer very CRLs? OpenSSL does not automatically download and verify CRLs. OCSP is not yet supported by Python's ssl module. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270335111 From freeipa-github-notification at redhat.com Wed Jan 4 10:02:35 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 11:02:35 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA tiran commented: """ * Ticket 5695 is about ```FreeIPA on FIPS enabled systems```. Moving from NSS to OpenSSL is a big change and should be tracked by its own ticket. * Are customers fine with the fact that FreeIPA clients will no longer very CRLs? OpenSSL does not automatically download and verify CRLs. OCSP is not yet supported by Python's ssl module. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270335111 From freeipa-github-notification at redhat.com Wed Jan 4 10:40:53 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 04 Jan 2017 11:40:53 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: martbab commented: """ @stlaz thanks for an idea, that will actually make the log output much more useful. I will try to think about it. """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270342516 From freeipa-github-notification at redhat.com Wed Jan 4 11:10:12 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 12:10:12 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ You're right, I should probably write some design. The current implementation does not check CRL or OSCP, so we're "fine" with this change. There is a plan on doing CRL check in certmonger, though. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270347796 From freeipa-github-notification at redhat.com Wed Jan 4 11:29:51 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 12:29:51 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: stlaz commented: """ @martbab My naive solution is to do something like ```bash LINE=`grep -n -m 1 $CI_TRAVIS_LOG -e "=== FAILURES ===" | cut -d: -f1` LINES=`wc -l $CI_TRAVIS_LOG` tail -n `expr $LINES - $LINE` $CI_TRAVIS_LOG ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270350910 From freeipa-github-notification at redhat.com Wed Jan 4 11:31:26 2017 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 04 Jan 2017 12:31:26 +0100 Subject: [Freeipa-devel] [freeipa PR#368][opened] WebUI: fix incorrect behavior of ESC button on combobox Message-ID: URL: https://github.com/freeipa/freeipa/pull/368 Author: pvomacka Title: #368: WebUI: fix incorrect behavior of ESC button on combobox Action: opened PR body: """ When combobox is opened then ESC key should close it. There was a bug that ESC key closed also the dialog. It was caused by bad keyboard event handling. The CB was closed by keydown event and the dialog by keyup. Therefore the propagating of keyup and keydown event is stopped when CB is opened (when the event is fired on CB element). https://fedorahosted.org/freeipa/ticket/6388 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/368/head:pr368 git checkout pr368 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-368.patch Type: text/x-diff Size: 3391 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 11:36:21 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 12:36:21 +0100 Subject: [Freeipa-devel] [freeipa PR#334][comment] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Title: #334: Py3: Fix ToASCII method tiran commented: """ I have kicked Travis. Let's see if the test is passing now. """ See the full comment at https://github.com/freeipa/freeipa/pull/334#issuecomment-270351974 From freeipa-github-notification at redhat.com Wed Jan 4 11:55:49 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 12:55:49 +0100 Subject: [Freeipa-devel] [freeipa PR#352][comment] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/352 Title: #352: Clarify meaning of --domain and --realm in installers stlaz commented: """ The fixes to raised issues are fixed in https://github.com/freeipa/freeipa/issues/362 """ See the full comment at https://github.com/freeipa/freeipa/pull/352#issuecomment-270355061 From freeipa-github-notification at redhat.com Wed Jan 4 11:55:53 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 12:55:53 +0100 Subject: [Freeipa-devel] [freeipa PR#352][+rejected] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/352 Title: #352: Clarify meaning of --domain and --realm in installers Label: +rejected From freeipa-github-notification at redhat.com Wed Jan 4 11:55:58 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 12:55:58 +0100 Subject: [Freeipa-devel] [freeipa PR#352][closed] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/352 Author: pspacek Title: #352: Clarify meaning of --domain and --realm in installers Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/352/head:pr352 git checkout pr352 From freeipa-github-notification at redhat.com Wed Jan 4 12:37:17 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Wed, 04 Jan 2017 13:37:17 +0100 Subject: [Freeipa-devel] [freeipa PR#294][synchronized] client, platform: Use paths.SSH* instead of get_config_dir(). In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/294 Author: tjaalton Title: #294: client, platform: Use paths.SSH* instead of get_config_dir(). Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/294/head:pr294 git checkout pr294 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-294.patch Type: text/x-diff Size: 6251 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 12:42:43 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 13:42:43 +0100 Subject: [Freeipa-devel] [freeipa PR#366][synchronized] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-366.patch Type: text/x-diff Size: 4627 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 12:43:16 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 13:43:16 +0100 Subject: [Freeipa-devel] [freeipa PR#369][opened] Catch ValueError raised by pytest.config.getoption() Message-ID: URL: https://github.com/freeipa/freeipa/pull/369 Author: tiran Title: #369: Catch ValueError raised by pytest.config.getoption() Action: opened PR body: """ pytest.config.getoption() can raise ValueError for unknown options, too. I ran into the issue while I was working on PR #366 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/369/head:pr369 git checkout pr369 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-369.patch Type: text/x-diff Size: 1482 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 14:26:50 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Wed, 04 Jan 2017 15:26:50 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ Did you open a bug against NSS or python-nss regarding the PIN requirement? """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270382386 From freeipa-github-notification at redhat.com Wed Jan 4 14:31:23 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 04 Jan 2017 15:31:23 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ @rcritten I spoke to the NSS people who assured me it's the intended behavior. But thanks for the remainder, I will open a Bugzilla for that as well, I was considering it before Christmas. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270383517 From freeipa-github-notification at redhat.com Wed Jan 4 15:06:10 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 04 Jan 2017 16:06:10 +0100 Subject: [Freeipa-devel] [freeipa PR#366][synchronized] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-366.patch Type: text/x-diff Size: 8975 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 15:13:32 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 04 Jan 2017 16:13:32 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 236595 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 4 15:14:24 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 04 Jan 2017 16:14:24 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ Rebased on master and fixed a couple minor lint issues """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270394337 From Bob.Carroll at conocophillips.com Tue Jan 3 21:52:20 2017 From: Bob.Carroll at conocophillips.com (Carroll, Bob) Date: Tue, 3 Jan 2017 21:52:20 +0000 Subject: [Freeipa-devel] ypcat passwd lists disabled accounts Message-ID: Should ypcat be filtering out the disabled accounts? Bob Carroll Sr. Analyst/Technical Unix Services/ConocoPhillips/Information Technology Phone: +1 281 293-1438 Mobile: +1 918 841-1131 Submit a ServiceNow Ticket -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Thu Jan 5 01:10:15 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 02:10:15 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates frasertweedale commented: """ @stlaz as I see it, the `_ldap_search` can potentially search all objects of a particular type (user/service/host), which have `(userCertificate=*)`. The result is then used to filter or add to the result, depending on whether the result is "key complete" or not (indicated by the variable `complete`). Anyhow I leave to Honza to comment further; he probably understands the code better than me :) """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-270534943 From freeipa-github-notification at redhat.com Thu Jan 5 02:27:00 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 03:27:00 +0100 Subject: [Freeipa-devel] [freeipa PR#370][opened] [EXPERIMENT] ci: send build log to paste.fedoraproject.org Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: opened PR body: """ This commit is just to see if we can ship our build logs off travis to a pastebin. If we can, we can refine the approach to only ship logs when the build broke, provide better output about where to find them, etc. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 927 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 02:29:20 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 03:29:20 +0100 Subject: [Freeipa-devel] [freeipa PR#370][synchronized] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 942 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 03:49:52 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 04:49:52 +0100 Subject: [Freeipa-devel] [freeipa PR#370][synchronized] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 1375 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 04:01:21 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 05:01:21 +0100 Subject: [Freeipa-devel] [freeipa PR#370][synchronized] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 1485 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 04:59:53 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 05:59:53 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org frasertweedale commented: """ OK, so we can ship a paste off but paste.fedoraproject.org does not like the file size (~1.8M). In this case the HTTP response is 200 OK and the response body is the HTML frontpage. The paste does not succeed. Experimentally: a paste of < 512K succeeds, but a paste of ~1M fails. Now, fpaste is happy enough accepting binary data, e.g. a gzipped file curl https://paste.fedoraproject.org/520077/raw/ | zless The downsides to doing that are: 1. Cannot view in browser 2. Inefficiency of percent-encoding (compressed data will inflate by ~2.5x for transfer) - base64url-encoding the compressed data will avoid percent-encoding and limit inflation to 1.33x But the upside is of course that we can get these files off so developers can get at them, so I think we should do that. """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270564366 From freeipa-github-notification at redhat.com Thu Jan 5 05:47:08 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 06:47:08 +0100 Subject: [Freeipa-devel] [freeipa PR#370][synchronized] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 1430 bytes Desc: not available URL: From ftweedal at redhat.com Thu Jan 5 07:06:38 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 Jan 2017 17:06:38 +1000 Subject: [Freeipa-devel] CI: exporting test runner output Message-ID: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> Hi all, Although it has been discussed before and met with some skepticism, here is a POC that exporting test runner output to, e.g. a pastebin, does work: - experimental commit: https://github.com/freeipa/freeipa/pull/370 - example paste: https://paste.fedoraproject.org/520085/ (it is gzipped for reasons discussed in the PR) I think we should proceed with getting these artifacts out of Travis and stored somewhere (it doesn't have to be paste.fedoraproject.org). ``tail -n 5000`` of the log file has proven to be not enough to diagnose all failures. If we stick with paste.fedoraproject.org, we can send to a "project-specific" namespace e.g. https://paste.fedoraproject.org/~freeipa, so that we do not clutter up the main archive (I think). A few questions for discussion: 1. Stick with fpaste or not? If so, use "~freeipa" namespace? (Keep in mind that the size limitation that exists for fpaste, which requires compressing the artifact, may not be a problem elsewhere). 2. Export log always, or only if the build job failed? 3. Should pasted logs expire? If so, what should TTL be? 4. Should we continue to `tail -n 5000` the log as we currently do, or just rely on exported log? Thanks, Fraser From freeipa-github-notification at redhat.com Thu Jan 5 07:51:30 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 08:51:30 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org stlaz commented: """ Um, sorry, but I fail to see the real upside here, perhaps I am missing something. If I see here on github that a build of my PR failed, and I really don't check it if it's ok, I can just go, click three or four times and I get where I want and see what I want and that all is at the same spot where my code is. What exactly do I get by having the log pasted somewhere where it's nowhere connected to the code I submitted? I believe I must be missing something so please educate me :) """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270583984 From freeipa-github-notification at redhat.com Thu Jan 5 07:53:14 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 08:53:14 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ @rcritten I spoke to the NSS people who assured me it's the intended behavior. But thanks for the remainder, I will open a Bugzilla for that as well, I was considering it before Christmas. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270383517 From mbabinsk at redhat.com Thu Jan 5 07:53:14 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Thu, 5 Jan 2017 08:53:14 +0100 Subject: [Freeipa-devel] CI: exporting test runner output In-Reply-To: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> References: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> Message-ID: <2374e4b3-9302-b5cc-77cd-659628dd877d@redhat.com> On 01/05/2017 08:06 AM, Fraser Tweedale wrote: > Hi all, > > Although it has been discussed before and met with some skepticism, > here is a POC that exporting test runner output to, e.g. a pastebin, > does work: > > - experimental commit: https://github.com/freeipa/freeipa/pull/370 > - example paste: https://paste.fedoraproject.org/520085/ > (it is gzipped for reasons discussed in the PR) > > I think we should proceed with getting these artifacts out of Travis > and stored somewhere (it doesn't have to be > paste.fedoraproject.org). ``tail -n 5000`` of the log file has > proven to be not enough to diagnose all failures. > Wow this is great, why have I not thought about it beforehand? We can reduce the log size if we truncate everything before ERRORS/FAILURES output of pytest run (we leave the log as it is if the fail occurs before this stage), that should shave off considerable amount of cruft from the paste unless somebody sends a PR that breaks all out tests :D. > If we stick with paste.fedoraproject.org, we can send to a > "project-specific" namespace e.g. > https://paste.fedoraproject.org/~freeipa, so that we do not clutter > up the main archive (I think). > > A few questions for discussion: > > 1. Stick with fpaste or not? If so, use "~freeipa" namespace? > (Keep in mind that the size limitation that exists for fpaste, > which requires compressing the artifact, may not be a problem > elsewhere). > > 2. Export log always, or only if the build job failed? > I would also paste the output to "freeipa" or even better "freeipa-travis" namespace and only send it if the job fails. > 3. Should pasted logs expire? If so, what should TTL be? > IMHO yes, but TTL is hard to determine, since the author of the PR may not be present to review the results immediately (because he is on PTO etc.). I think we should set TTL to something like 1 week and as a fallback keep tailing the CI results log. > 4. Should we continue to `tail -n 5000` the log as we currently do, > or just rely on exported log? > > Thanks, > Fraser > Fraser, are you OK with waiting with this effort until we push https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more adjustments there (like result log trimming) and it should be pushed ASAP. -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Thu Jan 5 07:54:21 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 08:54:21 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org stlaz commented: """ Um, sorry, but I fail to see the real upside here, perhaps I am missing something. If I see here on github that a build of my PR failed, and I really don't check it if it's ok, I can just go, click three or four times and I get where I want and see what I want and that all is at the same spot where my code is. What exactly do I get by having the log pasted somewhere where it's nowhere connected to the code I submitted? I believe I must be missing something so please educate me :) """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270583984 From freeipa-github-notification at redhat.com Thu Jan 5 08:07:06 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 05 Jan 2017 09:07:06 +0100 Subject: [Freeipa-devel] [freeipa PR#348][comment] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only HonzaCholasta commented: """ @frasertweedale, is that an ACK? :-) """ See the full comment at https://github.com/freeipa/freeipa/pull/348#issuecomment-270586148 From ftweedal at redhat.com Thu Jan 5 08:25:32 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 Jan 2017 18:25:32 +1000 Subject: [Freeipa-devel] CI: exporting test runner output In-Reply-To: <2374e4b3-9302-b5cc-77cd-659628dd877d@redhat.com> References: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> <2374e4b3-9302-b5cc-77cd-659628dd877d@redhat.com> Message-ID: <20170105082532.GK4539@dhcp-40-8.bne.redhat.com> On Thu, Jan 05, 2017 at 08:53:14AM +0100, Martin Babinsky wrote: > On 01/05/2017 08:06 AM, Fraser Tweedale wrote: > > Hi all, > > > > Although it has been discussed before and met with some skepticism, > > here is a POC that exporting test runner output to, e.g. a pastebin, > > does work: > > > > - experimental commit: https://github.com/freeipa/freeipa/pull/370 > > - example paste: https://paste.fedoraproject.org/520085/ > > (it is gzipped for reasons discussed in the PR) > > > > I think we should proceed with getting these artifacts out of Travis > > and stored somewhere (it doesn't have to be > > paste.fedoraproject.org). ``tail -n 5000`` of the log file has > > proven to be not enough to diagnose all failures. > > > Wow this is great, why have I not thought about it beforehand? > > We can reduce the log size if we truncate everything before ERRORS/FAILURES > output of pytest run (we leave the log as it is if the fail occurs before > this stage), that should shave off considerable amount of cruft from the > paste unless somebody sends a PR that breaks all out tests :D. > > > If we stick with paste.fedoraproject.org, we can send to a > > "project-specific" namespace e.g. > > https://paste.fedoraproject.org/~freeipa, so that we do not clutter > > up the main archive (I think). > > > > A few questions for discussion: > > > > 1. Stick with fpaste or not? If so, use "~freeipa" namespace? > > (Keep in mind that the size limitation that exists for fpaste, > > which requires compressing the artifact, may not be a problem > > elsewhere). > > > > 2. Export log always, or only if the build job failed? > > > I would also paste the output to "freeipa" or even better "freeipa-travis" > namespace and only send it if the job fails. > I might go with "freeipa-ci". > > 3. Should pasted logs expire? If so, what should TTL be? > > > IMHO yes, but TTL is hard to determine, since the author of the PR may not > be present to review the results immediately (because he is on PTO etc.). I > think we should set TTL to something like 1 week and as a fallback keep > tailing the CI results log. > 1 week sounds reasonable. We can change it later if we need to. > > 4. Should we continue to `tail -n 5000` the log as we currently do, > > or just rely on exported log? > > > > Thanks, > > Fraser > > > > Fraser, are you OK with waiting with this effort until we push > https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more > adjustments there (like result log trimming) and it should be pushed ASAP. > Yes, I was aware that there would be conflicts with this PR. I don't mind waiting. Thanks for your input. Cheers, Fraser From freeipa-github-notification at redhat.com Thu Jan 5 08:26:43 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 09:26:43 +0100 Subject: [Freeipa-devel] [freeipa PR#348][comment] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only frasertweedale commented: """ It is an ACK. I don't have perms to add the label tho :) """ See the full comment at https://github.com/freeipa/freeipa/pull/348#issuecomment-270589226 From freeipa-github-notification at redhat.com Thu Jan 5 08:29:46 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:29:46 +0100 Subject: [Freeipa-devel] [freeipa PR#348][comment] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only mbasti-rh commented: """ @frasertweedale your permissions have been upgraded :) """ See the full comment at https://github.com/freeipa/freeipa/pull/348#issuecomment-270589759 From freeipa-github-notification at redhat.com Thu Jan 5 08:33:03 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 09:33:03 +0100 Subject: [Freeipa-devel] [freeipa PR#348][+ack] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 08:33:35 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 09:33:35 +0100 Subject: [Freeipa-devel] [freeipa PR#348][comment] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only frasertweedale commented: """ Thanks @mbasti-rh ! """ See the full comment at https://github.com/freeipa/freeipa/pull/348#issuecomment-270590370 From Oucema.Bellagha at hotmail.com Thu Jan 5 08:36:21 2017 From: Oucema.Bellagha at hotmail.com (Oucema Bellagha) Date: Thu, 5 Jan 2017 08:36:21 +0000 Subject: [Freeipa-devel] FreeIPA, Duo Security integration Message-ID: Hi, As of now, we have FreeIPA with OTP working perfectly. Now, I am looking at possibly integrating Duo security instead of FreeIPA's 2FA. I am concerned about how it will fit in with FreeIPA... Has anyone else tried this before? If so, are there any pitfalls or problems you have encountered or any general advise? Cheers, Euqanra'l -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkrizek at redhat.com Thu Jan 5 08:38:03 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 5 Jan 2017 09:38:03 +0100 Subject: [Freeipa-devel] CI: exporting test runner output In-Reply-To: <20170105082532.GK4539@dhcp-40-8.bne.redhat.com> References: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> <2374e4b3-9302-b5cc-77cd-659628dd877d@redhat.com> <20170105082532.GK4539@dhcp-40-8.bne.redhat.com> Message-ID: On 01/05/2017 09:25 AM, Fraser Tweedale wrote: > On Thu, Jan 05, 2017 at 08:53:14AM +0100, Martin Babinsky wrote: >> On 01/05/2017 08:06 AM, Fraser Tweedale wrote: >>> Hi all, >>> >>> Although it has been discussed before and met with some skepticism, >>> here is a POC that exporting test runner output to, e.g. a pastebin, >>> does work: >>> >>> - experimental commit: https://github.com/freeipa/freeipa/pull/370 >>> - example paste: https://paste.fedoraproject.org/520085/ >>> (it is gzipped for reasons discussed in the PR) >>> >>> I think we should proceed with getting these artifacts out of Travis >>> and stored somewhere (it doesn't have to be >>> paste.fedoraproject.org). ``tail -n 5000`` of the log file has >>> proven to be not enough to diagnose all failures. >>> >> Wow this is great, why have I not thought about it beforehand? Seems like a great feature. Thanks, Fraser! >> We can reduce the log size if we truncate everything before ERRORS/FAILURES >> output of pytest run (we leave the log as it is if the fail occurs before >> this stage), that should shave off considerable amount of cruft from the >> paste unless somebody sends a PR that breaks all out tests :D. >> >>> If we stick with paste.fedoraproject.org, we can send to a >>> "project-specific" namespace e.g. >>> https://paste.fedoraproject.org/~freeipa, so that we do not clutter >>> up the main archive (I think). >>> >>> A few questions for discussion: >>> >>> 1. Stick with fpaste or not? If so, use "~freeipa" namespace? >>> (Keep in mind that the size limitation that exists for fpaste, >>> which requires compressing the artifact, may not be a problem >>> elsewhere). >>> >>> 2. Export log always, or only if the build job failed? >>> >> I would also paste the output to "freeipa" or even better "freeipa-travis" >> namespace and only send it if the job fails. >> > I might go with "freeipa-ci". +1 >>> 3. Should pasted logs expire? If so, what should TTL be? >>> >> IMHO yes, but TTL is hard to determine, since the author of the PR may not >> be present to review the results immediately (because he is on PTO etc.). I >> think we should set TTL to something like 1 week and as a fallback keep >> tailing the CI results log. >> > 1 week sounds reasonable. We can change it later if we need to. I actually wouldn't mind extending this to something like 2-4 weeks. In some cases it might be useful to have access to older logs (PTOs, or simply to just view the history for some reason). Is there any downside to keeping the logs for a bit longer? >>> 4. Should we continue to `tail -n 5000` the log as we currently do, >>> or just rely on exported log? If you're talking about the log in the travis web interface, I would keep it. It's easily accessible from the browser. >>> Thanks, >>> Fraser >> Fraser, are you OK with waiting with this effort until we push >> https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more >> adjustments there (like result log trimming) and it should be pushed ASAP. >> > Yes, I was aware that there would be conflicts with this PR. I > don't mind waiting. Thanks for your input. > > Cheers, > Fraser > -- Tomas Krizek From freeipa-github-notification at redhat.com Thu Jan 5 08:47:48 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:47:48 +0100 Subject: [Freeipa-devel] [freeipa PR#362][comment] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Title: #362: Clarify meaning of --domain and --realm in installers mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/25a6ddcce8e7b9effaf19431c421dc5b3497fa22 """ See the full comment at https://github.com/freeipa/freeipa/pull/362#issuecomment-270592688 From freeipa-github-notification at redhat.com Thu Jan 5 08:47:49 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:47:49 +0100 Subject: [Freeipa-devel] [freeipa PR#362][+pushed] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Title: #362: Clarify meaning of --domain and --realm in installers Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 08:47:51 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:47:51 +0100 Subject: [Freeipa-devel] [freeipa PR#362][closed] Clarify meaning of --domain and --realm in installers In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/362 Author: stlaz Title: #362: Clarify meaning of --domain and --realm in installers Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/362/head:pr362 git checkout pr362 From freeipa-github-notification at redhat.com Thu Jan 5 08:49:24 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 09:49:24 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org frasertweedale commented: """ Additional notes about paste.fedoraproject.org projects: - seems that only names consisting entirely of alpha chars work (thus ruling out `freeipa-ci` or similar) - pastes to a project namespace appear in *both* the project archive, and the main archive. - example command: ```shell curl -v https://paste.fedoraproject.org/~freeipa/ -H Expect: \ -d api_submit=true \ -d mode=json \ -d paste_lang=text \ -d paste_data=hello+world \ -d paste_expire=300 ``` - paste can be accessed via top name space or project (or any *other*, too) """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270592924 From freeipa-github-notification at redhat.com Thu Jan 5 08:49:45 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:49:45 +0100 Subject: [Freeipa-devel] [freeipa PR#365][+ack] Silence pylint import errors of ipaserver in ipalib and ipaclient In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/365 Title: #365: Silence pylint import errors of ipaserver in ipalib and ipaclient Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 08:50:47 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:50:47 +0100 Subject: [Freeipa-devel] [freeipa PR#365][+pushed] Silence pylint import errors of ipaserver in ipalib and ipaclient In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/365 Title: #365: Silence pylint import errors of ipaserver in ipalib and ipaclient Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 08:50:49 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:50:49 +0100 Subject: [Freeipa-devel] [freeipa PR#365][comment] Silence pylint import errors of ipaserver in ipalib and ipaclient In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/365 Title: #365: Silence pylint import errors of ipaserver in ipalib and ipaclient mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/987d24f784e05e911bf4e87bd1156abb1dd56210 """ See the full comment at https://github.com/freeipa/freeipa/pull/365#issuecomment-270593168 From freeipa-github-notification at redhat.com Thu Jan 5 08:50:50 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:50:50 +0100 Subject: [Freeipa-devel] [freeipa PR#365][closed] Silence pylint import errors of ipaserver in ipalib and ipaclient In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/365 Author: tiran Title: #365: Silence pylint import errors of ipaserver in ipalib and ipaclient Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/365/head:pr365 git checkout pr365 From ftweedal at redhat.com Thu Jan 5 08:54:29 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Thu, 5 Jan 2017 18:54:29 +1000 Subject: [Freeipa-devel] CI: exporting test runner output In-Reply-To: References: <20170105070637.GJ4539@dhcp-40-8.bne.redhat.com> <2374e4b3-9302-b5cc-77cd-659628dd877d@redhat.com> <20170105082532.GK4539@dhcp-40-8.bne.redhat.com> Message-ID: <20170105085429.GL4539@dhcp-40-8.bne.redhat.com> On Thu, Jan 05, 2017 at 09:38:03AM +0100, Tomas Krizek wrote: > On 01/05/2017 09:25 AM, Fraser Tweedale wrote: > > On Thu, Jan 05, 2017 at 08:53:14AM +0100, Martin Babinsky wrote: > >> On 01/05/2017 08:06 AM, Fraser Tweedale wrote: > >>> Hi all, > >>> > >>> Although it has been discussed before and met with some skepticism, > >>> here is a POC that exporting test runner output to, e.g. a pastebin, > >>> does work: > >>> > >>> - experimental commit: https://github.com/freeipa/freeipa/pull/370 > >>> - example paste: https://paste.fedoraproject.org/520085/ > >>> (it is gzipped for reasons discussed in the PR) > >>> > >>> I think we should proceed with getting these artifacts out of Travis > >>> and stored somewhere (it doesn't have to be > >>> paste.fedoraproject.org). ``tail -n 5000`` of the log file has > >>> proven to be not enough to diagnose all failures. > >>> > >> Wow this is great, why have I not thought about it beforehand? > Seems like a great feature. Thanks, Fraser! > >> We can reduce the log size if we truncate everything before ERRORS/FAILURES > >> output of pytest run (we leave the log as it is if the fail occurs before > >> this stage), that should shave off considerable amount of cruft from the > >> paste unless somebody sends a PR that breaks all out tests :D. > >> > >>> If we stick with paste.fedoraproject.org, we can send to a > >>> "project-specific" namespace e.g. > >>> https://paste.fedoraproject.org/~freeipa, so that we do not clutter > >>> up the main archive (I think). > >>> I was wrong. All "project" pastes appear in main namespace as well as project namespace. Not sure if by design or not. > >>> A few questions for discussion: > >>> > >>> 1. Stick with fpaste or not? If so, use "~freeipa" namespace? > >>> (Keep in mind that the size limitation that exists for fpaste, > >>> which requires compressing the artifact, may not be a problem > >>> elsewhere). > >>> > >>> 2. Export log always, or only if the build job failed? > >>> > >> I would also paste the output to "freeipa" or even better "freeipa-travis" > >> namespace and only send it if the job fails. > >> > > I might go with "freeipa-ci". > +1 > Unfortunately fpaste can't handle this. Has to be all-alpha. So we can use "freeipaci" but given the constraint I would rather just use "freeipa". I shall file a fedora-infra ticket to see if this can be addressed. > >>> 3. Should pasted logs expire? If so, what should TTL be? > >>> > >> IMHO yes, but TTL is hard to determine, since the author of the PR may not > >> be present to review the results immediately (because he is on PTO etc.). I > >> think we should set TTL to something like 1 week and as a fallback keep > >> tailing the CI results log. > >> > > 1 week sounds reasonable. We can change it later if we need to. > I actually wouldn't mind extending this to something like 2-4 weeks. In > some cases it might be useful to have access to older logs (PTOs, or > simply to just view the history for some reason). Is there any downside > to keeping the logs for a bit longer? > Not really. I was thinking server diskspace is logs were very big but now that we're compressing I don't think it matters. 4 weeks, sure why not :) > >>> 4. Should we continue to `tail -n 5000` the log as we currently do, > >>> or just rely on exported log? > If you're talking about the log in the travis web interface, I would > keep it. It's easily accessible from the browser. > >>> Thanks, > >>> Fraser > >> Fraser, are you OK with waiting with this effort until we push > >> https://github.com/freeipa/freeipa/pull/361 ?. I will just do some more > >> adjustments there (like result log trimming) and it should be pushed ASAP. > >> > > Yes, I was aware that there would be conflicts with this PR. I > > don't mind waiting. Thanks for your input. > > > > Cheers, > > Fraser > > > -- > Tomas Krizek > > From freeipa-github-notification at redhat.com Thu Jan 5 08:57:54 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 09:57:54 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values mbasti-rh commented: """ PR needs rebase """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270594446 From freeipa-github-notification at redhat.com Thu Jan 5 09:17:26 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 10:17:26 +0100 Subject: [Freeipa-devel] [freeipa PR#355][+pushed] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 09:17:28 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 10:17:28 +0100 Subject: [Freeipa-devel] [freeipa PR#355][comment] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/6f7d982fe2e2d2f042e85710b8d8d59167e5796f https://fedorahosted.org/freeipa/changeset/a5fb5f2da1be158cde585a087aaf97eca6218dd7 """ See the full comment at https://github.com/freeipa/freeipa/pull/355#issuecomment-270598125 From freeipa-github-notification at redhat.com Thu Jan 5 09:17:29 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 10:17:29 +0100 Subject: [Freeipa-devel] [freeipa PR#355][closed] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Author: frasertweedale Title: #355: Set up DS TLS on replica in CA-less topology Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/355/head:pr355 git checkout pr355 From freeipa-github-notification at redhat.com Thu Jan 5 09:21:17 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 10:21:17 +0100 Subject: [Freeipa-devel] [freeipa PR#355][comment] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology mbasti-rh commented: """ Please provide PR for ipa-4-4 too """ See the full comment at https://github.com/freeipa/freeipa/pull/355#issuecomment-270598873 From freeipa-github-notification at redhat.com Thu Jan 5 09:22:51 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 10:22:51 +0100 Subject: [Freeipa-devel] [freeipa PR#361][synchronized] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Author: martbab Title: #361: This PR implements a number of improvements for our Travis CI: Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/361/head:pr361 git checkout pr361 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-361.patch Type: text/x-diff Size: 12377 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 09:23:53 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 10:23:53 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: martbab commented: """ @stlaz I have implemented a simple log trimming which keeps only pytest failures if present. The original behavior is kept as a fallback for the case if the setup fails. """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270599385 From sbose at redhat.com Thu Jan 5 09:39:34 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 5 Jan 2017 10:39:34 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> Message-ID: <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > On 18.10.2016 07:34, Jan Cholasta wrote: > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > Jan Cholasta wrote: > > > > Hi, > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > ===== Issuer specific matching ===== > > > > > Although the MIT Kerberos rules allow to select the issuer of a > > > > > certificate there are use cases where a more specific selection is > > > > > needed. E.g. if there are some default matching rules for all issuers > > > > > and some other issuer specific rules where the default rules should > > > > > not apply. To make this possible with the above scheme the default > > > > > rules must have an clause which matches all but the issuer > > > > > with the specific rules. Writing regular-expressions to not match a > > > > > specific string or a list of strings is at least error-prone if not > > > > > impossible. > > > > > > > > > > To make it easier to define issuer specific rules and default rules at > > > > > the same time and optional issuer string can be added to the rule to > > > > > indicate that for the given issuer only those rules should be > > > > > considered. Given the use-case I think it is acceptable to require > > > > > that the full issuer must be specified here in LDAP order (see below) > > > > > and case-sensitive matching is used. > > > > > > > > This could also be solved by adding priority to rules - if two rules > > > > match, the one with higher priority (the issuer specific rule) is > > > > preferred over the one with lower priority (the default rule). IMO this > > > > is better than an optional issuer string as it offers greater > > > > flexibility. > > > > > > The use cases I've seen haven't had to do with priority, though that > > > would be a nice enhancement, but with only allowing certificates issued > > > by a specific CA to be allowed (this is pretty common in web servers). > > > Being able to say "only do the matching on certificates issued by foo" > > > is valuable. > > > > Sure, I'm not suggesting that matching by issuer should be removed, only > > that rule precedence should not be determined by the issuer field setting. > > > > Bump. Sumit, what is your opinion on this? I'm fine with an optional(?) priority as well. Since priorities are already used in the pwpolicies this should be already known to the experienced admin. I guess we just have stick with "A lower value indicates a higher priority" to not confuse users. That's why I think that the priority should be optional here and a missing value indicates the lowest priority (default rules). Are you thinking of using the CoS scheme here as well would a priority attribute be sufficient because we do not want to reference internal objects in the mapping rules? bye, Sumit > > -- > Jan Cholasta From freeipa-github-notification at redhat.com Thu Jan 5 09:45:58 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 05 Jan 2017 10:45:58 +0100 Subject: [Freeipa-devel] [freeipa PR#279][+pushed] installer: Stop adding distro-specific NTP servers into ntp.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/279 Title: #279: installer: Stop adding distro-specific NTP servers into ntp.conf Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 09:45:59 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 05 Jan 2017 10:45:59 +0100 Subject: [Freeipa-devel] [freeipa PR#279][comment] installer: Stop adding distro-specific NTP servers into ntp.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/279 Title: #279: installer: Stop adding distro-specific NTP servers into ntp.conf dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a15fdea615fa4e1153fbbed234113a235135572e """ See the full comment at https://github.com/freeipa/freeipa/pull/279#issuecomment-270603889 From freeipa-github-notification at redhat.com Thu Jan 5 09:46:01 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 05 Jan 2017 10:46:01 +0100 Subject: [Freeipa-devel] [freeipa PR#279][closed] installer: Stop adding distro-specific NTP servers into ntp.conf In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/279 Author: dkupka Title: #279: installer: Stop adding distro-specific NTP servers into ntp.conf Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/279/head:pr279 git checkout pr279 From freeipa-github-notification at redhat.com Thu Jan 5 09:49:42 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 10:49:42 +0100 Subject: [Freeipa-devel] [freeipa PR#371][opened] Set up DS TLS on replica in CA-less topology Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Author: frasertweedale Title: #371: Set up DS TLS on replica in CA-less topology Action: opened PR body: """ Fixes: https://fedorahosted.org/freeipa/ticket/6226 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/371/head:pr371 git checkout pr371 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-371.patch Type: text/x-diff Size: 1049 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 09:24:56 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 10:24:56 +0100 Subject: [Freeipa-devel] [freeipa PR#361][synchronized] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Author: martbab Title: #361: This PR implements a number of improvements for our Travis CI: Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/361/head:pr361 git checkout pr361 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-361.patch Type: text/x-diff Size: 12365 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 09:53:54 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 10:53:54 +0100 Subject: [Freeipa-devel] [freeipa PR#355][comment] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/355 Title: #355: Set up DS TLS on replica in CA-less topology frasertweedale commented: """ ipa-4-4 PR: #371 """ See the full comment at https://github.com/freeipa/freeipa/pull/355#issuecomment-270605522 From freeipa-github-notification at redhat.com Thu Jan 5 09:59:14 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 05 Jan 2017 10:59:14 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ @simo5, I might have fixed the certmonger issue, see HonzaCholasta at 907ef3cff2045edd4625d4c422d1d0ae473fe51c, however I'm hitting the "No valid Negotiate header in server response" error again. Any idea what might be causing it? """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270606660 From freeipa-github-notification at redhat.com Thu Jan 5 10:14:58 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Thu, 05 Jan 2017 11:14:58 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org frasertweedale commented: """ fedora-infra ticket for project name limitations: https://pagure.io/fedora-infrastructure/issue/5661 """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270609873 From freeipa-github-notification at redhat.com Thu Jan 5 10:23:04 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 11:23:04 +0100 Subject: [Freeipa-devel] [freeipa PR#371][edited] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Author: frasertweedale Title: #371: [4.4] Set up DS TLS on replica in CA-less topology Action: edited Changed field: title Original value: """ Set up DS TLS on replica in CA-less topology """ From freeipa-github-notification at redhat.com Thu Jan 5 10:27:45 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 11:27:45 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: stlaz commented: """ The change LGTM, ACK, we'll see how it works :) """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270612407 From freeipa-github-notification at redhat.com Thu Jan 5 10:27:49 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 11:27:49 +0100 Subject: [Freeipa-devel] [freeipa PR#361][+ack] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 11:25:33 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 12:25:33 +0100 Subject: [Freeipa-devel] [freeipa PR#366][synchronized] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-366.patch Type: text/x-diff Size: 7186 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 11:48:09 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 12:48:09 +0100 Subject: [Freeipa-devel] [freeipa PR#372][opened] Restore IPA 3.0 compatibility of copy-schema-to-ca.py Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Author: tiran Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py Action: opened PR body: """ Apparently ipaplatform.paths is not available on IPA 3.x. https://fedorahosted.org/freeipa/ticket/6540 Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/372/head:pr372 git checkout pr372 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-372.patch Type: text/x-diff Size: 2234 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 12:06:44 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 05 Jan 2017 13:06:44 +0100 Subject: [Freeipa-devel] [freeipa PR#371][comment] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Title: #371: [4.4] Set up DS TLS on replica in CA-less topology tomaskrizek commented: """ I re-tested CA-less and CA-full use cases in both domlvl0 and domlvl1. They all seem to work and ldapssl is running. Thanks for fixing the issue! """ See the full comment at https://github.com/freeipa/freeipa/pull/371#issuecomment-270629905 From freeipa-github-notification at redhat.com Thu Jan 5 12:06:47 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 05 Jan 2017 13:06:47 +0100 Subject: [Freeipa-devel] [freeipa PR#371][+ack] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Title: #371: [4.4] Set up DS TLS on replica in CA-less topology Label: +ack From sbose at redhat.com Thu Jan 5 12:15:57 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 5 Jan 2017 13:15:57 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> Message-ID: <20170105121557.GB3710@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote: > On 19.12.2016 12:13, Sumit Bose wrote: > > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: > > > I agree with *almost* everything Sumit said. See my inline comments below. > > > > > > On 16.12.2016 11:53, Sumit Bose wrote: > > > > On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: > > > > > Hi, > > > > > > > > > > I have started a feature description for the Certificate Identity Mapping at > > > > > the following location: > > > > > http://www.freeipa.org/page/V4/Certificate_Identity_Mapping > > > > > > > > > > This is a first step, focusing on the interface we would like to provide. It > > > > > still contains open questions, some of which are linked to the corresponding > > > > > design on SSSD side: > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities > > > > > > > > > > Comments, concerns and suggestions are welcome. Thanks! > > > > > > > > Hi Flo, > > > > > > > > thank you very much for setting up the page. > > > > > > > > My comments are mostly about the commands. > > > > > > > > certmappingconfig-mod: > > > > > > > > * --enable=Boolean: if this option is 'False' SSSD will basically show > > > > the current behavior and just look up the certificates directly. But I > > > > wonder if the option is needed at all because not adding any mapping > > > > rules would have the same effect. > > > > > > > > What is the scope here, only the IPA domain, or all trusted domains as > > > > well? If it is for trusted domains as well will the certmappingrule-* > > > > commands and user-{add/remove}-certmapping return an error? > > > > > > > > So, in general I see an overlap with the mapping rules and I think it > > > > would be clearer to drop this option and do the lookups according to > > > > the mapping rules. > > > > > > > > * --prompt-username=Boolean: the description implies that this option is > > > > synonymous to 1:1 mapping, but it is not. On Linux authentication in > > > > most cases use a user name either by directly asking (e.g. /bin/login) > > > > or using the current user name (e.g. sudo). So, according to its name > > > > it would only control if gdm is allowed to ask for an (optional) user > > > > name. > > > > > > > > If the option is renamed to e.g. --force-1-to-1-mapping to really > > > > enforce a 1:1 mapping then it would make sense to derived to gdm > > > > behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to > > > > ask for a user name and if it is not enforced then it makes sense to > > > > offer and optional user name input field. > > > > > > > > * --enable-username-mismatch=Boolean: I think this option can be > > > > dropped. My test so far show that if a non-matching hint is given on a > > > > Windows client authentication fails. > > > > > > > > * --alternate-attribute=STRING: I think this option isn't needed as > > > > well. For IPA server-side we should decide on an attribute name and > > > > add it to the schema for user objects. On the client side the > > > > attribute name can be taken from the mapping rule.A > > > > > > > > > > > > certmappingrule.*: > > > > > > > > * ISSUERDN: it looks like you want to use issuerName here. In > > > > certificateRecord it it used with LDAP ordering and I would prefer > > > > LDAP ordering at all points where we have a choice. Unfortunately in the > > > > issuer-subject mapping AD dictates X.500 ordering. > > > > > > LDAP ordering should indeed be preferred, as it is used everywhere else in > > > IPA. We can convert to/from X.500 ordering where necessary, when possible. > > > > > > > > > > > * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in > > > > the example? My intention in the SSSD design-page was to specify the > > > > domain (as in DNS domain/IPA domain/trusted domain) where the matching > > > > user should be searched. Different domains might certificates from > > > > different issuers and some domains might not even use certificates. > > > > With this information SSSD does not have to search any domain trusted > > > > by IPA from a given certificate, but look only at domains listed here > > > > (the attribute should be a multi-value one). > > > > > > > > There are objects in the LDAP tree for each trusted domain which are > > > > used by SSSD so using a DN syntax would be valid here. > > > > > > We use domain names rather than DNs to refer to domains everywhere else in > > > the framework. I don't think this place should be an exception. > > > > I'm fine with domain names as well. In fact I didn't thought of using > > DNs for this before I read DOMAINDN on the design page. > > > > > > > > > > > > > * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search > > > > filters should just be a special kind of mapping rules. I can image in > > > > syntax like: . I > > > > think the difficult part with the LDAP filters will to define sensible > > > > templates. > > > > > > I'm not sure I understand. Could you please elaborate a little bit? > > > > A LDAP search filter which would cover the AD behavior would look like: > > > > (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) > > > > where > > > > %A: must be replaced with the issuer of the certificate in X.500 order > > %B: must be replaced with the subject of the certificate in X.500 order > > > > it would be possible of course to use a specific template here which > > would generate the complete search attribute value. > > > > %C: must be replaced by the principal from AD's SAN > > szOID_NT_PRINCIPAL_NAME > > %D: must be replaced with only then name component (the part before the > > realm) of the principal from szOID_NT_PRINCIPAL_NAME > > > > As %C and %D imply this filter will only work for certificates which > > have szOID_NT_PRINCIPAL_NAME but for those it must be used to be > > compatible with AD. For certificates without > > > > (altSecurityIdentities=%A%B) > > > > is sufficient. It is possible to select the right filter with matching > > rules. > > Right. > > > > > So we have to find suitable names for the %A, %B, %C and %D templates > > and also allow different representations (e.g. LDAP or X.500 order for > > DNs). > > I would personally prefer if we used Python-style formatting strings for the > templates, I find them much more pleasant to work with than C-style sure, I used %A etc as arbitrary templates, I didn't wanted to imply that C-style syntax should be used. > formatting strings. The filter which covers AD behavior could be written as: > > > (|(altSecurityIdentities={issuer_dn!x500}{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name})) I think this is quite readable and understandable to an admin with basic knowledge of LDAP search filters and certificate components. Are the names used here (issuer_dn, subject_dn, subject_nt_principal) already used by e.g. some Python modules or do we have to define the list of names? If there a reason for using '!x500' to indicate X500 ordering? Wouldn't e.g. issuer_dn.x500 work as well similar to Python's str.lower()? Having only one symbol to indicate a special formatting of the value from the certificate would make the syntax easier to learn. > > > > > > > > > > But as long as we keep the general mapping rule syntax > > > > flexible the LDAP filter rules can be added in a later version. > > > > > > IMHO it should be the other way round and LDAP filters should be implemented > > > first, as they offer all the flexibility we need (all of the other fields > > > can be easily implemented on top of LDAP filters) and are by default > > > extensible without having to update servers and clients. > > > > In general I agree, as long we can find a suitable scheme to handle the > > templates to add content from the certificate in a specific format to > > the search filters. > > > > But from the user/admin perspective there should be special rules for > > common use-cases which do not require to know too much details about > > certificates and LDAP trees. E.g. for AD (either via direct or indirect > > integration) there should be a rule which just does all which > > AD would do depending on the certificate type. For IPA something like > > might be a good start for handling external > > certificates which do not contain user specific data which can be mapped > > to user object because the syntax is already known from AD. > > This could be handled in the IPA plugin by converting from the user-friendly > representation to LDAP filter template internally when a mapping rule is > added or modified. Yes, but it can also be expanded by the component/library which will replace the templates with the actual values from the certificate. This would have the befit that the user-friendly representation is visible even with low-level LDAP commands? bye, Sumit > > > > > > > > > > > > > > * enable/disable: I think this is a good idea and would be consistent > > > > with other rules like HBAC and sudo > > > > > > > > * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be > > > > better to not add this option and only implement the > > > > 'user-{add/remove}-certmapping' commands > > > > > > > > * user-{add/remove}-certmapping: you say '... almost any type of mapping, > > > > or a more user-friendly API ...'. I would not say 'or' but 'and' and > > > > implement both > > > > > > > > * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I > > > > think both are note needed, see above > > > > > > > > * altSecurityIdentities: I would prefer to use a different name and OID. > > > > Using the same definition as AD would imo imply that it can be used in > > > > the same way as in AD. But e.g. AD also supports other content like > > > > KERBEROS:alternative_user_principal at AD.DOMAIN which we will not > > > > support. > > > > > > > > * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is > > > > general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since > > > > the issuer DN in general will not be a DN from the local LDAP tree I > > > > think the UTF-8 version fits better. > > > > > > I think it's worth mentioning that if the attribute used DN syntax and > > > matching, we wouldn't have to worry about normalizing the issuer name before > > > searching for it, as DS would do that for us. > > > > Good point, but I think the main use case for this attribute is on the > > client side to determine if a rule should be applied to a certificate or > > not. So I guess LDAP searches with this attribute would be rare because > > the client will load all rules in one run. > > > > > > > > > > > > > * nsslapd-certmap-basedn, see DOMAINDN above > > > > > > > > * altSecurityIdentities example: X.500 ordering is used by AD here and > > > > unfortunately I think we have to adopt it at least for this specific > > > > usage, here is an ldapsearch output from AD: > > > > > > > > altSecurityIdentities: > > > > X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC > > > > =ad,CN=Users,CN=t u,E=test.user at email.domain > > > > altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate > > > > AuthorityDC > > > > =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co > > > > m,CN=Sumit Bose Sumit Bose > > > > > > > > * Certificate Mapping Administrators or re-use Certificate > > > > Administrators: I would prefer a new 'Certificate Mapping > > > > Administrators' > > > > > > > > * Users can manage their own X.509 certificate mappings? I'm not sure > > > > here, at the first glance I would say no. How are OTP tokens handled? > > > > Maybe this would be a candidate for certmappingconfig-* option? > > > > > > I think a better question is "How is userCertificate handled?" > > > > > > Anyway, self-service permissions can be enabled/disabled, so there is really > > > no need for a new certmappingconfig option. > > > > Yes, this makes sense. > > > > bye, > > Sumit > > > > > > > > > > > That's all :-) > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta From sbose at redhat.com Thu Jan 5 12:30:08 2017 From: sbose at redhat.com (Sumit Bose) Date: Thu, 5 Jan 2017 13:30:08 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20170105123008.GC3710@p.Speedport_W_724V_Typ_A_05011603_00_011> On Tue, Dec 20, 2016 at 10:10:29AM +0100, Florence Blanc-Renaud wrote: > Hi Sumit and Jan, > > thanks to both of you for providing detailed comments. Please find answers > inline. > > On 12/19/2016 12:13 PM, Sumit Bose wrote: > > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: > > > I agree with *almost* everything Sumit said. See my inline comments below. > > > > > > On 16.12.2016 11:53, Sumit Bose wrote: > > > > On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: > > > > > Hi, > > > > > > > > > > I have started a feature description for the Certificate Identity Mapping at > > > > > the following location: > > > > > http://www.freeipa.org/page/V4/Certificate_Identity_Mapping > > > > > > > > > > This is a first step, focusing on the interface we would like to provide. It > > > > > still contains open questions, some of which are linked to the corresponding > > > > > design on SSSD side: > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities > > > > > > > > > > Comments, concerns and suggestions are welcome. Thanks! > > > > > > > > Hi Flo, > > > > > > > > thank you very much for setting up the page. > > > > > > > > My comments are mostly about the commands. > > > > > > > > certmappingconfig-mod: > > > > > > > > * --enable=Boolean: if this option is 'False' SSSD will basically show > > > > the current behavior and just look up the certificates directly. But I > > > > wonder if the option is needed at all because not adding any mapping > > > > rules would have the same effect. > > > > > > > > What is the scope here, only the IPA domain, or all trusted domains as > > > > well? If it is for trusted domains as well will the certmappingrule-* > > > > commands and user-{add/remove}-certmapping return an error? > > > > > > > > So, in general I see an overlap with the mapping rules and I think it > > > > would be clearer to drop this option and do the lookups according to > > > > the mapping rules. > I saw this option as a convenient way to disable all the rules with a single > command, but I agree it's redundant with the mapping rules and we can live > without it. > > > > > > > > > * --prompt-username=Boolean: the description implies that this option is > > > > synonymous to 1:1 mapping, but it is not. On Linux authentication in > > > > most cases use a user name either by directly asking (e.g. /bin/login) > > > > or using the current user name (e.g. sudo). So, according to its name > > > > it would only control if gdm is allowed to ask for an (optional) user > > > > name. > > > > > > > > If the option is renamed to e.g. --force-1-to-1-mapping to really > > > > enforce a 1:1 mapping then it would make sense to derived to gdm > > > > behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to > > > > ask for a user name and if it is not enforced then it makes sense to > > > > offer and optional user name input field. > > > > > Agree, force-1-to-1-mapping is clearer. Please don't get me wrong, I just wanted to point out that switching on and off the username prompt (or hint) is not the same as forcing a 1:1 mapping. I think it is good to have the --prompt-username option to tell applications which by default might not prompt for a user name when doing Smartcard authentication, like gdm or web apps, to show a user name. This allows to reach a similar behaviour as the 'username hint' GPO in AD. I think we currently do not have a requirement to force a 1:1 mappping. bye, Sumit > > > > > * --enable-username-mismatch=Boolean: I think this option can be > > > > dropped. My test so far show that if a non-matching hint is given on a > > > > Windows client authentication fails. > OK, thanks for the heads-up. > > > > > > > > > * --alternate-attribute=STRING: I think this option isn't needed as > > > > well. For IPA server-side we should decide on an attribute name and > > > > add it to the schema for user objects. On the client side the > > > > attribute name can be taken from the mapping rule.A > OK. > > > > > > > > > > > > > certmappingrule.*: > > > > > > > > * ISSUERDN: it looks like you want to use issuerName here. In > > > > certificateRecord it it used with LDAP ordering and I would prefer > > > > LDAP ordering at all points where we have a choice. Unfortunately in the > > > > issuer-subject mapping AD dictates X.500 ordering. > > > > > > LDAP ordering should indeed be preferred, as it is used everywhere else in > > > IPA. We can convert to/from X.500 ordering where necessary, when possible. > > > > We can use the issuerName attribute with LDAP ordering and convert when > needed, as Jan suggested. > > > > > > > > > * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in > > > > the example? My intention in the SSSD design-page was to specify the > > > > domain (as in DNS domain/IPA domain/trusted domain) where the matching > > > > user should be searched. Different domains might certificates from > > > > different issuers and some domains might not even use certificates. > > > > With this information SSSD does not have to search any domain trusted > > > > by IPA from a given certificate, but look only at domains listed here > > > > (the attribute should be a multi-value one). > > > > > > > > There are objects in the LDAP tree for each trusted domain which are > > > > used by SSSD so using a DN syntax would be valid here. > > > > > > We use domain names rather than DNs to refer to domains everywhere else in > > > the framework. I don't think this place should be an exception. > > > > I'm fine with domain names as well. In fact I didn't thought of using > > DNs for this before I read DOMAINDN on the design page. > > > I don't have any objection against using a domain name rather than a base > DN. > > > > > > > > > > > > * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search > > > > filters should just be a special kind of mapping rules. I can image in > > > > syntax like: . I > > > > think the difficult part with the LDAP filters will to define sensible > > > > templates. > > > > > > I'm not sure I understand. Could you please elaborate a little bit? > > > > A LDAP search filter which would cover the AD behavior would look like: > > > > (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) > > > > where > > > > %A: must be replaced with the issuer of the certificate in X.500 order > > %B: must be replaced with the subject of the certificate in X.500 order > > > > it would be possible of course to use a specific template here which > > would generate the complete search attribute value. > > > > %C: must be replaced by the principal from AD's SAN > > szOID_NT_PRINCIPAL_NAME > > %D: must be replaced with only then name component (the part before the > > realm) of the principal from szOID_NT_PRINCIPAL_NAME > > > > As %C and %D imply this filter will only work for certificates which > > have szOID_NT_PRINCIPAL_NAME but for those it must be used to be > > compatible with AD. For certificates without > > > > (altSecurityIdentities=%A%B) > > > > is sufficient. It is possible to select the right filter with matching > > rules. > > > > So we have to find suitable names for the %A, %B, %C and %D templates > > and also allow different representations (e.g. LDAP or X.500 order for > > DNs). > > > > > > > > > But as long as we keep the general mapping rule syntax > > > > flexible the LDAP filter rules can be added in a later version. > > > > > > IMHO it should be the other way round and LDAP filters should be implemented > > > first, as they offer all the flexibility we need (all of the other fields > > > can be easily implemented on top of LDAP filters) and are by default > > > extensible without having to update servers and clients. > > > > In general I agree, as long we can find a suitable scheme to handle the > > templates to add content from the certificate in a specific format to > > the search filters. > > > > But from the user/admin perspective there should be special rules for > > common use-cases which do not require to know too much details about > > certificates and LDAP trees. E.g. for AD (either via direct or indirect > > integration) there should be a rule which just does all which > > AD would do depending on the certificate type. For IPA something like > > might be a good start for handling external > > certificates which do not contain user specific data which can be mapped > > to user object because the syntax is already known from AD. > > > > > > > > > > > > > * enable/disable: I think this is a good idea and would be consistent > > > > with other rules like HBAC and sudo > > > > > > > > * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be > > > > better to not add this option and only implement the > > > > 'user-{add/remove}-certmapping' commands > Agree, I prefer providing a single method to configure the user mapping. > > > > > > > > > * user-{add/remove}-certmapping: you say '... almost any type of mapping, > > > > or a more user-friendly API ...'. I would not say 'or' but 'and' and > > > > implement both > Agree. > > > > > > > > > * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I > > > > think both are note needed, see above > Agree. > > > > > > > > > * altSecurityIdentities: I would prefer to use a different name and OID. > > > > Using the same definition as AD would imo imply that it can be used in > > > > the same way as in AD. But e.g. AD also supports other content like > > > > KERBEROS:alternative_user_principal at AD.DOMAIN which we will not > > > > support. > Agree. > > > > > > > > > * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is > > > > general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since > > > > the issuer DN in general will not be a DN from the local LDAP tree I > > > > think the UTF-8 version fits better. > > > > > > I think it's worth mentioning that if the attribute used DN syntax and > > > matching, we wouldn't have to worry about normalizing the issuer name before > > > searching for it, as DS would do that for us. > > > I agree with Jan, leveraging DN syntax would definitely be a pro, even if > the issuer DN is outside of the local tree. > If we use UTF-8 instead, would you apply format checks or also accept any > value non-DN conformant? > > > Good point, but I think the main use case for this attribute is on the > > client side to determine if a rule should be applied to a certificate or > > not. So I guess LDAP searches with this attribute would be rare because > > the client will load all rules in one run. > > > > > > > > > > > > > * nsslapd-certmap-basedn, see DOMAINDN above > OK for a domain instead of a DN, we could reuse associatedDomain instead. > > > > > > > > * altSecurityIdentities example: X.500 ordering is used by AD here and > > > > unfortunately I think we have to adopt it at least for this specific > > > > usage, here is an ldapsearch output from AD: > > > > > > > > altSecurityIdentities: > > > > X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC > > > > =ad,CN=Users,CN=t u,E=test.user at email.domain > > > > altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate > > > > AuthorityDC > > > > =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co > > > > m,CN=Sumit Bose Sumit Bose > OK. > > > > > > > > > * Certificate Mapping Administrators or re-use Certificate > > > > Administrators: I would prefer a new 'Certificate Mapping > > > > Administrators' > > > > > > > > * Users can manage their own X.509 certificate mappings? I'm not sure > > > > here, at the first glance I would say no. How are OTP tokens handled? > > > > Maybe this would be a candidate for certmappingconfig-* option? > > > > > > I think a better question is "How is userCertificate handled?" > > > > There is already a self-service permission "Users can manage their own X509 > certificates". Same thing for OTP tokens, users are allowed to add a token > to their own account. > > Flo. > > > Anyway, self-service permissions can be enabled/disabled, so there is really > > > no need for a new certmappingconfig option. > > > > Yes, this makes sense. > > > > bye, > > Sumit > > > > > > > > > > > That's all :-) > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > -- > > > Jan Cholasta > > > From freeipa-github-notification at redhat.com Thu Jan 5 13:05:19 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 14:05:19 +0100 Subject: [Freeipa-devel] [freeipa PR#361][-ack] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: Label: -ack From pvoborni at redhat.com Thu Jan 5 13:08:47 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 5 Jan 2017 14:08:47 +0100 Subject: [Freeipa-devel] FreeIPA, Duo Security integration In-Reply-To: References: Message-ID: On 01/05/2017 09:36 AM, Oucema Bellagha wrote: > Hi, > As of now, we have FreeIPA with OTP working perfectly. Now, I am looking at > possibly integrating Duo security instead of FreeIPA's 2FA. I am concerned > about how it will fit in with FreeIPA... Has anyone else tried this before? If > so, are there any pitfalls or problems you have encountered or any general advise? > > Cheers, Euqanra'l -- > Hello Oucema, Integration with other 2FA system can be handled by RADIUS proxy feature: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/otp.html#migrating-proprietary-otp For practical experience with Duo, better ask on freeipa-users mailing list where admin community dwells. freeipa-devel is primarily used for development discussions. Btw, what is the use case or reasons to integrate with Duo instead of using FreeIPA's 2FA? -- Petr Vobornik From freeipa-github-notification at redhat.com Thu Jan 5 13:22:40 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Thu, 05 Jan 2017 14:22:40 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values gkaihorodova commented: """ will do, but before let me do small changes that was requested by @stlaz in #210, to use str.format() instead of " %r " """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270642709 From freeipa-github-notification at redhat.com Thu Jan 5 13:22:48 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 14:22:48 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py stlaz commented: """ Is there a reason not to stick with the original `ipautil.SHARE_DIR` and without setting `confdir`? This script won't be run on servers that either need `confdir` set or have `ipaplatform.paths`, will it (I know I acked the latter, did not realize there would be trouble)? """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-270642731 From freeipa-github-notification at redhat.com Thu Jan 5 13:37:44 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 14:37:44 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py tiran commented: """ ```SHARE_DIR``` is no longer available. I had to find another approach. The approach ```import else use well-known constants``` is safe and will not break any time soon. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-270645628 From freeipa-github-notification at redhat.com Thu Jan 5 13:49:03 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 14:49:03 +0100 Subject: [Freeipa-devel] [freeipa PR#361][synchronized] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Author: martbab Title: #361: This PR implements a number of improvements for our Travis CI: Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/361/head:pr361 git checkout pr361 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-361.patch Type: text/x-diff Size: 12376 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 14:07:03 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Thu, 05 Jan 2017 15:07:03 +0100 Subject: [Freeipa-devel] [freeipa PR#210][synchronized] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Author: gkaihorodova Title: #210: Tests: Stage User Tracker implementation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/210/head:pr210 git checkout pr210 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-210.patch Type: text/x-diff Size: 4713 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 14:09:50 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 15:09:50 +0100 Subject: [Freeipa-devel] [freeipa PR#371][+pushed] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Title: #371: [4.4] Set up DS TLS on replica in CA-less topology Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 14:09:51 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 15:09:51 +0100 Subject: [Freeipa-devel] [freeipa PR#371][closed] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Author: frasertweedale Title: #371: [4.4] Set up DS TLS on replica in CA-less topology Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/371/head:pr371 git checkout pr371 From freeipa-github-notification at redhat.com Thu Jan 5 14:09:52 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 15:09:52 +0100 Subject: [Freeipa-devel] [freeipa PR#371][comment] [4.4] Set up DS TLS on replica in CA-less topology In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/371 Title: #371: [4.4] Set up DS TLS on replica in CA-less topology mbasti-rh commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/cdb6ffb779b7e1e563494eb3234b2441ba74d692 """ See the full comment at https://github.com/freeipa/freeipa/pull/371#issuecomment-270651977 From freeipa-github-notification at redhat.com Thu Jan 5 14:14:26 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 05 Jan 2017 15:14:26 +0100 Subject: [Freeipa-devel] [freeipa PR#366][+ack] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Title: #366: Use pytest conftest.py Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 14:14:41 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 05 Jan 2017 15:14:41 +0100 Subject: [Freeipa-devel] [freeipa PR#366][comment] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Title: #366: Use pytest conftest.py apophys commented: """ Thank you for squashing the commits. """ See the full comment at https://github.com/freeipa/freeipa/pull/366#issuecomment-270653055 From freeipa-github-notification at redhat.com Thu Jan 5 14:20:37 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Thu, 05 Jan 2017 15:20:37 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ I switched all endpoints to use GSSAPI (and transparently use a session cookie once one transation is successful), so there may be some parts of the code a bit surprised about it, do you have apache logs to chare that show the problem ? (enabling ipa debug would probably help too) """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-270654342 From freeipa-github-notification at redhat.com Thu Jan 5 14:20:42 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 05 Jan 2017 15:20:42 +0100 Subject: [Freeipa-devel] [freeipa PR#369][+ack] Catch ValueError raised by pytest.config.getoption() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/369 Title: #369: Catch ValueError raised by pytest.config.getoption() Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 14:33:09 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 05 Jan 2017 15:33:09 +0100 Subject: [Freeipa-devel] [freeipa PR#373][opened] ipaplatform: Add Debian platform module. Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: opened PR body: """ Hi, this just adds the Debian platform module. There are still other changes needed before vanilla master can be used on Debian or it's derivatives, but they need bigger changes while this is mostly standalone. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16011 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 14:41:48 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 05 Jan 2017 15:41:48 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16210 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 14:43:55 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 15:43:55 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: stlaz commented: """ I have no more remarks on this, hopefully final ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270659749 From freeipa-github-notification at redhat.com Thu Jan 5 14:44:03 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 05 Jan 2017 15:44:03 +0100 Subject: [Freeipa-devel] [freeipa PR#361][+ack] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 14:44:35 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 15:44:35 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA tiran commented: """ ``` ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv23) ctx.options = ssl.OP_ALL | ssl.OP_NO_COMPRESSION | ssl.OP_SINGLE_DH_USE | ssl.OP_SINGLE_ECDH_USE | ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 try: # use Fedora crypto policy # https://fedoraproject.org/wiki/Changes/CryptoPolicy ctx.set_ciphers("PROFILE=SYSTEM") except ssl.SSLError: # high ciphers without RC4, MD5, TripleDES, pre-shared key and secure remote password ctx.set_ciphers("HIGH:!aNULL:!eNULL:!MD5:!RC4:!3DES:!PSK:!SRP") ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270659921 From freeipa-github-notification at redhat.com Thu Jan 5 14:46:56 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Thu, 05 Jan 2017 15:46:56 +0100 Subject: [Freeipa-devel] [freeipa PR#181][synchronized] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 4495 bytes Desc: not available URL: From flo at redhat.com Thu Jan 5 14:50:16 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Thu, 5 Jan 2017 15:50:16 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <20170105123008.GC3710@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> <20170105123008.GC3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <88df000d-dd2f-29fd-19c5-027d9ca66c2c@redhat.com> On 01/05/2017 01:30 PM, Sumit Bose wrote: > On Tue, Dec 20, 2016 at 10:10:29AM +0100, Florence Blanc-Renaud wrote: >> Hi Sumit and Jan, >> >> thanks to both of you for providing detailed comments. Please find answers >> inline. >> >> On 12/19/2016 12:13 PM, Sumit Bose wrote: >>> On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: >>>> I agree with *almost* everything Sumit said. See my inline comments below. >>>> >>>> On 16.12.2016 11:53, Sumit Bose wrote: >>>>> On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: >>>>>> Hi, >>>>>> >>>>>> I have started a feature description for the Certificate Identity Mapping at >>>>>> the following location: >>>>>> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >>>>>> >>>>>> This is a first step, focusing on the interface we would like to provide. It >>>>>> still contains open questions, some of which are linked to the corresponding >>>>>> design on SSSD side: >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >>>>>> >>>>>> Comments, concerns and suggestions are welcome. Thanks! >>>>> >>>>> Hi Flo, >>>>> >>>>> thank you very much for setting up the page. >>>>> >>>>> My comments are mostly about the commands. >>>>> >>>>> certmappingconfig-mod: >>>>> >>>>> * --enable=Boolean: if this option is 'False' SSSD will basically show >>>>> the current behavior and just look up the certificates directly. But I >>>>> wonder if the option is needed at all because not adding any mapping >>>>> rules would have the same effect. >>>>> >>>>> What is the scope here, only the IPA domain, or all trusted domains as >>>>> well? If it is for trusted domains as well will the certmappingrule-* >>>>> commands and user-{add/remove}-certmapping return an error? >>>>> >>>>> So, in general I see an overlap with the mapping rules and I think it >>>>> would be clearer to drop this option and do the lookups according to >>>>> the mapping rules. >> I saw this option as a convenient way to disable all the rules with a single >> command, but I agree it's redundant with the mapping rules and we can live >> without it. >> >>>>> >>>>> * --prompt-username=Boolean: the description implies that this option is >>>>> synonymous to 1:1 mapping, but it is not. On Linux authentication in >>>>> most cases use a user name either by directly asking (e.g. /bin/login) >>>>> or using the current user name (e.g. sudo). So, according to its name >>>>> it would only control if gdm is allowed to ask for an (optional) user >>>>> name. >>>>> >>>>> If the option is renamed to e.g. --force-1-to-1-mapping to really >>>>> enforce a 1:1 mapping then it would make sense to derived to gdm >>>>> behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to >>>>> ask for a user name and if it is not enforced then it makes sense to >>>>> offer and optional user name input field. >>>>> >> Agree, force-1-to-1-mapping is clearer. > > Please don't get me wrong, I just wanted to point out that switching on > and off the username prompt (or hint) is not the same as forcing a 1:1 > mapping. > > I think it is good to have the --prompt-username option to tell > applications which by default might not prompt for a user name when > doing Smartcard authentication, like gdm or web apps, to show a user > name. This allows to reach a similar behaviour as the 'username hint' > GPO in AD. > > I think we currently do not have a requirement to force a 1:1 mappping. > Hi Summit, glad you clarified your point because I clearly got it wrong :) I will keep --prompt-username and I agree that there is no need for force-1-to-1-mapping. Flo > bye, > Sumit > >> >>>>> * --enable-username-mismatch=Boolean: I think this option can be >>>>> dropped. My test so far show that if a non-matching hint is given on a >>>>> Windows client authentication fails. >> OK, thanks for the heads-up. >> >>>>> >>>>> * --alternate-attribute=STRING: I think this option isn't needed as >>>>> well. For IPA server-side we should decide on an attribute name and >>>>> add it to the schema for user objects. On the client side the >>>>> attribute name can be taken from the mapping rule.A >> OK. >> >>>>> >>>>> >>>>> certmappingrule.*: >>>>> >>>>> * ISSUERDN: it looks like you want to use issuerName here. In >>>>> certificateRecord it it used with LDAP ordering and I would prefer >>>>> LDAP ordering at all points where we have a choice. Unfortunately in the >>>>> issuer-subject mapping AD dictates X.500 ordering. >>>> >>>> LDAP ordering should indeed be preferred, as it is used everywhere else in >>>> IPA. We can convert to/from X.500 ordering where necessary, when possible. >>>> >> We can use the issuerName attribute with LDAP ordering and convert when >> needed, as Jan suggested. >> >>>>> >>>>> * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in >>>>> the example? My intention in the SSSD design-page was to specify the >>>>> domain (as in DNS domain/IPA domain/trusted domain) where the matching >>>>> user should be searched. Different domains might certificates from >>>>> different issuers and some domains might not even use certificates. >>>>> With this information SSSD does not have to search any domain trusted >>>>> by IPA from a given certificate, but look only at domains listed here >>>>> (the attribute should be a multi-value one). >>>>> >>>>> There are objects in the LDAP tree for each trusted domain which are >>>>> used by SSSD so using a DN syntax would be valid here. >>>> >>>> We use domain names rather than DNs to refer to domains everywhere else in >>>> the framework. I don't think this place should be an exception. >>> >>> I'm fine with domain names as well. In fact I didn't thought of using >>> DNs for this before I read DOMAINDN on the design page. >>> >> I don't have any objection against using a domain name rather than a base >> DN. >> >>>> >>>>> >>>>> * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search >>>>> filters should just be a special kind of mapping rules. I can image in >>>>> syntax like: . I >>>>> think the difficult part with the LDAP filters will to define sensible >>>>> templates. >>>> >>>> I'm not sure I understand. Could you please elaborate a little bit? >>> >>> A LDAP search filter which would cover the AD behavior would look like: >>> >>> (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) >>> >>> where >>> >>> %A: must be replaced with the issuer of the certificate in X.500 order >>> %B: must be replaced with the subject of the certificate in X.500 order >>> >>> it would be possible of course to use a specific template here which >>> would generate the complete search attribute value. >>> >>> %C: must be replaced by the principal from AD's SAN >>> szOID_NT_PRINCIPAL_NAME >>> %D: must be replaced with only then name component (the part before the >>> realm) of the principal from szOID_NT_PRINCIPAL_NAME >>> >>> As %C and %D imply this filter will only work for certificates which >>> have szOID_NT_PRINCIPAL_NAME but for those it must be used to be >>> compatible with AD. For certificates without >>> >>> (altSecurityIdentities=%A%B) >>> >>> is sufficient. It is possible to select the right filter with matching >>> rules. >>> >>> So we have to find suitable names for the %A, %B, %C and %D templates >>> and also allow different representations (e.g. LDAP or X.500 order for >>> DNs). >>> >>>> >>>>> But as long as we keep the general mapping rule syntax >>>>> flexible the LDAP filter rules can be added in a later version. >>>> >>>> IMHO it should be the other way round and LDAP filters should be implemented >>>> first, as they offer all the flexibility we need (all of the other fields >>>> can be easily implemented on top of LDAP filters) and are by default >>>> extensible without having to update servers and clients. >>> >>> In general I agree, as long we can find a suitable scheme to handle the >>> templates to add content from the certificate in a specific format to >>> the search filters. >>> >>> But from the user/admin perspective there should be special rules for >>> common use-cases which do not require to know too much details about >>> certificates and LDAP trees. E.g. for AD (either via direct or indirect >>> integration) there should be a rule which just does all which >>> AD would do depending on the certificate type. For IPA something like >>> might be a good start for handling external >>> certificates which do not contain user specific data which can be mapped >>> to user object because the syntax is already known from AD. >>> >>>> >>>>> >>>>> * enable/disable: I think this is a good idea and would be consistent >>>>> with other rules like HBAC and sudo >>>>> >>>>> * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be >>>>> better to not add this option and only implement the >>>>> 'user-{add/remove}-certmapping' commands >> Agree, I prefer providing a single method to configure the user mapping. >> >>>>> >>>>> * user-{add/remove}-certmapping: you say '... almost any type of mapping, >>>>> or a more user-friendly API ...'. I would not say 'or' but 'and' and >>>>> implement both >> Agree. >> >>>>> >>>>> * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I >>>>> think both are note needed, see above >> Agree. >> >>>>> >>>>> * altSecurityIdentities: I would prefer to use a different name and OID. >>>>> Using the same definition as AD would imo imply that it can be used in >>>>> the same way as in AD. But e.g. AD also supports other content like >>>>> KERBEROS:alternative_user_principal at AD.DOMAIN which we will not >>>>> support. >> Agree. >> >>>>> >>>>> * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is >>>>> general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since >>>>> the issuer DN in general will not be a DN from the local LDAP tree I >>>>> think the UTF-8 version fits better. >>>> >>>> I think it's worth mentioning that if the attribute used DN syntax and >>>> matching, we wouldn't have to worry about normalizing the issuer name before >>>> searching for it, as DS would do that for us. >>> >> I agree with Jan, leveraging DN syntax would definitely be a pro, even if >> the issuer DN is outside of the local tree. >> If we use UTF-8 instead, would you apply format checks or also accept any >> value non-DN conformant? >> >>> Good point, but I think the main use case for this attribute is on the >>> client side to determine if a rule should be applied to a certificate or >>> not. So I guess LDAP searches with this attribute would be rare because >>> the client will load all rules in one run. >>> >>>> >>>>> >>>>> * nsslapd-certmap-basedn, see DOMAINDN above >> OK for a domain instead of a DN, we could reuse associatedDomain instead. >>>>> >>>>> * altSecurityIdentities example: X.500 ordering is used by AD here and >>>>> unfortunately I think we have to adopt it at least for this specific >>>>> usage, here is an ldapsearch output from AD: >>>>> >>>>> altSecurityIdentities: >>>>> X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC >>>>> =ad,CN=Users,CN=t u,E=test.user at email.domain >>>>> altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate >>>>> AuthorityDC >>>>> =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co >>>>> m,CN=Sumit Bose Sumit Bose >> OK. >> >>>>> >>>>> * Certificate Mapping Administrators or re-use Certificate >>>>> Administrators: I would prefer a new 'Certificate Mapping >>>>> Administrators' >>>>> >>>>> * Users can manage their own X.509 certificate mappings? I'm not sure >>>>> here, at the first glance I would say no. How are OTP tokens handled? >>>>> Maybe this would be a candidate for certmappingconfig-* option? >>>> >>>> I think a better question is "How is userCertificate handled?" >>>> >> There is already a self-service permission "Users can manage their own X509 >> certificates". Same thing for OTP tokens, users are allowed to add a token >> to their own account. >> >> Flo. >>>> Anyway, self-service permissions can be enabled/disabled, so there is really >>>> no need for a new certmappingconfig option. >>> >>> Yes, this makes sense. >>> >>> bye, >>> Sumit >>>> >>>>> >>>>> That's all :-) >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>> >>>> >>>> -- >>>> Jan Cholasta >>> >> From freeipa-github-notification at redhat.com Thu Jan 5 15:22:17 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 16:22:17 +0100 Subject: [Freeipa-devel] [freeipa PR#361][+pushed] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 15:22:18 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 16:22:18 +0100 Subject: [Freeipa-devel] [freeipa PR#361][closed] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Author: martbab Title: #361: This PR implements a number of improvements for our Travis CI: Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/361/head:pr361 git checkout pr361 From freeipa-github-notification at redhat.com Thu Jan 5 15:22:19 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Thu, 05 Jan 2017 16:22:19 +0100 Subject: [Freeipa-devel] [freeipa PR#361][comment] This PR implements a number of improvements for our Travis CI: In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/361 Title: #361: This PR implements a number of improvements for our Travis CI: martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d86cae7748a8a629c942f1eafc0a0267f2c9611e https://fedorahosted.org/freeipa/changeset/758731088eee0294af59812dbd1976db89b9dda0 https://fedorahosted.org/freeipa/changeset/aff4e684e1f13d7da4248d17c0b8b2adf2e37033 https://fedorahosted.org/freeipa/changeset/1267e3e72305ee6bda0dd348ae1737b6f68f4371 https://fedorahosted.org/freeipa/changeset/149d86de14b00b73f625fefe73c2322a2fffac06 https://fedorahosted.org/freeipa/changeset/b8423492f5dce32183b34d718e4619fe3ca8bfef https://fedorahosted.org/freeipa/changeset/b6216756f6c7a950e9bf2afe56a582dd8195c513 https://fedorahosted.org/freeipa/changeset/f48d6fc168253209bed3f1dd5a543f15d1f54669 https://fedorahosted.org/freeipa/changeset/4abd3f554a436e6446ba59c75c09fb0ff8b7fe4a https://fedorahosted.org/freeipa/changeset/0ef55a91ef9c591cee3a7e1ff0e391cdc32423c3 """ See the full comment at https://github.com/freeipa/freeipa/pull/361#issuecomment-270669456 From freeipa-github-notification at redhat.com Thu Jan 5 16:10:52 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 05 Jan 2017 17:10:52 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16361 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 16:35:52 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:35:52 +0100 Subject: [Freeipa-devel] [freeipa PR#369][comment] Catch ValueError raised by pytest.config.getoption() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/369 Title: #369: Catch ValueError raised by pytest.config.getoption() mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/3387734e6c6d47a756b5e914e7e515d2610a424f """ See the full comment at https://github.com/freeipa/freeipa/pull/369#issuecomment-270690329 From freeipa-github-notification at redhat.com Thu Jan 5 16:35:53 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:35:53 +0100 Subject: [Freeipa-devel] [freeipa PR#369][+pushed] Catch ValueError raised by pytest.config.getoption() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/369 Title: #369: Catch ValueError raised by pytest.config.getoption() Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 16:35:54 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:35:54 +0100 Subject: [Freeipa-devel] [freeipa PR#369][closed] Catch ValueError raised by pytest.config.getoption() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/369 Author: tiran Title: #369: Catch ValueError raised by pytest.config.getoption() Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/369/head:pr369 git checkout pr369 From freeipa-github-notification at redhat.com Thu Jan 5 16:37:30 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:37:30 +0100 Subject: [Freeipa-devel] [freeipa PR#366][comment] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Title: #366: Use pytest conftest.py mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/1e06a5195bafe0224d77371987f2509f5508ca2f """ See the full comment at https://github.com/freeipa/freeipa/pull/366#issuecomment-270690800 From freeipa-github-notification at redhat.com Thu Jan 5 16:37:32 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:37:32 +0100 Subject: [Freeipa-devel] [freeipa PR#366][+pushed] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Title: #366: Use pytest conftest.py Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 16:37:34 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:37:34 +0100 Subject: [Freeipa-devel] [freeipa PR#366][closed] Use pytest conftest.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/366 Author: tiran Title: #366: Use pytest conftest.py Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/366/head:pr366 git checkout pr366 From freeipa-github-notification at redhat.com Thu Jan 5 16:41:16 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:41:16 +0100 Subject: [Freeipa-devel] [freeipa PR#348][+pushed] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 16:41:18 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:41:18 +0100 Subject: [Freeipa-devel] [freeipa PR#348][comment] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Title: #348: ca: fix ca-find with --pkey-only mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/ceb26f5ac428cdbed8ec1fa89e9ed6f1d903a5a0 """ See the full comment at https://github.com/freeipa/freeipa/pull/348#issuecomment-270691803 From freeipa-github-notification at redhat.com Thu Jan 5 16:41:19 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:41:19 +0100 Subject: [Freeipa-devel] [freeipa PR#348][closed] ca: fix ca-find with --pkey-only In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/348 Author: HonzaCholasta Title: #348: ca: fix ca-find with --pkey-only Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/348/head:pr348 git checkout pr348 From freeipa-github-notification at redhat.com Thu Jan 5 16:43:21 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:43:21 +0100 Subject: [Freeipa-devel] [freeipa PR#181][-ack] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values Label: -ack From freeipa-github-notification at redhat.com Thu Jan 5 16:44:02 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:44:02 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values mbasti-rh commented: """ Then, @stlaz must give final ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270692529 From freeipa-github-notification at redhat.com Thu Jan 5 16:49:56 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:49:56 +0100 Subject: [Freeipa-devel] [freeipa PR#294][+ack] client, platform: Use paths.SSH* instead of get_config_dir(). In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/294 Title: #294: client, platform: Use paths.SSH* instead of get_config_dir(). Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 16:50:22 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:50:22 +0100 Subject: [Freeipa-devel] [freeipa PR#294][+pushed] client, platform: Use paths.SSH* instead of get_config_dir(). In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/294 Title: #294: client, platform: Use paths.SSH* instead of get_config_dir(). Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 16:50:23 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:50:23 +0100 Subject: [Freeipa-devel] [freeipa PR#294][comment] client, platform: Use paths.SSH* instead of get_config_dir(). In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/294 Title: #294: client, platform: Use paths.SSH* instead of get_config_dir(). mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/0ff12de338a8db32bb10e1b41f32255e7b971b6f """ See the full comment at https://github.com/freeipa/freeipa/pull/294#issuecomment-270694164 From freeipa-github-notification at redhat.com Thu Jan 5 16:50:25 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 17:50:25 +0100 Subject: [Freeipa-devel] [freeipa PR#294][closed] client, platform: Use paths.SSH* instead of get_config_dir(). In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/294 Author: tjaalton Title: #294: client, platform: Use paths.SSH* instead of get_config_dir(). Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/294/head:pr294 git checkout pr294 From freeipa-github-notification at redhat.com Thu Jan 5 17:01:28 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:01:28 +0100 Subject: [Freeipa-devel] [freeipa PR#351][comment] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Title: #351: [fedora-26] named.conf template: update API for bind 9.11 mbasti-rh commented: """ How do you solve upgrades F25->F26? """ See the full comment at https://github.com/freeipa/freeipa/pull/351#issuecomment-270697172 From freeipa-github-notification at redhat.com Thu Jan 5 17:05:23 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 05 Jan 2017 18:05:23 +0100 Subject: [Freeipa-devel] [freeipa PR#351][comment] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Title: #351: [fedora-26] named.conf template: update API for bind 9.11 tomaskrizek commented: """ This fix only applies to new IPA installations. Upgrade of `named.conf` will be handled separately by bind-dyndb-ldap. When a new version will be installed, a postinstall scriptet will run a script to transform `named.conf` to the new format. """ See the full comment at https://github.com/freeipa/freeipa/pull/351#issuecomment-270698221 From freeipa-github-notification at redhat.com Thu Jan 5 17:23:29 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:23:29 +0100 Subject: [Freeipa-devel] [freeipa PR#340][+ack] schema_cache: Make handling of string compatible with python3 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/340 Title: #340: schema_cache: Make handling of string compatible with python3 Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 17:29:00 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:29:00 +0100 Subject: [Freeipa-devel] [freeipa PR#317][+ack] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Title: #317: Unify password generation across FreeIPA Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 17:30:32 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:30:32 +0100 Subject: [Freeipa-devel] [freeipa PR#340][+pushed] schema_cache: Make handling of string compatible with python3 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/340 Title: #340: schema_cache: Make handling of string compatible with python3 Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 17:30:33 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:30:33 +0100 Subject: [Freeipa-devel] [freeipa PR#340][closed] schema_cache: Make handling of string compatible with python3 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/340 Author: dkupka Title: #340: schema_cache: Make handling of string compatible with python3 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/340/head:pr340 git checkout pr340 From freeipa-github-notification at redhat.com Thu Jan 5 17:30:35 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:30:35 +0100 Subject: [Freeipa-devel] [freeipa PR#340][comment] schema_cache: Make handling of string compatible with python3 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/340 Title: #340: schema_cache: Make handling of string compatible with python3 mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/388ed93935de56adbf1db976e9df276327c9a1e4 """ See the full comment at https://github.com/freeipa/freeipa/pull/340#issuecomment-270704477 From freeipa-github-notification at redhat.com Thu Jan 5 17:32:42 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 18:32:42 +0100 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap pvoborni commented: """ works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-270705015 From freeipa-github-notification at redhat.com Thu Jan 5 17:32:44 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 18:32:44 +0100 Subject: [Freeipa-devel] [freeipa PR#158][+ack] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 17:33:12 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 18:33:12 +0100 Subject: [Freeipa-devel] [freeipa PR#317][comment] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Title: #317: Unify password generation across FreeIPA mbasti-rh commented: """ PR needs rebase """ See the full comment at https://github.com/freeipa/freeipa/pull/317#issuecomment-270705142 From freeipa-github-notification at redhat.com Thu Jan 5 17:34:19 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 18:34:19 +0100 Subject: [Freeipa-devel] [freeipa PR#158][comment] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap pvoborni commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/18425dbbe7b7c311cf947074d505225b235df769 """ See the full comment at https://github.com/freeipa/freeipa/pull/158#issuecomment-270705433 From freeipa-github-notification at redhat.com Thu Jan 5 17:34:21 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 18:34:21 +0100 Subject: [Freeipa-devel] [freeipa PR#158][+pushed] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Title: #158: WebUI: update Patternfly and Bootstrap Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 17:34:22 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 18:34:22 +0100 Subject: [Freeipa-devel] [freeipa PR#158][closed] WebUI: update Patternfly and Bootstrap In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/158 Author: pvomacka Title: #158: WebUI: update Patternfly and Bootstrap Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/158/head:pr158 git checkout pr158 From freeipa-github-notification at redhat.com Thu Jan 5 18:10:03 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 19:10:03 +0100 Subject: [Freeipa-devel] [freeipa PR#327][comment] WebUI: RPC refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/327 Title: #327: WebUI: RPC refactoring pvoborni commented: """ works for me, the travis failure is invalid? - web ui is not related to the tests and pylint passes """ See the full comment at https://github.com/freeipa/freeipa/pull/327#issuecomment-270714291 From freeipa-github-notification at redhat.com Thu Jan 5 18:10:06 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 19:10:06 +0100 Subject: [Freeipa-devel] [freeipa PR#327][+ack] WebUI: RPC refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/327 Title: #327: WebUI: RPC refactoring Label: +ack From freeipa-github-notification at redhat.com Thu Jan 5 18:14:08 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 19:14:08 +0100 Subject: [Freeipa-devel] [freeipa PR#327][+pushed] WebUI: RPC refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/327 Title: #327: WebUI: RPC refactoring Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 5 18:14:09 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 19:14:09 +0100 Subject: [Freeipa-devel] [freeipa PR#327][comment] WebUI: RPC refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/327 Title: #327: WebUI: RPC refactoring pvoborni commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5a950aeb29963ed22a2c3c1b80723589ac4097de https://fedorahosted.org/freeipa/changeset/be7865bf4f9b6774a17f31380e96b76d0473f982 """ See the full comment at https://github.com/freeipa/freeipa/pull/327#issuecomment-270715304 From freeipa-github-notification at redhat.com Thu Jan 5 18:14:10 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Thu, 05 Jan 2017 19:14:10 +0100 Subject: [Freeipa-devel] [freeipa PR#327][closed] WebUI: RPC refactoring In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/327 Author: pvomacka Title: #327: WebUI: RPC refactoring Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/327/head:pr327 git checkout pr327 From freeipa-github-notification at redhat.com Thu Jan 5 18:31:47 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 19:31:47 +0100 Subject: [Freeipa-devel] [freeipa PR#374][opened] pytest: set rules to find test files and functions Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Author: tiran Title: #374: pytest: set rules to find test files and functions Action: opened PR body: """ 1e06a5195bafe0224d77371987f2509f5508ca2f removed pytest.ini. Without the ini file, pytest 3.x has suboptimal settings and no longer picks up all test functions and test files. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/374/head:pr374 git checkout pr374 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-374.patch Type: text/x-diff Size: 1628 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 18:52:43 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 05 Jan 2017 19:52:43 +0100 Subject: [Freeipa-devel] [freeipa PR#375][opened] Fix used before assignment bug in host_port_open() Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Author: tiran Title: #375: Fix used before assignment bug in host_port_open() Action: opened PR body: """ Detected by most recent pylint under Python 3.5. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/375/head:pr375 git checkout pr375 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-375.patch Type: text/x-diff Size: 1193 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 5 19:04:40 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 05 Jan 2017 20:04:40 +0100 Subject: [Freeipa-devel] [freeipa PR#375][comment] Fix used before assignment bug in host_port_open() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Title: #375: Fix used before assignment bug in host_port_open() mbasti-rh commented: """ Instant ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/375#issuecomment-270728710 From freeipa-github-notification at redhat.com Fri Jan 6 00:42:26 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 06 Jan 2017 01:42:26 +0100 Subject: [Freeipa-devel] [freeipa PR#370][synchronized] [EXPERIMENT] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: [EXPERIMENT] ci: send build log to paste.fedoraproject.org Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/370/head:pr370 git checkout pr370 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-370.patch Type: text/x-diff Size: 1762 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 00:42:58 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 06 Jan 2017 01:42:58 +0100 Subject: [Freeipa-devel] [freeipa PR#370][edited] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: ci: send build log to paste.fedoraproject.org Action: edited Changed field: title Original value: """ [EXPERIMENT] ci: send build log to paste.fedoraproject.org """ From freeipa-github-notification at redhat.com Fri Jan 6 00:44:21 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 06 Jan 2017 01:44:21 +0100 Subject: [Freeipa-devel] [freeipa PR#370][edited] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Author: frasertweedale Title: #370: ci: send build log to paste.fedoraproject.org Action: edited Changed field: body Original value: """ This commit is just to see if we can ship our build logs off travis to a pastebin. If we can, we can refine the approach to only ship logs when the build broke, provide better output about where to find them, etc. """ From freeipa-github-notification at redhat.com Fri Jan 6 00:51:43 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Fri, 06 Jan 2017 01:51:43 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: ci: send build log to paste.fedoraproject.org frasertweedale commented: """ Note: a new fedora pastebin is forthcoming. Staging instance: https://modernpaste.stg.fedoraproject.org/ """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-270801791 From freeipa-github-notification at redhat.com Fri Jan 6 07:11:28 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 08:11:28 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values stlaz commented: """ Seems fine + Travis is satisfied as well, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270845790 From freeipa-github-notification at redhat.com Fri Jan 6 07:21:17 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 08:21:17 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values stlaz commented: """ Seems fine + Travis is satisfied as well, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270845790 From freeipa-github-notification at redhat.com Fri Jan 6 07:27:05 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 08:27:05 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values stlaz commented: """ The changes introduce different behavior than in the previous change where repr() of the given strings would have been printed. To have repr() of the given string, use '{!r}' instead of '{}' in string format if that is what's desired. CondACK if it's not but please tell :) Same for https://github.com/freeipa/freeipa/pull/210 """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270847597 From jcholast at redhat.com Fri Jan 6 07:40:31 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 6 Jan 2017 08:40:31 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <20170105121557.GB3710@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> <20170105121557.GB3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <4301cd9d-7ddc-ff82-28f6-01aa3131db57@redhat.com> On 5.1.2017 13:15, Sumit Bose wrote: > On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote: >> On 19.12.2016 12:13, Sumit Bose wrote: >>> On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: >>>> I agree with *almost* everything Sumit said. See my inline comments below. >>>> >>>> On 16.12.2016 11:53, Sumit Bose wrote: >>>>> On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: >>>>>> Hi, >>>>>> >>>>>> I have started a feature description for the Certificate Identity Mapping at >>>>>> the following location: >>>>>> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >>>>>> >>>>>> This is a first step, focusing on the interface we would like to provide. It >>>>>> still contains open questions, some of which are linked to the corresponding >>>>>> design on SSSD side: >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >>>>>> >>>>>> Comments, concerns and suggestions are welcome. Thanks! >>>>> >>>>> Hi Flo, >>>>> >>>>> thank you very much for setting up the page. >>>>> >>>>> My comments are mostly about the commands. >>>>> >>>>> certmappingconfig-mod: >>>>> >>>>> * --enable=Boolean: if this option is 'False' SSSD will basically show >>>>> the current behavior and just look up the certificates directly. But I >>>>> wonder if the option is needed at all because not adding any mapping >>>>> rules would have the same effect. >>>>> >>>>> What is the scope here, only the IPA domain, or all trusted domains as >>>>> well? If it is for trusted domains as well will the certmappingrule-* >>>>> commands and user-{add/remove}-certmapping return an error? >>>>> >>>>> So, in general I see an overlap with the mapping rules and I think it >>>>> would be clearer to drop this option and do the lookups according to >>>>> the mapping rules. >>>>> >>>>> * --prompt-username=Boolean: the description implies that this option is >>>>> synonymous to 1:1 mapping, but it is not. On Linux authentication in >>>>> most cases use a user name either by directly asking (e.g. /bin/login) >>>>> or using the current user name (e.g. sudo). So, according to its name >>>>> it would only control if gdm is allowed to ask for an (optional) user >>>>> name. >>>>> >>>>> If the option is renamed to e.g. --force-1-to-1-mapping to really >>>>> enforce a 1:1 mapping then it would make sense to derived to gdm >>>>> behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to >>>>> ask for a user name and if it is not enforced then it makes sense to >>>>> offer and optional user name input field. >>>>> >>>>> * --enable-username-mismatch=Boolean: I think this option can be >>>>> dropped. My test so far show that if a non-matching hint is given on a >>>>> Windows client authentication fails. >>>>> >>>>> * --alternate-attribute=STRING: I think this option isn't needed as >>>>> well. For IPA server-side we should decide on an attribute name and >>>>> add it to the schema for user objects. On the client side the >>>>> attribute name can be taken from the mapping rule.A >>>>> >>>>> >>>>> certmappingrule.*: >>>>> >>>>> * ISSUERDN: it looks like you want to use issuerName here. In >>>>> certificateRecord it it used with LDAP ordering and I would prefer >>>>> LDAP ordering at all points where we have a choice. Unfortunately in the >>>>> issuer-subject mapping AD dictates X.500 ordering. >>>> >>>> LDAP ordering should indeed be preferred, as it is used everywhere else in >>>> IPA. We can convert to/from X.500 ordering where necessary, when possible. >>>> >>>>> >>>>> * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in >>>>> the example? My intention in the SSSD design-page was to specify the >>>>> domain (as in DNS domain/IPA domain/trusted domain) where the matching >>>>> user should be searched. Different domains might certificates from >>>>> different issuers and some domains might not even use certificates. >>>>> With this information SSSD does not have to search any domain trusted >>>>> by IPA from a given certificate, but look only at domains listed here >>>>> (the attribute should be a multi-value one). >>>>> >>>>> There are objects in the LDAP tree for each trusted domain which are >>>>> used by SSSD so using a DN syntax would be valid here. >>>> >>>> We use domain names rather than DNs to refer to domains everywhere else in >>>> the framework. I don't think this place should be an exception. >>> >>> I'm fine with domain names as well. In fact I didn't thought of using >>> DNs for this before I read DOMAINDN on the design page. >>> >>>> >>>>> >>>>> * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search >>>>> filters should just be a special kind of mapping rules. I can image in >>>>> syntax like: . I >>>>> think the difficult part with the LDAP filters will to define sensible >>>>> templates. >>>> >>>> I'm not sure I understand. Could you please elaborate a little bit? >>> >>> A LDAP search filter which would cover the AD behavior would look like: >>> >>> (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) >>> >>> where >>> >>> %A: must be replaced with the issuer of the certificate in X.500 order >>> %B: must be replaced with the subject of the certificate in X.500 order >>> >>> it would be possible of course to use a specific template here which >>> would generate the complete search attribute value. >>> >>> %C: must be replaced by the principal from AD's SAN >>> szOID_NT_PRINCIPAL_NAME >>> %D: must be replaced with only then name component (the part before the >>> realm) of the principal from szOID_NT_PRINCIPAL_NAME >>> >>> As %C and %D imply this filter will only work for certificates which >>> have szOID_NT_PRINCIPAL_NAME but for those it must be used to be >>> compatible with AD. For certificates without >>> >>> (altSecurityIdentities=%A%B) >>> >>> is sufficient. It is possible to select the right filter with matching >>> rules. >> >> Right. >> >>> >>> So we have to find suitable names for the %A, %B, %C and %D templates >>> and also allow different representations (e.g. LDAP or X.500 order for >>> DNs). >> >> I would personally prefer if we used Python-style formatting strings for the >> templates, I find them much more pleasant to work with than C-style > > sure, I used %A etc as arbitrary templates, I didn't wanted to imply > that C-style syntax should be used. > >> formatting strings. The filter which covers AD behavior could be written as: >> >> >> (|(altSecurityIdentities={issuer_dn!x500}{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name})) > > I think this is quite readable and understandable to an admin with basic > knowledge of LDAP search filters and certificate components. Are the > names used here (issuer_dn, subject_dn, subject_nt_principal) already > used by e.g. some Python modules or do we have to define the list of > names? They are not defined anywhere, it's just something I came up with. > > If there a reason for using '!x500' to indicate X500 ordering? Wouldn't > e.g. issuer_dn.x500 work as well similar to Python's str.lower()? Having > only one symbol to indicate a special formatting of the value from the > certificate would make the syntax easier to learn. I tried to follow the Python convention, where '.' is used for attribute access and '!' for value conversion. In other words, '.' selects a component of the value and '!' takes the whole value and formats it in a certain way. > >> >>> >>>> >>>>> But as long as we keep the general mapping rule syntax >>>>> flexible the LDAP filter rules can be added in a later version. >>>> >>>> IMHO it should be the other way round and LDAP filters should be implemented >>>> first, as they offer all the flexibility we need (all of the other fields >>>> can be easily implemented on top of LDAP filters) and are by default >>>> extensible without having to update servers and clients. >>> >>> In general I agree, as long we can find a suitable scheme to handle the >>> templates to add content from the certificate in a specific format to >>> the search filters. >>> >>> But from the user/admin perspective there should be special rules for >>> common use-cases which do not require to know too much details about >>> certificates and LDAP trees. E.g. for AD (either via direct or indirect >>> integration) there should be a rule which just does all which >>> AD would do depending on the certificate type. For IPA something like >>> might be a good start for handling external >>> certificates which do not contain user specific data which can be mapped >>> to user object because the syntax is already known from AD. >> >> This could be handled in the IPA plugin by converting from the user-friendly >> representation to LDAP filter template internally when a mapping rule is >> added or modified. > > Yes, but it can also be expanded by the component/library which will > replace the templates with the actual values from the certificate. This > would have the befit that the user-friendly representation is visible > even with low-level LDAP commands? That's true (although I can't imagine why would anyone look on the LDAP entries directly, especially if they didn't understand LDAP filters), but IMHO it lacks certain elegancy by having more than one way to define the same rule, more code paths to handle the rules, etc. Additionally, LDAP filters provide better forward compatiblity - if we had to add support for a new mapping style in the future, with LDAP filters only the IPA server would have to be updated, without LDAP filters we would also have to worry about updating old clients which do not understand the new mapping style. > > bye, > Sumit > >> >>> >>>> >>>>> >>>>> * enable/disable: I think this is a good idea and would be consistent >>>>> with other rules like HBAC and sudo >>>>> >>>>> * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be >>>>> better to not add this option and only implement the >>>>> 'user-{add/remove}-certmapping' commands >>>>> >>>>> * user-{add/remove}-certmapping: you say '... almost any type of mapping, >>>>> or a more user-friendly API ...'. I would not say 'or' but 'and' and >>>>> implement both >>>>> >>>>> * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I >>>>> think both are note needed, see above >>>>> >>>>> * altSecurityIdentities: I would prefer to use a different name and OID. >>>>> Using the same definition as AD would imo imply that it can be used in >>>>> the same way as in AD. But e.g. AD also supports other content like >>>>> KERBEROS:alternative_user_principal at AD.DOMAIN which we will not >>>>> support. >>>>> >>>>> * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is >>>>> general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since >>>>> the issuer DN in general will not be a DN from the local LDAP tree I >>>>> think the UTF-8 version fits better. >>>> >>>> I think it's worth mentioning that if the attribute used DN syntax and >>>> matching, we wouldn't have to worry about normalizing the issuer name before >>>> searching for it, as DS would do that for us. >>> >>> Good point, but I think the main use case for this attribute is on the >>> client side to determine if a rule should be applied to a certificate or >>> not. So I guess LDAP searches with this attribute would be rare because >>> the client will load all rules in one run. >>> >>>> >>>>> >>>>> * nsslapd-certmap-basedn, see DOMAINDN above >>>>> >>>>> * altSecurityIdentities example: X.500 ordering is used by AD here and >>>>> unfortunately I think we have to adopt it at least for this specific >>>>> usage, here is an ldapsearch output from AD: >>>>> >>>>> altSecurityIdentities: >>>>> X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC >>>>> =ad,CN=Users,CN=t u,E=test.user at email.domain >>>>> altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate >>>>> AuthorityDC >>>>> =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co >>>>> m,CN=Sumit Bose Sumit Bose >>>>> >>>>> * Certificate Mapping Administrators or re-use Certificate >>>>> Administrators: I would prefer a new 'Certificate Mapping >>>>> Administrators' >>>>> >>>>> * Users can manage their own X.509 certificate mappings? I'm not sure >>>>> here, at the first glance I would say no. How are OTP tokens handled? >>>>> Maybe this would be a candidate for certmappingconfig-* option? >>>> >>>> I think a better question is "How is userCertificate handled?" >>>> >>>> Anyway, self-service permissions can be enabled/disabled, so there is really >>>> no need for a new certmappingconfig option. >>> >>> Yes, this makes sense. >>> >>> bye, >>> Sumit >>>> >>>>> >>>>> That's all :-) >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>> >>>> >>>> -- >>>> Jan Cholasta >> >> >> -- >> Jan Cholasta -- Jan Cholasta From jcholast at redhat.com Fri Jan 6 07:50:14 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 6 Jan 2017 08:50:14 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <0b522bc7-de1f-f81b-cfad-ba418c93d414@redhat.com> On 5.1.2017 10:39, Sumit Bose wrote: > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: >> On 18.10.2016 07:34, Jan Cholasta wrote: >>> On 17.10.2016 16:50, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 13.10.2016 18:52, Sumit Bose wrote: >>>>>> ===== Issuer specific matching ===== >>>>>> Although the MIT Kerberos rules allow to select the issuer of a >>>>>> certificate there are use cases where a more specific selection is >>>>>> needed. E.g. if there are some default matching rules for all issuers >>>>>> and some other issuer specific rules where the default rules should >>>>>> not apply. To make this possible with the above scheme the default >>>>>> rules must have an clause which matches all but the issuer >>>>>> with the specific rules. Writing regular-expressions to not match a >>>>>> specific string or a list of strings is at least error-prone if not >>>>>> impossible. >>>>>> >>>>>> To make it easier to define issuer specific rules and default rules at >>>>>> the same time and optional issuer string can be added to the rule to >>>>>> indicate that for the given issuer only those rules should be >>>>>> considered. Given the use-case I think it is acceptable to require >>>>>> that the full issuer must be specified here in LDAP order (see below) >>>>>> and case-sensitive matching is used. >>>>> >>>>> This could also be solved by adding priority to rules - if two rules >>>>> match, the one with higher priority (the issuer specific rule) is >>>>> preferred over the one with lower priority (the default rule). IMO this >>>>> is better than an optional issuer string as it offers greater >>>>> flexibility. >>>> >>>> The use cases I've seen haven't had to do with priority, though that >>>> would be a nice enhancement, but with only allowing certificates issued >>>> by a specific CA to be allowed (this is pretty common in web servers). >>>> Being able to say "only do the matching on certificates issued by foo" >>>> is valuable. >>> >>> Sure, I'm not suggesting that matching by issuer should be removed, only >>> that rule precedence should not be determined by the issuer field setting. >>> >> >> Bump. Sumit, what is your opinion on this? > > I'm fine with an optional(?) priority as well. Since priorities are > already used in the pwpolicies this should be already known to the > experienced admin. I guess we just have stick with "A lower value > indicates a higher priority" to not confuse users. That's why I think > that the priority should be optional here and a missing value indicates > the lowest priority (default rules). In pwpolicy and sudorule, the priority is required and has to be unique. Maybe we should do this for certificate mapping rules as well? > > Are you thinking of using the CoS scheme here as well would a priority > attribute be sufficient because we do not want to reference internal > objects in the mapping rules? I'm not sure how CoS would be helpful here, I think a simple interger attribute would be perfectly sufficient. > > bye, > Sumit > >> >> -- >> Jan Cholasta -- Jan Cholasta From ftweedal at redhat.com Fri Jan 6 08:08:04 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 6 Jan 2017 18:08:04 +1000 Subject: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication Message-ID: <20170106080804.GP4539@dhcp-40-8.bne.redhat.com> Hi comrades, I have written up the high-level details of the FreeIPA->Dogtag GSS-API authentication design. The goal is improve security by removing an egregious privilege separation violation: the RA Agent cert. There is a fair bit of work still to do on the Dogtag side but things are shaping up there and it's time to work out the IPA aspects. The design is at: http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication Right now, I need feedback about the Domain Level aspects: whether it is the right approach, whether there are mechanisms to perform update steps (specifically: LDAP updates and/or api calls) alongside a DL bump, or if there aren't, how to deal with that (implement such a mechanism, make admins do extra steps, ???). Of course, any other general or specific feedback is welcome. Thanks, Fraser From freeipa-github-notification at redhat.com Fri Jan 6 08:13:13 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 09:13:13 +0100 Subject: [Freeipa-devel] [freeipa PR#317][synchronized] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Author: stlaz Title: #317: Unify password generation across FreeIPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/317/head:pr317 git checkout pr317 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-317.patch Type: text/x-diff Size: 22723 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 08:14:44 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 09:14:44 +0100 Subject: [Freeipa-devel] [freeipa PR#317][comment] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Title: #317: Unify password generation across FreeIPA stlaz commented: """ I don't see any merge conflicts and the rebase was automatic so I don't see why, but ok. Just note that ipatool may be confused with me commiting @pspacek's commit as he was the author of the main code and I put it to work with the rest of IPA. """ See the full comment at https://github.com/freeipa/freeipa/pull/317#issuecomment-270853592 From freeipa-github-notification at redhat.com Fri Jan 6 08:27:32 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 09:27:32 +0100 Subject: [Freeipa-devel] [freeipa PR#317][+pushed] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Title: #317: Unify password generation across FreeIPA Label: +pushed From freeipa-github-notification at redhat.com Fri Jan 6 08:27:34 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 09:27:34 +0100 Subject: [Freeipa-devel] [freeipa PR#317][comment] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Title: #317: Unify password generation across FreeIPA mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/8db5b277a079fdfe5efbd7d49311f14489cee0e8 https://fedorahosted.org/freeipa/changeset/fb7c111ac13510609e2cba14ecf88cd2ed291a4b """ See the full comment at https://github.com/freeipa/freeipa/pull/317#issuecomment-270855325 From freeipa-github-notification at redhat.com Fri Jan 6 08:27:35 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 09:27:35 +0100 Subject: [Freeipa-devel] [freeipa PR#317][closed] Unify password generation across FreeIPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/317 Author: stlaz Title: #317: Unify password generation across FreeIPA Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/317/head:pr317 git checkout pr317 From freeipa-github-notification at redhat.com Fri Jan 6 08:37:13 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Fri, 06 Jan 2017 09:37:13 +0100 Subject: [Freeipa-devel] [freeipa PR#376][opened] client install: correctly report all failures Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Author: HonzaCholasta Title: #376: client install: correctly report all failures Action: opened PR body: """ In commit 5249eb817efbb5708d097173a8d5f1e322fb201e, the client install code was converted to use exception handling instead of return codes. However, some return statements were not converted to raise statements and as a result, ipa-client-install will report success in some error conditions. Convert the return statements to raise statements to fix the issue. https://fedorahosted.org/freeipa/ticket/6392 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/376/head:pr376 git checkout pr376 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-376.patch Type: text/x-diff Size: 3321 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 08:54:08 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 09:54:08 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 51892 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 08:55:50 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 09:55:50 +0100 Subject: [Freeipa-devel] [freeipa PR#367][edited] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: edited Changed field: body Original value: """ This batch of patches removes NSSConnection along with the whole ipapython.nsslib from IPA and replaces it with more standard httplib.HTTPSConnection. NSSConnection was causing a lot of trouble in the past because it is apparently very fragile when it comes to nss library initialization. On top of that, when NSSConnection is used to set up an HTTPS connection in FIPS, it always requires a password to NSS database as NSS apparently tries to create a temporary private key and store it to the database even though client authentication is not required in the SSL connection. TODO (will require changes in certmonger/dogatg.c): - [x] remove NSSConnection from client modules - [x] remove NSSConnection from server modules where it's used to connect to the certificate server - [x] remove the nsslib library completely - [ ] we may probably remove ipaCert from /etc/httpd/alias and stop tracking it with certmonger - [ ] once ^- is done, track /var/lib/ipa/ra-agent.pem in certmonger instead https://fedorahosted.org/freeipa/ticket/5695 """ From freeipa-github-notification at redhat.com Fri Jan 6 09:00:13 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 06 Jan 2017 10:00:13 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 51998 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 09:07:20 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 10:07:20 +0100 Subject: [Freeipa-devel] [freeipa PR#375][+ack] Fix used before assignment bug in host_port_open() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Title: #375: Fix used before assignment bug in host_port_open() Label: +ack From freeipa-github-notification at redhat.com Fri Jan 6 09:08:00 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 10:08:00 +0100 Subject: [Freeipa-devel] [freeipa PR#375][comment] Fix used before assignment bug in host_port_open() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Title: #375: Fix used before assignment bug in host_port_open() mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/deaad95247fa9624bef0108bf3813f358fb17ee5 """ See the full comment at https://github.com/freeipa/freeipa/pull/375#issuecomment-270861373 From freeipa-github-notification at redhat.com Fri Jan 6 09:08:02 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 10:08:02 +0100 Subject: [Freeipa-devel] [freeipa PR#375][+pushed] Fix used before assignment bug in host_port_open() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Title: #375: Fix used before assignment bug in host_port_open() Label: +pushed From freeipa-github-notification at redhat.com Fri Jan 6 09:08:03 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 10:08:03 +0100 Subject: [Freeipa-devel] [freeipa PR#375][closed] Fix used before assignment bug in host_port_open() In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/375 Author: tiran Title: #375: Fix used before assignment bug in host_port_open() Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/375/head:pr375 git checkout pr375 From sbose at redhat.com Fri Jan 6 09:30:37 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 6 Jan 2017 10:30:37 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <0b522bc7-de1f-f81b-cfad-ba418c93d414@redhat.com> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> <0b522bc7-de1f-f81b-cfad-ba418c93d414@redhat.com> Message-ID: <20170106093037.GG3710@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: > On 5.1.2017 10:39, Sumit Bose wrote: > > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > > > On 18.10.2016 07:34, Jan Cholasta wrote: > > > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > > > Jan Cholasta wrote: > > > > > > Hi, > > > > > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > > > ===== Issuer specific matching ===== > > > > > > > Although the MIT Kerberos rules allow to select the issuer of a > > > > > > > certificate there are use cases where a more specific selection is > > > > > > > needed. E.g. if there are some default matching rules for all issuers > > > > > > > and some other issuer specific rules where the default rules should > > > > > > > not apply. To make this possible with the above scheme the default > > > > > > > rules must have an clause which matches all but the issuer > > > > > > > with the specific rules. Writing regular-expressions to not match a > > > > > > > specific string or a list of strings is at least error-prone if not > > > > > > > impossible. > > > > > > > > > > > > > > To make it easier to define issuer specific rules and default rules at > > > > > > > the same time and optional issuer string can be added to the rule to > > > > > > > indicate that for the given issuer only those rules should be > > > > > > > considered. Given the use-case I think it is acceptable to require > > > > > > > that the full issuer must be specified here in LDAP order (see below) > > > > > > > and case-sensitive matching is used. > > > > > > > > > > > > This could also be solved by adding priority to rules - if two rules > > > > > > match, the one with higher priority (the issuer specific rule) is > > > > > > preferred over the one with lower priority (the default rule). IMO this > > > > > > is better than an optional issuer string as it offers greater > > > > > > flexibility. > > > > > > > > > > The use cases I've seen haven't had to do with priority, though that > > > > > would be a nice enhancement, but with only allowing certificates issued > > > > > by a specific CA to be allowed (this is pretty common in web servers). > > > > > Being able to say "only do the matching on certificates issued by foo" > > > > > is valuable. > > > > > > > > Sure, I'm not suggesting that matching by issuer should be removed, only > > > > that rule precedence should not be determined by the issuer field setting. > > > > > > > > > > Bump. Sumit, what is your opinion on this? > > > > I'm fine with an optional(?) priority as well. Since priorities are > > already used in the pwpolicies this should be already known to the > > experienced admin. I guess we just have stick with "A lower value > > indicates a higher priority" to not confuse users. That's why I think > > that the priority should be optional here and a missing value indicates > > the lowest priority (default rules). > > In pwpolicy and sudorule, the priority is required and has to be unique. > Maybe we should do this for certificate mapping rules as well? I think there is no requirement that only a single rule should match hence I think the priority here must not be unique. > > > > > Are you thinking of using the CoS scheme here as well would a priority > > attribute be sufficient because we do not want to reference internal > > objects in the mapping rules? > > I'm not sure how CoS would be helpful here, I think a simple interger > attribute would be perfectly sufficient. I agree. bye, Sumit > > > > > bye, > > Sumit > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta From sbose at redhat.com Fri Jan 6 09:48:45 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 6 Jan 2017 10:48:45 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <4301cd9d-7ddc-ff82-28f6-01aa3131db57@redhat.com> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> <20170105121557.GB3710@p.Speedport_W_724V_Typ_A_05011603_00_011> <4301cd9d-7ddc-ff82-28f6-01aa3131db57@redhat.com> Message-ID: <20170106094845.GH3710@p.Speedport_W_724V_Typ_A_05011603_00_011> On Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote: > On 5.1.2017 13:15, Sumit Bose wrote: > > On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote: > > > On 19.12.2016 12:13, Sumit Bose wrote: > > > > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: > > > > > I agree with *almost* everything Sumit said. See my inline comments below. > > > > > > > > > > On 16.12.2016 11:53, Sumit Bose wrote: > > > > > > On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I have started a feature description for the Certificate Identity Mapping at > > > > > > > the following location: > > > > > > > http://www.freeipa.org/page/V4/Certificate_Identity_Mapping > > > > > > > > > > > > > > This is a first step, focusing on the interface we would like to provide. It > > > > > > > still contains open questions, some of which are linked to the corresponding > > > > > > > design on SSSD side: > > > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates > > > > > > > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities > > > > > > > > > > > > > > Comments, concerns and suggestions are welcome. Thanks! > > > > > > > > > > > > Hi Flo, > > > > > > > > > > > > thank you very much for setting up the page. > > > > > > > > > > > > My comments are mostly about the commands. > > > > > > > > > > > > certmappingconfig-mod: > > > > > > > > > > > > * --enable=Boolean: if this option is 'False' SSSD will basically show > > > > > > the current behavior and just look up the certificates directly. But I > > > > > > wonder if the option is needed at all because not adding any mapping > > > > > > rules would have the same effect. > > > > > > > > > > > > What is the scope here, only the IPA domain, or all trusted domains as > > > > > > well? If it is for trusted domains as well will the certmappingrule-* > > > > > > commands and user-{add/remove}-certmapping return an error? > > > > > > > > > > > > So, in general I see an overlap with the mapping rules and I think it > > > > > > would be clearer to drop this option and do the lookups according to > > > > > > the mapping rules. > > > > > > > > > > > > * --prompt-username=Boolean: the description implies that this option is > > > > > > synonymous to 1:1 mapping, but it is not. On Linux authentication in > > > > > > most cases use a user name either by directly asking (e.g. /bin/login) > > > > > > or using the current user name (e.g. sudo). So, according to its name > > > > > > it would only control if gdm is allowed to ask for an (optional) user > > > > > > name. > > > > > > > > > > > > If the option is renamed to e.g. --force-1-to-1-mapping to really > > > > > > enforce a 1:1 mapping then it would make sense to derived to gdm > > > > > > behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to > > > > > > ask for a user name and if it is not enforced then it makes sense to > > > > > > offer and optional user name input field. > > > > > > > > > > > > * --enable-username-mismatch=Boolean: I think this option can be > > > > > > dropped. My test so far show that if a non-matching hint is given on a > > > > > > Windows client authentication fails. > > > > > > > > > > > > * --alternate-attribute=STRING: I think this option isn't needed as > > > > > > well. For IPA server-side we should decide on an attribute name and > > > > > > add it to the schema for user objects. On the client side the > > > > > > attribute name can be taken from the mapping rule.A > > > > > > > > > > > > > > > > > > certmappingrule.*: > > > > > > > > > > > > * ISSUERDN: it looks like you want to use issuerName here. In > > > > > > certificateRecord it it used with LDAP ordering and I would prefer > > > > > > LDAP ordering at all points where we have a choice. Unfortunately in the > > > > > > issuer-subject mapping AD dictates X.500 ordering. > > > > > > > > > > LDAP ordering should indeed be preferred, as it is used everywhere else in > > > > > IPA. We can convert to/from X.500 ordering where necessary, when possible. > > > > > > > > > > > > > > > > > * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in > > > > > > the example? My intention in the SSSD design-page was to specify the > > > > > > domain (as in DNS domain/IPA domain/trusted domain) where the matching > > > > > > user should be searched. Different domains might certificates from > > > > > > different issuers and some domains might not even use certificates. > > > > > > With this information SSSD does not have to search any domain trusted > > > > > > by IPA from a given certificate, but look only at domains listed here > > > > > > (the attribute should be a multi-value one). > > > > > > > > > > > > There are objects in the LDAP tree for each trusted domain which are > > > > > > used by SSSD so using a DN syntax would be valid here. > > > > > > > > > > We use domain names rather than DNs to refer to domains everywhere else in > > > > > the framework. I don't think this place should be an exception. > > > > > > > > I'm fine with domain names as well. In fact I didn't thought of using > > > > DNs for this before I read DOMAINDN on the design page. > > > > > > > > > > > > > > > > > > > > > * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search > > > > > > filters should just be a special kind of mapping rules. I can image in > > > > > > syntax like: . I > > > > > > think the difficult part with the LDAP filters will to define sensible > > > > > > templates. > > > > > > > > > > I'm not sure I understand. Could you please elaborate a little bit? > > > > > > > > A LDAP search filter which would cover the AD behavior would look like: > > > > > > > > (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) > > > > > > > > where > > > > > > > > %A: must be replaced with the issuer of the certificate in X.500 order > > > > %B: must be replaced with the subject of the certificate in X.500 order > > > > > > > > it would be possible of course to use a specific template here which > > > > would generate the complete search attribute value. > > > > > > > > %C: must be replaced by the principal from AD's SAN > > > > szOID_NT_PRINCIPAL_NAME > > > > %D: must be replaced with only then name component (the part before the > > > > realm) of the principal from szOID_NT_PRINCIPAL_NAME > > > > > > > > As %C and %D imply this filter will only work for certificates which > > > > have szOID_NT_PRINCIPAL_NAME but for those it must be used to be > > > > compatible with AD. For certificates without > > > > > > > > (altSecurityIdentities=%A%B) > > > > > > > > is sufficient. It is possible to select the right filter with matching > > > > rules. > > > > > > Right. > > > > > > > > > > > So we have to find suitable names for the %A, %B, %C and %D templates > > > > and also allow different representations (e.g. LDAP or X.500 order for > > > > DNs). > > > > > > I would personally prefer if we used Python-style formatting strings for the > > > templates, I find them much more pleasant to work with than C-style > > > > sure, I used %A etc as arbitrary templates, I didn't wanted to imply > > that C-style syntax should be used. > > > > > formatting strings. The filter which covers AD behavior could be written as: > > > > > > > > > (|(altSecurityIdentities={issuer_dn!x500}{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name})) > > > > I think this is quite readable and understandable to an admin with basic > > knowledge of LDAP search filters and certificate components. Are the > > names used here (issuer_dn, subject_dn, subject_nt_principal) already > > used by e.g. some Python modules or do we have to define the list of > > names? > > They are not defined anywhere, it's just something I came up with. > > > > > If there a reason for using '!x500' to indicate X500 ordering? Wouldn't > > e.g. issuer_dn.x500 work as well similar to Python's str.lower()? Having > > only one symbol to indicate a special formatting of the value from the > > certificate would make the syntax easier to learn. > > I tried to follow the Python convention, where '.' is used for attribute > access and '!' for value conversion. In other words, '.' selects a component > of the value and '!' takes the whole value and formats it in a certain way. ok, makes sense. > > > > > > > > > > > > > > > > > > > > > But as long as we keep the general mapping rule syntax > > > > > > flexible the LDAP filter rules can be added in a later version. > > > > > > > > > > IMHO it should be the other way round and LDAP filters should be implemented > > > > > first, as they offer all the flexibility we need (all of the other fields > > > > > can be easily implemented on top of LDAP filters) and are by default > > > > > extensible without having to update servers and clients. > > > > > > > > In general I agree, as long we can find a suitable scheme to handle the > > > > templates to add content from the certificate in a specific format to > > > > the search filters. > > > > > > > > But from the user/admin perspective there should be special rules for > > > > common use-cases which do not require to know too much details about > > > > certificates and LDAP trees. E.g. for AD (either via direct or indirect > > > > integration) there should be a rule which just does all which > > > > AD would do depending on the certificate type. For IPA something like > > > > might be a good start for handling external > > > > certificates which do not contain user specific data which can be mapped > > > > to user object because the syntax is already known from AD. > > > > > > This could be handled in the IPA plugin by converting from the user-friendly > > > representation to LDAP filter template internally when a mapping rule is > > > added or modified. > > > > Yes, but it can also be expanded by the component/library which will > > replace the templates with the actual values from the certificate. This > > would have the befit that the user-friendly representation is visible > > even with low-level LDAP commands? > > That's true (although I can't imagine why would anyone look on the LDAP > entries directly, especially if they didn't understand LDAP filters), but > IMHO it lacks certain elegancy by having more than one way to define the > same rule, more code paths to handle the rules, etc. > > Additionally, LDAP filters provide better forward compatiblity - if we had > to add support for a new mapping style in the future, with LDAP filters only > the IPA server would have to be updated, without LDAP filters we would also > have to worry about updating old clients which do not understand the new > mapping style. ok, but if the new mapping style introduces some new templates or formatting options the clients must be updated as well. bye, Sumit > > > > > bye, > > Sumit > > > > > > > > > > > > > > > > > > > > > > > > > > * enable/disable: I think this is a good idea and would be consistent > > > > > > with other rules like HBAC and sudo > > > > > > > > > > > > * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be > > > > > > better to not add this option and only implement the > > > > > > 'user-{add/remove}-certmapping' commands > > > > > > > > > > > > * user-{add/remove}-certmapping: you say '... almost any type of mapping, > > > > > > or a more user-friendly API ...'. I would not say 'or' but 'and' and > > > > > > implement both > > > > > > > > > > > > * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I > > > > > > think both are note needed, see above > > > > > > > > > > > > * altSecurityIdentities: I would prefer to use a different name and OID. > > > > > > Using the same definition as AD would imo imply that it can be used in > > > > > > the same way as in AD. But e.g. AD also supports other content like > > > > > > KERBEROS:alternative_user_principal at AD.DOMAIN which we will not > > > > > > support. > > > > > > > > > > > > * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is > > > > > > general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since > > > > > > the issuer DN in general will not be a DN from the local LDAP tree I > > > > > > think the UTF-8 version fits better. > > > > > > > > > > I think it's worth mentioning that if the attribute used DN syntax and > > > > > matching, we wouldn't have to worry about normalizing the issuer name before > > > > > searching for it, as DS would do that for us. > > > > > > > > Good point, but I think the main use case for this attribute is on the > > > > client side to determine if a rule should be applied to a certificate or > > > > not. So I guess LDAP searches with this attribute would be rare because > > > > the client will load all rules in one run. > > > > > > > > > > > > > > > > > > > > > * nsslapd-certmap-basedn, see DOMAINDN above > > > > > > > > > > > > * altSecurityIdentities example: X.500 ordering is used by AD here and > > > > > > unfortunately I think we have to adopt it at least for this specific > > > > > > usage, here is an ldapsearch output from AD: > > > > > > > > > > > > altSecurityIdentities: > > > > > > X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC > > > > > > =ad,CN=Users,CN=t u,E=test.user at email.domain > > > > > > altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate > > > > > > AuthorityDC > > > > > > =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co > > > > > > m,CN=Sumit Bose Sumit Bose > > > > > > > > > > > > * Certificate Mapping Administrators or re-use Certificate > > > > > > Administrators: I would prefer a new 'Certificate Mapping > > > > > > Administrators' > > > > > > > > > > > > * Users can manage their own X.509 certificate mappings? I'm not sure > > > > > > here, at the first glance I would say no. How are OTP tokens handled? > > > > > > Maybe this would be a candidate for certmappingconfig-* option? > > > > > > > > > > I think a better question is "How is userCertificate handled?" > > > > > > > > > > Anyway, self-service permissions can be enabled/disabled, so there is really > > > > > no need for a new certmappingconfig option. > > > > > > > > Yes, this makes sense. > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > > > > > That's all :-) > > > > > > > > > > > > bye, > > > > > > Sumit > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jan Cholasta > > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta From freeipa-github-notification at redhat.com Fri Jan 6 10:05:52 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Fri, 06 Jan 2017 11:05:52 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values gkaihorodova commented: """ Yes, the intention was to have repr() of the given string , so I'll use ''{!r} instead of '{}', and apply that change to #210 also. Thank you. """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-270871478 From freeipa-github-notification at redhat.com Fri Jan 6 11:04:47 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Fri, 06 Jan 2017 12:04:47 +0100 Subject: [Freeipa-devel] [freeipa PR#181][synchronized] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 5473 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 11:09:31 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Fri, 06 Jan 2017 12:09:31 +0100 Subject: [Freeipa-devel] [freeipa PR#210][synchronized] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Author: gkaihorodova Title: #210: Tests: Stage User Tracker implementation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/210/head:pr210 git checkout pr210 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-210.patch Type: text/x-diff Size: 5691 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 6 11:43:11 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 12:43:11 +0100 Subject: [Freeipa-devel] [freeipa PR#334][comment] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Title: #334: Py3: Fix ToASCII method mbasti-rh commented: """ bump for review """ See the full comment at https://github.com/freeipa/freeipa/pull/334#issuecomment-270888152 From freeipa-github-notification at redhat.com Fri Jan 6 11:47:06 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 06 Jan 2017 12:47:06 +0100 Subject: [Freeipa-devel] [freeipa PR#334][+ack] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Title: #334: Py3: Fix ToASCII method Label: +ack From freeipa-github-notification at redhat.com Fri Jan 6 11:48:32 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 12:48:32 +0100 Subject: [Freeipa-devel] [freeipa PR#334][comment] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Title: #334: Py3: Fix ToASCII method mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/35ba724de90b270773d91596de310291df745df0 """ See the full comment at https://github.com/freeipa/freeipa/pull/334#issuecomment-270888978 From freeipa-github-notification at redhat.com Fri Jan 6 11:48:34 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 12:48:34 +0100 Subject: [Freeipa-devel] [freeipa PR#334][closed] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Author: mbasti-rh Title: #334: Py3: Fix ToASCII method Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/334/head:pr334 git checkout pr334 From freeipa-github-notification at redhat.com Fri Jan 6 11:48:35 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 06 Jan 2017 12:48:35 +0100 Subject: [Freeipa-devel] [freeipa PR#334][+pushed] Py3: Fix ToASCII method In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/334 Title: #334: Py3: Fix ToASCII method Label: +pushed From flo at redhat.com Fri Jan 6 15:43:16 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Fri, 6 Jan 2017 16:43:16 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> Message-ID: <2afe7b9e-7db0-73b0-f943-7100d27ff808@redhat.com> On 12/16/2016 09:34 AM, Florence Blanc-Renaud wrote: > On 12/06/2016 04:39 PM, Florence Blanc-Renaud wrote: >> Hi, >> >> I have started a feature description for the Certificate Identity >> Mapping at the following location: >> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >> >> This is a first step, focusing on the interface we would like to >> provide. It still contains open questions, some of which are linked to >> the corresponding design on SSSD side: >> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >> >> >> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >> >> >> >> Comments, concerns and suggestions are welcome. Thanks! >> >> Flo. >> > > Hi, > > the design page for Certificate Identity Mapping [1] has been updated > with a schema proposal and an example of configuration data. > > Please share your comments, concerns, suggestions before January 7, so > that we can finalize the API and start the implementation. > Thanks, > Flo. > > [1] http://www.freeipa.org/page/V4/Certificate_Identity_Mapping > Hi, thanks for all the comments provided so far. The design page [1] has been updated and I hope that it reflects the current state of discussions: - removed configuration options that did not seem useful - shortened the feature name to certmap-xx - added the notion of priority in the cert map rules As always, comments are welcome. Flo [1] http://www.freeipa.org/page/V4/Certificate_Identity_Mapping From freeipa-github-notification at redhat.com Fri Jan 6 17:54:22 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 06 Jan 2017 18:54:22 +0100 Subject: [Freeipa-devel] [freeipa PR#374][comment] pytest: set rules to find test files and functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Title: #374: pytest: set rules to find test files and functions tiran commented: """ Reproducer: * clone my tox branch https://github.com/tiran/freeipa/tree/tox * run ```tox -e py27``` ``` $ tox -e py27 py27 create: /home/heimes/redhat/freeipa/.tox/py27 py27 installdeps: ipaclient, ipatests ['/home/heimes/redhat/freeipa/.tox-install.sh', '/home/heimes/redhat/freeipa/.tox/py27/bin/python', '/home/heimes/redhat/freeipa/.tox/py27/lib/python2.7/site-packages', 'ipaclient', 'ipatests'] py27 installed: cffi==1.9.1,configparser==3.5.0,cryptography==1.7.1,custodia==0.2.0,decorator==4.0.10,dnspython==1.15.0,enum34==1.1.6,gssapi==1.2.0,idna==2.2,ipaclient==4.4.90.dev201701051932+gitadb0120,ipaddress==1.0.17,ipalib==4.4.90.dev201701051932+gitadb0120,ipapython==4.4.90.dev201701051932+gitadb0120,ipatests==4.4.90.dev201701051932+gitadb0120,jwcrypto==0.4.0,netaddr==0.7.18,netifaces==0.10.5,nose==1.3.7,polib==1.0.8,py==1.4.32,pyasn1==0.1.9,pyasn1-modules==0.0.8,pycparser==2.17,pyldap==2.4.25.1,pytest==3.0.5,pytest-multihost==1.1,python-nss==1.0.1,python-yubico==1.3.2,pyusb==1.0.0,qrcode==5.3,requests==2.12.4,six==1.10.0 py27 runtests: PYTHONHASHSEED='3237466879' py27 runtests: commands[0] | ipa-run-tests test_ipapython test_ipalib test_pkcs10 --ignore=test_ipalib/test_rpc.py =================================================================== test session starts ==================================================================== platform linux2 -- Python 2.7.12, pytest-3.0.5, py-1.4.32, pluggy-0.4.0 rootdir: /home/heimes/redhat, inifile: tox.ini plugins: multihost-1.1 collected 0 items =============================================================== no tests ran in 0.12 seconds =============================================================== ERROR: InvocationError: '/home/heimes/redhat/freeipa/.tox/py27/bin/ipa-run-tests test_ipapython test_ipalib test_pkcs10 --ignore=test_ipalib/test_rpc.py' _________________________________________________________________________ summary __________________________________________________________________________ ERROR: py27: commands failed ``` * edit ```ipatests/conftest.py``` and enable ```python_files``` on line 47 * run ```tox -e py27``` again ``` =================================================================== test session starts ==================================================================== platform linux2 -- Python 2.7.12, pytest-3.0.5, py-1.4.32, pluggy-0.4.0 rootdir: /home/heimes/redhat, inifile: tox.ini plugins: multihost-1.1 collected 406 items test_ipapython/test_cookie.py ............ test_ipapython/test_dn.py ........................... test_ipapython/test_ipautil.py .................................................................. test_ipapython/test_ipavalidate.py .......... test_ipapython/test_kerberos.py .............. test_ipapython/test_keyring.py .......... test_ipapython/test_ssh.py ............................... test_ipalib/test_aci.py ................... test_ipalib/test_backend.py ........ test_ipalib/test_base.py ............... test_ipalib/test_capabilities.py . test_ipalib/test_cli.py ... test_ipalib/test_config.py ............... test_ipalib/test_crud.py ............... test_ipalib/test_errors.py ....... test_ipalib/test_frontend.py ........................................ test_ipalib/test_messages.py .... test_ipalib/test_output.py ... test_ipalib/test_parameters.py ............................................................. test_ipalib/test_plugable.py ........ test_ipalib/test_text.py ............................. test_ipalib/test_x509.py ... test_pkcs10/test_pkcs10.py ..... ================================================================== pytest-warning summary ================================================================== ... ====================================================== 406 passed, 59 pytest-warnings in 2.04 seconds ==================================================== _________________________________________________________________________ summary ________________________________________________________________________ py27: commands succeeded congratulations :) ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/374#issuecomment-270962079 From freeipa-github-notification at redhat.com Mon Jan 9 07:16:49 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 08:16:49 +0100 Subject: [Freeipa-devel] [freeipa PR#210][+ack] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Title: #210: Tests: Stage User Tracker implementation Label: +ack From freeipa-github-notification at redhat.com Mon Jan 9 07:17:54 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 08:17:54 +0100 Subject: [Freeipa-devel] [freeipa PR#181][+ack] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values Label: +ack From freeipa-github-notification at redhat.com Mon Jan 9 07:18:05 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 08:18:05 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values stlaz commented: """ Thank you for the changes! """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-271222754 From freeipa-github-notification at redhat.com Mon Jan 9 07:30:46 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 09 Jan 2017 08:30:46 +0100 Subject: [Freeipa-devel] [freeipa PR#377][opened] dogtaginstance: track server certificate with our renew agent Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Author: HonzaCholasta Title: #377: dogtaginstance: track server certificate with our renew agent Action: opened PR body: """ This patchset is intended to make @simo5's life easier when changing the RA agent certificate location in #314. **renew agent: handle non-replicated certificates** In addition to replicated certificates (Dogtag certificates, RA certificate), handle non-replicated certificates in dogtag-ipa-ca-renew-agent as well. **dogtaginstance: track server certificate with our renew agent** Track Dogtag's server certificate with dogtag-ipa-ca-renew-agent instead of dogtag-ipa-renew-agent. **cainstance: do not configure renewal guard** Do not configure renewal guard for dogtag-ipa-renew-agent, as it is not used in IPA anymore. https://fedorahosted.org/freeipa/ticket/5959 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/377/head:pr377 git checkout pr377 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-377.patch Type: text/x-diff Size: 8690 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 9 07:46:22 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 Jan 2017 08:46:22 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: <20170106093037.GG3710@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <20161006104930.GC22626@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> <0b522bc7-de1f-f81b-cfad-ba418c93d414@redhat.com> <20170106093037.GG3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: On 6.1.2017 10:30, Sumit Bose wrote: > On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: >> On 5.1.2017 10:39, Sumit Bose wrote: >>> On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: >>>> On 18.10.2016 07:34, Jan Cholasta wrote: >>>>> On 17.10.2016 16:50, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 13.10.2016 18:52, Sumit Bose wrote: >>>>>>>> ===== Issuer specific matching ===== >>>>>>>> Although the MIT Kerberos rules allow to select the issuer of a >>>>>>>> certificate there are use cases where a more specific selection is >>>>>>>> needed. E.g. if there are some default matching rules for all issuers >>>>>>>> and some other issuer specific rules where the default rules should >>>>>>>> not apply. To make this possible with the above scheme the default >>>>>>>> rules must have an clause which matches all but the issuer >>>>>>>> with the specific rules. Writing regular-expressions to not match a >>>>>>>> specific string or a list of strings is at least error-prone if not >>>>>>>> impossible. >>>>>>>> >>>>>>>> To make it easier to define issuer specific rules and default rules at >>>>>>>> the same time and optional issuer string can be added to the rule to >>>>>>>> indicate that for the given issuer only those rules should be >>>>>>>> considered. Given the use-case I think it is acceptable to require >>>>>>>> that the full issuer must be specified here in LDAP order (see below) >>>>>>>> and case-sensitive matching is used. >>>>>>> >>>>>>> This could also be solved by adding priority to rules - if two rules >>>>>>> match, the one with higher priority (the issuer specific rule) is >>>>>>> preferred over the one with lower priority (the default rule). IMO this >>>>>>> is better than an optional issuer string as it offers greater >>>>>>> flexibility. >>>>>> >>>>>> The use cases I've seen haven't had to do with priority, though that >>>>>> would be a nice enhancement, but with only allowing certificates issued >>>>>> by a specific CA to be allowed (this is pretty common in web servers). >>>>>> Being able to say "only do the matching on certificates issued by foo" >>>>>> is valuable. >>>>> >>>>> Sure, I'm not suggesting that matching by issuer should be removed, only >>>>> that rule precedence should not be determined by the issuer field setting. >>>>> >>>> >>>> Bump. Sumit, what is your opinion on this? >>> >>> I'm fine with an optional(?) priority as well. Since priorities are >>> already used in the pwpolicies this should be already known to the >>> experienced admin. I guess we just have stick with "A lower value >>> indicates a higher priority" to not confuse users. That's why I think >>> that the priority should be optional here and a missing value indicates >>> the lowest priority (default rules). >> >> In pwpolicy and sudorule, the priority is required and has to be unique. >> Maybe we should do this for certificate mapping rules as well? > > I think there is no requirement that only a single rule should match > hence I think the priority here must not be unique. Is there a requirement that it must be possible for multiple rules to match? If not, we could begin with a simpler (for admin) solution with unique priorities and lift the restriction later when/if it becomes necessary. But I don't have a strong opinion on this. > >> >>> >>> Are you thinking of using the CoS scheme here as well would a priority >>> attribute be sufficient because we do not want to reference internal >>> objects in the mapping rules? >> >> I'm not sure how CoS would be helpful here, I think a simple interger >> attribute would be perfectly sufficient. > > I agree. > > bye, > Sumit > >> >>> >>> bye, >>> Sumit >>> >>>> >>>> -- >>>> Jan Cholasta >> >> >> -- >> Jan Cholasta -- Jan Cholasta From jcholast at redhat.com Mon Jan 9 07:55:03 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 9 Jan 2017 08:55:03 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: <20170106094845.GH3710@p.Speedport_W_724V_Typ_A_05011603_00_011> References: <3f7fdd64-df25-69c3-e472-585a4d33eb94@redhat.com> <20161216105321.GH3623@p.Speedport_W_724V_Typ_A_05011603_00_011> <20161219111344.GB26807@p.Speedport_W_724V_Typ_A_05011603_00_011> <5b84ac35-cc6f-763b-6a8f-f2805720643f@redhat.com> <20170105121557.GB3710@p.Speedport_W_724V_Typ_A_05011603_00_011> <4301cd9d-7ddc-ff82-28f6-01aa3131db57@redhat.com> <20170106094845.GH3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: On 6.1.2017 10:48, Sumit Bose wrote: > On Fri, Jan 06, 2017 at 08:40:31AM +0100, Jan Cholasta wrote: >> On 5.1.2017 13:15, Sumit Bose wrote: >>> On Mon, Jan 02, 2017 at 08:06:04AM +0100, Jan Cholasta wrote: >>>> On 19.12.2016 12:13, Sumit Bose wrote: >>>>> On Mon, Dec 19, 2016 at 10:02:58AM +0100, Jan Cholasta wrote: >>>>>> I agree with *almost* everything Sumit said. See my inline comments below. >>>>>> >>>>>> On 16.12.2016 11:53, Sumit Bose wrote: >>>>>>> On Tue, Dec 06, 2016 at 04:39:10PM +0100, Florence Blanc-Renaud wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have started a feature description for the Certificate Identity Mapping at >>>>>>>> the following location: >>>>>>>> http://www.freeipa.org/page/V4/Certificate_Identity_Mapping >>>>>>>> >>>>>>>> This is a first step, focusing on the interface we would like to provide. It >>>>>>>> still contains open questions, some of which are linked to the corresponding >>>>>>>> design on SSSD side: >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/MatchingAndMappingCertificates >>>>>>>> https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardsAndMultipleIdentities >>>>>>>> >>>>>>>> Comments, concerns and suggestions are welcome. Thanks! >>>>>>> >>>>>>> Hi Flo, >>>>>>> >>>>>>> thank you very much for setting up the page. >>>>>>> >>>>>>> My comments are mostly about the commands. >>>>>>> >>>>>>> certmappingconfig-mod: >>>>>>> >>>>>>> * --enable=Boolean: if this option is 'False' SSSD will basically show >>>>>>> the current behavior and just look up the certificates directly. But I >>>>>>> wonder if the option is needed at all because not adding any mapping >>>>>>> rules would have the same effect. >>>>>>> >>>>>>> What is the scope here, only the IPA domain, or all trusted domains as >>>>>>> well? If it is for trusted domains as well will the certmappingrule-* >>>>>>> commands and user-{add/remove}-certmapping return an error? >>>>>>> >>>>>>> So, in general I see an overlap with the mapping rules and I think it >>>>>>> would be clearer to drop this option and do the lookups according to >>>>>>> the mapping rules. >>>>>>> >>>>>>> * --prompt-username=Boolean: the description implies that this option is >>>>>>> synonymous to 1:1 mapping, but it is not. On Linux authentication in >>>>>>> most cases use a user name either by directly asking (e.g. /bin/login) >>>>>>> or using the current user name (e.g. sudo). So, according to its name >>>>>>> it would only control if gdm is allowed to ask for an (optional) user >>>>>>> name. >>>>>>> >>>>>>> If the option is renamed to e.g. --force-1-to-1-mapping to really >>>>>>> enforce a 1:1 mapping then it would make sense to derived to gdm >>>>>>> behavior. I.e. if 1:1 mapping is enforce it makes no sense for gdm to >>>>>>> ask for a user name and if it is not enforced then it makes sense to >>>>>>> offer and optional user name input field. >>>>>>> >>>>>>> * --enable-username-mismatch=Boolean: I think this option can be >>>>>>> dropped. My test so far show that if a non-matching hint is given on a >>>>>>> Windows client authentication fails. >>>>>>> >>>>>>> * --alternate-attribute=STRING: I think this option isn't needed as >>>>>>> well. For IPA server-side we should decide on an attribute name and >>>>>>> add it to the schema for user objects. On the client side the >>>>>>> attribute name can be taken from the mapping rule.A >>>>>>> >>>>>>> >>>>>>> certmappingrule.*: >>>>>>> >>>>>>> * ISSUERDN: it looks like you want to use issuerName here. In >>>>>>> certificateRecord it it used with LDAP ordering and I would prefer >>>>>>> LDAP ordering at all points where we have a choice. Unfortunately in the >>>>>>> issuer-subject mapping AD dictates X.500 ordering. >>>>>> >>>>>> LDAP ordering should indeed be preferred, as it is used everywhere else in >>>>>> IPA. We can convert to/from X.500 ordering where necessary, when possible. >>>>>> >>>>>>> >>>>>>> * DOMAINDN: does this refer to the nsslapd-certmap-basedn attribute in >>>>>>> the example? My intention in the SSSD design-page was to specify the >>>>>>> domain (as in DNS domain/IPA domain/trusted domain) where the matching >>>>>>> user should be searched. Different domains might certificates from >>>>>>> different issuers and some domains might not even use certificates. >>>>>>> With this information SSSD does not have to search any domain trusted >>>>>>> by IPA from a given certificate, but look only at domains listed here >>>>>>> (the attribute should be a multi-value one). >>>>>>> >>>>>>> There are objects in the LDAP tree for each trusted domain which are >>>>>>> used by SSSD so using a DN syntax would be valid here. >>>>>> >>>>>> We use domain names rather than DNs to refer to domains everywhere else in >>>>>> the framework. I don't think this place should be an exception. >>>>> >>>>> I'm fine with domain names as well. In fact I didn't thought of using >>>>> DNs for this before I read DOMAINDN on the design page. >>>>> >>>>>> >>>>>>> >>>>>>> * LDAPSEARCHFILTER: I think a separate option is not need. LDAP search >>>>>>> filters should just be a special kind of mapping rules. I can image in >>>>>>> syntax like: . I >>>>>>> think the difficult part with the LDAP filters will to define sensible >>>>>>> templates. >>>>>> >>>>>> I'm not sure I understand. Could you please elaborate a little bit? >>>>> >>>>> A LDAP search filter which would cover the AD behavior would look like: >>>>> >>>>> (|(altSecurityIdentities=%A%B)(userPrincipalName=%C)(samAccountName=%D)) >>>>> >>>>> where >>>>> >>>>> %A: must be replaced with the issuer of the certificate in X.500 order >>>>> %B: must be replaced with the subject of the certificate in X.500 order >>>>> >>>>> it would be possible of course to use a specific template here which >>>>> would generate the complete search attribute value. >>>>> >>>>> %C: must be replaced by the principal from AD's SAN >>>>> szOID_NT_PRINCIPAL_NAME >>>>> %D: must be replaced with only then name component (the part before the >>>>> realm) of the principal from szOID_NT_PRINCIPAL_NAME >>>>> >>>>> As %C and %D imply this filter will only work for certificates which >>>>> have szOID_NT_PRINCIPAL_NAME but for those it must be used to be >>>>> compatible with AD. For certificates without >>>>> >>>>> (altSecurityIdentities=%A%B) >>>>> >>>>> is sufficient. It is possible to select the right filter with matching >>>>> rules. >>>> >>>> Right. >>>> >>>>> >>>>> So we have to find suitable names for the %A, %B, %C and %D templates >>>>> and also allow different representations (e.g. LDAP or X.500 order for >>>>> DNs). >>>> >>>> I would personally prefer if we used Python-style formatting strings for the >>>> templates, I find them much more pleasant to work with than C-style >>> >>> sure, I used %A etc as arbitrary templates, I didn't wanted to imply >>> that C-style syntax should be used. >>> >>>> formatting strings. The filter which covers AD behavior could be written as: >>>> >>>> >>>> (|(altSecurityIdentities={issuer_dn!x500}{subject_dn!x500})(userPrincipalName={subject_nt_principal})(samAccountName={subject_nt_principal.name})) >>> >>> I think this is quite readable and understandable to an admin with basic >>> knowledge of LDAP search filters and certificate components. Are the >>> names used here (issuer_dn, subject_dn, subject_nt_principal) already >>> used by e.g. some Python modules or do we have to define the list of >>> names? >> >> They are not defined anywhere, it's just something I came up with. >> >>> >>> If there a reason for using '!x500' to indicate X500 ordering? Wouldn't >>> e.g. issuer_dn.x500 work as well similar to Python's str.lower()? Having >>> only one symbol to indicate a special formatting of the value from the >>> certificate would make the syntax easier to learn. >> >> I tried to follow the Python convention, where '.' is used for attribute >> access and '!' for value conversion. In other words, '.' selects a component >> of the value and '!' takes the whole value and formats it in a certain way. > > ok, makes sense. > >> >>> >>>> >>>>> >>>>>> >>>>>>> But as long as we keep the general mapping rule syntax >>>>>>> flexible the LDAP filter rules can be added in a later version. >>>>>> >>>>>> IMHO it should be the other way round and LDAP filters should be implemented >>>>>> first, as they offer all the flexibility we need (all of the other fields >>>>>> can be easily implemented on top of LDAP filters) and are by default >>>>>> extensible without having to update servers and clients. >>>>> >>>>> In general I agree, as long we can find a suitable scheme to handle the >>>>> templates to add content from the certificate in a specific format to >>>>> the search filters. >>>>> >>>>> But from the user/admin perspective there should be special rules for >>>>> common use-cases which do not require to know too much details about >>>>> certificates and LDAP trees. E.g. for AD (either via direct or indirect >>>>> integration) there should be a rule which just does all which >>>>> AD would do depending on the certificate type. For IPA something like >>>>> might be a good start for handling external >>>>> certificates which do not contain user specific data which can be mapped >>>>> to user object because the syntax is already known from AD. >>>> >>>> This could be handled in the IPA plugin by converting from the user-friendly >>>> representation to LDAP filter template internally when a mapping rule is >>>> added or modified. >>> >>> Yes, but it can also be expanded by the component/library which will >>> replace the templates with the actual values from the certificate. This >>> would have the befit that the user-friendly representation is visible >>> even with low-level LDAP commands? >> >> That's true (although I can't imagine why would anyone look on the LDAP >> entries directly, especially if they didn't understand LDAP filters), but >> IMHO it lacks certain elegancy by having more than one way to define the >> same rule, more code paths to handle the rules, etc. >> >> Additionally, LDAP filters provide better forward compatiblity - if we had >> to add support for a new mapping style in the future, with LDAP filters only >> the IPA server would have to be updated, without LDAP filters we would also >> have to worry about updating old clients which do not understand the new >> mapping style. > > ok, but if the new mapping style introduces some new templates or > formatting options the clients must be updated as well. Right, the forward compatibility of LDAP filters is limited only to LDAP attribute names. When a new template or formatting option is added, the clients will have to be updated no matter which rule style we go with. > > bye, > Sumit > >> >>> >>> bye, >>> Sumit >>> >>>> >>>>> >>>>>> >>>>>>> >>>>>>> * enable/disable: I think this is a good idea and would be consistent >>>>>>> with other rules like HBAC and sudo >>>>>>> >>>>>>> * user-{add/mod} LOGIN --certmappingdata DATA: I think it might be >>>>>>> better to not add this option and only implement the >>>>>>> 'user-{add/remove}-certmapping' commands >>>>>>> >>>>>>> * user-{add/remove}-certmapping: you say '... almost any type of mapping, >>>>>>> or a more user-friendly API ...'. I would not say 'or' but 'and' and >>>>>>> implement both >>>>>>> >>>>>>> * ipaCertMappingEnableMismatch and ipaCertMappingAlternateIdAttribute; I >>>>>>> think both are note needed, see above >>>>>>> >>>>>>> * altSecurityIdentities: I would prefer to use a different name and OID. >>>>>>> Using the same definition as AD would imo imply that it can be used in >>>>>>> the same way as in AD. But e.g. AD also supports other content like >>>>>>> KERBEROS:alternative_user_principal at AD.DOMAIN which we will not >>>>>>> support. >>>>>>> >>>>>>> * issuerName vs ipaCAIssuerDN: I would prefer issuerName because it is >>>>>>> general UTF-8 and not DN syntax (1.3.6.1.4.1.1466.115.121.1.12). Since >>>>>>> the issuer DN in general will not be a DN from the local LDAP tree I >>>>>>> think the UTF-8 version fits better. >>>>>> >>>>>> I think it's worth mentioning that if the attribute used DN syntax and >>>>>> matching, we wouldn't have to worry about normalizing the issuer name before >>>>>> searching for it, as DS would do that for us. >>>>> >>>>> Good point, but I think the main use case for this attribute is on the >>>>> client side to determine if a rule should be applied to a certificate or >>>>> not. So I guess LDAP searches with this attribute would be rare because >>>>> the client will load all rules in one run. >>>>> >>>>>> >>>>>>> >>>>>>> * nsslapd-certmap-basedn, see DOMAINDN above >>>>>>> >>>>>>> * altSecurityIdentities example: X.500 ordering is used by AD here and >>>>>>> unfortunately I think we have to adopt it at least for this specific >>>>>>> usage, here is an ldapsearch output from AD: >>>>>>> >>>>>>> altSecurityIdentities: >>>>>>> X509:DC=devel,DC=ad,CN=ad-AD-SERVER-CADC=devel,DC >>>>>>> =ad,CN=Users,CN=t u,E=test.user at email.domain >>>>>>> altSecurityIdentities: X509:O=Red Hat,OU=prod,CN=Certificate >>>>>>> AuthorityDC >>>>>>> =com,DC=redhat,OU=users,OID.0.9.2342.19200300.100.1.1=sbose,E=sbose at redhat.co >>>>>>> m,CN=Sumit Bose Sumit Bose >>>>>>> >>>>>>> * Certificate Mapping Administrators or re-use Certificate >>>>>>> Administrators: I would prefer a new 'Certificate Mapping >>>>>>> Administrators' >>>>>>> >>>>>>> * Users can manage their own X.509 certificate mappings? I'm not sure >>>>>>> here, at the first glance I would say no. How are OTP tokens handled? >>>>>>> Maybe this would be a candidate for certmappingconfig-* option? >>>>>> >>>>>> I think a better question is "How is userCertificate handled?" >>>>>> >>>>>> Anyway, self-service permissions can be enabled/disabled, so there is really >>>>>> no need for a new certmappingconfig option. >>>>> >>>>> Yes, this makes sense. >>>>> >>>>> bye, >>>>> Sumit >>>>>> >>>>>>> >>>>>>> That's all :-) >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jan Cholasta >>>> >>>> >>>> -- >>>> Jan Cholasta >> >> >> -- >> Jan Cholasta -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Jan 9 08:07:33 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 09 Jan 2017 09:07:33 +0100 Subject: [Freeipa-devel] [freeipa PR#363][+ack] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Label: +ack From freeipa-github-notification at redhat.com Mon Jan 9 08:08:15 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 09 Jan 2017 09:08:15 +0100 Subject: [Freeipa-devel] [freeipa PR#363][comment] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d15ccde20fcc97a597180255ee9f5eb38caa206c """ See the full comment at https://github.com/freeipa/freeipa/pull/363#issuecomment-271228271 From freeipa-github-notification at redhat.com Mon Jan 9 08:08:17 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 09 Jan 2017 09:08:17 +0100 Subject: [Freeipa-devel] [freeipa PR#363][+pushed] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 9 08:08:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 09 Jan 2017 09:08:19 +0100 Subject: [Freeipa-devel] [freeipa PR#363][closed] ipaclient: schema cache: Handle malformed server info data gracefully In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/363 Author: dkupka Title: #363: ipaclient: schema cache: Handle malformed server info data gracefully Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/363/head:pr363 git checkout pr363 From freeipa-github-notification at redhat.com Mon Jan 9 09:05:46 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Mon, 09 Jan 2017 10:05:46 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values gkaihorodova commented: """ Thank you for review! """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-271236642 From bind-dyndb-ldap-github-notification at redhat.com Mon Jan 9 09:34:44 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 10:34:44 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#7][opened] Added named.conf API transformation script to spec Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/7 Author: tomaskrizek Title: #7: Added named.conf API transformation script to spec Action: opened PR body: """ A script that converts old-style configuration API of named.conf to the new-style API after rpm isntallation was added to contrib specfile. Required version of BIND was also bumped to 9.11. """ To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/7/head:pr7 git checkout pr7 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-7.patch Type: text/x-diff Size: 2550 bytes Desc: not available URL: From bind-dyndb-ldap-github-notification at redhat.com Mon Jan 9 09:48:28 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 10:48:28 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#7][comment] Added named.conf API transformation script to spec In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/7 Title: #7: Added named.conf API transformation script to spec tomaskrizek commented: """ This patch is meant to fix existing IPA installations when they're upgraded to use BIND-9.11. New IPA installations are covered by freeipa/freeipa#351 The script is written in sed. I added some inline comments for better clarity. """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/7#issuecomment-271244266 From freeipa-github-notification at redhat.com Mon Jan 9 10:44:03 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 09 Jan 2017 11:44:03 +0100 Subject: [Freeipa-devel] [freeipa PR#378][opened] Integrate make check into CI Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Author: tiran Title: #378: Integrate make check into CI Action: opened PR body: """ make check runs cmocka tests for our C code. The patch also adds some additional files to gitignore and cleanup. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/378/head:pr378 git checkout pr378 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-378.patch Type: text/x-diff Size: 1930 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 10:47:17 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 09 Jan 2017 11:47:17 +0100 Subject: [Freeipa-devel] [freeipa PR#379][opened] Packaging: Add placeholder and IPA commands packages Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Author: tiran Title: #379: Packaging: Add placeholder and IPA commands packages Action: opened PR body: """ The ipacommands package contains ipa-getkeytab and ipa-rmkeytab for installation in a virtual env. The programs are compiled with distutils / setuptools. The ipa and freeipa packages are placeholders to prevent PyPI squashing attacks and reserve the names for future use. `pip install ipa` installs ipaclient. https://fedorahosted.org/freeipa/ticket/6484 Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/379/head:pr379 git checkout pr379 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-379.patch Type: text/x-diff Size: 17442 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 11:06:26 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 12:06:26 +0100 Subject: [Freeipa-devel] [freeipa PR#351][synchronized] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Author: tomaskrizek Title: #351: [fedora-26] named.conf template: update API for bind 9.11 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/351/head:pr351 git checkout pr351 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-351.patch Type: text/x-diff Size: 4122 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 11:09:58 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 12:09:58 +0100 Subject: [Freeipa-devel] [freeipa PR#351][comment] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Title: #351: [fedora-26] named.conf template: update API for bind 9.11 tomaskrizek commented: """ Required version of BIND is a subject to change. When a version with fixed `named-pkcs11` issue ([BZ 1410433](https://bugzilla.redhat.com/show_bug.cgi?id=1410433)) is released, I will update it. Patch should not be merged until then. """ See the full comment at https://github.com/freeipa/freeipa/pull/351#issuecomment-271259526 From freeipa-github-notification at redhat.com Mon Jan 9 11:34:54 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 12:34:54 +0100 Subject: [Freeipa-devel] [freeipa PR#380][opened] Travis CI: actually return non-zero exit status when the test job fails Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Author: martbab Title: #380: Travis CI: actually return non-zero exit status when the test job fails Action: opened PR body: """ Thanks to @stlaz for catching this. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/380/head:pr380 git checkout pr380 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-380.patch Type: text/x-diff Size: 1707 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 12:27:31 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 13:27:31 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions tomaskrizek commented: """ Please see my feedback in in-line comments. """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-271272632 From freeipa-github-notification at redhat.com Mon Jan 9 12:50:42 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 13:50:42 +0100 Subject: [Freeipa-devel] [freeipa PR#380][comment] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails stlaz commented: """ It works but for some reason there are many extra newlines in the failure log """ See the full comment at https://github.com/freeipa/freeipa/pull/380#issuecomment-271276855 From freeipa-github-notification at redhat.com Mon Jan 9 13:12:04 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 14:12:04 +0100 Subject: [Freeipa-devel] [freeipa PR#380][comment] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails stlaz commented: """ It works but for some reason there are many extra newlines in the failure log """ See the full comment at https://github.com/freeipa/freeipa/pull/380#issuecomment-271276855 From freeipa-github-notification at redhat.com Mon Jan 9 13:12:07 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 14:12:07 +0100 Subject: [Freeipa-devel] [freeipa PR#380][+ack] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails Label: +ack From freeipa-github-notification at redhat.com Mon Jan 9 13:12:19 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Mon, 09 Jan 2017 14:12:19 +0100 Subject: [Freeipa-devel] [freeipa PR#380][comment] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails stlaz commented: """ It works but for some reason there are many extra newlines in the failure log **edit:** nvm, displayes correctly now, apparently it's a Travis streaming issue. ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/380#issuecomment-271276855 From freeipa-github-notification at redhat.com Mon Jan 9 13:29:21 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 14:29:21 +0100 Subject: [Freeipa-devel] [freeipa PR#380][synchronized] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Author: martbab Title: #380: Travis CI: actually return non-zero exit status when the test job fails Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/380/head:pr380 git checkout pr380 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-380.patch Type: text/x-diff Size: 844 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 14:23:12 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 15:23:12 +0100 Subject: [Freeipa-devel] [freeipa PR#380][+pushed] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 9 14:23:14 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 15:23:14 +0100 Subject: [Freeipa-devel] [freeipa PR#380][closed] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Author: martbab Title: #380: Travis CI: actually return non-zero exit status when the test job fails Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/380/head:pr380 git checkout pr380 From freeipa-github-notification at redhat.com Mon Jan 9 14:23:15 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 15:23:15 +0100 Subject: [Freeipa-devel] [freeipa PR#380][comment] Travis CI: actually return non-zero exit status when the test job fails In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/380 Title: #380: Travis CI: actually return non-zero exit status when the test job fails martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/9b5b7131502a73fa24dc56c72a9648528c5aceee """ See the full comment at https://github.com/freeipa/freeipa/pull/380#issuecomment-271296037 From freeipa-github-notification at redhat.com Mon Jan 9 14:35:39 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Mon, 09 Jan 2017 15:35:39 +0100 Subject: [Freeipa-devel] [freeipa PR#374][+ack] pytest: set rules to find test files and functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Title: #374: pytest: set rules to find test files and functions Label: +ack From freeipa-github-notification at redhat.com Mon Jan 9 15:52:11 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 09 Jan 2017 16:52:11 +0100 Subject: [Freeipa-devel] [freeipa PR#179][comment] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig tomaskrizek commented: """ I investigated some other options for the displayed error message, but I haven't found anything more appropriate. [Comment#4](https://fedorahosted.org/freeipa/ticket/5244#comment:4) in the ticket says the message should mention an SSSD restart issue. Perhaps someone else has a suggestion for a more descriptive message then `Failed to execute authconfig command`? If this message is fine, the code has an ack. """ See the full comment at https://github.com/freeipa/freeipa/pull/179#issuecomment-271320161 From freeipa-github-notification at redhat.com Mon Jan 9 16:29:55 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 17:29:55 +0100 Subject: [Freeipa-devel] [freeipa PR#381][opened] disable hostname canonicalization by Kerberos library Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Author: martbab Title: #381: disable hostname canonicalization by Kerberos library Action: opened PR body: """ By default, Kerberos client library attempts to canonicalize service hostname in TGS requests. This can fail e.g. if hosts file on the client machine references short names before FQDNs. In this case the short name is used in TGS_REQ which KDC fails to resolve. Since we do not (yet) support referencing hosts by their short names it is safe to just disable this behavior in krb5.conf and use supplied FQDNs. https://fedorahosted.org/freeipa/ticket/6584 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/381/head:pr381 git checkout pr381 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-381.patch Type: text/x-diff Size: 1272 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 16:38:42 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 09 Jan 2017 17:38:42 +0100 Subject: [Freeipa-devel] [freeipa PR#378][comment] Integrate make check into CI In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Title: #378: Integrate make check into CI martbab commented: """ IIRC cmocka tests are already ran as a part of build process, seee the following excerpt from the build log: ``` PASS: ipa_kdb_tests ============================================================================ Testsuite summary for freeipa 4.4.90.dev201701091412+git5dd9c32 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ ``` I am not sure if we need to run them as a separate step right now. """ See the full comment at https://github.com/freeipa/freeipa/pull/378#issuecomment-271334743 From freeipa-github-notification at redhat.com Mon Jan 9 18:48:31 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 09 Jan 2017 19:48:31 +0100 Subject: [Freeipa-devel] [freeipa PR#382][opened] [WIP] Py3 ipa-server-install fixes Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [WIP] Py3 ipa-server-install fixes Action: opened PR body: """ This PR should allow to install server with py3 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 8860 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 9 18:50:44 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 09 Jan 2017 19:50:44 +0100 Subject: [Freeipa-devel] [freeipa PR#383][opened] Remove duplicated step from DS install Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Author: mbasti-rh Title: #383: Remove duplicated step from DS install Action: opened PR body: """ "Adding SASL mappings.." is duplicated step in __common_setup in DS instance and should be removed. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/383/head:pr383 git checkout pr383 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-383.patch Type: text/x-diff Size: 1063 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 04:32:49 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 10 Jan 2017 05:32:49 +0100 Subject: [Freeipa-devel] [freeipa PR#384][opened] Add fix for user prompt in dnsrecord-add Message-ID: URL: https://github.com/freeipa/freeipa/pull/384 Author: Akasurde Title: #384: Add fix for user prompt in dnsrecord-add Action: opened PR body: """ Fix added to skip optional parameter in dnsrecord-add interactive prompts Fixes https://fedorahosted.org/freeipa/ticket/6457 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/384/head:pr384 git checkout pr384 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-384.patch Type: text/x-diff Size: 901 bytes Desc: not available URL: From jcholast at redhat.com Tue Jan 10 06:58:12 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Jan 2017 07:58:12 +0100 Subject: [Freeipa-devel] CSR autogeneration next steps In-Reply-To: <77684b8f-c0f5-b1ad-cf7c-075184b5ee39@redhat.com> References: <4d31f26b-e332-7362-2b8e-3382a0109067@redhat.com> <2ac0c9af-ef4a-65fe-0cb9-2d161bb7eba0@redhat.com> <77684b8f-c0f5-b1ad-cf7c-075184b5ee39@redhat.com> Message-ID: <71e4dec2-dde8-1cf5-c4cf-399e70f5c60d@redhat.com> On 19.12.2016 21:59, Ben Lipton wrote: > > On 12/15/2016 11:11 PM, Ben Lipton wrote: >> >> On 12/12/2016 03:52 AM, Jan Cholasta wrote: >>> On 5.12.2016 16:48, Ben Lipton wrote: >>>> Hi Jan, thanks for the comments. >>>> >>>> >>>> On 12/05/2016 04:25 AM, Jan Cholasta wrote: >>>>> Hi Ben, >>>>> >>>>> On 3.11.2016 00:12, Ben Lipton wrote: >>>>>> Hi everybody, >>>>>> >>>>>> Soon I'm going to have to reduce the amount of time I spend on new >>>>>> development work for the CSR autogeneration project, and I want to >>>>>> leave >>>>>> the project in as organized a state as possible. So, I'm taking >>>>>> inventory of the work I've done in order to make sure that what's >>>>>> ready >>>>>> for review can get reviewed and the ideas that have been discussed >>>>>> get >>>>>> prototyped or at least recorded so they won't be forgotten. >>>>> >>>>> Thanks, I have some questions and comments, see below. >>>>> >>>>>> >>>>>> Code that's ready for review (I will continue to put in as much >>>>>> time as >>>>>> needed to help get these ready for submission): >>>>>> >>>>>> - Current PR: https://github.com/freeipa/freeipa/pull/10 >>>>> >>>>> How hard would it be to update the PR to use the "new" interface from >>>>> the design thread? By this I mean that currently there is a command >>>>> (cert_get_requestdata), which creates a CSR from profile id + >>>>> principal + helper, but in the design we discussed a command which >>>>> creates a CertificationRequestInfo from profile id + principal + >>>>> public key. >>>>> >>>>> Internally it could use the OpenSSL helper, no need to implement the >>>>> full "new" design. With your build_requestinfo.c code below it looks >>>>> like it should be pretty straightforward. >>>> >>>> This is probably doable with the cffi, but I'm concerned about >>>> usability. A user can run the current command to get a (reusable) >>>> script, and run the script to get a CSR. It works with keys in both PEM >>>> files and NSS databases already. If we change to outputting a >>>> CertificationRequestInfo, in order to make this usable on the command >>>> line, we'll need: >>>> - An additional tool to sign a CSR given a CertificationRequestInfo >>>> (for >>>> both types of key storage). >>>> - A way to extract a SubjectPublicKeyInfo structure from a key within >>>> the ipa command (like [1] but we need it for both types of key storage) >>>> Since as far as I know there's no standard encoding for files >>>> containing >>>> only a CertificationRequestInfo or a SubjectPublicKeyInfo, we'll be >>>> writing and distributing these ourselves. I think that's where most of >>>> the extra work will come in. >>> >>> For PEM files, this is easily doable using python-cryptography (to >>> extract SubjectPublicKeyInfo and sign CertificationRequestInfo) and >>> PyASN1 (to create a CSR from the CertificationRequestInfo and the >>> signature). >> >> I didn't realize that python-cryptography knew about >> SubjectPublicKeyInfo structures, but indeed this seems to be pretty >> straightforward: >> >> key = load_pem_private_key(key_bytes, None, default_backend()) >> pubkey_info = key.public_key().public_bytes(Encoding.DER, >> PublicFormat.SubjectPublicKeyInfo) >> >> Thanks for letting me know this functionality already existed. >>> >>> For NSS databases, this will be trickier and will require calling C >>> functions, as neither certutil nor python-nss provide a way to a) >>> address existing keys in the database by key ID b) get >>> SubjectPublicKeyInfo for a given key. This can be worked around by: 1. Generating a key + temporary certificate: n=$(head -c 40 /dev/urandom | base32) certutil -S -n $n -s CN=$n -x -t ,, 2. Extracting the public key from the certificate: certutil -L -n $n -a >temp.crt (extract the public key using python-cryptography) 3. Deleting the temporary certificate: certutil -D -n $n 4. Importing the newly issued certificate: certutil -A -n $n -t ,, -a >> >>> As for encoding, the obvious choice is DER. It does not really matter >>> there is no standard file format, as we won't be transferring these >>> as files anyway. >> >> Agreed. I just meant there aren't tools already because this isn't a >> type of file one often needs to process. >>> >>>> >>>> Would it be ok to stick with the current design in this PR? I'd feel >>>> much better if we could get the basic functionality into the repo and >>>> then iterate on it rather than changing the plan at this point. I can >>>> create a separate PR to change cert_get_requestdata to this new >>>> interface and at the same time add the necessary adapters (bullet >>>> points >>>> above) to make it user-friendly. >>> >>> Works for me. >> >> Updated the PR to fix conflicts with master. Had some trouble with CI >> but creating a new PR with the same commits fixed it >> (https://github.com/freeipa/freeipa/pull/337). Not sure if it's fixed >> permanently, so I guess I'll just keep the two PRs synchronized now, >> or we could close the old one. You can close the old one. Just to make sure we are on the same page, you want this PR to be merged before submitting additional PRs built on top of it? >>> >>>> >>>> I would probably just implement the adapters within the >>>> cert_build/cert_request client code unless you think having standalone >>>> tools is valuable. I suppose certmonger is going to need these features >>>> too, but I don't know how well sharing code between them is going to >>>> work. >>> >>> cert-request is exactly the place where it should be :-) I wouldn't >>> bother with certmonger until we have a server-side csrgen. >>> >>>>> >>>>>> >>>>>> - Allow some fields to be specified by the user at creation time: >>>>>> https://github.com/LiptonB/freeipa/commits/local-user-data >>>>> >>>>> Good idea :-) >>>>> >>>>>> >>>>>> - Automation for the full process from getting CSR data to requesting >>>>>> cert: https://github.com/LiptonB/freeipa/commits/local-cert-build >>>>> >>>>> LGTM, although I would prefer if this was a client-side extension of >>>>> cert-request rather than a completely new command. >>>> >>>> I did try that at first, but I struggled to figure out the interface >>>> for >>>> the modified cert-request. (Not that the current solution is so great, >>>> what with the copying of options from cert_request and certreq.) If I >>>> remember correctly, I was uncertain how to implement parameters that >>>> are >>>> required/invalid based on other parameters: the current cert-request >>>> takes a signed CSR (required), a principal (required), and a profile >>>> ID; >>>> the new cert-request (what I implemented as cert-build) takes a >>>> principal (required), a profile ID (required), and a key location >>>> (required). I can't remember if that was the only problem, but I'll try >>>> again to merge the commands and get back to you. >>> >>> To make the CSR argument optional on the client, you can do this: >>> >>> def get_options(self): >>> for option in super(cert_request, self).get_options(): >>> if option.name == 'csr': >>> option = option.clone(required=False) >>> yield >>> >>> IMO profile ID should default to caIPAserviceCert on the client as well. >> >> I originally had it doing so, but changed it to a required option >> based on feedback in this email: >> https://www.redhat.com/archives/freeipa-devel/2016-August/msg00021.html: >> "In general use I think that 'caIPAserviceCert' is unlikely to be used >> a majory of the time, and it is a new command so there are no >> compatibility issues; therefore why not make the profile option >> mandatory?" I guess since we're talking about cert-request now, the >> compatibility issues are back. >> >> https://github.com/LiptonB/freeipa/commits/local-cert-build has now >> been updated to change the cert_request command rather than adding a >> new command. It seems to work now (thanks for the advice on making the >> argument optional), the only thing I'm having trouble with is the >> default for the profile_id argument. Previously, the default was >> applied by this code in cert_request.execute: >> >> profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) >> >> But now, in the client, I need the default to pass to >> cert_get_requestdata if no profile is specified. I'm not sure I can >> access backends from the client to get it the same way the server code >> does. Should I just import ipapython/dogtag.py and use the >> DEFAULT_PROFILE set in there? Is there a way I can give the option a >> default that will be seen in both the server and the client? >>> >>>>> >>>>>> >>>>>> Other prototypes and design ideas that aren't ready for submission >>>>>> yet: >>>>>> >>>>>> - Utility written in C to build a CertificationRequestInfo from a >>>>>> SubjectPublicKeyInfo and an openssl-style config file. The purpose of >>>>>> this is to take a config that my code already knows how to >>>>>> generate, and >>>>>> put it in a form that certmonger can use. This is nearly done and >>>>>> available at: >>>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/build_requestinfo.c >>>>>> >>>>>> >>>>> >>>>> Nice! As I said above, this could really make implementing the "new" >>>>> csrgen interface simple. >>>>> >>>>>> >>>>>> >>>>>> - Ideally it should be possible to use this tool to reimplement >>>>>> the full >>>>>> cert-request automation (local-cert-build branch) without a >>>>>> dependency >>>>>> on the certutil/openssl tools. However, I don't think any of the >>>>>> python >>>>>> crypto libraries have bindings for the functions that deal with >>>>>> CertificationRequestInfo objects, so I don't think I can do this >>>>>> in the >>>>>> short term. >>>>> >>>>> You can use python-cffi to write your own minimal bindings. It's >>>>> fairly straightforward, take a look at FreeIPA commit 500ee7e2 for an >>>>> example of how to port C code to Python with python-cffi. >>>> >>>> Thank you for the example. I will take a look. >>>>> >>>>>> >>>>>> - Certmonger "helper" program that takes in the >>>>>> CertificationRequestInfo >>>>>> that certmonger generates, calls out to IPA for profile-specific >>>>>> data, >>>>>> and returns an updated CertificationRequestInfo built from the data. >>>>>> Certmonger doesn't currently support this type of helper, but (if I >>>>>> understood correctly) this is the architecture Nalin believed >>>>>> would be >>>>>> simplest to fit in. This is not done yet, but I intend to complete it >>>>>> soon - it shouldn't require much code beyond what's in >>>>>> build_requestinfo.c. >>>>> >>>>> To me this sounds like it should be a new operation of the current >>>>> helper rather than a completely new helper. >>>> >>>> Maybe so. I certainly wouldn't call this a finished design, I just >>>> wanted to have some kind of proof of concept for how the certmonger >>>> integration could work. For what it's worth, that prototype is now >>>> available at [2]. >>> >>> OK. >>> >>>>> >>>>> Anyway, the ultimate goal is to move the csrgen code to the server, >>>>> which means everything the helper will have to do is call a command >>>>> over RPC. >>>>> >>>>>> >>>>>> - Tool to convert an XER-encoded cert extension to DER, given the >>>>>> ASN.1 >>>>>> description of the extension. This would unblock Jan Cholasta's >>>>>> idea of >>>>>> using XSLT for templates rather than text-based formatting. I >>>>>> should be >>>>>> able to implement the conversion tool, but it may be a while before I >>>>>> have time to demo the full XSLT idea. >>>>> >>>>> Was there any progress on this? >>>> >>>> I have started working on implementing it with asn1c, and I'm already >>>> seeing some of the inconvenience (security issues aside) of building on >>>> the server. Libtasn1 seems like a much better model, but doesn't >>>> seem to >>>> have XER support. Anyway, don't quite have results here yet but I think >>>> I should have the XER->DER demo with asn1c ready in a week or two. >>> >>> Implementing XER codec on top of libtasn1 shouldn't be too hard; I >>> have a WIP which I will post soon. > > It took me some experimentation to get this to work, but the solution > with asn1c is actually quite simple because the tool automatically > provides a sample C file that converts between different formats. So, > this very basic shell script is able to do the conversion: > https://github.com/LiptonB/freeipa-prototypes/blob/master/xer2der.sh > > $ cat ExtKeyUsage.xer > > 1.3.6.1.5.5.7.3.2 > 1.3.6.1.5.5.7.3.4 > > > $ cat KeyUsage.asn1 > KUModule DEFINITIONS ::= > BEGIN > > KeyUsage ::= BIT STRING { > digitalSignature (0), > nonRepudiation (1), -- recent editions of X.509 have > -- renamed this bit to contentCommitment > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId > > KeyPurposeId ::= OBJECT IDENTIFIER > > END > > $ ./xer2der.sh KeyUsage.asn1 ExtKeyUsageSyntax ExtKeyUsage.xer > 2>/dev/null | xxd > 00000000: 3014 0608 2b06 0105 0507 0302 0608 2b06 0...+.........+. > 00000010: 0105 0507 0304 ...... So far I don't have a working example using libtasn1. I have something close to it, but it's hacky, as the libtasn1 API is pretty limited, and I didn't have time to work on it in the last few weeks. > >>> >>>>> >>>>>> >>>>>> So: currently on my to do list are the certmonger helper and the >>>>>> XER->DER conversion tool. Do you have any comments about these plans, >>>>>> and is there anything else I can do to wrap up the project neatly? >>>>>> >>>>>> Thanks, >>>>>> Ben >>>>>> >>>>> >>>>> Honza >>>>> >>>> [1] >>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/key2spki.c >>>> [2] >>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/cm_ipa_csrgen.c >>>> >>> >> > -- Jan Cholasta From mbabinsk at redhat.com Tue Jan 10 09:48:08 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Tue, 10 Jan 2017 10:48:08 +0100 Subject: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication In-Reply-To: <20170106080804.GP4539@dhcp-40-8.bne.redhat.com> References: <20170106080804.GP4539@dhcp-40-8.bne.redhat.com> Message-ID: <2f2b8dd8-3b96-2b90-fa39-c2c1c45e438a@redhat.com> Hi Fraser, I have some rather inane comments. I guess Jan cholasta will do a more thorough review of your design. See below: On 01/06/2017 09:08 AM, Fraser Tweedale wrote: > Hi comrades, > > I have written up the high-level details of the FreeIPA->Dogtag > GSS-API authentication design. The goal is improve security by > removing an egregious privilege separation violation: the RA Agent > cert. > > There is a fair bit of work still to do on the Dogtag side but > things are shaping up there and it's time to work out the IPA > aspects. The design is at: > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication first of all, you link a internal document from publicly available design page. you should prepare a publicly visible version of the Dogtag-side design and link that. It would also be nice to have a high-level graphical representation of the proposed CSR processing workflow. I think you can re-use the one that is in the Dogtag part, omit the Dogtag internals and add IPA-specific parts. > > Right now, I need feedback about the Domain Level aspects: whether > it is the right approach, whether there are mechanisms to perform > update steps (specifically: LDAP updates and/or api calls) alongside > a DL bump, or if there aren't, how to deal with that (implement such > a mechanism, make admins do extra steps, ???). > Is the DL bump really necessary? Are you sure we really can not just update the profile configuration and let older Dogtag installation handle it gracefully? IIRC we have done some profile inclusion work in 4.2 development and on and never really bothered about older Dogtag understanding them. Anyway I guess we can call `certprofile-import' to load ExternalProcessConstraint-enabled profile upon setting domain level to 2, we just have to know where on the FS it is located. > Of course, any other general or specific feedback is welcome. > > Thanks, > Fraser > So if I understand correctly there will be no change in CA ACL management interface and only the code which evaluates them will be factored out into 'ipa-pki-validate-cert-request' command? Also, wouldn't it simpler if the CA ACL evaluation was delegated to a separate API command instead? ExternalProcessConstraint would then only ask IPA JSON api and process the response. -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Tue Jan 10 10:04:17 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 10 Jan 2017 11:04:17 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library tiran commented: """ One Travis job was failing, I restarted it. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271534967 From freeipa-github-notification at redhat.com Tue Jan 10 10:13:38 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 10 Jan 2017 11:13:38 +0100 Subject: [Freeipa-devel] [freeipa PR#245][comment] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN HonzaCholasta commented: """ * `--subject-base` and `--ca-subject` are not validated in `ipa-ca-install`. * Please squash "{ds,ca}instance: rename 'subject' to 'ca_subject'" into "Allow full customisability of IPA CA subject DN". * Please use the correct ticket URL in "Add sanity checks for use of --ca-subject and --subject-base". """ See the full comment at https://github.com/freeipa/freeipa/pull/245#issuecomment-271536923 From freeipa-github-notification at redhat.com Tue Jan 10 12:04:14 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 13:04:14 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 51900 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 12:13:50 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 13:13:50 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ In the last update I added SSLv2 support in IPAHTTPSConnection for backward compatibility (https://goo.gl/images/gqh2D9). I also removed the Fedora crypto policies ciphers as we are not supporting that right now and if we did, we should do that on server as well. There would perhaps be a ticket required. Also added a ticket to "Move RA agent certificate file export to a different location" as it fixes an issue with missing /etc/httpd/alias/kra-agent.pem as well. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-271560505 From freeipa-github-notification at redhat.com Tue Jan 10 12:16:31 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 13:16:31 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 51882 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 13:23:03 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Tue, 10 Jan 2017 14:23:03 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 17002 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 14:05:39 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Tue, 10 Jan 2017 15:05:39 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 17277 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 16:07:17 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 17:07:17 +0100 Subject: [Freeipa-devel] [freeipa PR#385][opened] Generate sha256 ssh pubkey fingerprints for hosts Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Author: stlaz Title: #385: Generate sha256 ssh pubkey fingerprints for hosts Action: opened PR body: """ Replace md5 with sha256 for host ssh pubkey fingerprints. MD5 is disabled in FIPS mode, newer versions of OpenSSH print SHA256 public key fingeprint anyway. https://fedorahosted.org/freeipa/ticket/5695 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/385/head:pr385 git checkout pr385 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-385.patch Type: text/x-diff Size: 5510 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 16:23:57 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 17:23:57 +0100 Subject: [Freeipa-devel] [freeipa PR#383][+ack] Remove duplicated step from DS install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Title: #383: Remove duplicated step from DS install Label: +ack From freeipa-github-notification at redhat.com Tue Jan 10 16:24:06 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 17:24:06 +0100 Subject: [Freeipa-devel] [freeipa PR#383][comment] Remove duplicated step from DS install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Title: #383: Remove duplicated step from DS install stlaz commented: """ The tests passed, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/383#issuecomment-271622092 From freeipa-github-notification at redhat.com Tue Jan 10 16:45:58 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 10 Jan 2017 17:45:58 +0100 Subject: [Freeipa-devel] [freeipa PR#385][synchronized] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Author: stlaz Title: #385: Generate sha256 ssh pubkey fingerprints for hosts Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/385/head:pr385 git checkout pr385 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-385.patch Type: text/x-diff Size: 5793 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 17:37:50 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 10 Jan 2017 18:37:50 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [WIP] Py3 ipa-server-install fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [WIP] Py3 ipa-server-install fixes Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 17576 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 17:48:47 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Tue, 10 Jan 2017 18:48:47 +0100 Subject: [Freeipa-devel] [freeipa PR#386][opened] Tests: Add tree root domain role in legacy client tests Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Author: gkaihorodova Title: #386: Tests: Add tree root domain role in legacy client tests Action: opened PR body: """ Legacy client tests inherits test cases from trust tests, that have role for tree root domain. That role was missing in legacy client tests. https://fedorahosted.org/freeipa/ticket/6600 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/386/head:pr386 git checkout pr386 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-386.patch Type: text/x-diff Size: 1783 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 10 22:31:57 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Tue, 10 Jan 2017 23:31:57 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 80943 bytes Desc: not available URL: From blipton at redhat.com Tue Jan 10 23:38:17 2017 From: blipton at redhat.com (Ben Lipton) Date: Tue, 10 Jan 2017 18:38:17 -0500 Subject: [Freeipa-devel] CSR autogeneration next steps In-Reply-To: <71e4dec2-dde8-1cf5-c4cf-399e70f5c60d@redhat.com> References: <4d31f26b-e332-7362-2b8e-3382a0109067@redhat.com> <2ac0c9af-ef4a-65fe-0cb9-2d161bb7eba0@redhat.com> <77684b8f-c0f5-b1ad-cf7c-075184b5ee39@redhat.com> <71e4dec2-dde8-1cf5-c4cf-399e70f5c60d@redhat.com> Message-ID: <547fedb7-9996-0264-edb4-a563c1f038cf@redhat.com> On 01/10/2017 01:58 AM, Jan Cholasta wrote: > On 19.12.2016 21:59, Ben Lipton wrote: >> >> On 12/15/2016 11:11 PM, Ben Lipton wrote: >>> >>> On 12/12/2016 03:52 AM, Jan Cholasta wrote: >>>> On 5.12.2016 16:48, Ben Lipton wrote: >>>>> Hi Jan, thanks for the comments. >>>>> >>>>> >>>>> On 12/05/2016 04:25 AM, Jan Cholasta wrote: >>>>>> Hi Ben, >>>>>> >>>>>> On 3.11.2016 00:12, Ben Lipton wrote: >>>>>>> Hi everybody, >>>>>>> >>>>>>> Soon I'm going to have to reduce the amount of time I spend on new >>>>>>> development work for the CSR autogeneration project, and I want to >>>>>>> leave >>>>>>> the project in as organized a state as possible. So, I'm taking >>>>>>> inventory of the work I've done in order to make sure that what's >>>>>>> ready >>>>>>> for review can get reviewed and the ideas that have been discussed >>>>>>> get >>>>>>> prototyped or at least recorded so they won't be forgotten. >>>>>> >>>>>> Thanks, I have some questions and comments, see below. >>>>>> >>>>>>> >>>>>>> Code that's ready for review (I will continue to put in as much >>>>>>> time as >>>>>>> needed to help get these ready for submission): >>>>>>> >>>>>>> - Current PR: https://github.com/freeipa/freeipa/pull/10 >>>>>> >>>>>> How hard would it be to update the PR to use the "new" interface >>>>>> from >>>>>> the design thread? By this I mean that currently there is a command >>>>>> (cert_get_requestdata), which creates a CSR from profile id + >>>>>> principal + helper, but in the design we discussed a command which >>>>>> creates a CertificationRequestInfo from profile id + principal + >>>>>> public key. >>>>>> >>>>>> Internally it could use the OpenSSL helper, no need to implement the >>>>>> full "new" design. With your build_requestinfo.c code below it looks >>>>>> like it should be pretty straightforward. >>>>> >>>>> This is probably doable with the cffi, but I'm concerned about >>>>> usability. A user can run the current command to get a (reusable) >>>>> script, and run the script to get a CSR. It works with keys in >>>>> both PEM >>>>> files and NSS databases already. If we change to outputting a >>>>> CertificationRequestInfo, in order to make this usable on the command >>>>> line, we'll need: >>>>> - An additional tool to sign a CSR given a CertificationRequestInfo >>>>> (for >>>>> both types of key storage). >>>>> - A way to extract a SubjectPublicKeyInfo structure from a key within >>>>> the ipa command (like [1] but we need it for both types of key >>>>> storage) >>>>> Since as far as I know there's no standard encoding for files >>>>> containing >>>>> only a CertificationRequestInfo or a SubjectPublicKeyInfo, we'll be >>>>> writing and distributing these ourselves. I think that's where >>>>> most of >>>>> the extra work will come in. >>>> >>>> For PEM files, this is easily doable using python-cryptography (to >>>> extract SubjectPublicKeyInfo and sign CertificationRequestInfo) and >>>> PyASN1 (to create a CSR from the CertificationRequestInfo and the >>>> signature). >>> >>> I didn't realize that python-cryptography knew about >>> SubjectPublicKeyInfo structures, but indeed this seems to be pretty >>> straightforward: >>> >>> key = load_pem_private_key(key_bytes, None, default_backend()) >>> pubkey_info = key.public_key().public_bytes(Encoding.DER, >>> PublicFormat.SubjectPublicKeyInfo) >>> >>> Thanks for letting me know this functionality already existed. I'm currently working on the step of signing the CertificationRequestInfo and creating a CSR from it. I think I have it working with pyasn1, but of course the "signature algorithm" for the CSR needs to be specified and implemented within the code since I'm not using a library that understands CSRs natively. The code I have currently always produces CSRs with the sha256WithRSAEncryption algorithm (DER-encode request info, SHA256, PKCS #1v1.5 padding, RSA encryption), and the OID for that algorithm is hardcoded in the output CSR. Is this ok or will we need more flexibility than that? >>>> >>>> For NSS databases, this will be trickier and will require calling C >>>> functions, as neither certutil nor python-nss provide a way to a) >>>> address existing keys in the database by key ID b) get >>>> SubjectPublicKeyInfo for a given key. > > This can be worked around by: > > 1. Generating a key + temporary certificate: > > n=$(head -c 40 /dev/urandom | base32) > certutil -S -n $n -s CN=$n -x -t ,, > > 2. Extracting the public key from the certificate: > > certutil -L -n $n -a >temp.crt > (extract the public key using python-cryptography) > > 3. Deleting the temporary certificate: > > certutil -D -n $n > > 4. Importing the newly issued certificate: > > certutil -A -n $n -t ,, -a Oof, thanks, I'm not sure I would have been able to come up with that. Can you generate a key without a temporary certificate if you use the NSS API, or does their model require every key to belong to a cert? >>>> >>>> As for encoding, the obvious choice is DER. It does not really matter >>>> there is no standard file format, as we won't be transferring these >>>> as files anyway. >>> >>> Agreed. I just meant there aren't tools already because this isn't a >>> type of file one often needs to process. >>>> >>>>> >>>>> Would it be ok to stick with the current design in this PR? I'd feel >>>>> much better if we could get the basic functionality into the repo and >>>>> then iterate on it rather than changing the plan at this point. I can >>>>> create a separate PR to change cert_get_requestdata to this new >>>>> interface and at the same time add the necessary adapters (bullet >>>>> points >>>>> above) to make it user-friendly. >>>> >>>> Works for me. >>> >>> Updated the PR to fix conflicts with master. Had some trouble with CI >>> but creating a new PR with the same commits fixed it >>> (https://github.com/freeipa/freeipa/pull/337). Not sure if it's fixed >>> permanently, so I guess I'll just keep the two PRs synchronized now, >>> or we could close the old one. > > You can close the old one. > > Just to make sure we are on the same page, you want this PR to be > merged before submitting additional PRs built on top of it? Yes, I would like to merge this one to have as a starting point if you're comfortable with it: https://github.com/freeipa/freeipa/pull/337. I just did a force push to clean up the history, but the final diff should be the same as it was before. > >>>> >>>>> >>>>> I would probably just implement the adapters within the >>>>> cert_build/cert_request client code unless you think having >>>>> standalone >>>>> tools is valuable. I suppose certmonger is going to need these >>>>> features >>>>> too, but I don't know how well sharing code between them is going to >>>>> work. >>>> >>>> cert-request is exactly the place where it should be :-) I wouldn't >>>> bother with certmonger until we have a server-side csrgen. >>>> >>>>>> >>>>>>> >>>>>>> - Allow some fields to be specified by the user at creation time: >>>>>>> https://github.com/LiptonB/freeipa/commits/local-user-data >>>>>> >>>>>> Good idea :-) >>>>>> >>>>>>> >>>>>>> - Automation for the full process from getting CSR data to >>>>>>> requesting >>>>>>> cert: https://github.com/LiptonB/freeipa/commits/local-cert-build >>>>>> >>>>>> LGTM, although I would prefer if this was a client-side extension of >>>>>> cert-request rather than a completely new command. >>>>> >>>>> I did try that at first, but I struggled to figure out the interface >>>>> for >>>>> the modified cert-request. (Not that the current solution is so >>>>> great, >>>>> what with the copying of options from cert_request and certreq.) If I >>>>> remember correctly, I was uncertain how to implement parameters that >>>>> are >>>>> required/invalid based on other parameters: the current cert-request >>>>> takes a signed CSR (required), a principal (required), and a profile >>>>> ID; >>>>> the new cert-request (what I implemented as cert-build) takes a >>>>> principal (required), a profile ID (required), and a key location >>>>> (required). I can't remember if that was the only problem, but >>>>> I'll try >>>>> again to merge the commands and get back to you. >>>> >>>> To make the CSR argument optional on the client, you can do this: >>>> >>>> def get_options(self): >>>> for option in super(cert_request, self).get_options(): >>>> if option.name == 'csr': >>>> option = option.clone(required=False) >>>> yield >>>> >>>> IMO profile ID should default to caIPAserviceCert on the client as >>>> well. >>> >>> I originally had it doing so, but changed it to a required option >>> based on feedback in this email: >>> https://www.redhat.com/archives/freeipa-devel/2016-August/msg00021.html: >>> >>> "In general use I think that 'caIPAserviceCert' is unlikely to be used >>> a majory of the time, and it is a new command so there are no >>> compatibility issues; therefore why not make the profile option >>> mandatory?" I guess since we're talking about cert-request now, the >>> compatibility issues are back. >>> >>> https://github.com/LiptonB/freeipa/commits/local-cert-build has now >>> been updated to change the cert_request command rather than adding a >>> new command. It seems to work now (thanks for the advice on making the >>> argument optional), the only thing I'm having trouble with is the >>> default for the profile_id argument. Previously, the default was >>> applied by this code in cert_request.execute: >>> >>> profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) >>> >>> But now, in the client, I need the default to pass to >>> cert_get_requestdata if no profile is specified. I'm not sure I can >>> access backends from the client to get it the same way the server code >>> does. Should I just import ipapython/dogtag.py and use the >>> DEFAULT_PROFILE set in there? Is there a way I can give the option a >>> default that will be seen in both the server and the client? Just wanted to call attention to this question. The code that's currently problematic is here: https://github.com/LiptonB/freeipa/blob/dda05b0b4dfa332569a8ca75632eaeceb95fbd6a/ipaclient/plugins/cert.py#L86 (will pass None when in fact the argument default should be used). >>>> >>>>>> >>>>>>> >>>>>>> Other prototypes and design ideas that aren't ready for submission >>>>>>> yet: >>>>>>> >>>>>>> - Utility written in C to build a CertificationRequestInfo from a >>>>>>> SubjectPublicKeyInfo and an openssl-style config file. The >>>>>>> purpose of >>>>>>> this is to take a config that my code already knows how to >>>>>>> generate, and >>>>>>> put it in a form that certmonger can use. This is nearly done and >>>>>>> available at: >>>>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/build_requestinfo.c >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Nice! As I said above, this could really make implementing the "new" >>>>>> csrgen interface simple. >>>>>> >>>>>>> >>>>>>> >>>>>>> - Ideally it should be possible to use this tool to reimplement >>>>>>> the full >>>>>>> cert-request automation (local-cert-build branch) without a >>>>>>> dependency >>>>>>> on the certutil/openssl tools. However, I don't think any of the >>>>>>> python >>>>>>> crypto libraries have bindings for the functions that deal with >>>>>>> CertificationRequestInfo objects, so I don't think I can do this >>>>>>> in the >>>>>>> short term. >>>>>> >>>>>> You can use python-cffi to write your own minimal bindings. It's >>>>>> fairly straightforward, take a look at FreeIPA commit 500ee7e2 >>>>>> for an >>>>>> example of how to port C code to Python with python-cffi. >>>>> >>>>> Thank you for the example. I will take a look. >>>>>> >>>>>>> >>>>>>> - Certmonger "helper" program that takes in the >>>>>>> CertificationRequestInfo >>>>>>> that certmonger generates, calls out to IPA for profile-specific >>>>>>> data, >>>>>>> and returns an updated CertificationRequestInfo built from the >>>>>>> data. >>>>>>> Certmonger doesn't currently support this type of helper, but (if I >>>>>>> understood correctly) this is the architecture Nalin believed >>>>>>> would be >>>>>>> simplest to fit in. This is not done yet, but I intend to >>>>>>> complete it >>>>>>> soon - it shouldn't require much code beyond what's in >>>>>>> build_requestinfo.c. >>>>>> >>>>>> To me this sounds like it should be a new operation of the current >>>>>> helper rather than a completely new helper. >>>>> >>>>> Maybe so. I certainly wouldn't call this a finished design, I just >>>>> wanted to have some kind of proof of concept for how the certmonger >>>>> integration could work. For what it's worth, that prototype is now >>>>> available at [2]. >>>> >>>> OK. >>>> >>>>>> >>>>>> Anyway, the ultimate goal is to move the csrgen code to the server, >>>>>> which means everything the helper will have to do is call a command >>>>>> over RPC. >>>>>> >>>>>>> >>>>>>> - Tool to convert an XER-encoded cert extension to DER, given the >>>>>>> ASN.1 >>>>>>> description of the extension. This would unblock Jan Cholasta's >>>>>>> idea of >>>>>>> using XSLT for templates rather than text-based formatting. I >>>>>>> should be >>>>>>> able to implement the conversion tool, but it may be a while >>>>>>> before I >>>>>>> have time to demo the full XSLT idea. >>>>>> >>>>>> Was there any progress on this? >>>>> >>>>> I have started working on implementing it with asn1c, and I'm already >>>>> seeing some of the inconvenience (security issues aside) of >>>>> building on >>>>> the server. Libtasn1 seems like a much better model, but doesn't >>>>> seem to >>>>> have XER support. Anyway, don't quite have results here yet but I >>>>> think >>>>> I should have the XER->DER demo with asn1c ready in a week or two. >>>> >>>> Implementing XER codec on top of libtasn1 shouldn't be too hard; I >>>> have a WIP which I will post soon. >> >> It took me some experimentation to get this to work, but the solution >> with asn1c is actually quite simple because the tool automatically >> provides a sample C file that converts between different formats. So, >> this very basic shell script is able to do the conversion: >> https://github.com/LiptonB/freeipa-prototypes/blob/master/xer2der.sh >> >> $ cat ExtKeyUsage.xer >> >> 1.3.6.1.5.5.7.3.2 >> 1.3.6.1.5.5.7.3.4 >> >> >> $ cat KeyUsage.asn1 >> KUModule DEFINITIONS ::= >> BEGIN >> >> KeyUsage ::= BIT STRING { >> digitalSignature (0), >> nonRepudiation (1), -- recent editions of X.509 have >> -- renamed this bit to contentCommitment >> keyEncipherment (2), >> dataEncipherment (3), >> keyAgreement (4), >> keyCertSign (5), >> cRLSign (6), >> encipherOnly (7), >> decipherOnly (8) } >> >> ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId >> >> KeyPurposeId ::= OBJECT IDENTIFIER >> >> END >> >> $ ./xer2der.sh KeyUsage.asn1 ExtKeyUsageSyntax ExtKeyUsage.xer >> 2>/dev/null | xxd >> 00000000: 3014 0608 2b06 0105 0507 0302 0608 2b06 0...+.........+. >> 00000010: 0105 0507 0304 ...... > > So far I don't have a working example using libtasn1. I have something > close to it, but it's hacky, as the libtasn1 API is pretty limited, > and I didn't have time to work on it in the last few weeks. > >> >>>> >>>>>> >>>>>>> >>>>>>> So: currently on my to do list are the certmonger helper and the >>>>>>> XER->DER conversion tool. Do you have any comments about these >>>>>>> plans, >>>>>>> and is there anything else I can do to wrap up the project neatly? >>>>>>> >>>>>>> Thanks, >>>>>>> Ben >>>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> [1] >>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/key2spki.c >>>>> [2] >>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/cm_ipa_csrgen.c >>>>> >>>>> >>>> >>> >> > > From ftweedal at redhat.com Wed Jan 11 01:09:15 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Wed, 11 Jan 2017 11:09:15 +1000 Subject: [Freeipa-devel] [DESIGN] Dogtag GSS-API Authentication In-Reply-To: <2f2b8dd8-3b96-2b90-fa39-c2c1c45e438a@redhat.com> References: <20170106080804.GP4539@dhcp-40-8.bne.redhat.com> <2f2b8dd8-3b96-2b90-fa39-c2c1c45e438a@redhat.com> Message-ID: <20170111010915.GR4539@dhcp-40-8.bne.redhat.com> On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote: > Hi Fraser, > > I have some rather inane comments. I guess Jan cholasta will do a more > thorough review of your design. See below: > > On 01/06/2017 09:08 AM, Fraser Tweedale wrote: > > Hi comrades, > > > > I have written up the high-level details of the FreeIPA->Dogtag > > GSS-API authentication design. The goal is improve security by > > removing an egregious privilege separation violation: the RA Agent > > cert. > > > > There is a fair bit of work still to do on the Dogtag side but > > things are shaping up there and it's time to work out the IPA > > aspects. The design is at: > > > > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > first of all, you link a internal document from publicly available design > page. you should prepare a publicly visible version of the Dogtag-side > design and link that. > Will do; thanks. > It would also be nice to have a high-level graphical representation of the > proposed CSR processing workflow. I think you can re-use the one that is in > the Dogtag part, omit the Dogtag internals and add IPA-specific parts. > I will definitely do this a bit later, once more details of IPA design are established. > > > > Right now, I need feedback about the Domain Level aspects: whether > > it is the right approach, whether there are mechanisms to perform > > update steps (specifically: LDAP updates and/or api calls) alongside > > a DL bump, or if there aren't, how to deal with that (implement such > > a mechanism, make admins do extra steps, ???). > > > > Is the DL bump really necessary? Are you sure we really can not just update > the profile configuration and let older Dogtag installation handle it > gracefully? IIRC we have done some profile inclusion work in 4.2 development > and on and never really bothered about older Dogtag understanding them. > The problem is that the new profiles will refer to plugins (i.e. classes) that do not exist in older versions of Dogtag. Profile config is replicated, so if we upgrade profile config with old versions of Dogtag in the topology, it breaks them. I considered a mechanism where multiple versions of a profile exist in LDAP (i.e. multiple attribute values), and Dogtag picks the one that's "right" for it. (An example of how to do this might be attribute tagging where tag indicates minimum version of Dogtag containing components used in that profile version, and Dogag picks the highest that it supports). The advantage of such a mechanism is that we could use it for any future scenario where we introduce new profile components that we want to use in IPA. The downside is that it significantly complicates profile management (including for administrators), and can result in the same profile having different behaviour on different Dogtag instances, which could be confusing and make it harder to diagnose issues. Given the tradeoffs, I think a DL bump is preferable. > Anyway I guess we can call `certprofile-import' to load > ExternalProcessConstraint-enabled profile upon setting domain level to 2, we > just have to know where on the FS it is located. > > > Of course, any other general or specific feedback is welcome. > > > > Thanks, > > Fraser > > > > So if I understand correctly there will be no change in CA ACL management > interface and only the code which evaluates them will be factored out into > 'ipa-pki-validate-cert-request' command? Also, wouldn't it simpler if the CA > ACL evaluation was delegated to a separate API command instead? > ExternalProcessConstraint would then only ask IPA JSON api and process the > response. > There are no changes to CA ACL management interface as part of this design, but there are proposals to extend/rework it in future, e.g. #6424, #6425, #6426. Having a separate command for CA ACL evaluation is a good idea, and a clean refactoring target. ExternalProcessConstraint is generic with no knowledge of IPA API, but 'pki-pki-validate-cert-request' can invoke the new API command. Thanks for your feedback, Martin! Cheers, Fraser From freeipa-github-notification at redhat.com Wed Jan 11 07:20:34 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 11 Jan 2017 08:20:34 +0100 Subject: [Freeipa-devel] [freeipa PR#387][opened] Update warning message for ipa server uninstall Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Author: Akasurde Title: #387: Update warning message for ipa server uninstall Action: opened PR body: """ Fix adds an additional recommendation message for taking backup of existing data and configuration before proceeding to ipa server uninstallation procedures. Fixes https://fedorahosted.org/freeipa/ticket/6548 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/387/head:pr387 git checkout pr387 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-387.patch Type: text/x-diff Size: 1382 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 08:26:00 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 11 Jan 2017 09:26:00 +0100 Subject: [Freeipa-devel] [freeipa PR#385][+ack] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts Label: +ack From freeipa-github-notification at redhat.com Wed Jan 11 09:01:26 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 10:01:26 +0100 Subject: [Freeipa-devel] [freeipa PR#388][opened] py3: enable py3 pylint Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Author: mbasti-rh Title: #388: py3: enable py3 pylint Action: opened PR body: """ We should run pylint in both python2 and python3 versions """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/388/head:pr388 git checkout pr388 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-388.patch Type: text/x-diff Size: 833 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 09:04:34 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Wed, 11 Jan 2017 10:04:34 +0100 Subject: [Freeipa-devel] [freeipa PR#386][edited] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Author: gkaihorodova Title: #386: Tests: Add tree root domain role in legacy client tests Action: edited Changed field: body Original value: """ Legacy client tests inherits test cases from trust tests, that have role for tree root domain. That role was missing in legacy client tests. https://fedorahosted.org/freeipa/ticket/6600 """ From freeipa-github-notification at redhat.com Wed Jan 11 09:22:17 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 11 Jan 2017 10:22:17 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library tomaskrizek commented: """ Works as expected. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271818581 From freeipa-github-notification at redhat.com Wed Jan 11 09:22:20 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 11 Jan 2017 10:22:20 +0100 Subject: [Freeipa-devel] [freeipa PR#381][+ack] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library Label: +ack From freeipa-github-notification at redhat.com Wed Jan 11 09:29:28 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 11 Jan 2017 10:29:28 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library martbab commented: """ Thanks for ACK. I would like to ask @simo5 if this change is okay from krb5 point of view and does not pose any security problem for clients. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271820219 From freeipa-github-notification at redhat.com Wed Jan 11 10:06:30 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 11:06:30 +0100 Subject: [Freeipa-devel] [freeipa PR#388][+ack] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint Label: +ack From freeipa-github-notification at redhat.com Wed Jan 11 10:23:01 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 11:23:01 +0100 Subject: [Freeipa-devel] [freeipa PR#388][-ack] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint Label: -ack From freeipa-github-notification at redhat.com Wed Jan 11 10:38:32 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 11:38:32 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts tiran commented: """ What's the migration plan for existing SSHFP records? Are there any supported versions of OpenSSH or other SSH client that do not support SSHFP with SHA256? Would it make sense to run a hybrid mode for a while (SHA256 and MD5 records unless FIPS is enabled)? """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-271835544 From freeipa-github-notification at redhat.com Wed Jan 11 10:40:58 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 11:40:58 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. tiran commented: """ pylint is failing: ``` Pylint is running, please wait ... ************* Module ipaplatform.debian.tasks ipaplatform/debian/tasks.py:10: [E0611(no-name-in-module), ] No name 'BaseTaskNameSpace' in module 'ipaplatform.base.tasks') ipaplatform/debian/tasks.py:49: [E0602(undefined-variable), DebianTaskNamespace.parse_ipa_version] Undefined variable 'BaseTaskNamespace') ipaplatform/debian/tasks.py:9: [W0611(unused-import), ] Unused paths imported from ipaplatform.paths) ipaplatform/debian/tasks.py:10: [W0611(unused-import), ] Unused BaseTaskNameSpace imported from ipaplatform.base.tasks) ************* Module ipaplatform.debian.services ipaplatform/debian/services.py:64: [R0102(simplifiable-if-statement), DebianSysvService.stop] The if statement can be replaced with 'var = bool(test)') ipaplatform/debian/services.py:65: [W0612(unused-variable), DebianSysvService.stop] Unused variable 'update_service_list') ipaplatform/debian/services.py:73: [R0102(simplifiable-if-statement), DebianSysvService.start] The if statement can be replaced with 'var = bool(test)') ipaplatform/debian/services.py:74: [W0612(unused-variable), DebianSysvService.start] Unused variable 'update_service_list') ipaplatform/debian/services.py:9: [W0611(unused-import), ] Unused import time) ipaplatform/debian/services.py:11: [W0611(unused-import), ] Unused tasks imported from ipaplatform.tasks) ipaplatform/debian/services.py:15: [W0611(unused-import), ] Unused root_logger imported from ipapython.ipa_log_manager) make: *** [pylint] Error 14 ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-271836117 From freeipa-github-notification at redhat.com Wed Jan 11 11:06:24 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 11 Jan 2017 12:06:24 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts stlaz commented: """ @tiran Which SSHFP records do you mean? """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-271841277 From freeipa-github-notification at redhat.com Wed Jan 11 11:22:49 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 11 Jan 2017 12:22:49 +0100 Subject: [Freeipa-devel] [freeipa PR#367][edited] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: edited Changed field: body Original value: """ This batch of patches removes NSSConnection along with the whole ipapython.nsslib from IPA and replaces it with more standard httplib.HTTPSConnection. NSSConnection was causing a lot of trouble in the past because it is apparently very fragile when it comes to nss library initialization. On top of that, when NSSConnection is used to set up an HTTPS connection in FIPS, it always requires a password to NSS database as NSS apparently tries to create a temporary private key and store it to the database even though client authentication is not required in the SSL connection. TODO (will require changes in certmonger/dogatg.c): - [x] remove NSSConnection from client modules - [x] remove NSSConnection from server modules where it's used to connect to the certificate server - [x] remove the nsslib library completely - [ ] we may probably remove ipaCert from /etc/httpd/alias and stop tracking it with certmonger - [ ] separate ra-agent.pem into certificate and private-key files, have private-key file encrypted - [ ] once ^- is done, track the new files in certmonger instead https://fedorahosted.org/freeipa/ticket/5695 """ From freeipa-github-notification at redhat.com Wed Jan 11 11:25:04 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 12:25:04 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts tiran commented: """ Your change influenced the value of ```entry_attrs['sshpubkeyfp']``` in ```convert_sshpubkey_post```. Is the value only used in UI or does it affect data in LDAP like DNS SSHFP records? I tracked down some code paths and it looks like the pubkey fingerprint isn't stored in LDAP. The DNS plugin uses different method to calculate SSHFP records. Am I right to assume that this change only affects UI? """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-271844780 From freeipa-github-notification at redhat.com Wed Jan 11 11:26:54 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 11 Jan 2017 12:26:54 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts stlaz commented: """ @tiran Yes, exactly, this is only a UI thing. """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-271845090 From freeipa-github-notification at redhat.com Wed Jan 11 11:27:57 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 11 Jan 2017 12:27:57 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ I created the design for this effort: http://www.freeipa.org/page/V4/Replace_NSS_with_OpenSSL """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-271845272 From freeipa-github-notification at redhat.com Wed Jan 11 11:28:56 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Wed, 11 Jan 2017 12:28:56 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ I created the design for this effort: http://www.freeipa.org/page/V4/Replace_NSS_with_OpenSSL """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-271845272 From freeipa-github-notification at redhat.com Wed Jan 11 11:30:05 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 12:30:05 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts tiran commented: """ @stlaz I'm sorry, go ahead and ignore what I said! :) """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-271845641 From freeipa-github-notification at redhat.com Wed Jan 11 11:39:40 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 12:39:40 +0100 Subject: [Freeipa-devel] [freeipa PR#388][synchronized] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Author: mbasti-rh Title: #388: py3: enable py3 pylint Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/388/head:pr388 git checkout pr388 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-388.patch Type: text/x-diff Size: 835 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 11:46:48 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 12:46:48 +0100 Subject: [Freeipa-devel] [freeipa PR#388][comment] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint tiran commented: """ It's just a minor performance improvements to speed up CI. """ See the full comment at https://github.com/freeipa/freeipa/pull/388#issuecomment-271848791 From freeipa-github-notification at redhat.com Wed Jan 11 12:03:26 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 13:03:26 +0100 Subject: [Freeipa-devel] [freeipa PR#388][+ack] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint Label: +ack From freeipa-github-notification at redhat.com Wed Jan 11 12:16:52 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 13:16:52 +0100 Subject: [Freeipa-devel] [freeipa PR#388][comment] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint mbasti-rh commented: """ Lint part of travis-CI passed """ See the full comment at https://github.com/freeipa/freeipa/pull/388#issuecomment-271854299 From freeipa-github-notification at redhat.com Wed Jan 11 12:17:37 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 13:17:37 +0100 Subject: [Freeipa-devel] [freeipa PR#388][+pushed] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 11 12:17:39 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 13:17:39 +0100 Subject: [Freeipa-devel] [freeipa PR#388][comment] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Title: #388: py3: enable py3 pylint mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d648c6a6925298a1db0c61381d72b6c4d0500c10 """ See the full comment at https://github.com/freeipa/freeipa/pull/388#issuecomment-271854430 From freeipa-github-notification at redhat.com Wed Jan 11 12:17:40 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 13:17:40 +0100 Subject: [Freeipa-devel] [freeipa PR#388][closed] py3: enable py3 pylint In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/388 Author: mbasti-rh Title: #388: py3: enable py3 pylint Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/388/head:pr388 git checkout pr388 From freeipa-github-notification at redhat.com Wed Jan 11 12:18:25 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 13:18:25 +0100 Subject: [Freeipa-devel] [freeipa PR#378][comment] Integrate make check into CI In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Title: #378: Integrate make check into CI tiran commented: """ The changes to .gitignore and clean-local are still required to fix in-tree testing. make check leaves some files around. """ See the full comment at https://github.com/freeipa/freeipa/pull/378#issuecomment-271854570 From freeipa-github-notification at redhat.com Wed Jan 11 12:36:09 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 13:36:09 +0100 Subject: [Freeipa-devel] [freeipa PR#378][synchronized] Integrate make check into CI In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Author: tiran Title: #378: Integrate make check into CI Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/378/head:pr378 git checkout pr378 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-378.patch Type: text/x-diff Size: 1472 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 12:36:21 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 13:36:21 +0100 Subject: [Freeipa-devel] [freeipa PR#378][edited] Clean / ignore make check artefact In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Author: tiran Title: #378: Clean / ignore make check artefact Action: edited Changed field: title Original value: """ Integrate make check into CI """ From freeipa-github-notification at redhat.com Wed Jan 11 12:47:01 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 11 Jan 2017 13:47:01 +0100 Subject: [Freeipa-devel] [freeipa PR#245][synchronized] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Author: frasertweedale Title: #245: Allow full customisability of IPA CA subject DN Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/245/head:pr245 git checkout pr245 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-245.patch Type: text/x-diff Size: 78471 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 12:47:15 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 11 Jan 2017 13:47:15 +0100 Subject: [Freeipa-devel] [freeipa PR#245][comment] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN frasertweedale commented: """ @HonzaCholasta PR updated. Re ticket URL, I think 2614 is the correct one for that commit. """ See the full comment at https://github.com/freeipa/freeipa/pull/245#issuecomment-271859881 From freeipa-github-notification at redhat.com Wed Jan 11 12:54:43 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 11 Jan 2017 13:54:43 +0100 Subject: [Freeipa-devel] [freeipa PR#245][comment] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN HonzaCholasta commented: """ @frasertweedale, the ticket *number* is correct, but the URL points to Dogtag Trac. """ See the full comment at https://github.com/freeipa/freeipa/pull/245#issuecomment-271861244 From freeipa-github-notification at redhat.com Wed Jan 11 13:07:05 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 11 Jan 2017 14:07:05 +0100 Subject: [Freeipa-devel] [freeipa PR#245][comment] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN frasertweedale commented: """ @HonzaCholasta whups! Thanks for clarifying; fixed. """ See the full comment at https://github.com/freeipa/freeipa/pull/245#issuecomment-271863765 From freeipa-github-notification at redhat.com Wed Jan 11 13:14:57 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 11 Jan 2017 14:14:57 +0100 Subject: [Freeipa-devel] [freeipa PR#245][synchronized] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Author: frasertweedale Title: #245: Allow full customisability of IPA CA subject DN Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/245/head:pr245 git checkout pr245 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-245.patch Type: text/x-diff Size: 78475 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 13:44:03 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 11 Jan 2017 14:44:03 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tomaskrizek commented: """ Could you please extend [V4/Build system refactoring](http://www.freeipa.org/page/V4/Build_system_refactoring) to include steps describing how to perform client-only build? Also, is this supposed to build the freeipa-client rpm package? I wasn't able to build the rpm (``` *** No rule to make target 'distdir'. Stop.```). Or does it only support make + make install? When I tried to do this it also produced ipaserver and ipatests directories. It was probably a misconfiguration on my side. Please provide instructions on how to do a proper client-only build. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-271871528 From freeipa-github-notification at redhat.com Wed Jan 11 14:01:09 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 11 Jan 2017 15:01:09 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library simo5 commented: """ @martbab this change actually improves security by avoiding a DNS lookup that could be manipulated by an attacker, however it also means some setups may break, because they depend on canonicalization to actually get the correct name, and should be documented in release notes. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271875472 From freeipa-github-notification at redhat.com Wed Jan 11 14:10:12 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 15:10:12 +0100 Subject: [Freeipa-devel] [freeipa PR#364][synchronized] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Author: tiran Title: #364: Client-only builds with --disable-server Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/364/head:pr364 git checkout pr364 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-364.patch Type: text/x-diff Size: 16655 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 14:14:27 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:14:27 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [WIP] Py3 ipa-server-install fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [WIP] Py3 ipa-server-install fixes Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 25153 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 14:15:18 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:15:18 +0100 Subject: [Freeipa-devel] [freeipa PR#382][edited] [WIP] Py3 ipa-server-install fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [WIP] Py3 ipa-server-install fixes Action: edited Changed field: body Original value: """ This PR should allow to install server with py3 """ From freeipa-github-notification at redhat.com Wed Jan 11 14:15:52 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:15:52 +0100 Subject: [Freeipa-devel] [freeipa PR#382][edited] [WIP] Py3 ipa-server-install fixes In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [WIP] Py3 ipa-server-install fixes Action: edited Changed field: title Original value: """ [WIP] Py3 ipa-server-install fixes """ From freeipa-github-notification at redhat.com Wed Jan 11 14:18:07 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 11 Jan 2017 15:18:07 +0100 Subject: [Freeipa-devel] [freeipa PR#245][+ack] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN Label: +ack From freeipa-github-notification at redhat.com Wed Jan 11 14:18:32 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 15:18:32 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tiran commented: """ The PR only affects ```make install```, Python packaging and integration efforts. The goal is to reduce the amount of necessary build dependencies for installation and packaging of Python wheels or for developers that are only interested to build ipa-client locally. At the moment it is not possible to build FreeIPA without Samba, talloc, tevent, 389 DS, systemd and a couple of more packages. The dependency tree is rather heavy. These dependencies are not relevant for clients, though. I haven't touched RPM builds deliberately. RPM spec can be adjusted in a subsequent PR. It's not relevant for me. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-271879617 From freeipa-github-notification at redhat.com Wed Jan 11 14:23:32 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 11 Jan 2017 15:23:32 +0100 Subject: [Freeipa-devel] [freeipa PR#245][comment] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/324183cd63aeadbaa9678d610ba59e1295a606fe https://fedorahosted.org/freeipa/changeset/db6674096c598918ea6b12ca33a96cf5e617a434 https://fedorahosted.org/freeipa/changeset/c6db493b06320455a2366945911939a605df2a73 https://fedorahosted.org/freeipa/changeset/6f3eb85c302f54bec561337e6627c89144b589ff https://fedorahosted.org/freeipa/changeset/46bf0e89ae054b34adc66d08f205a5155e6f3fd6 https://fedorahosted.org/freeipa/changeset/f54df62abae4a15064bf297634558eb9be83ce33 https://fedorahosted.org/freeipa/changeset/09a65df6842411d42966111e50924df3de0b7031 https://fedorahosted.org/freeipa/changeset/3d01ec14c6e36fa962d0c54b2e08df0ecd401bd6 https://fedorahosted.org/freeipa/changeset/3f5660973251fe4b178e6486b6b86fbdd162d4d6 https://fedorahosted.org/freeipa/changeset/0c95a00147b1dd508736dacc847873ddddafb504 """ See the full comment at https://github.com/freeipa/freeipa/pull/245#issuecomment-271880802 From freeipa-github-notification at redhat.com Wed Jan 11 14:23:33 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 11 Jan 2017 15:23:33 +0100 Subject: [Freeipa-devel] [freeipa PR#245][closed] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Author: frasertweedale Title: #245: Allow full customisability of IPA CA subject DN Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/245/head:pr245 git checkout pr245 From freeipa-github-notification at redhat.com Wed Jan 11 14:24:14 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 11 Jan 2017 15:24:14 +0100 Subject: [Freeipa-devel] [freeipa PR#245][+pushed] Allow full customisability of IPA CA subject DN In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/245 Title: #245: Allow full customisability of IPA CA subject DN Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 11 14:24:34 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:24:34 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 25153 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 14:28:19 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:28:19 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 25025 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 14:36:03 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Wed, 11 Jan 2017 15:36:03 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library pvoborni commented: """ To not forget to update the release notes later at release, @martbab could you update the respected fields in both ticket and BZ when the patch is pushed. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271883989 From freeipa-github-notification at redhat.com Wed Jan 11 14:56:48 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Wed, 11 Jan 2017 15:56:48 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 25072 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 15:15:55 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 11 Jan 2017 16:15:55 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library martbab commented: """ @pvoborni will do. """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271894729 From freeipa-github-notification at redhat.com Wed Jan 11 15:18:43 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 11 Jan 2017 16:18:43 +0100 Subject: [Freeipa-devel] [freeipa PR#381][+pushed] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 11 15:18:44 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 11 Jan 2017 16:18:44 +0100 Subject: [Freeipa-devel] [freeipa PR#381][comment] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Title: #381: disable hostname canonicalization by Kerberos library martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/566c86a782bfd7d50938866e9f89faf56cea773f """ See the full comment at https://github.com/freeipa/freeipa/pull/381#issuecomment-271895542 From freeipa-github-notification at redhat.com Wed Jan 11 15:18:45 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 11 Jan 2017 16:18:45 +0100 Subject: [Freeipa-devel] [freeipa PR#381][closed] disable hostname canonicalization by Kerberos library In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/381 Author: martbab Title: #381: disable hostname canonicalization by Kerberos library Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/381/head:pr381 git checkout pr381 From freeipa-github-notification at redhat.com Wed Jan 11 15:19:35 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 11 Jan 2017 16:19:35 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tomaskrizek commented: """ The extra dependencies are indeed not necessary with this change. However, `make install` produces directories like `/usr/lib/python2.7/site-packages/ipaserver`, `/usr/lib/python2.7/site-packages/ipatests`, ... I don't think these should be present when doing a client-only build. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-271895769 From freeipa-github-notification at redhat.com Wed Jan 11 15:38:18 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 16:38:18 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tiran commented: """ Nit-pick: A build does not produce any files outside the build environment. Of course **make install** produces the files -- unless you change the prefix with ```./configure --prefix```. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-271901278 From freeipa-github-notification at redhat.com Wed Jan 11 16:16:02 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 11 Jan 2017 17:16:02 +0100 Subject: [Freeipa-devel] [freeipa PR#389][opened] Fix build in mock Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Author: lslebodn Title: #389: Fix build in mock Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/389/head:pr389 git checkout pr389 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-389.patch Type: text/x-diff Size: 3334 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 16:18:06 2017 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 11 Jan 2017 17:18:06 +0100 Subject: [Freeipa-devel] [freeipa PR#390][opened] WebUI: Fix Coverity JS bugs Message-ID: URL: https://github.com/freeipa/freeipa/pull/390 Author: pvomacka Title: #390: WebUI: Fix Coverity JS bugs Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/390/head:pr390 git checkout pr390 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-390.patch Type: text/x-diff Size: 2094 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 16:23:15 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 11 Jan 2017 17:23:15 +0100 Subject: [Freeipa-devel] [freeipa PR#389][comment] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock tiran commented: """ Thanks, your PR fixes some concerns of my ticket https://fedorahosted.org/freeipa/ticket/6604. """ See the full comment at https://github.com/freeipa/freeipa/pull/389#issuecomment-271914990 From freeipa-github-notification at redhat.com Wed Jan 11 16:32:11 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 11 Jan 2017 17:32:11 +0100 Subject: [Freeipa-devel] [freeipa PR#389][synchronized] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Author: lslebodn Title: #389: Fix build in mock Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/389/head:pr389 git checkout pr389 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-389.patch Type: text/x-diff Size: 3729 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 16:34:57 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 11 Jan 2017 17:34:57 +0100 Subject: [Freeipa-devel] [freeipa PR#389][synchronized] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Author: lslebodn Title: #389: Fix build in mock Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/389/head:pr389 git checkout pr389 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-389.patch Type: text/x-diff Size: 3336 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 17:17:42 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 11 Jan 2017 18:17:42 +0100 Subject: [Freeipa-devel] [freeipa PR#389][synchronized] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Author: lslebodn Title: #389: Fix build in mock Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/389/head:pr389 git checkout pr389 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-389.patch Type: text/x-diff Size: 4537 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 17:19:07 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Wed, 11 Jan 2017 18:19:07 +0100 Subject: [Freeipa-devel] [freeipa PR#389][comment] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock lslebodn commented: """ I updated doc help do jslint in latest version """ See the full comment at https://github.com/freeipa/freeipa/pull/389#issuecomment-271931555 From freeipa-github-notification at redhat.com Wed Jan 11 23:17:29 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 12 Jan 2017 00:17:29 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16701 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 11 23:27:36 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Thu, 12 Jan 2017 00:27:36 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16773 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 08:00:20 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 12 Jan 2017 09:00:20 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ @simo5, I can't reproduce the bug anymore with the latest update. Pylint found one trivial issue: ``` ipaserver/install/server/upgrade.py:83: [E0602(undefined-variable), uninstall_ipa_memcached] Undefined variable 'SimpleServiceInstance') ``` (It should be `service.SimpleServiceInstance`.) """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-272100308 From freeipa-github-notification at redhat.com Thu Jan 12 08:20:01 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Thu, 12 Jan 2017 09:20:01 +0100 Subject: [Freeipa-devel] [freeipa PR#179][synchronized] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Author: Akasurde Title: #179: Fix for handling CalledProcessError in authconfig Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/179/head:pr179 git checkout pr179 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-179.patch Type: text/x-diff Size: 3139 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 08:44:20 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 12 Jan 2017 09:44:20 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ Not sure if it's this PR or not, but `ipa-server-install` *sometimes* fails with: ``` [11/22]: setting up ssl [error] NetworkError: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket': ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR cannot connect to 'ldapi://%2fvar%2frun%2fslapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM.socket': ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-272106420 From freeipa-github-notification at redhat.com Thu Jan 12 08:47:05 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Thu, 12 Jan 2017 09:47:05 +0100 Subject: [Freeipa-devel] [freeipa PR#377][comment] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent abbra commented: """ Looks very good to me. ACK from my side. """ See the full comment at https://github.com/freeipa/freeipa/pull/377#issuecomment-272106955 From jcholast at redhat.com Thu Jan 12 09:35:53 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Jan 2017 10:35:53 +0100 Subject: [Freeipa-devel] CSR autogeneration next steps In-Reply-To: <547fedb7-9996-0264-edb4-a563c1f038cf@redhat.com> References: <4d31f26b-e332-7362-2b8e-3382a0109067@redhat.com> <2ac0c9af-ef4a-65fe-0cb9-2d161bb7eba0@redhat.com> <77684b8f-c0f5-b1ad-cf7c-075184b5ee39@redhat.com> <71e4dec2-dde8-1cf5-c4cf-399e70f5c60d@redhat.com> <547fedb7-9996-0264-edb4-a563c1f038cf@redhat.com> Message-ID: <5198614b-1704-27b6-7985-46d57b528643@redhat.com> On 11.1.2017 00:38, Ben Lipton wrote: > > On 01/10/2017 01:58 AM, Jan Cholasta wrote: >> On 19.12.2016 21:59, Ben Lipton wrote: >>> >>> On 12/15/2016 11:11 PM, Ben Lipton wrote: >>>> >>>> On 12/12/2016 03:52 AM, Jan Cholasta wrote: >>>>> On 5.12.2016 16:48, Ben Lipton wrote: >>>>>> Hi Jan, thanks for the comments. >>>>>> >>>>>> >>>>>> On 12/05/2016 04:25 AM, Jan Cholasta wrote: >>>>>>> Hi Ben, >>>>>>> >>>>>>> On 3.11.2016 00:12, Ben Lipton wrote: >>>>>>>> Hi everybody, >>>>>>>> >>>>>>>> Soon I'm going to have to reduce the amount of time I spend on new >>>>>>>> development work for the CSR autogeneration project, and I want to >>>>>>>> leave >>>>>>>> the project in as organized a state as possible. So, I'm taking >>>>>>>> inventory of the work I've done in order to make sure that what's >>>>>>>> ready >>>>>>>> for review can get reviewed and the ideas that have been discussed >>>>>>>> get >>>>>>>> prototyped or at least recorded so they won't be forgotten. >>>>>>> >>>>>>> Thanks, I have some questions and comments, see below. >>>>>>> >>>>>>>> >>>>>>>> Code that's ready for review (I will continue to put in as much >>>>>>>> time as >>>>>>>> needed to help get these ready for submission): >>>>>>>> >>>>>>>> - Current PR: https://github.com/freeipa/freeipa/pull/10 >>>>>>> >>>>>>> How hard would it be to update the PR to use the "new" interface >>>>>>> from >>>>>>> the design thread? By this I mean that currently there is a command >>>>>>> (cert_get_requestdata), which creates a CSR from profile id + >>>>>>> principal + helper, but in the design we discussed a command which >>>>>>> creates a CertificationRequestInfo from profile id + principal + >>>>>>> public key. >>>>>>> >>>>>>> Internally it could use the OpenSSL helper, no need to implement the >>>>>>> full "new" design. With your build_requestinfo.c code below it looks >>>>>>> like it should be pretty straightforward. >>>>>> >>>>>> This is probably doable with the cffi, but I'm concerned about >>>>>> usability. A user can run the current command to get a (reusable) >>>>>> script, and run the script to get a CSR. It works with keys in >>>>>> both PEM >>>>>> files and NSS databases already. If we change to outputting a >>>>>> CertificationRequestInfo, in order to make this usable on the command >>>>>> line, we'll need: >>>>>> - An additional tool to sign a CSR given a CertificationRequestInfo >>>>>> (for >>>>>> both types of key storage). >>>>>> - A way to extract a SubjectPublicKeyInfo structure from a key within >>>>>> the ipa command (like [1] but we need it for both types of key >>>>>> storage) >>>>>> Since as far as I know there's no standard encoding for files >>>>>> containing >>>>>> only a CertificationRequestInfo or a SubjectPublicKeyInfo, we'll be >>>>>> writing and distributing these ourselves. I think that's where >>>>>> most of >>>>>> the extra work will come in. >>>>> >>>>> For PEM files, this is easily doable using python-cryptography (to >>>>> extract SubjectPublicKeyInfo and sign CertificationRequestInfo) and >>>>> PyASN1 (to create a CSR from the CertificationRequestInfo and the >>>>> signature). >>>> >>>> I didn't realize that python-cryptography knew about >>>> SubjectPublicKeyInfo structures, but indeed this seems to be pretty >>>> straightforward: >>>> >>>> key = load_pem_private_key(key_bytes, None, default_backend()) >>>> pubkey_info = key.public_key().public_bytes(Encoding.DER, >>>> PublicFormat.SubjectPublicKeyInfo) >>>> >>>> Thanks for letting me know this functionality already existed. > > I'm currently working on the step of signing the > CertificationRequestInfo and creating a CSR from it. I think I have it > working with pyasn1, but of course the "signature algorithm" for the CSR > needs to be specified and implemented within the code since I'm not > using a library that understands CSRs natively. The code I have > currently always produces CSRs with the sha256WithRSAEncryption > algorithm (DER-encode request info, SHA256, PKCS #1v1.5 padding, RSA > encryption), and the OID for that algorithm is hardcoded in the output > CSR. Is this ok or will we need more flexibility than that? IMO it's OK for starters. >>>>> >>>>> For NSS databases, this will be trickier and will require calling C >>>>> functions, as neither certutil nor python-nss provide a way to a) >>>>> address existing keys in the database by key ID b) get >>>>> SubjectPublicKeyInfo for a given key. >> >> This can be worked around by: >> >> 1. Generating a key + temporary certificate: >> >> n=$(head -c 40 /dev/urandom | base32) >> certutil -S -n $n -s CN=$n -x -t ,, >> >> 2. Extracting the public key from the certificate: >> >> certutil -L -n $n -a >temp.crt >> (extract the public key using python-cryptography) >> >> 3. Deleting the temporary certificate: >> >> certutil -D -n $n >> >> 4. Importing the newly issued certificate: >> >> certutil -A -n $n -t ,, -a > > Oof, thanks, I'm not sure I would have been able to come up with that. > Can you generate a key without a temporary certificate if you use the > NSS API, or does their model require every key to belong to a cert? I'm pretty sure it's possible, but it certainly won't be as simple as this. I gave up after a few hours of digging into NSS source code and not being able to figure out how. >>>>> >>>>> As for encoding, the obvious choice is DER. It does not really matter >>>>> there is no standard file format, as we won't be transferring these >>>>> as files anyway. >>>> >>>> Agreed. I just meant there aren't tools already because this isn't a >>>> type of file one often needs to process. >>>>> >>>>>> >>>>>> Would it be ok to stick with the current design in this PR? I'd feel >>>>>> much better if we could get the basic functionality into the repo and >>>>>> then iterate on it rather than changing the plan at this point. I can >>>>>> create a separate PR to change cert_get_requestdata to this new >>>>>> interface and at the same time add the necessary adapters (bullet >>>>>> points >>>>>> above) to make it user-friendly. >>>>> >>>>> Works for me. >>>> >>>> Updated the PR to fix conflicts with master. Had some trouble with CI >>>> but creating a new PR with the same commits fixed it >>>> (https://github.com/freeipa/freeipa/pull/337). Not sure if it's fixed >>>> permanently, so I guess I'll just keep the two PRs synchronized now, >>>> or we could close the old one. >> >> You can close the old one. >> >> Just to make sure we are on the same page, you want this PR to be >> merged before submitting additional PRs built on top of it? > > Yes, I would like to merge this one to have as a starting point if > you're comfortable with it: https://github.com/freeipa/freeipa/pull/337. > I just did a force push to clean up the history, but the final diff > should be the same as it was before. OK. >> >>>>> >>>>>> >>>>>> I would probably just implement the adapters within the >>>>>> cert_build/cert_request client code unless you think having >>>>>> standalone >>>>>> tools is valuable. I suppose certmonger is going to need these >>>>>> features >>>>>> too, but I don't know how well sharing code between them is going to >>>>>> work. >>>>> >>>>> cert-request is exactly the place where it should be :-) I wouldn't >>>>> bother with certmonger until we have a server-side csrgen. >>>>> >>>>>>> >>>>>>>> >>>>>>>> - Allow some fields to be specified by the user at creation time: >>>>>>>> https://github.com/LiptonB/freeipa/commits/local-user-data >>>>>>> >>>>>>> Good idea :-) >>>>>>> >>>>>>>> >>>>>>>> - Automation for the full process from getting CSR data to >>>>>>>> requesting >>>>>>>> cert: https://github.com/LiptonB/freeipa/commits/local-cert-build >>>>>>> >>>>>>> LGTM, although I would prefer if this was a client-side extension of >>>>>>> cert-request rather than a completely new command. >>>>>> >>>>>> I did try that at first, but I struggled to figure out the interface >>>>>> for >>>>>> the modified cert-request. (Not that the current solution is so >>>>>> great, >>>>>> what with the copying of options from cert_request and certreq.) If I >>>>>> remember correctly, I was uncertain how to implement parameters that >>>>>> are >>>>>> required/invalid based on other parameters: the current cert-request >>>>>> takes a signed CSR (required), a principal (required), and a profile >>>>>> ID; >>>>>> the new cert-request (what I implemented as cert-build) takes a >>>>>> principal (required), a profile ID (required), and a key location >>>>>> (required). I can't remember if that was the only problem, but >>>>>> I'll try >>>>>> again to merge the commands and get back to you. >>>>> >>>>> To make the CSR argument optional on the client, you can do this: >>>>> >>>>> def get_options(self): >>>>> for option in super(cert_request, self).get_options(): >>>>> if option.name == 'csr': >>>>> option = option.clone(required=False) >>>>> yield >>>>> >>>>> IMO profile ID should default to caIPAserviceCert on the client as >>>>> well. >>>> >>>> I originally had it doing so, but changed it to a required option >>>> based on feedback in this email: >>>> https://www.redhat.com/archives/freeipa-devel/2016-August/msg00021.html: >>>> >>>> "In general use I think that 'caIPAserviceCert' is unlikely to be used >>>> a majory of the time, and it is a new command so there are no >>>> compatibility issues; therefore why not make the profile option >>>> mandatory?" I guess since we're talking about cert-request now, the >>>> compatibility issues are back. >>>> >>>> https://github.com/LiptonB/freeipa/commits/local-cert-build has now >>>> been updated to change the cert_request command rather than adding a >>>> new command. It seems to work now (thanks for the advice on making the >>>> argument optional), the only thing I'm having trouble with is the >>>> default for the profile_id argument. Previously, the default was >>>> applied by this code in cert_request.execute: >>>> >>>> profile_id = kw.get('profile_id', self.Backend.ra.DEFAULT_PROFILE) >>>> >>>> But now, in the client, I need the default to pass to >>>> cert_get_requestdata if no profile is specified. I'm not sure I can >>>> access backends from the client to get it the same way the server code >>>> does. Should I just import ipapython/dogtag.py and use the >>>> DEFAULT_PROFILE set in there? Is there a way I can give the option a >>>> default that will be seen in both the server and the client? > Just wanted to call attention to this question. The code that's > currently problematic is here: > https://github.com/LiptonB/freeipa/blob/dda05b0b4dfa332569a8ca75632eaeceb95fbd6a/ipaclient/plugins/cert.py#L86 > (will pass None when in fact the argument default should be used). self.get_default_of('profile_id') >>>>> >>>>>>> >>>>>>>> >>>>>>>> Other prototypes and design ideas that aren't ready for submission >>>>>>>> yet: >>>>>>>> >>>>>>>> - Utility written in C to build a CertificationRequestInfo from a >>>>>>>> SubjectPublicKeyInfo and an openssl-style config file. The >>>>>>>> purpose of >>>>>>>> this is to take a config that my code already knows how to >>>>>>>> generate, and >>>>>>>> put it in a form that certmonger can use. This is nearly done and >>>>>>>> available at: >>>>>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/build_requestinfo.c >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Nice! As I said above, this could really make implementing the "new" >>>>>>> csrgen interface simple. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - Ideally it should be possible to use this tool to reimplement >>>>>>>> the full >>>>>>>> cert-request automation (local-cert-build branch) without a >>>>>>>> dependency >>>>>>>> on the certutil/openssl tools. However, I don't think any of the >>>>>>>> python >>>>>>>> crypto libraries have bindings for the functions that deal with >>>>>>>> CertificationRequestInfo objects, so I don't think I can do this >>>>>>>> in the >>>>>>>> short term. >>>>>>> >>>>>>> You can use python-cffi to write your own minimal bindings. It's >>>>>>> fairly straightforward, take a look at FreeIPA commit 500ee7e2 >>>>>>> for an >>>>>>> example of how to port C code to Python with python-cffi. >>>>>> >>>>>> Thank you for the example. I will take a look. >>>>>>> >>>>>>>> >>>>>>>> - Certmonger "helper" program that takes in the >>>>>>>> CertificationRequestInfo >>>>>>>> that certmonger generates, calls out to IPA for profile-specific >>>>>>>> data, >>>>>>>> and returns an updated CertificationRequestInfo built from the >>>>>>>> data. >>>>>>>> Certmonger doesn't currently support this type of helper, but (if I >>>>>>>> understood correctly) this is the architecture Nalin believed >>>>>>>> would be >>>>>>>> simplest to fit in. This is not done yet, but I intend to >>>>>>>> complete it >>>>>>>> soon - it shouldn't require much code beyond what's in >>>>>>>> build_requestinfo.c. >>>>>>> >>>>>>> To me this sounds like it should be a new operation of the current >>>>>>> helper rather than a completely new helper. >>>>>> >>>>>> Maybe so. I certainly wouldn't call this a finished design, I just >>>>>> wanted to have some kind of proof of concept for how the certmonger >>>>>> integration could work. For what it's worth, that prototype is now >>>>>> available at [2]. >>>>> >>>>> OK. >>>>> >>>>>>> >>>>>>> Anyway, the ultimate goal is to move the csrgen code to the server, >>>>>>> which means everything the helper will have to do is call a command >>>>>>> over RPC. >>>>>>> >>>>>>>> >>>>>>>> - Tool to convert an XER-encoded cert extension to DER, given the >>>>>>>> ASN.1 >>>>>>>> description of the extension. This would unblock Jan Cholasta's >>>>>>>> idea of >>>>>>>> using XSLT for templates rather than text-based formatting. I >>>>>>>> should be >>>>>>>> able to implement the conversion tool, but it may be a while >>>>>>>> before I >>>>>>>> have time to demo the full XSLT idea. >>>>>>> >>>>>>> Was there any progress on this? >>>>>> >>>>>> I have started working on implementing it with asn1c, and I'm already >>>>>> seeing some of the inconvenience (security issues aside) of >>>>>> building on >>>>>> the server. Libtasn1 seems like a much better model, but doesn't >>>>>> seem to >>>>>> have XER support. Anyway, don't quite have results here yet but I >>>>>> think >>>>>> I should have the XER->DER demo with asn1c ready in a week or two. >>>>> >>>>> Implementing XER codec on top of libtasn1 shouldn't be too hard; I >>>>> have a WIP which I will post soon. >>> >>> It took me some experimentation to get this to work, but the solution >>> with asn1c is actually quite simple because the tool automatically >>> provides a sample C file that converts between different formats. So, >>> this very basic shell script is able to do the conversion: >>> https://github.com/LiptonB/freeipa-prototypes/blob/master/xer2der.sh >>> >>> $ cat ExtKeyUsage.xer >>> >>> 1.3.6.1.5.5.7.3.2 >>> 1.3.6.1.5.5.7.3.4 >>> >>> >>> $ cat KeyUsage.asn1 >>> KUModule DEFINITIONS ::= >>> BEGIN >>> >>> KeyUsage ::= BIT STRING { >>> digitalSignature (0), >>> nonRepudiation (1), -- recent editions of X.509 have >>> -- renamed this bit to contentCommitment >>> keyEncipherment (2), >>> dataEncipherment (3), >>> keyAgreement (4), >>> keyCertSign (5), >>> cRLSign (6), >>> encipherOnly (7), >>> decipherOnly (8) } >>> >>> ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId >>> >>> KeyPurposeId ::= OBJECT IDENTIFIER >>> >>> END >>> >>> $ ./xer2der.sh KeyUsage.asn1 ExtKeyUsageSyntax ExtKeyUsage.xer >>> 2>/dev/null | xxd >>> 00000000: 3014 0608 2b06 0105 0507 0302 0608 2b06 0...+.........+. >>> 00000010: 0105 0507 0304 ...... >> >> So far I don't have a working example using libtasn1. I have something >> close to it, but it's hacky, as the libtasn1 API is pretty limited, >> and I didn't have time to work on it in the last few weeks. I got it working, needs just a little polishing. It's still ugly hacky though. >> >>> >>>>> >>>>>>> >>>>>>>> >>>>>>>> So: currently on my to do list are the certmonger helper and the >>>>>>>> XER->DER conversion tool. Do you have any comments about these >>>>>>>> plans, >>>>>>>> and is there anything else I can do to wrap up the project neatly? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ben >>>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> [1] >>>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/key2spki.c >>>>>> [2] >>>>>> https://github.com/LiptonB/freeipa-prototypes/blob/master/cm_ipa_csrgen.c >>>>>> >>>>>> >>>>> >>>> >>> >> >> > -- Jan Cholasta From freeipa-github-notification at redhat.com Thu Jan 12 09:59:21 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 10:59:21 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values mbasti-rh commented: """ This PR still needs rebase, it is not possible to apply patch without 3way merge, please pull the latest master and do rebase, we merge only patches that can be merged without 3-way merge ``` $ hub am https://github.com/freeipa/freeipa/pull/181 -3 Applying: Unaccessible variable self.attrs in Tracker Using index info to reconstruct a base tree... M ipatests/test_xmlrpc/tracker/base.py Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: User Tracker: creation of user with minimal values Using index info to reconstruct a base tree... M ipatests/test_xmlrpc/tracker/user_plugin.py Falling back to patching base and 3-way merge... Auto-merging ipatests/test_xmlrpc/tracker/user_plugin.py Applying: User Tracker: Test to create user with minimal values ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-272122000 From freeipa-github-notification at redhat.com Thu Jan 12 10:05:09 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:05:09 +0100 Subject: [Freeipa-devel] [freeipa PR#210][comment] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Title: #210: Tests: Stage User Tracker implementation mbasti-rh commented: """ Needs rebase ``` Applying: Unaccessible variable self.attrs in Tracker Patch failed at 0001 Unaccessible variable self.attrs in Tracker The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". error: patch failed: ipatests/test_xmlrpc/tracker/base.py:76 error: ipatests/test_xmlrpc/tracker/base.py: patch does not apply ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/210#issuecomment-272123222 From freeipa-github-notification at redhat.com Thu Jan 12 10:10:08 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:10:08 +0100 Subject: [Freeipa-devel] [freeipa PR#385][comment] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/721105c53de6fbc0abc7799ec7f48920e02089bd """ See the full comment at https://github.com/freeipa/freeipa/pull/385#issuecomment-272124272 From freeipa-github-notification at redhat.com Thu Jan 12 10:10:09 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:10:09 +0100 Subject: [Freeipa-devel] [freeipa PR#385][closed] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Author: stlaz Title: #385: Generate sha256 ssh pubkey fingerprints for hosts Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/385/head:pr385 git checkout pr385 From freeipa-github-notification at redhat.com Thu Jan 12 10:10:11 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:10:11 +0100 Subject: [Freeipa-devel] [freeipa PR#385][+pushed] Generate sha256 ssh pubkey fingerprints for hosts In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/385 Title: #385: Generate sha256 ssh pubkey fingerprints for hosts Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 12 10:15:32 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:15:32 +0100 Subject: [Freeipa-devel] [freeipa PR#383][+pushed] Remove duplicated step from DS install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Title: #383: Remove duplicated step from DS install Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 12 10:15:34 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:15:34 +0100 Subject: [Freeipa-devel] [freeipa PR#383][comment] Remove duplicated step from DS install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Title: #383: Remove duplicated step from DS install mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/083b4241d287a731e2cf7fed5c61b30da52a8e37 """ See the full comment at https://github.com/freeipa/freeipa/pull/383#issuecomment-272125454 From freeipa-github-notification at redhat.com Thu Jan 12 10:15:35 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:15:35 +0100 Subject: [Freeipa-devel] [freeipa PR#383][closed] Remove duplicated step from DS install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/383 Author: mbasti-rh Title: #383: Remove duplicated step from DS install Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/383/head:pr383 git checkout pr383 From freeipa-github-notification at redhat.com Thu Jan 12 10:18:12 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:18:12 +0100 Subject: [Freeipa-devel] [freeipa PR#374][comment] pytest: set rules to find test files and functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Title: #374: pytest: set rules to find test files and functions mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/68cb4d2b0f6b28f20513371e46b279d80c0b3070 """ See the full comment at https://github.com/freeipa/freeipa/pull/374#issuecomment-272126112 From freeipa-github-notification at redhat.com Thu Jan 12 10:18:14 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:18:14 +0100 Subject: [Freeipa-devel] [freeipa PR#374][closed] pytest: set rules to find test files and functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Author: tiran Title: #374: pytest: set rules to find test files and functions Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/374/head:pr374 git checkout pr374 From freeipa-github-notification at redhat.com Thu Jan 12 10:18:15 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 11:18:15 +0100 Subject: [Freeipa-devel] [freeipa PR#374][+pushed] pytest: set rules to find test files and functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/374 Title: #374: pytest: set rules to find test files and functions Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 12 11:13:31 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 12 Jan 2017 12:13:31 +0100 Subject: [Freeipa-devel] [freeipa PR#391][opened] ipapython: Add dependencies on version.py Message-ID: URL: https://github.com/freeipa/freeipa/pull/391 Author: tiran Title: #391: ipapython: Add dependencies on version.py Action: opened PR body: """ install-exec and bdist_wheel also depend on version.py. Let's ensure that version.py is correctly generated when installing or building packages. Yes, make is clever and correctly merges dependencies with rules from included make files. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/391/head:pr391 git checkout pr391 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-391.patch Type: text/x-diff Size: 41143 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 11:15:20 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 12:15:20 +0100 Subject: [Freeipa-devel] [freeipa PR#377][comment] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent stlaz commented: """ Works fine. """ See the full comment at https://github.com/freeipa/freeipa/pull/377#issuecomment-272137913 From freeipa-github-notification at redhat.com Thu Jan 12 12:08:04 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 13:08:04 +0100 Subject: [Freeipa-devel] [freeipa PR#377][comment] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent stlaz commented: """ I made a patch that makes is_renewal_master and set_renewal_master classmethods on @tiran recommendation. Feel free to push it along or leave it, don't let it slow us down if you don't like it. http://pastebin.com/dCDTAtnS ACK """ See the full comment at https://github.com/freeipa/freeipa/pull/377#issuecomment-272147569 From freeipa-github-notification at redhat.com Thu Jan 12 12:08:19 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 13:08:19 +0100 Subject: [Freeipa-devel] [freeipa PR#377][+ack] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent Label: +ack From slaznick at redhat.com Thu Jan 12 12:15:27 2017 From: slaznick at redhat.com (Standa Laznicka) Date: Thu, 12 Jan 2017 13:15:27 +0100 Subject: [Freeipa-devel] Changed SSH public key fingerprint to SHA256 Message-ID: <414d01c0-2648-b1fb-5ca6-58c10dfd8345@redhat.com> Hello list, In PR https://github.com/freeipa/freeipa/pull/385 we changed the hashing algorithm for SSH public key fingerprints which are printed for hosts/users in their respective show commands. These fingerprints are not stored anywhere and are calculated during runtime on demand. We did the mentioned change to move from MD5 use of which breaks IPA in FIPS. Also, SHA256 (along with MD5) fingerprints are now printed by default in Fedora 25 when trying to connect to a new host via ssh. If you think this could break some use-case, please, share your concern. Have a nice day, Standa From freeipa-github-notification at redhat.com Thu Jan 12 12:19:13 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 12 Jan 2017 13:19:13 +0100 Subject: [Freeipa-devel] [freeipa PR#392][opened] Fix coverity issue Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Author: tomaskrizek Title: #392: Fix coverity issue Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/392/head:pr392 git checkout pr392 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-392.patch Type: text/x-diff Size: 1021 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 13:07:52 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 14:07:52 +0100 Subject: [Freeipa-devel] [freeipa PR#392][comment] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Title: #392: Fix coverity issue mbasti-rh commented: """ Could be commit message more descriptive or at least any? """ See the full comment at https://github.com/freeipa/freeipa/pull/392#issuecomment-272158709 From freeipa-github-notification at redhat.com Thu Jan 12 13:36:09 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 14:36:09 +0100 Subject: [Freeipa-devel] [freeipa PR#367][synchronized] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Author: stlaz Title: #367: Remove nsslib from IPA Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/367/head:pr367 git checkout pr367 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-367.patch Type: text/x-diff Size: 53274 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 14:01:35 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Thu, 12 Jan 2017 15:01:35 +0100 Subject: [Freeipa-devel] [freeipa PR#391][+ack] ipapython: Add dependencies on version.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/391 Title: #391: ipapython: Add dependencies on version.py Label: +ack From freeipa-github-notification at redhat.com Thu Jan 12 14:02:11 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 15:02:11 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ @rcritten I spoke to the NSS people who assured me it's the intended behavior. But thanks for the remainder, I will open a Bugzilla for that as well, I was considering it before Christmas. **edit:** https://bugzilla.redhat.com/show_bug.cgi?id=1410143 """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-270383517 From freeipa-github-notification at redhat.com Thu Jan 12 14:09:17 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Thu, 12 Jan 2017 15:09:17 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ Thanks @HonzaCholasta I already fixed the service thing but didn't push as I started getting another error on install, buit before I fix that I am working on releasing gssproxy where wer are hitting another heisenbug just in the testing suite (works as expected when installed). On the ldapi error I have seen it too during development, for a period I was getting it every time once on install ie: install, play, uninstall, install, Error!, uninstall, install, play ... So I had to install - uninstall - reinstall for each test, but it had disappeared for a while. It seem some uninstall snag to me, if I can find some info on why it occurs I'll open a bug (or fix it if it is due to my code changes). """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-272171891 From freeipa-github-notification at redhat.com Thu Jan 12 14:12:31 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Thu, 12 Jan 2017 15:12:31 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values gkaihorodova commented: """ @mbasti-rh done. hope now it's fine """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-272172666 From freeipa-github-notification at redhat.com Thu Jan 12 14:21:03 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Thu, 12 Jan 2017 15:21:03 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ Wait, you added support for SSLv2? Please remove it, it isn't needed even for backwards compatibility and would not be considered a regression. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272174784 From freeipa-github-notification at redhat.com Thu Jan 12 14:29:58 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 12 Jan 2017 15:29:58 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA tiran commented: """ @rcritten I wonder if we need to support any version except TLS 1.2 at all. Are there any versions of FreeIPA stack that do not have TLS 1.2 support? """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272176995 From tkrizek at redhat.com Thu Jan 12 14:34:45 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Thu, 12 Jan 2017 15:34:45 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> Message-ID: <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> On 12/19/2016 04:41 PM, Standa Laznicka wrote: > On 12/19/2016 03:07 PM, John Dennis wrote: >> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>> Standa Laznicka wrote: >>>>> Hello, >>>>> >>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>> >>>>> Me and Tom?? are still investigating what of all things will need to >>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>> managed >>>>> to install and run patched FreeIPA server and client and connect them >>>>> together. >>>>> >>>>> There are some issues with NSS when trying to create an HTTPS request >>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>> connection). I am actually thinking of removing NSSConnection from >>>>> the >>>>> client altogether. >>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>> access to a private key. What connection(s) are you talking about, and >>>> what would you replace NSSConnection with? >>>> >>>> rob >>> >>> Hello Rob, >>> >>> Thank you for this excellent question, in order to cut the email >>> short I >>> seem to have omitted quite a few information. >>> >>> One of the very first problems I had with FreeIPA with FIPS was that >>> NSS >>> was always asking for password/pin. I was discussing this with the NSS >>> guys on their IRC chat last week and it turns out that NSS tries to >>> create a private key every time you want to use it as a backend for an >>> SSL connection on FIPS. I still don't think this is quite right so I >>> may >>> open a bugzilla for that. >> >> I don't understand, I thought the case you were having problems with >> was the FreeIPA client, not the server. I assume when you use the >> term "backend" you mean server, and yes when NSS is in server mode it >> will access to keys. So isn't the problem NSS is not being >> initialized correctly so that it recognizes it is in client mode and >> not server mode? >> > What I meant was "a client backend for an SSL connection" - we're > using NSS implementation of SSL (via python-nss) for HTTPS connections > from client to server during which we're getting a CA cert from an NSS > database but this eventually leads to a password prompt. >>> >>> Anyway, the guys suggested me that we could try to create the database >>> with an empty password and everything will work. I don't quite like >>> that, too, but it's at least something if you don't want the `ipa` >>> command to always bug you for password you have no way knowing if >>> you're >>> just a regular user. >>> >>> What I think would be a better way to go is to use >>> httplib.HTTPSConnection. We have the needed certificates in >>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>> with Honza this morning and it seems that with this approach we may get >>> rid of the NSSConnection class altogether (although I still need to >>> check a few spots) and start the process of moving away from NSS which >>> was discussed some year ago in an internal mailing list (for some >>> reason). >>> >>> Will be happy to hear thoughts on this, >>> Standa >> >> I'm not a big fan of NSS, it has it's issues. As the author of the >> Python binding I'm quite aware of all the nasty behaviors NSS has and >> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >> has it's own issues too. If you remove NSS you're also removing the >> option to support smart cards, HSM's etc. Perhaps before removing >> functionality it would be good to assess what the requirements are. >> > I'm sorry I generalized too much, the original topic was moving away > from python-nss (of which I am even more sorry as you're the author). > We could use some ideas on how to handle replica installations in FIPS. We might use some flag in LDAP to indicate that a topology is FIPS-enabled. It seems like a good idea to force all servers in FIPS-enabled topology to also be FIPS-enabled. At the start of replica installation, a check could be performed to verify the FIPS topology status is the same as the current system's FIPS status. However, this proposal has a flaw. It is possible to simply install a FIPS-enabled replica and then turn FIPS off. This would result in non-FIPS systems being part of a FIPS-enabled topology. So we have a couple questions: Does it make sense to require all the servers in the topology to be either FIPS-enabled or FIPS-disabled? What would be a good approach to achieve this? Simply checking during installation does not guarantee that FIPS will stay turned on. -- Tomas Krizek From freeipa-github-notification at redhat.com Thu Jan 12 14:37:30 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 12 Jan 2017 15:37:30 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA tiran commented: """ Let's not make @stlaz jump through more bike-shedding hoops. How about we let him finish this PR, and then address TLS versions, ciphers and other simplifications in another PR? """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272178840 From freeipa-github-notification at redhat.com Thu Jan 12 14:50:05 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 12 Jan 2017 15:50:05 +0100 Subject: [Freeipa-devel] [freeipa PR#392][synchronized] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Author: tomaskrizek Title: #392: Fix coverity issue Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/392/head:pr392 git checkout pr392 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-392.patch Type: text/x-diff Size: 1133 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 14:52:03 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 12 Jan 2017 15:52:03 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA stlaz commented: """ @rcritten `tls_version_min/max` could have been set to "ssl2" just as well as "ssl3" but perhaps it's for the best to remove them. I will try to do the certmonger part and will remove this with it. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272182713 From cheimes at redhat.com Thu Jan 12 14:53:37 2017 From: cheimes at redhat.com (Christian Heimes) Date: Thu, 12 Jan 2017 15:53:37 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> Message-ID: On 2016-12-19 15:07, John Dennis wrote: > I'm not a big fan of NSS, it has it's issues. As the author of the > Python binding I'm quite aware of all the nasty behaviors NSS has and > needs to be worked around. I wouldn't be sad to see it go but OpenSSL > has it's own issues too. If you remove NSS you're also removing the > option to support smart cards, HSM's etc. Perhaps before removing > functionality it would be good to assess what the requirements are. When Standa started to work on the PR, I raised similar concerns regarding the feature set of OpenSSL. I asked him to write a design spec to address some of the concerns. HSM and smart card authentication are of no concern. Standa's PR replaces FreeIPA's internal HTTS connection with a OpenSSL based implementation. It's used to communicate from an IPA client to an IPA server or from an IPA server to Dogtag. We don't support client cert auth for client to server. Smart card authentication is performed based on pkinit and Kerberos. Currently just IPA server to Dogtag uses client cert authentication. That part will be replaced with GSSAPI eventually. I'm more concerned that we loose the ability to check revocation state of certificates. Python's ssl module has no support for OCSP. OpenSSL's and Python's CRL capabilities are sub-par compared to NSS. The ssl module can load CRLs but it has no means to retrieve or update a CRL from a remote server. For Fedora 26 we will have to deal with similar concerns for libldap. Fedora has switched from NSS to OpenSSL as TLS backend. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Jan 12 15:17:56 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jan 2017 10:17:56 -0500 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> Message-ID: <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> Tomas Krizek wrote: > On 12/19/2016 04:41 PM, Standa Laznicka wrote: >> On 12/19/2016 03:07 PM, John Dennis wrote: >>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>> Standa Laznicka wrote: >>>>>> Hello, >>>>>> >>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>> >>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>> managed >>>>>> to install and run patched FreeIPA server and client and connect them >>>>>> together. >>>>>> >>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>> the >>>>>> client altogether. >>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>> access to a private key. What connection(s) are you talking about, and >>>>> what would you replace NSSConnection with? >>>>> >>>>> rob >>>> >>>> Hello Rob, >>>> >>>> Thank you for this excellent question, in order to cut the email >>>> short I >>>> seem to have omitted quite a few information. >>>> >>>> One of the very first problems I had with FreeIPA with FIPS was that >>>> NSS >>>> was always asking for password/pin. I was discussing this with the NSS >>>> guys on their IRC chat last week and it turns out that NSS tries to >>>> create a private key every time you want to use it as a backend for an >>>> SSL connection on FIPS. I still don't think this is quite right so I >>>> may >>>> open a bugzilla for that. >>> >>> I don't understand, I thought the case you were having problems with >>> was the FreeIPA client, not the server. I assume when you use the >>> term "backend" you mean server, and yes when NSS is in server mode it >>> will access to keys. So isn't the problem NSS is not being >>> initialized correctly so that it recognizes it is in client mode and >>> not server mode? >>> >> What I meant was "a client backend for an SSL connection" - we're >> using NSS implementation of SSL (via python-nss) for HTTPS connections >> from client to server during which we're getting a CA cert from an NSS >> database but this eventually leads to a password prompt. >>>> >>>> Anyway, the guys suggested me that we could try to create the database >>>> with an empty password and everything will work. I don't quite like >>>> that, too, but it's at least something if you don't want the `ipa` >>>> command to always bug you for password you have no way knowing if >>>> you're >>>> just a regular user. >>>> >>>> What I think would be a better way to go is to use >>>> httplib.HTTPSConnection. We have the needed certificates in >>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>> with Honza this morning and it seems that with this approach we may get >>>> rid of the NSSConnection class altogether (although I still need to >>>> check a few spots) and start the process of moving away from NSS which >>>> was discussed some year ago in an internal mailing list (for some >>>> reason). >>>> >>>> Will be happy to hear thoughts on this, >>>> Standa >>> >>> I'm not a big fan of NSS, it has it's issues. As the author of the >>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>> has it's own issues too. If you remove NSS you're also removing the >>> option to support smart cards, HSM's etc. Perhaps before removing >>> functionality it would be good to assess what the requirements are. >>> >> I'm sorry I generalized too much, the original topic was moving away >> from python-nss (of which I am even more sorry as you're the author). >> > We could use some ideas on how to handle replica installations in FIPS. > > We might use some flag in LDAP to indicate that a topology is > FIPS-enabled. It seems like a good idea to force all servers in > FIPS-enabled topology to also be FIPS-enabled. At the start of replica > installation, a check could be performed to verify the FIPS topology > status is the same as the current system's FIPS status. However, this > proposal has a flaw. It is possible to simply install a FIPS-enabled > replica and then turn FIPS off. This would result in non-FIPS systems > being part of a FIPS-enabled topology. > > So we have a couple questions: > > Does it make sense to require all the servers in the topology to be > either FIPS-enabled or FIPS-disabled? > What would be a good approach to achieve this? Simply checking during > installation does not guarantee that FIPS will stay turned on. > You could set some value in the replicated tree on FIPS status and write a 389-ds plugin to refuse to start if the environment doesn't match. Given this is started first it should cause a cascade of failures so no services are available. rob From freeipa-github-notification at redhat.com Thu Jan 12 15:34:41 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 16:34:41 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: mbasti-rh Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 32461 bytes Desc: not available URL: From abokovoy at redhat.com Thu Jan 12 15:51:32 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Jan 2017 17:51:32 +0200 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> Message-ID: <20170112155132.zxahglf353ldzko2@redhat.com> On to, 12 tammi 2017, Christian Heimes wrote: >On 2016-12-19 15:07, John Dennis wrote: >> I'm not a big fan of NSS, it has it's issues. As the author of the >> Python binding I'm quite aware of all the nasty behaviors NSS has and >> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >> has it's own issues too. If you remove NSS you're also removing the >> option to support smart cards, HSM's etc. Perhaps before removing >> functionality it would be good to assess what the requirements are. > >When Standa started to work on the PR, I raised similar concerns >regarding the feature set of OpenSSL. I asked him to write a design spec >to address some of the concerns. > >HSM and smart card authentication are of no concern. Standa's PR >replaces FreeIPA's internal HTTS connection with a OpenSSL based >implementation. It's used to communicate from an IPA client to an IPA >server or from an IPA server to Dogtag. We don't support client cert >auth for client to server. Smart card authentication is performed based >on pkinit and Kerberos. Currently just IPA server to Dogtag uses client >cert authentication. That part will be replaced with GSSAPI eventually. We are adding client cert authentication in 4.5. This is pretty big part of the release, actually, as we are getting external authentication and privilege separation support. See Simo's PR#314 which is very close to be merged. We don't plan yet to use this for IPA client itself, but nothing prevent clients other than web browsers to utilize client cert auth to establish TLS session authentication. In fact, this is something which most likely will be used for external entities anyway. >I'm more concerned that we loose the ability to check revocation state >of certificates. Python's ssl module has no support for OCSP. OpenSSL's >and Python's CRL capabilities are sub-par compared to NSS. The ssl >module can load CRLs but it has no means to retrieve or update a CRL >from a remote server. > >For Fedora 26 we will have to deal with similar concerns for libldap. >Fedora has switched from NSS to OpenSSL as TLS backend. > >Christian > >-- >Manage your subscription for the Freeipa-devel mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-devel >Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Thu Jan 12 16:11:53 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Thu, 12 Jan 2017 17:11:53 +0100 Subject: [Freeipa-devel] [freeipa PR#367][comment] Remove nsslib from IPA In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/367 Title: #367: Remove nsslib from IPA rcritten commented: """ SSLv2 should not be supported, period. Not that it would work anyway because most SSL libs have completely removed this support, but it is just a terrible idea to even try and allow it. The rest I'm flexible on. """ See the full comment at https://github.com/freeipa/freeipa/pull/367#issuecomment-272205432 From freeipa-github-notification at redhat.com Thu Jan 12 17:57:17 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 18:57:17 +0100 Subject: [Freeipa-devel] [freeipa PR#393][opened] [WIP] Py3 allow to run wsgi Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: opened PR body: """ With these patches we can run commands with server running on py3 Note: to use py3 install module `python3-mod_wsgi` that enables py3 wsgi automatically Note: this may or may not depend (I haven't tested) on my PR #382 so it contains all patches, will be rebased when PR #382 merged WSGI related patches py3: session.py decode server name to str ?? 7ff4b83 py3: rpcserver: decode input because json requires string ?? a754021 Py3: Fix undefined variable ?? 5b4c9d8 py3: session: fix r/w ccache data ?? 985deaf py3: WSGI executioners must return bytes in list ?? acedc31 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 38280 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 12 17:57:35 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 18:57:35 +0100 Subject: [Freeipa-devel] [freeipa PR#393][edited] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: edited Changed field: body Original value: """ With these patches we can run commands with server running on py3 Note: to use py3 install module `python3-mod_wsgi` that enables py3 wsgi automatically Note: this may or may not depend (I haven't tested) on my PR #382 so it contains all patches, will be rebased when PR #382 merged WSGI related patches py3: session.py decode server name to str ?? 7ff4b83 py3: rpcserver: decode input because json requires string ?? a754021 Py3: Fix undefined variable ?? 5b4c9d8 py3: session: fix r/w ccache data ?? 985deaf py3: WSGI executioners must return bytes in list ?? acedc31 """ From freeipa-github-notification at redhat.com Thu Jan 12 18:41:55 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Thu, 12 Jan 2017 19:41:55 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 41058 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 13 04:06:36 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Fri, 13 Jan 2017 05:06:36 +0100 Subject: [Freeipa-devel] [freeipa PR#394][opened] Add fix for ipa plugins command Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Author: Akasurde Title: #394: Add fix for ipa plugins command Action: opened PR body: """ Fix adds count of plugins loaded to return dict Fixes https://fedorahosted.org/freeipa/ticket/6513 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/394/head:pr394 git checkout pr394 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-394.patch Type: text/x-diff Size: 680 bytes Desc: not available URL: From ftweedal at redhat.com Fri Jan 13 06:21:16 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 13 Jan 2017 16:21:16 +1000 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs Message-ID: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> In ca_add.pre_callback, we have: if not ldap.can_add(dn[1:]): raise ACIError(...) `can_add' uses the GetEffectiveRights control to see what rights the user has. When a user with the 'System: Add CA' permission attempts to add a CA, the above ACIError gets raised. This is definitely a bug. I think it is a bug in DS GetEffectiveRights code. The ACI in play is: dn: cn=cas,cn=ca,dc=ipa,dc=local aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System : Add CA";allow (add) groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn= pbac,dc=ipa,dc=local";) ... The user definitely has the right membership: dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local memberof: cn=LWCA Administration,cn=privileges,cn=pbac,dc=ipa,dc=local memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local William suggested I check whether direct vs. indirect membership made a difference. It does not. A wild guess is that the algorithm that computes whether the subject has add access under the given entry does not take the targetfilter into account. To solve, perhaps we could ignore ACI targetfilter when computing add access for GER. Alternatively, is there another way for a user to determine if they can add an entry at a particular place, without actually doing the add? Thanks, Fraser From ftweedal at redhat.com Fri Jan 13 07:07:13 2017 From: ftweedal at redhat.com (Fraser Tweedale) Date: Fri, 13 Jan 2017 17:07:13 +1000 Subject: [Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag Message-ID: <20170113070713.GG4539@dhcp-40-8.bne.redhat.com> Related to design: http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication Currently there are some operations that hit the CA that involve a number of privileged operations against the CA, but for which there is only one associated IPA permission. Deleting a CA is a good example (but it is one specific case of a more general issue). Summary of current ca-del behaviour: 1. Disable LWCA in Dogtag (uses RA Agent cert) 2. Delete LWCA in Dogtag (uses RA Agent cert) 3. Delete CA entry from IPA (requires "System: Delete CA" permission) So there are two things going on under the hood: a modify operation (disable CA) and the delete. When we implement proxy authentication to Dogtag, Dogtag will enforce the IPA permissions on its operations. Disable will map to "System: Modify CA" and delete to "System: Delete CA". So to delete a CA a user will need *both* permissions. Which could be surprising. There are a couple of reasonable approaches to this. 1. Decouple the disable and delete operations. If CA is not disabled, the user will be instructed to execute the ca-disable command separately before they can disable the CA. This introduces an additional manual step for operators. 2. Just improve the error reporting. In my WIP, for a user that has 'System: Delete CA' permission but not 'System: Modify CA', the reported failure is a 403 Authorization Error from Dogtag. We can add guards to fail more gracefully. I lean towards #2 because I guess the common case will be that users either get all CA admin permissions, or none, and we don't want to make more work (in the form of more commands to run) for users in the common case. I welcome alternative views and suggestions. Thanks, Fraser From freeipa-github-notification at redhat.com Fri Jan 13 07:57:52 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Fri, 13 Jan 2017 08:57:52 +0100 Subject: [Freeipa-devel] [freeipa PR#395][opened] Configure PKI ajp redirection to use "localhost" instead of "::1" Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Author: flo-renaud Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" Action: opened PR body: """ When ipa-server-install configures PKI, it provides a configuration file with the parameter pki_ajp_host set to ::1. This parameter is used to configure Tomcat redirection in /etc/pki/pki-tomcat/server.xml: ie all requests to port 8009 are redirected to port 8443 on address ::1. If the /etc/hosts config file does not define ::1 for localhost, then AJP redirection fails and replica install is not able to request a certificate for the replica. Using "localhost" instead works with IPv4 or IPv6. https://fedorahosted.org/freeipa/ticket/6575 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/395/head:pr395 git checkout pr395 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-395.patch Type: text/x-diff Size: 1495 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 13 08:06:25 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Fri, 13 Jan 2017 09:06:25 +0100 Subject: [Freeipa-devel] [freeipa PR#384][comment] Add fix for user prompt in dnsrecord-add In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/384 Title: #384: Add fix for user prompt in dnsrecord-add HonzaCholasta commented: """ I'm afraid this is not a proper fix, as it introduces a regression in CLI behavior. A proper fix would be to use correct argument names - in the trace in the ticket it says `a_part_create_reverse`, but it should be `a_extra_create_reverse`. """ See the full comment at https://github.com/freeipa/freeipa/pull/384#issuecomment-272384334 From tbordaz at redhat.com Fri Jan 13 08:12:09 2017 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 13 Jan 2017 09:12:09 +0100 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs In-Reply-To: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> References: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> Message-ID: <58788BD9.8020904@redhat.com> Hi Fraser, I failed to reproduce you test case, I mean the aci granted the add right to a group member to ADD an entry with the filtered attribute. Now I have a doubt to test attribute valule on an entry that does not yet exist. Would you run /usr/lib64/mozldap/ldapsearch -D "cn=directory manager" W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=alice,cn=users,cn=accounts,dc=ipa,dc=local" "(objectclass=*)" to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local Also you may replay your test case with ACL logs (http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), nsslapd-errorlog-level: 262272 thanks thierry On 01/13/2017 07:21 AM, Fraser Tweedale wrote: > In ca_add.pre_callback, we have: > > if not ldap.can_add(dn[1:]): > raise ACIError(...) > > `can_add' uses the GetEffectiveRights control to see what rights the > user has. > > When a user with the 'System: Add CA' permission attempts to add a > CA, the above ACIError gets raised. This is definitely a bug. I > think it is a bug in DS GetEffectiveRights code. > > The ACI in play is: > > dn: cn=cas,cn=ca,dc=ipa,dc=local > aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System > : Add CA";allow (add) groupdn = "ldap:///cn=System: Add CA,cn=permissions,cn= > pbac,dc=ipa,dc=local";) > ... > > The user definitely has the right membership: > > dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local > memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local > memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local > memberof: cn=LWCA Administration,cn=privileges,cn=pbac,dc=ipa,dc=local > memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local > > William suggested I check whether direct vs. indirect membership > made a difference. It does not. > > A wild guess is that the algorithm that computes whether the subject > has add access under the given entry does not take the targetfilter > into account. To solve, perhaps we could ignore ACI targetfilter when > computing add access for GER. > > Alternatively, is there another way for a user to determine if they > can add an entry at a particular place, without actually doing the > add? > > Thanks, > Fraser From freeipa-github-notification at redhat.com Fri Jan 13 09:32:35 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 13 Jan 2017 10:32:35 +0100 Subject: [Freeipa-devel] [freeipa PR#347][synchronized] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Author: martbab Title: #347: Improvements in {get|set}_directive functions Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/347/head:pr347 git checkout pr347 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-347.patch Type: text/x-diff Size: 11339 bytes Desc: not available URL: From lkrispen at redhat.com Fri Jan 13 10:01:29 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 13 Jan 2017 11:01:29 +0100 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs In-Reply-To: <58788BD9.8020904@redhat.com> References: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> <58788BD9.8020904@redhat.com> Message-ID: <5878A579.8020807@redhat.com> Hi, if you look at: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html#ex-ger-non-entry then it looks like you can provide GER a bit of information eg objectclass of the new entry, so that the existing aci would be selected. Maybe can_add can be extended. Ludwig On 01/13/2017 09:12 AM, thierry bordaz wrote: > Hi Fraser, > > I failed to reproduce you test case, I mean the aci granted the add > right to a group member to ADD an entry with the filtered attribute. > Now I have a doubt to test attribute valule on an entry that does not > yet exist. > > Would you run /usr/lib64/mozldap/ldapsearch -D "cn=directory > manager" W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J > "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=alice,cn=users,cn=accounts,dc=ipa,dc=local" > "(objectclass=*)" > > to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local > > Also you may replay your test case with ACL logs > (http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), > nsslapd-errorlog-level: 262272 > > > thanks > thierry > On 01/13/2017 07:21 AM, Fraser Tweedale wrote: >> In ca_add.pre_callback, we have: >> >> if not ldap.can_add(dn[1:]): >> raise ACIError(...) >> >> `can_add' uses the GetEffectiveRights control to see what rights the >> user has. >> >> When a user with the 'System: Add CA' permission attempts to add a >> CA, the above ACIError gets raised. This is definitely a bug. I >> think it is a bug in DS GetEffectiveRights code. >> >> The ACI in play is: >> >> dn: cn=cas,cn=ca,dc=ipa,dc=local >> aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl >> "permission:System >> : Add CA";allow (add) groupdn = "ldap:///cn=System: Add >> CA,cn=permissions,cn= >> pbac,dc=ipa,dc=local";) >> ... >> >> The user definitely has the right membership: >> >> dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local >> memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local >> memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local >> memberof: cn=LWCA >> Administration,cn=privileges,cn=pbac,dc=ipa,dc=local >> memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local >> >> William suggested I check whether direct vs. indirect membership >> made a difference. It does not. >> >> A wild guess is that the algorithm that computes whether the subject >> has add access under the given entry does not take the targetfilter >> into account. To solve, perhaps we could ignore ACI targetfilter when >> computing add access for GER. >> >> Alternatively, is there another way for a user to determine if they >> can add an entry at a particular place, without actually doing the >> add? >> >> Thanks, >> Fraser > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From freeipa-github-notification at redhat.com Fri Jan 13 11:37:12 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 13 Jan 2017 12:37:12 +0100 Subject: [Freeipa-devel] [freeipa PR#396][opened] Explicitly remove support of SSLv2 Message-ID: URL: https://github.com/freeipa/freeipa/pull/396 Author: stlaz Title: #396: Explicitly remove support of SSLv2 Action: opened PR body: """ It was possible to set tls_version_min/max to 'ssl2', even though newer versions of NSS will fail to set this as a valid TLS version. This patch explicitly checks for deprecated TLS versions prior to creating a TLS connection. https://fedorahosted.org/freeipa/ticket/6607 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/396/head:pr396 git checkout pr396 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-396.patch Type: text/x-diff Size: 3516 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 13 11:44:38 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 13 Jan 2017 12:44:38 +0100 Subject: [Freeipa-devel] [freeipa PR#377][comment] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent stlaz commented: """ This PR can be safely pushed, an unknown upstream contributor with the same github nick as me will later create a PR with the proposed classmethod change. """ See the full comment at https://github.com/freeipa/freeipa/pull/377#issuecomment-272425065 From freeipa-github-notification at redhat.com Fri Jan 13 13:09:57 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 13 Jan 2017 14:09:57 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 48826 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 13 13:12:28 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 13 Jan 2017 14:12:28 +0100 Subject: [Freeipa-devel] [freeipa PR#393][edited] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: edited Changed field: body Original value: """ With these patches we can run commands with server running on py3 Note: to use py3 install module `python3-mod_wsgi` that enables py3 wsgi automatically Note: this may or may not depend (I haven't tested) on my PR #382 so it contains all patches, will be rebased when PR #382 merged WSGI related patches - py3: session.py decode server name to str ?? 7ff4b83 - py3: rpcserver: decode input because json requires string ?? a754021 - Py3: Fix undefined variable ?? 5b4c9d8 - py3: session: fix r/w ccache data ?? 985deaf - py3: WSGI executioners must return bytes in list ?? acedc31 """ From freeipa-github-notification at redhat.com Fri Jan 13 14:35:41 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Fri, 13 Jan 2017 15:35:41 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tomaskrizek commented: """ The fix solves [ticket #6575](https://fedorahosted.org/freeipa/ticket/6575), but I once again encountered [ticket #4291](https://fedorahosted.org/freeipa/ticket/4291): In pure IPv6 environments, the CA fails to start at the end of IPA server installation. I'm not sure why that happens, since `localhost` does correctly resolve to `::1` when using `getent hosts localhost`. Flo is investigating and trying to reproduce the issue. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272456955 From tkrizek at redhat.com Fri Jan 13 14:45:05 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Fri, 13 Jan 2017 15:45:05 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> Message-ID: On 01/12/2017 04:17 PM, Rob Crittenden wrote: > Tomas Krizek wrote: >> On 12/19/2016 04:41 PM, Standa Laznicka wrote: >>> On 12/19/2016 03:07 PM, John Dennis wrote: >>>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>>> Standa Laznicka wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>>> >>>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>>> managed >>>>>>> to install and run patched FreeIPA server and client and connect them >>>>>>> together. >>>>>>> >>>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>>> the >>>>>>> client altogether. >>>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>>> access to a private key. What connection(s) are you talking about, and >>>>>> what would you replace NSSConnection with? >>>>>> >>>>>> rob >>>>> Hello Rob, >>>>> >>>>> Thank you for this excellent question, in order to cut the email >>>>> short I >>>>> seem to have omitted quite a few information. >>>>> >>>>> One of the very first problems I had with FreeIPA with FIPS was that >>>>> NSS >>>>> was always asking for password/pin. I was discussing this with the NSS >>>>> guys on their IRC chat last week and it turns out that NSS tries to >>>>> create a private key every time you want to use it as a backend for an >>>>> SSL connection on FIPS. I still don't think this is quite right so I >>>>> may >>>>> open a bugzilla for that. >>>> I don't understand, I thought the case you were having problems with >>>> was the FreeIPA client, not the server. I assume when you use the >>>> term "backend" you mean server, and yes when NSS is in server mode it >>>> will access to keys. So isn't the problem NSS is not being >>>> initialized correctly so that it recognizes it is in client mode and >>>> not server mode? >>>> >>> What I meant was "a client backend for an SSL connection" - we're >>> using NSS implementation of SSL (via python-nss) for HTTPS connections >>> from client to server during which we're getting a CA cert from an NSS >>> database but this eventually leads to a password prompt. >>>>> Anyway, the guys suggested me that we could try to create the database >>>>> with an empty password and everything will work. I don't quite like >>>>> that, too, but it's at least something if you don't want the `ipa` >>>>> command to always bug you for password you have no way knowing if >>>>> you're >>>>> just a regular user. >>>>> >>>>> What I think would be a better way to go is to use >>>>> httplib.HTTPSConnection. We have the needed certificates in >>>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>>> with Honza this morning and it seems that with this approach we may get >>>>> rid of the NSSConnection class altogether (although I still need to >>>>> check a few spots) and start the process of moving away from NSS which >>>>> was discussed some year ago in an internal mailing list (for some >>>>> reason). >>>>> >>>>> Will be happy to hear thoughts on this, >>>>> Standa >>>> I'm not a big fan of NSS, it has it's issues. As the author of the >>>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>>> has it's own issues too. If you remove NSS you're also removing the >>>> option to support smart cards, HSM's etc. Perhaps before removing >>>> functionality it would be good to assess what the requirements are. >>>> >>> I'm sorry I generalized too much, the original topic was moving away >>> from python-nss (of which I am even more sorry as you're the author). >>> >> We could use some ideas on how to handle replica installations in FIPS. >> >> We might use some flag in LDAP to indicate that a topology is >> FIPS-enabled. It seems like a good idea to force all servers in >> FIPS-enabled topology to also be FIPS-enabled. At the start of replica >> installation, a check could be performed to verify the FIPS topology >> status is the same as the current system's FIPS status. However, this >> proposal has a flaw. It is possible to simply install a FIPS-enabled >> replica and then turn FIPS off. This would result in non-FIPS systems >> being part of a FIPS-enabled topology. >> >> So we have a couple questions: >> >> Does it make sense to require all the servers in the topology to be >> either FIPS-enabled or FIPS-disabled? >> What would be a good approach to achieve this? Simply checking during >> installation does not guarantee that FIPS will stay turned on. >> > You could set some value in the replicated tree on FIPS status and write > a 389-ds plugin to refuse to start if the environment doesn't match. > Given this is started first it should cause a cascade of failures so no > services are available. > > rob Based on an offline discussion, we might just omit this feature entirely. Our goal is to enable FreeIPA installation of FIPS configured systems. It should be up to the customer to make sure other FIPS requirements are met, i.e. all servers are configured to use FIPS. -- Tomas Krizek From rcritten at redhat.com Fri Jan 13 14:49:37 2017 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jan 2017 09:49:37 -0500 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> Message-ID: <859df0d5-f002-2b22-9336-5ca904a35ecd@redhat.com> Tomas Krizek wrote: > On 01/12/2017 04:17 PM, Rob Crittenden wrote: >> Tomas Krizek wrote: >>> On 12/19/2016 04:41 PM, Standa Laznicka wrote: >>>> On 12/19/2016 03:07 PM, John Dennis wrote: >>>>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>>>> Standa Laznicka wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>>>> >>>>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>>>> managed >>>>>>>> to install and run patched FreeIPA server and client and connect them >>>>>>>> together. >>>>>>>> >>>>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>>>> the >>>>>>>> client altogether. >>>>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>>>> access to a private key. What connection(s) are you talking about, and >>>>>>> what would you replace NSSConnection with? >>>>>>> >>>>>>> rob >>>>>> Hello Rob, >>>>>> >>>>>> Thank you for this excellent question, in order to cut the email >>>>>> short I >>>>>> seem to have omitted quite a few information. >>>>>> >>>>>> One of the very first problems I had with FreeIPA with FIPS was that >>>>>> NSS >>>>>> was always asking for password/pin. I was discussing this with the NSS >>>>>> guys on their IRC chat last week and it turns out that NSS tries to >>>>>> create a private key every time you want to use it as a backend for an >>>>>> SSL connection on FIPS. I still don't think this is quite right so I >>>>>> may >>>>>> open a bugzilla for that. >>>>> I don't understand, I thought the case you were having problems with >>>>> was the FreeIPA client, not the server. I assume when you use the >>>>> term "backend" you mean server, and yes when NSS is in server mode it >>>>> will access to keys. So isn't the problem NSS is not being >>>>> initialized correctly so that it recognizes it is in client mode and >>>>> not server mode? >>>>> >>>> What I meant was "a client backend for an SSL connection" - we're >>>> using NSS implementation of SSL (via python-nss) for HTTPS connections >>>> from client to server during which we're getting a CA cert from an NSS >>>> database but this eventually leads to a password prompt. >>>>>> Anyway, the guys suggested me that we could try to create the database >>>>>> with an empty password and everything will work. I don't quite like >>>>>> that, too, but it's at least something if you don't want the `ipa` >>>>>> command to always bug you for password you have no way knowing if >>>>>> you're >>>>>> just a regular user. >>>>>> >>>>>> What I think would be a better way to go is to use >>>>>> httplib.HTTPSConnection. We have the needed certificates in >>>>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>>>> with Honza this morning and it seems that with this approach we may get >>>>>> rid of the NSSConnection class altogether (although I still need to >>>>>> check a few spots) and start the process of moving away from NSS which >>>>>> was discussed some year ago in an internal mailing list (for some >>>>>> reason). >>>>>> >>>>>> Will be happy to hear thoughts on this, >>>>>> Standa >>>>> I'm not a big fan of NSS, it has it's issues. As the author of the >>>>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>>>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>>>> has it's own issues too. If you remove NSS you're also removing the >>>>> option to support smart cards, HSM's etc. Perhaps before removing >>>>> functionality it would be good to assess what the requirements are. >>>>> >>>> I'm sorry I generalized too much, the original topic was moving away >>>> from python-nss (of which I am even more sorry as you're the author). >>>> >>> We could use some ideas on how to handle replica installations in FIPS. >>> >>> We might use some flag in LDAP to indicate that a topology is >>> FIPS-enabled. It seems like a good idea to force all servers in >>> FIPS-enabled topology to also be FIPS-enabled. At the start of replica >>> installation, a check could be performed to verify the FIPS topology >>> status is the same as the current system's FIPS status. However, this >>> proposal has a flaw. It is possible to simply install a FIPS-enabled >>> replica and then turn FIPS off. This would result in non-FIPS systems >>> being part of a FIPS-enabled topology. >>> >>> So we have a couple questions: >>> >>> Does it make sense to require all the servers in the topology to be >>> either FIPS-enabled or FIPS-disabled? >>> What would be a good approach to achieve this? Simply checking during >>> installation does not guarantee that FIPS will stay turned on. >>> >> You could set some value in the replicated tree on FIPS status and write >> a 389-ds plugin to refuse to start if the environment doesn't match. >> Given this is started first it should cause a cascade of failures so no >> services are available. >> >> rob > Based on an offline discussion, we might just omit this feature > entirely. Our goal is to enable FreeIPA installation of FIPS configured > systems. It should be up to the customer to make sure other FIPS > requirements are met, i.e. all servers are configured to use FIPS. > Up to you but this is bound to be an RFE and seems like quite a weakness to me. You'll want to be sure to enforce that any additional masters get FIPS by default if the initial master has it. In other words, they shouldn't need to remember to pass an option, it should be automatic. rob From freeipa-github-notification at redhat.com Fri Jan 13 14:51:35 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 13 Jan 2017 15:51:35 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tiran commented: """ Bad news, you are out of luck. Dogtag uses its own LDAP connector, which in turn uses JSS (NSS bindings for Java) to provide TLS for LDAP. SSLSocket from ```org.mozilla.jss``` does not support ```AF_INET6``` and is therefore limited to IPv4 connections, https://hg.mozilla.org/projects/jss/file/1a96a08e6f3d/org/mozilla/jss/ssl/SSLSocket.c#l443 The experimental branch of JSS has IPv6 support, https://hg.mozilla.org/projects/jss/file/c76470016016/org/mozilla/jss/ssl/SSLSocket.c#l593, though. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272460844 From freeipa-github-notification at redhat.com Fri Jan 13 15:16:46 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 13 Jan 2017 16:16:46 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tiran commented: """ I have created ticket https://fedorahosted.org/pki/ticket/2575 to track the issue. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272467139 From pvoborni at redhat.com Fri Jan 13 16:44:03 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Jan 2017 17:44:03 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <859df0d5-f002-2b22-9336-5ca904a35ecd@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> <859df0d5-f002-2b22-9336-5ca904a35ecd@redhat.com> Message-ID: <2d4f4629-27f0-86e2-abc9-5455a009cf0c@redhat.com> On 01/13/2017 03:49 PM, Rob Crittenden wrote: > Tomas Krizek wrote: >> On 01/12/2017 04:17 PM, Rob Crittenden wrote: >>> Tomas Krizek wrote: >>>> On 12/19/2016 04:41 PM, Standa Laznicka wrote: >>>>> On 12/19/2016 03:07 PM, John Dennis wrote: >>>>>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>>>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>>>>> Standa Laznicka wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>>>>> >>>>>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>>>>> managed >>>>>>>>> to install and run patched FreeIPA server and client and connect them >>>>>>>>> together. >>>>>>>>> >>>>>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>>>>> the >>>>>>>>> client altogether. >>>>>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>>>>> access to a private key. What connection(s) are you talking about, and >>>>>>>> what would you replace NSSConnection with? >>>>>>>> >>>>>>>> rob >>>>>>> Hello Rob, >>>>>>> >>>>>>> Thank you for this excellent question, in order to cut the email >>>>>>> short I >>>>>>> seem to have omitted quite a few information. >>>>>>> >>>>>>> One of the very first problems I had with FreeIPA with FIPS was that >>>>>>> NSS >>>>>>> was always asking for password/pin. I was discussing this with the NSS >>>>>>> guys on their IRC chat last week and it turns out that NSS tries to >>>>>>> create a private key every time you want to use it as a backend for an >>>>>>> SSL connection on FIPS. I still don't think this is quite right so I >>>>>>> may >>>>>>> open a bugzilla for that. >>>>>> I don't understand, I thought the case you were having problems with >>>>>> was the FreeIPA client, not the server. I assume when you use the >>>>>> term "backend" you mean server, and yes when NSS is in server mode it >>>>>> will access to keys. So isn't the problem NSS is not being >>>>>> initialized correctly so that it recognizes it is in client mode and >>>>>> not server mode? >>>>>> >>>>> What I meant was "a client backend for an SSL connection" - we're >>>>> using NSS implementation of SSL (via python-nss) for HTTPS connections >>>>> from client to server during which we're getting a CA cert from an NSS >>>>> database but this eventually leads to a password prompt. >>>>>>> Anyway, the guys suggested me that we could try to create the database >>>>>>> with an empty password and everything will work. I don't quite like >>>>>>> that, too, but it's at least something if you don't want the `ipa` >>>>>>> command to always bug you for password you have no way knowing if >>>>>>> you're >>>>>>> just a regular user. >>>>>>> >>>>>>> What I think would be a better way to go is to use >>>>>>> httplib.HTTPSConnection. We have the needed certificates in >>>>>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>>>>> with Honza this morning and it seems that with this approach we may get >>>>>>> rid of the NSSConnection class altogether (although I still need to >>>>>>> check a few spots) and start the process of moving away from NSS which >>>>>>> was discussed some year ago in an internal mailing list (for some >>>>>>> reason). >>>>>>> >>>>>>> Will be happy to hear thoughts on this, >>>>>>> Standa >>>>>> I'm not a big fan of NSS, it has it's issues. As the author of the >>>>>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>>>>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>>>>> has it's own issues too. If you remove NSS you're also removing the >>>>>> option to support smart cards, HSM's etc. Perhaps before removing >>>>>> functionality it would be good to assess what the requirements are. >>>>>> >>>>> I'm sorry I generalized too much, the original topic was moving away >>>>> from python-nss (of which I am even more sorry as you're the author). >>>>> >>>> We could use some ideas on how to handle replica installations in FIPS. >>>> >>>> We might use some flag in LDAP to indicate that a topology is >>>> FIPS-enabled. It seems like a good idea to force all servers in >>>> FIPS-enabled topology to also be FIPS-enabled. At the start of replica >>>> installation, a check could be performed to verify the FIPS topology >>>> status is the same as the current system's FIPS status. However, this >>>> proposal has a flaw. It is possible to simply install a FIPS-enabled >>>> replica and then turn FIPS off. This would result in non-FIPS systems >>>> being part of a FIPS-enabled topology. >>>> >>>> So we have a couple questions: >>>> >>>> Does it make sense to require all the servers in the topology to be >>>> either FIPS-enabled or FIPS-disabled? >>>> What would be a good approach to achieve this? Simply checking during >>>> installation does not guarantee that FIPS will stay turned on. >>>> >>> You could set some value in the replicated tree on FIPS status and write >>> a 389-ds plugin to refuse to start if the environment doesn't match. >>> Given this is started first it should cause a cascade of failures so no >>> services are available. >>> >>> rob >> Based on an offline discussion, we might just omit this feature >> entirely. Our goal is to enable FreeIPA installation of FIPS configured >> systems. It should be up to the customer to make sure other FIPS >> requirements are met, i.e. all servers are configured to use FIPS. >> > > Up to you but this is bound to be an RFE and seems like quite a weakness > to me. > > You'll want to be sure to enforce that any additional masters get FIPS > by default if the initial master has it. In other words, they shouldn't > need to remember to pass an option, it should be automatic. > > rob > +1 to Rob. We could operate between the two extremes: * Extreme 1: Ensuring that FIPS will remain enabled on all existing replica. * Extreme 2: Do not validate anything I.e. we could only: * Note in LDAP that first server was installed with FIPS * Check it at install time - prevent from installation of non-FIPS - prevent from installation of FIPS replica in non-FIPS topology It won't be bullet proof but it will check major mistakes which the admin can do by accident. -- Petr Vobornik From freeipa-github-notification at redhat.com Fri Jan 13 16:46:33 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Fri, 13 Jan 2017 17:46:33 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" flo-renaud commented: """ Hi @tomaskrizek, I was not able to reproduce the master install issue. Here are my steps: On the master: ip addr del 127.0.0.1 dev lo ip -4 addr del dev edit /etc/hosts: remove the line 127.0.0.1 localhost ... make sure ::1 localhost ... is defined add a line hostfqdn shortname setenforce 0 ipa-server-install ... The install succeeds. Do you perform the same steps? """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272485379 From tbordaz at redhat.com Fri Jan 13 17:24:37 2017 From: tbordaz at redhat.com (thierry bordaz) Date: Fri, 13 Jan 2017 18:24:37 +0100 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs In-Reply-To: <5878A579.8020807@redhat.com> References: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> <58788BD9.8020904@redhat.com> <5878A579.8020807@redhat.com> Message-ID: <58790D55.5070602@redhat.com> Hello, The option specifies the value of 'objectclass' attribute during the GER. That is evaluated at attributeLevelRights but not at the entryLevelRights. I was not able to fix the test case using this option. For information I opened that ticket https://fedorahosted.org/freeipa/ticket/6609 thanks thierry On 01/13/2017 11:01 AM, Ludwig Krispenz wrote: > Hi, > > if you look at: > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html#ex-ger-non-entry > > then it looks like you can provide GER a bit of information eg > objectclass of the new entry, so that the existing aci would be > selected. Maybe can_add can be extended. > > Ludwig > > On 01/13/2017 09:12 AM, thierry bordaz wrote: >> Hi Fraser, >> >> I failed to reproduce you test case, I mean the aci granted the add >> right to a group member to ADD an entry with the filtered attribute. >> Now I have a doubt to test attribute valule on an entry that does not >> yet exist. >> >> Would you run /usr/lib64/mozldap/ldapsearch -D "cn=directory >> manager" W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J >> "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=alice,cn=users,cn=accounts,dc=ipa,dc=local" >> "(objectclass=*)" >> >> to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local >> >> Also you may replay your test case with ACL logs >> (http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), >> nsslapd-errorlog-level: 262272 >> >> >> thanks >> thierry >> On 01/13/2017 07:21 AM, Fraser Tweedale wrote: >>> In ca_add.pre_callback, we have: >>> >>> if not ldap.can_add(dn[1:]): >>> raise ACIError(...) >>> >>> `can_add' uses the GetEffectiveRights control to see what rights the >>> user has. >>> >>> When a user with the 'System: Add CA' permission attempts to add a >>> CA, the above ACIError gets raised. This is definitely a bug. I >>> think it is a bug in DS GetEffectiveRights code. >>> >>> The ACI in play is: >>> >>> dn: cn=cas,cn=ca,dc=ipa,dc=local >>> aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl >>> "permission:System >>> : Add CA";allow (add) groupdn = "ldap:///cn=System: Add >>> CA,cn=permissions,cn= >>> pbac,dc=ipa,dc=local";) >>> ... >>> >>> The user definitely has the right membership: >>> >>> dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local >>> memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local >>> memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local >>> memberof: cn=LWCA >>> Administration,cn=privileges,cn=pbac,dc=ipa,dc=local >>> memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local >>> >>> William suggested I check whether direct vs. indirect membership >>> made a difference. It does not. >>> >>> A wild guess is that the algorithm that computes whether the subject >>> has add access under the given entry does not take the targetfilter >>> into account. To solve, perhaps we could ignore ACI targetfilter when >>> computing add access for GER. >>> >>> Alternatively, is there another way for a user to determine if they >>> can add an entry at a particular place, without actually doing the >>> add? >>> >>> Thanks, >>> Fraser >> > From freeipa-github-notification at redhat.com Fri Jan 13 17:48:52 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Fri, 13 Jan 2017 18:48:52 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" pvoborni commented: """ Btw our goal is not to make pure IPv6 working - this was not tested even before the regression. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272501393 From freeipa-github-notification at redhat.com Fri Jan 13 17:51:33 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Fri, 13 Jan 2017 18:51:33 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" pvoborni commented: """ Possible ways how to fix upgrades are outlined in https://bugzilla.redhat.com/show_bug.cgi?id=1398600#c48 and comment 49. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272502076 From freeipa-github-notification at redhat.com Fri Jan 13 17:56:30 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Fri, 13 Jan 2017 18:56:30 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 51314 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 16 10:46:12 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 16 Jan 2017 11:46:12 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tomaskrizek commented: """ @flo You're right, I'm able to install the IPA server in IPv6 env now. I probably forgot some configuration beforehand. @tiran That's odd. If JSS does not support IPv6 at all, why does `::1` work when IPv6 is enabled? """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272828847 From freeipa-github-notification at redhat.com Mon Jan 16 10:46:17 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 16 Jan 2017 11:46:17 +0100 Subject: [Freeipa-devel] [freeipa PR#395][+ack] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" Label: +ack From freeipa-github-notification at redhat.com Mon Jan 16 10:52:30 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Mon, 16 Jan 2017 11:52:30 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" flo-renaud commented: """ Please wait before merging this PR. @pvoborni Endi suggests 2 possible strategies for the upgrade fix: either in IPA or in PKI. We need to pick one, and depending on the choice modify this PR accordingly. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272830142 From freeipa-github-notification at redhat.com Mon Jan 16 10:54:46 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 16 Jan 2017 11:54:46 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tiran commented: """ @tomaskrizek Upstream doesn't support IPv6. @nkinder told me that our Fedora packages contan several patches. The patches are not yet in upstream. One of the patches adds IPv6 support. I have not checked if the patch provides IPv6 for both client and server sockets or just for SSLSocket. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272830620 From freeipa-github-notification at redhat.com Mon Jan 16 11:02:37 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 16 Jan 2017 12:02:37 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tiran commented: """ @tomaskrizek Upstream doesn't support IPv6. @nkinder told me that our Fedora packages contan several patches. The patches are not yet in upstream. One of the patches adds IPv6 support. I have not checked if the patch provides IPv6 for both client and server sockets or just for SSLSocket. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-272830620 From freeipa-github-notification at redhat.com Mon Jan 16 12:54:58 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 16 Jan 2017 13:54:58 +0100 Subject: [Freeipa-devel] [freeipa PR#351][synchronized] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Author: tomaskrizek Title: #351: [fedora-26] named.conf template: update API for bind 9.11 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/351/head:pr351 git checkout pr351 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-351.patch Type: text/x-diff Size: 8280 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 16 13:37:48 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:37:48 +0100 Subject: [Freeipa-devel] [freeipa PR#377][closed] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Author: HonzaCholasta Title: #377: dogtaginstance: track server certificate with our renew agent Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/377/head:pr377 git checkout pr377 From freeipa-github-notification at redhat.com Mon Jan 16 13:37:50 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:37:50 +0100 Subject: [Freeipa-devel] [freeipa PR#377][comment] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d5af11f65cc2a2d6860579a63a173b67cb12bcf3 https://fedorahosted.org/freeipa/changeset/ad49bda907b3c2ec5b98946a2c4000bb6edaf835 https://fedorahosted.org/freeipa/changeset/926fe2049a1839fd7e68c9fa55f64154ee83c841 """ See the full comment at https://github.com/freeipa/freeipa/pull/377#issuecomment-272863729 From freeipa-github-notification at redhat.com Mon Jan 16 13:37:51 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:37:51 +0100 Subject: [Freeipa-devel] [freeipa PR#377][+pushed] dogtaginstance: track server certificate with our renew agent In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/377 Title: #377: dogtaginstance: track server certificate with our renew agent Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 16 13:41:39 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:41:39 +0100 Subject: [Freeipa-devel] [freeipa PR#391][comment] ipapython: Add dependencies on version.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/391 Title: #391: ipapython: Add dependencies on version.py mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/504f4417070a308ef54b8f98ff25d02c6604a6f6 """ See the full comment at https://github.com/freeipa/freeipa/pull/391#issuecomment-272864550 From freeipa-github-notification at redhat.com Mon Jan 16 13:41:40 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:41:40 +0100 Subject: [Freeipa-devel] [freeipa PR#391][+pushed] ipapython: Add dependencies on version.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/391 Title: #391: ipapython: Add dependencies on version.py Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 16 13:41:42 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:41:42 +0100 Subject: [Freeipa-devel] [freeipa PR#391][closed] ipapython: Add dependencies on version.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/391 Author: tiran Title: #391: ipapython: Add dependencies on version.py Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/391/head:pr391 git checkout pr391 From freeipa-github-notification at redhat.com Mon Jan 16 13:43:21 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:43:21 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 50066 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 16 13:44:09 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:44:09 +0100 Subject: [Freeipa-devel] [freeipa PR#392][+ack] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Title: #392: Fix coverity issue Label: +ack From freeipa-github-notification at redhat.com Mon Jan 16 13:45:15 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:45:15 +0100 Subject: [Freeipa-devel] [freeipa PR#392][+pushed] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Title: #392: Fix coverity issue Label: +pushed From freeipa-github-notification at redhat.com Mon Jan 16 13:45:16 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:45:16 +0100 Subject: [Freeipa-devel] [freeipa PR#392][comment] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Title: #392: Fix coverity issue mbasti-rh commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/49855ca9dea9241ccd88e3a89b499b6fed4493c9 """ See the full comment at https://github.com/freeipa/freeipa/pull/392#issuecomment-272865344 From freeipa-github-notification at redhat.com Mon Jan 16 13:45:18 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:45:18 +0100 Subject: [Freeipa-devel] [freeipa PR#392][closed] Fix coverity issue In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/392 Author: tomaskrizek Title: #392: Fix coverity issue Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/392/head:pr392 git checkout pr392 From freeipa-github-notification at redhat.com Mon Jan 16 13:46:09 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 14:46:09 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) mbasti-rh commented: """ @HonzaCholasta @tiran bump for review """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-272865543 From freeipa-github-notification at redhat.com Mon Jan 16 14:12:55 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 15:12:55 +0100 Subject: [Freeipa-devel] [freeipa PR#378][+ack] Clean / ignore make check artefact In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Title: #378: Clean / ignore make check artefact Label: +ack From freeipa-github-notification at redhat.com Mon Jan 16 14:15:54 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 15:15:54 +0100 Subject: [Freeipa-devel] [freeipa PR#393][edited] [WIP] Py3 allow to run wsgi In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: mbasti-rh Title: #393: [WIP] Py3 allow to run wsgi Action: edited Changed field: title Original value: """ [WIP] Py3 allow to run wsgi """ From freeipa-github-notification at redhat.com Mon Jan 16 14:30:29 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Mon, 16 Jan 2017 15:30:29 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py mbasti-rh commented: """ this script must work only with IPA3.x, so I wouldn't add there anything from 4.4/master code. As I pointed out several times I don't think that this code even should be in master branch, as we are always just fixing regressions there, but rather as separate script, or script in IPA3.x. Unfortunately I haven't got enough support for my idea. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-272875313 From dkupka at redhat.com Mon Jan 16 14:52:28 2017 From: dkupka at redhat.com (David Kupka) Date: Mon, 16 Jan 2017 15:52:28 +0100 Subject: [Freeipa-devel] Stageuser API Message-ID: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Hello everyone! I've noticed that our API for stageuser is missing some commands that user has (stageuser-{add,remove}-{principal,cert}). I was wondering if there is reason for it but after asking some fellows developers it seems that there's none. I understand the stageuser area as a place where user entry can be created and amended during the hiring process in organization, example: 1. HR creates the entry with just basic informations (givenname, surname, manager) 2. IT assigns basic account information (uid, gid) 3. based on to-be-employee manager's request IT adds additional group membership (memberOf) 4. based on to-be-employee request IT adds login alias (krbPrincipalName) 5. Security Officer adds certificate from Smart Card assigned to the to-be-employee 6. HR adds extra information to the account (address, marital status, ...) 7. Facilities update work place related information (seat number, phone number, ...) 8. At the first day IT activates the user account. Considering this work flow I think it might be useful to have the same API for stageuser as for the user. Does the example work flow make sense? Should we provide the same set of commands for user and stageuser? Thanks for your ideas and opinions! -- David Kupka From lkrispen at redhat.com Mon Jan 16 16:09:07 2017 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 16 Jan 2017 17:09:07 +0100 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs In-Reply-To: <58790D55.5070602@redhat.com> References: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> <58788BD9.8020904@redhat.com> <5878A579.8020807@redhat.com> <58790D55.5070602@redhat.com> Message-ID: <587CF023.9090500@redhat.com> On 01/13/2017 06:24 PM, thierry bordaz wrote: > Hello, > > The option specifies the value of 'objectclass' attribute during the > GER. That is evaluated at attributeLevelRights but not at the > entryLevelRights. I was not able to fix the test case using this option. > > For information I opened that ticket > https://fedorahosted.org/freeipa/ticket/6609 I think we need a 389-ds ticket as well. Looking into it, the aci code contains parts to construct a template entry to evaluate access to a non existent entry, but it is not called because either entries are found and processed or the search returns no such object. It should be possible to make this work. > > thanks > thierry > > On 01/13/2017 11:01 AM, Ludwig Krispenz wrote: >> Hi, >> >> if you look at: >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html#ex-ger-non-entry >> >> then it looks like you can provide GER a bit of information eg >> objectclass of the new entry, so that the existing aci would be >> selected. Maybe can_add can be extended. >> >> Ludwig >> >> On 01/13/2017 09:12 AM, thierry bordaz wrote: >>> Hi Fraser, >>> >>> I failed to reproduce you test case, I mean the aci granted the add >>> right to a group member to ADD an entry with the filtered attribute. >>> Now I have a doubt to test attribute valule on an entry that does >>> not yet exist. >>> >>> Would you run /usr/lib64/mozldap/ldapsearch -D "cn=directory >>> manager" W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J >>> "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=alice,cn=users,cn=accounts,dc=ipa,dc=local" >>> "(objectclass=*)" >>> >>> to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local >>> >>> Also you may replay your test case with ACL logs >>> (http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), >>> nsslapd-errorlog-level: 262272 >>> >>> >>> thanks >>> thierry >>> On 01/13/2017 07:21 AM, Fraser Tweedale wrote: >>>> In ca_add.pre_callback, we have: >>>> >>>> if not ldap.can_add(dn[1:]): >>>> raise ACIError(...) >>>> >>>> `can_add' uses the GetEffectiveRights control to see what rights the >>>> user has. >>>> >>>> When a user with the 'System: Add CA' permission attempts to add a >>>> CA, the above ACIError gets raised. This is definitely a bug. I >>>> think it is a bug in DS GetEffectiveRights code. >>>> >>>> The ACI in play is: >>>> >>>> dn: cn=cas,cn=ca,dc=ipa,dc=local >>>> aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl >>>> "permission:System >>>> : Add CA";allow (add) groupdn = "ldap:///cn=System: Add >>>> CA,cn=permissions,cn= >>>> pbac,dc=ipa,dc=local";) >>>> ... >>>> >>>> The user definitely has the right membership: >>>> >>>> dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local >>>> memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local >>>> memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local >>>> memberof: cn=LWCA >>>> Administration,cn=privileges,cn=pbac,dc=ipa,dc=local >>>> memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local >>>> >>>> William suggested I check whether direct vs. indirect membership >>>> made a difference. It does not. >>>> >>>> A wild guess is that the algorithm that computes whether the subject >>>> has add access under the given entry does not take the targetfilter >>>> into account. To solve, perhaps we could ignore ACI targetfilter when >>>> computing add access for GER. >>>> >>>> Alternatively, is there another way for a user to determine if they >>>> can add an entry at a particular place, without actually doing the >>>> add? >>>> >>>> Thanks, >>>> Fraser >>> >> > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander From freeipa-github-notification at redhat.com Mon Jan 16 16:21:48 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 16 Jan 2017 17:21:48 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command martbab commented: """ Thanks the patch makes the command work. However, the namespace names are returned as string, not unicode literals and thus the framework returns them as base64-encoded values: ``` # ipa plugins ipaclient.plugins.automember.automember_add_condition: Q29tbWFuZA==, TWV0aG9k ipaclient.plugins.automount.automountlocation_import: Q29tbWFuZA== ipaclient.plugins.automount.automountlocation_tofiles: Q29tbWFuZA==, TWV0aG9k # echo 'Q29tbWFuZA==' | base64 -d && echo Command # echo '# echo 'TWV0aG9k' | base64 -d && echo Method ``` One way to fix this is to wrap namespace name in `six.test_type`, this should work in both py2 and py3: ```diff diff --git a/ipalib/misc.py b/ipalib/misc.py index 264ec29..6234961 100644 --- a/ipalib/misc.py +++ b/ipalib/misc.py @@ -3,6 +3,9 @@ # import re + +import six + from ipalib import LocalOrRemote, _, ngettext from ipalib.output import Output, summary from ipalib import Flag @@ -124,7 +127,7 @@ class plugins(LocalOrRemote): for plugin in self.api[namespace](): cls = type(plugin) key = '{}.{}'.format(cls.__module__, cls.__name__) - result.setdefault(key, []).append(namespace) + result.setdefault(key, []).append(six.text_type(namespace)) return dict( result=result ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-272905328 From freeipa-github-notification at redhat.com Mon Jan 16 21:06:26 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Mon, 16 Jan 2017 22:06:26 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command rcritten commented: """ How about a test to prevent future regressions? """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-272962038 From freeipa-github-notification at redhat.com Tue Jan 17 06:31:42 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 17 Jan 2017 07:31:42 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py HonzaCholasta commented: """ I agree with @mbasti-rh. IMO we should remove all 4.0+ specific code from the script, add a version check at the beginning and disable all failing pylint checks. Maybe also add a comment at the top saying that the file is not to be modified anymore. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273033336 From freeipa-github-notification at redhat.com Tue Jan 17 06:51:49 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 17 Jan 2017 07:51:49 +0100 Subject: [Freeipa-devel] [freeipa PR#394][synchronized] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Author: Akasurde Title: #394: Add fix for ipa plugins command Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/394/head:pr394 git checkout pr394 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-394.patch Type: text/x-diff Size: 1153 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 06:52:56 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 17 Jan 2017 07:52:56 +0100 Subject: [Freeipa-devel] [freeipa PR#387][comment] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Title: #387: Update warning message for ipa server uninstall Akasurde commented: """ Bump for review """ See the full comment at https://github.com/freeipa/freeipa/pull/387#issuecomment-273036178 From freeipa-github-notification at redhat.com Tue Jan 17 07:11:30 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 17 Jan 2017 08:11:30 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py stlaz commented: """ +1, that was actually my original point. Just revert the change done to the file in https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=d6b755e3fcaf32158f4ee36d45e3344b4a03fbc2, don't add `confdir` option to api.bootstrap() and let the script die in peace. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273038677 From freeipa-github-notification at redhat.com Tue Jan 17 07:38:08 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 08:38:08 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py tiran commented: """ How about we remove the file entirely and just post it on the wiki or something? """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273042550 From dkupka at redhat.com Tue Jan 17 07:57:13 2017 From: dkupka at redhat.com (David Kupka) Date: Tue, 17 Jan 2017 08:57:13 +0100 Subject: [Freeipa-devel] [DESIGN] IPA permission enforcement in Dogtag In-Reply-To: <20170113070713.GG4539@dhcp-40-8.bne.redhat.com> References: <20170113070713.GG4539@dhcp-40-8.bne.redhat.com> Message-ID: <06bccd8a-cebe-4acb-a5af-7c1ed985f313@redhat.com> On 13/01/17 08:07, Fraser Tweedale wrote: > Related to design: > http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication > > Currently there are some operations that hit the CA that involve a > number of privileged operations against the CA, but for which there > is only one associated IPA permission. Deleting a CA is a good > example (but it is one specific case of a more general issue). > Summary of current ca-del behaviour: > > 1. Disable LWCA in Dogtag (uses RA Agent cert) > 2. Delete LWCA in Dogtag (uses RA Agent cert) > 3. Delete CA entry from IPA (requires "System: Delete CA" permission) > > So there are two things going on under the hood: a modify operation > (disable CA) and the delete. > > When we implement proxy authentication to Dogtag, Dogtag will > enforce the IPA permissions on its operations. Disable will map to > "System: Modify CA" and delete to "System: Delete CA". So to delete > a CA a user will need *both* permissions. Which could be > surprising. > > There are a couple of reasonable approaches to this. > > 1. Decouple the disable and delete operations. If CA is not > disabled, the user will be instructed to execute the ca-disable > command separately before they can disable the CA. This introduces > an additional manual step for operators. > > 2. Just improve the error reporting. In my WIP, for a user that has > 'System: Delete CA' permission but not 'System: Modify CA', the > reported failure is a 403 Authorization Error from Dogtag. We can > add guards to fail more gracefully. > > I lean towards #2 because I guess the common case will be that users > either get all CA admin permissions, or none, and we don't want to > make more work (in the form of more commands to run) for users in > the common case. > > I welcome alternative views and suggestions. > > Thanks, > Fraser > Hi Fraser, as a user with "System: Delete CA" permission calling "ca-del" command I would be really surprised that I don't have enough privileges to complete the action. I would expect: a) "Cannot delete active CA, disable it first" error. b) Delete will be completed successfully. All internal and to my sight hidden operations will be allowed just because I'm allowed to perform the delete operation. I think that b) might lead to strange exceptions in authorization checking and therefore to security issues. So I would prefer decoupling ca-disable and ca-del as you're describing in 1). -- David Kupka From freeipa-github-notification at redhat.com Tue Jan 17 08:30:35 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 17 Jan 2017 09:30:35 +0100 Subject: [Freeipa-devel] [freeipa PR#266][synchronized] ipapython: simplify Env object initialization In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/266 Author: HonzaCholasta Title: #266: ipapython: simplify Env object initialization Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/266/head:pr266 git checkout pr266 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-266.patch Type: text/x-diff Size: 31098 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 09:20:34 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 17 Jan 2017 10:20:34 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py martbab commented: """ IIRC @mbasti-rh proposed to maintain the script separately and serve it to users via external repo or something but the idea was rejected. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273062322 From freeipa-github-notification at redhat.com Tue Jan 17 09:41:01 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 17 Jan 2017 10:41:01 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py mbasti-rh commented: """ I proposed 2 ideas: - move it to ipa-3-3 branch (or) - extract that script from freeipa repo and allow to download that script from freeipa.org (and access.redhat.com) """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273067048 From freeipa-github-notification at redhat.com Tue Jan 17 09:50:49 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 10:50:49 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py tiran commented: """ So with *separate script* you meant a separate downloadable version of the script. Got it! :) It seems we have a consent. @mbasti-rh I second your proposal to move it to freeipa.org (that what I meant with wiki) and access.redhat.com. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273071360 From freeipa-github-notification at redhat.com Tue Jan 17 11:00:59 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 17 Jan 2017 12:00:59 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py stlaz commented: """ +1, we need to fix the script first, though. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273108618 From flo at redhat.com Tue Jan 17 11:08:02 2017 From: flo at redhat.com (Florence Blanc-Renaud) Date: Tue, 17 Jan 2017 12:08:02 +0100 Subject: [Freeipa-devel] Stageuser API In-Reply-To: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Message-ID: On 01/16/2017 03:52 PM, David Kupka wrote: > Hello everyone! > > I've noticed that our API for stageuser is missing some commands that > user has (stageuser-{add,remove}-{principal,cert}). I was wondering if > there is reason for it but after asking some fellows developers it seems > that there's none. > > I understand the stageuser area as a place where user entry can be > created and amended during the hiring process in organization, example: > > 1. HR creates the entry with just basic informations (givenname, > surname, manager) > 2. IT assigns basic account information (uid, gid) > 3. based on to-be-employee manager's request IT adds additional group > membership (memberOf) > 4. based on to-be-employee request IT adds login alias (krbPrincipalName) > 5. Security Officer adds certificate from Smart Card assigned to the > to-be-employee > 6. HR adds extra information to the account (address, marital status, ...) > 7. Facilities update work place related information (seat number, phone > number, ...) > 8. At the first day IT activates the user account. > > Considering this work flow I think it might be useful to have the same > API for stageuser as for the user. > > Does the example work flow make sense? > Should we provide the same set of commands for user and stageuser? > > Thanks for your ideas and opinions! Hi David, I would be in favor of providing the same API for stageuser and user. It is already possible to add a certificate or a principal alias to a stageuser with ipa stageuser-mod --cert or ipa stageuser-mod --principal, meaning that those operations are not forbidden. I also checked that a stageuser - is not able to perform kinit with any of his principal aliases - is not able to authenticate to the LDAP server with a DN/pwd - is not able to authenticate to the LDAP server using his SSL cert - is not able to login with user/pwd on a client console so I do not see any security concern with your proposal. Flo. From freeipa-github-notification at redhat.com Tue Jan 17 11:08:08 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 12:08:08 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py tiran commented: """ Or we just grab a working and tested version from an old release. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273110797 From freeipa-github-notification at redhat.com Tue Jan 17 11:11:31 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 17 Jan 2017 12:11:31 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py mbasti-rh commented: """ @tiran +1, but first this has to be generally approved :) topic for meeting maybe (today?) """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273111475 From abokovoy at redhat.com Tue Jan 17 11:17:44 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Jan 2017 13:17:44 +0200 Subject: [Freeipa-devel] Stageuser API In-Reply-To: References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Message-ID: <20170117111744.3gufzd2p5c723vyh@redhat.com> On ti, 17 tammi 2017, Florence Blanc-Renaud wrote: >On 01/16/2017 03:52 PM, David Kupka wrote: >>Hello everyone! >> >>I've noticed that our API for stageuser is missing some commands that >>user has (stageuser-{add,remove}-{principal,cert}). I was wondering if >>there is reason for it but after asking some fellows developers it seems >>that there's none. >> >>I understand the stageuser area as a place where user entry can be >>created and amended during the hiring process in organization, example: >> >>1. HR creates the entry with just basic informations (givenname, >>surname, manager) >>2. IT assigns basic account information (uid, gid) >>3. based on to-be-employee manager's request IT adds additional group >>membership (memberOf) >>4. based on to-be-employee request IT adds login alias (krbPrincipalName) >>5. Security Officer adds certificate from Smart Card assigned to the >>to-be-employee >>6. HR adds extra information to the account (address, marital status, ...) >>7. Facilities update work place related information (seat number, phone >>number, ...) >>8. At the first day IT activates the user account. >> >>Considering this work flow I think it might be useful to have the same >>API for stageuser as for the user. >> >>Does the example work flow make sense? >>Should we provide the same set of commands for user and stageuser? >> >>Thanks for your ideas and opinions! >Hi David, > >I would be in favor of providing the same API for stageuser and user. > >It is already possible to add a certificate or a principal alias to a >stageuser with ipa stageuser-mod --cert or ipa stageuser-mod >--principal, meaning that those operations are not forbidden. > >I also checked that a stageuser >- is not able to perform kinit with any of his principal aliases >- is not able to authenticate to the LDAP server with a DN/pwd >- is not able to authenticate to the LDAP server using his SSL cert >- is not able to login with user/pwd on a client console >so I do not see any security concern with your proposal. Thank you, Flo. Let's then proceed with the David's proposal. For the record, we discussed this proposal on a weekly development call and I raised the questions about authentication above. Florence volunteered to experiment with it to see if SSL certificate authentication would be possible. It is not, so we can unify the API behind both user and stageuser. -- / Alexander Bokovoy From cheimes at redhat.com Tue Jan 17 11:38:14 2017 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 17 Jan 2017 12:38:14 +0100 Subject: [Freeipa-devel] Stageuser API In-Reply-To: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Message-ID: On 2017-01-16 15:52, David Kupka wrote: > Hello everyone! > > I've noticed that our API for stageuser is missing some commands that > user has (stageuser-{add,remove}-{principal,cert}). I was wondering if > there is reason for it but after asking some fellows developers it seems > that there's none. > > I understand the stageuser area as a place where user entry can be > created and amended during the hiring process in organization, example: > > 1. HR creates the entry with just basic informations (givenname, > surname, manager) > 2. IT assigns basic account information (uid, gid) > 3. based on to-be-employee manager's request IT adds additional group > membership (memberOf) > 4. based on to-be-employee request IT adds login alias (krbPrincipalName) > 5. Security Officer adds certificate from Smart Card assigned to the > to-be-employee > 6. HR adds extra information to the account (address, marital status, ...) > 7. Facilities update work place related information (seat number, phone > number, ...) > 8. At the first day IT activates the user account. > > Considering this work flow I think it might be useful to have the same > API for stageuser as for the user. > > Does the example work flow make sense? > Should we provide the same set of commands for user and stageuser? I see one potential issue in your proposal. A stage user does not reserve its user name. The unique index on uid excludes the staging user and deleted user branch. Therefore it is possible to create a user with the same login name as a staging user. We either have to ensure that this name clash does not cause any trouble with certificates or we have to enforce uniqueness of uid across the whole tree. For FreeIPA it's probably fine because we compare certs bytes. Third party applications parse the cert subject instead and use the subject to identify a user. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From freeipa-github-notification at redhat.com Tue Jan 17 11:44:52 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 12:44:52 +0100 Subject: [Freeipa-devel] [freeipa PR#397][opened] Improve wheel building and provide ipaserver wheel for local testing Message-ID: URL: https://github.com/freeipa/freeipa/pull/397 Author: tiran Title: #397: Improve wheel building and provide ipaserver wheel for local testing Action: opened PR body: """ The PR improve wheel bundle building and allows ipaserver bundles for local testing with instrumented build of Python. Debug builds and instrumented builds can have a different binary interface (ABI). For example it is useful for dtrace or test installations in a virtual env. ipaplatform and ipaserver will not be uploaded to PyPI, though. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/397/head:pr397 git checkout pr397 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-397.patch Type: text/x-diff Size: 10588 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 11:46:41 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 17 Jan 2017 12:46:41 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) mbasti-rh commented: """ We had discussion with @HonzaCholasta, and IPA framework only expects that everything is UTF-8 only, so even in case we parse UTF-32 properly, framework will answer by UTF-8 encoding. Maybe we should rather validate if input is utf-8 compatible earlier and send proper public error. """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-273118134 From mbasti at redhat.com Tue Jan 17 11:52:41 2017 From: mbasti at redhat.com (Martin Basti) Date: Tue, 17 Jan 2017 12:52:41 +0100 Subject: [Freeipa-devel] Stageuser API In-Reply-To: References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Message-ID: <66fb625a-67c8-ce41-e300-1a42dd2d60d9@redhat.com> On 17.01.2017 12:38, Christian Heimes wrote: > On 2017-01-16 15:52, David Kupka wrote: >> Hello everyone! >> >> I've noticed that our API for stageuser is missing some commands that >> user has (stageuser-{add,remove}-{principal,cert}). I was wondering if >> there is reason for it but after asking some fellows developers it seems >> that there's none. >> >> I understand the stageuser area as a place where user entry can be >> created and amended during the hiring process in organization, example: >> >> 1. HR creates the entry with just basic informations (givenname, >> surname, manager) >> 2. IT assigns basic account information (uid, gid) >> 3. based on to-be-employee manager's request IT adds additional group >> membership (memberOf) >> 4. based on to-be-employee request IT adds login alias (krbPrincipalName) >> 5. Security Officer adds certificate from Smart Card assigned to the >> to-be-employee >> 6. HR adds extra information to the account (address, marital status, ...) >> 7. Facilities update work place related information (seat number, phone >> number, ...) >> 8. At the first day IT activates the user account. >> >> Considering this work flow I think it might be useful to have the same >> API for stageuser as for the user. >> >> Does the example work flow make sense? >> Should we provide the same set of commands for user and stageuser? > I see one potential issue in your proposal. A stage user does not > reserve its user name. The unique index on uid excludes the staging user > and deleted user branch. Therefore it is possible to create a user with > the same login name as a staging user. > > We either have to ensure that this name clash does not cause any trouble > with certificates or we have to enforce uniqueness of uid across the > whole tree. For FreeIPA it's probably fine because we compare certs > bytes. Third party applications parse the cert subject instead and use > the subject to identify a user. > > Christian > > > AFAIK the non-uniques of stageuser and user names causes more pain than gain, this is not the first case when we have an issue with that. Maybe we should reevaluate this behavior and enforce uid uniqueness with stageusers too. Note: we explicitly updated uniqueness plugin to allow conflicting names but I don't remember the reason from top of my head. Martin^2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Tue Jan 17 11:55:51 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 12:55:51 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions tomaskrizek commented: """ I still managed to find a an issue for certain edge cases. See inline comments for more info. """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-273119920 From dkupka at redhat.com Tue Jan 17 11:56:10 2017 From: dkupka at redhat.com (David Kupka) Date: Tue, 17 Jan 2017 12:56:10 +0100 Subject: [Freeipa-devel] Stageuser API In-Reply-To: References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> Message-ID: <7071bc74-93fb-03e7-ec2b-3767423ad3fe@redhat.com> On 17/01/17 12:38, Christian Heimes wrote: > On 2017-01-16 15:52, David Kupka wrote: >> Hello everyone! >> >> I've noticed that our API for stageuser is missing some commands that >> user has (stageuser-{add,remove}-{principal,cert}). I was wondering if >> there is reason for it but after asking some fellows developers it seems >> that there's none. >> >> I understand the stageuser area as a place where user entry can be >> created and amended during the hiring process in organization, example: >> >> 1. HR creates the entry with just basic informations (givenname, >> surname, manager) >> 2. IT assigns basic account information (uid, gid) >> 3. based on to-be-employee manager's request IT adds additional group >> membership (memberOf) >> 4. based on to-be-employee request IT adds login alias (krbPrincipalName) >> 5. Security Officer adds certificate from Smart Card assigned to the >> to-be-employee >> 6. HR adds extra information to the account (address, marital status, ...) >> 7. Facilities update work place related information (seat number, phone >> number, ...) >> 8. At the first day IT activates the user account. >> >> Considering this work flow I think it might be useful to have the same >> API for stageuser as for the user. >> >> Does the example work flow make sense? >> Should we provide the same set of commands for user and stageuser? > > I see one potential issue in your proposal. A stage user does not > reserve its user name. The unique index on uid excludes the staging user > and deleted user branch. Therefore it is possible to create a user with > the same login name as a staging user. > > We either have to ensure that this name clash does not cause any trouble > with certificates or we have to enforce uniqueness of uid across the > whole tree. For FreeIPA it's probably fine because we compare certs > bytes. Third party applications parse the cert subject instead and use > the subject to identify a user. > > Christian > > > Hi Christian, uniqueness of uid is not checked in staging area on purpose, it may be changed multiple times before the stageuser is transformed into user (activated). The uid uniqueness is then checked during activation. Third party application that use FreeIPA's LDAP should: 1) search for users (and usercertificate attribute) only in cn=users,cn=accounts 2) respect the value of nsAccountLock that is set to true for all staged users. But it would be nice to have this scenario (stageuser.uid == user.uid) implemented as a part of [1]. [1] https://fedorahosted.org/freeipa/ticket/6615 -- David Kupka From abokovoy at redhat.com Tue Jan 17 12:00:07 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Jan 2017 14:00:07 +0200 Subject: [Freeipa-devel] Stageuser API In-Reply-To: <66fb625a-67c8-ce41-e300-1a42dd2d60d9@redhat.com> References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> <66fb625a-67c8-ce41-e300-1a42dd2d60d9@redhat.com> Message-ID: <20170117120007.bgrtzeqooufky6p6@redhat.com> On ti, 17 tammi 2017, Martin Basti wrote: > > >On 17.01.2017 12:38, Christian Heimes wrote: >>On 2017-01-16 15:52, David Kupka wrote: >>>Hello everyone! >>> >>>I've noticed that our API for stageuser is missing some commands that >>>user has (stageuser-{add,remove}-{principal,cert}). I was wondering if >>>there is reason for it but after asking some fellows developers it seems >>>that there's none. >>> >>>I understand the stageuser area as a place where user entry can be >>>created and amended during the hiring process in organization, example: >>> >>>1. HR creates the entry with just basic informations (givenname, >>>surname, manager) >>>2. IT assigns basic account information (uid, gid) >>>3. based on to-be-employee manager's request IT adds additional group >>>membership (memberOf) >>>4. based on to-be-employee request IT adds login alias (krbPrincipalName) >>>5. Security Officer adds certificate from Smart Card assigned to the >>>to-be-employee >>>6. HR adds extra information to the account (address, marital status, ...) >>>7. Facilities update work place related information (seat number, phone >>>number, ...) >>>8. At the first day IT activates the user account. >>> >>>Considering this work flow I think it might be useful to have the same >>>API for stageuser as for the user. >>> >>>Does the example work flow make sense? >>>Should we provide the same set of commands for user and stageuser? >>I see one potential issue in your proposal. A stage user does not >>reserve its user name. The unique index on uid excludes the staging user >>and deleted user branch. Therefore it is possible to create a user with >>the same login name as a staging user. >> >>We either have to ensure that this name clash does not cause any trouble >>with certificates or we have to enforce uniqueness of uid across the >>whole tree. For FreeIPA it's probably fine because we compare certs >>bytes. Third party applications parse the cert subject instead and use >>the subject to identify a user. >> >>Christian >> >> >> > >AFAIK the non-uniques of stageuser and user names causes more pain >than gain, this is not the first case when we have an issue with that. >Maybe we should reevaluate this behavior and enforce uid uniqueness >with stageusers too. > >Note: we explicitly updated uniqueness plugin to allow conflicting >names but I don't remember the reason from top of my head. There might be workflows where an existing normal user would be deleted and a new but completely separate stageuser would be promoted to a normal one, both having the same name over an overlapping period of time. In this case non-uniqueness requirement is needed. This is a fairly common situation for English-speaking countries with rather short common surnames and a typical username built out of a first name + surname combination. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Jan 17 12:09:13 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 17 Jan 2017 13:09:13 +0100 Subject: [Freeipa-devel] [freeipa PR#179][synchronized] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Author: Akasurde Title: #179: Fix for handling CalledProcessError in authconfig Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/179/head:pr179 git checkout pr179 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-179.patch Type: text/x-diff Size: 2865 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 12:09:28 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 17 Jan 2017 13:09:28 +0100 Subject: [Freeipa-devel] [freeipa PR#179][comment] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig Akasurde commented: """ @tomaskrizek Done. """ See the full comment at https://github.com/freeipa/freeipa/pull/179#issuecomment-273122447 From freeipa-github-notification at redhat.com Tue Jan 17 12:12:04 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 13:12:04 +0100 Subject: [Freeipa-devel] [freeipa PR#179][comment] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig tomaskrizek commented: """ Since there's been no suggestions for a more descriptive error message -> ack. """ See the full comment at https://github.com/freeipa/freeipa/pull/179#issuecomment-273122903 From freeipa-github-notification at redhat.com Tue Jan 17 12:12:09 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 13:12:09 +0100 Subject: [Freeipa-devel] [freeipa PR#179][+ack] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig Label: +ack From freeipa-github-notification at redhat.com Tue Jan 17 12:18:26 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 13:18:26 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tomaskrizek commented: """ I'm not really experienced with autotools, so I do not want to ack this PR without someone else taking a look. I'm also not sure about the best practices in this area. Perhaps @lslebodn could share his opinion on this change? """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-273124050 From cheimes at redhat.com Tue Jan 17 12:26:21 2017 From: cheimes at redhat.com (Christian Heimes) Date: Tue, 17 Jan 2017 13:26:21 +0100 Subject: [Freeipa-devel] Stageuser API In-Reply-To: <7071bc74-93fb-03e7-ec2b-3767423ad3fe@redhat.com> References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> <7071bc74-93fb-03e7-ec2b-3767423ad3fe@redhat.com> Message-ID: On 2017-01-17 12:56, David Kupka wrote: > Hi Christian, > uniqueness of uid is not checked in staging area on purpose, it may be > changed multiple times before the stageuser is transformed into user > (activated). The uid uniqueness is then checked during activation. > > Third party application that use FreeIPA's LDAP should: > 1) search for users (and usercertificate attribute) only in > cn=users,cn=accounts > 2) respect the value of nsAccountLock that is set to true for all staged > users. > > But it would be nice to have this scenario (stageuser.uid == user.uid) > implemented as a part of [1]. Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd party application *always* use the FreeIPA API or LDAP to validate a user cert? Some applications may just validate the certificate and OCSP/CRL for client cert authentication with e.g. mod_ssl. Consider this scenario: 1) IT issues a smart card for a staging user. The smart card contains a valid private/public key pair for FreeIPA. 2) HR sends the smart card to a new hire. 3) HR creates a standard user with same login as staging user 4) New hire uses the smart card to log into a system that only verifies validity of cert (signature, dates, OCSP status) and uses subject to identify user. Even if we 'fix' the issue with non-unique UIDs in staging, it stays dangerous to hand a valid certificate to a not-yet-valid user. At least we should try to reduce risks with a couple of measures: * Add a "valid from" field to stage users and set the cert's valid from date accordingly. That renders the public key useless until the estimated first day on the job. * Lock the smart card with a PIN and don't release the PIN until the user has been moved from staging area to user area. This arrangement makes the smart card inaccessible. We could use the KRA to store the PIN. Christian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From freeipa-github-notification at redhat.com Tue Jan 17 12:29:23 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Tue, 17 Jan 2017 13:29:23 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server lslebodn commented: """ I think it would be simpler to read the code without to many `AM_COND_IF()`. IMHO it would be simpler to move C-related part to separate file (e.g. `server_daemons.m4`) an conditionally include the file with `m4_include`. I checked it very briefly; I might miss something. How do you want to handle python server part? """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-273126212 From freeipa-github-notification at redhat.com Tue Jan 17 12:37:16 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 13:37:16 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tiran commented: """ @lslebodn I like the idea to move the server related header and lib detection to a separate m4 file. In server-less mode, I plan to ignore the Python server part completely. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-273130643 From freeipa-github-notification at redhat.com Tue Jan 17 12:46:18 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Tue, 17 Jan 2017 13:46:18 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server lslebodn commented: """ I fine with ignoring python related parts; but it should be documented. But you might ask other freeIPA developers. (maybe on freeipa-devel) """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-273135814 From abokovoy at redhat.com Tue Jan 17 13:01:26 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Jan 2017 15:01:26 +0200 Subject: [Freeipa-devel] Stageuser API In-Reply-To: References: <0c2da371-b039-44af-08ba-3141b29142fb@redhat.com> <7071bc74-93fb-03e7-ec2b-3767423ad3fe@redhat.com> Message-ID: <20170117130126.qjxsspqqdypziylm@redhat.com> On ti, 17 tammi 2017, Christian Heimes wrote: >On 2017-01-17 12:56, David Kupka wrote: >> Hi Christian, >> uniqueness of uid is not checked in staging area on purpose, it may be >> changed multiple times before the stageuser is transformed into user >> (activated). The uid uniqueness is then checked during activation. >> >> Third party application that use FreeIPA's LDAP should: >> 1) search for users (and usercertificate attribute) only in >> cn=users,cn=accounts >> 2) respect the value of nsAccountLock that is set to true for all staged >> users. >> >> But it would be nice to have this scenario (stageuser.uid == user.uid) >> implemented as a part of [1]. > >Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd >party application *always* use the FreeIPA API or LDAP to validate a >user cert? Some applications may just validate the certificate and >OCSP/CRL for client cert authentication with e.g. mod_ssl. > >Consider this scenario: > >1) IT issues a smart card for a staging user. The smart card contains a >valid private/public key pair for FreeIPA. >2) HR sends the smart card to a new hire. >3) HR creates a standard user with same login as staging user >4) New hire uses the smart card to log into a system that only verifies >validity of cert (signature, dates, OCSP status) and uses subject to >identify user. The certificate validity for a future users should have validity.notBefore property set. A login before that time should not be possible with systems like (4) describes. >Even if we 'fix' the issue with non-unique UIDs in staging, it stays >dangerous to hand a valid certificate to a not-yet-valid user. At least >we should try to reduce risks with a couple of measures: > >* Add a "valid from" field to stage users and set the cert's valid from >date accordingly. That renders the public key useless until the >estimated first day on the job. According to RFC 3280, validity is the mandatory part of the x.509 certificate. Granted, certmonger does not allow you to set validity.notBefore to some externally defined value, but this is something we could implement. You can already achieve that with your own certificate signing request. And it this case we deal with externally provided user certificates, so we could have no ability to influence what happens at all. >* Lock the smart card with a PIN and don't release the PIN until the >user has been moved from staging area to user area. This arrangement >makes the smart card inaccessible. We could use the KRA to store the PIN. This is just a process, not a technical solution. Someone needs to communicate PIN separate to the smartcard to a new hire anyway. -- / Alexander Bokovoy From freeipa-github-notification at redhat.com Tue Jan 17 13:04:38 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Tue, 17 Jan 2017 14:04:38 +0100 Subject: [Freeipa-devel] [freeipa PR#389][comment] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock lslebodn commented: """ @tiran or @pvomacka, @tomaskrizek It would be good if you could test/ack the latest version of the patch. Because currently it is not possible to build freeIPA with upstream spec file in mock; which blocks reasonable testing with static analysers """ See the full comment at https://github.com/freeipa/freeipa/pull/389#issuecomment-273147279 From freeipa-github-notification at redhat.com Tue Jan 17 13:05:13 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 14:05:13 +0100 Subject: [Freeipa-devel] [freeipa PR#364][synchronized] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Author: tiran Title: #364: Client-only builds with --disable-server Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/364/head:pr364 git checkout pr364 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-364.patch Type: text/x-diff Size: 19135 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 13:05:44 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 14:05:44 +0100 Subject: [Freeipa-devel] [freeipa PR#364][comment] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Title: #364: Client-only builds with --disable-server tiran commented: """ @lslebodn I think you misunderstood me. The PR adds a new build flavor that ignores and skips the any server-related steps of the build process. The fact that this PR ignores the server part is actually a a **feature**. :) The last version of the patch now skips ```ipaserver``` subdir completely, too. """ See the full comment at https://github.com/freeipa/freeipa/pull/364#issuecomment-273148073 From freeipa-github-notification at redhat.com Tue Jan 17 13:47:42 2017 From: freeipa-github-notification at redhat.com (tjaalton) Date: Tue, 17 Jan 2017 14:47:42 +0100 Subject: [Freeipa-devel] [freeipa PR#373][synchronized] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-373.patch Type: text/x-diff Size: 16795 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 13:54:30 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 17 Jan 2017 14:54:30 +0100 Subject: [Freeipa-devel] [freeipa PR#359][synchronized] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Author: HonzaCholasta Title: #359: dogtag: search past the first 100 certificates Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/359/head:pr359 git checkout pr359 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-359.patch Type: text/x-diff Size: 4193 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 13:56:31 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 17 Jan 2017 14:56:31 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates HonzaCholasta commented: """ I have identified some issues in search limit handling in `cert-find` and fixed them in an additional commit. See commit message for details. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-273166075 From freeipa-github-notification at redhat.com Tue Jan 17 14:06:14 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 15:06:14 +0100 Subject: [Freeipa-devel] [freeipa PR#390][+ack] WebUI: Fix Coverity JS bugs In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/390 Title: #390: WebUI: Fix Coverity JS bugs Label: +ack From freeipa-github-notification at redhat.com Tue Jan 17 14:10:02 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 17 Jan 2017 15:10:02 +0100 Subject: [Freeipa-devel] [freeipa PR#359][synchronized] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Author: HonzaCholasta Title: #359: dogtag: search past the first 100 certificates Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/359/head:pr359 git checkout pr359 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-359.patch Type: text/x-diff Size: 4195 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 14:50:33 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 17 Jan 2017 15:50:33 +0100 Subject: [Freeipa-devel] [freeipa PR#396][comment] Explicitly remove support of SSLv2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/396 Title: #396: Explicitly remove support of SSLv2 tiran commented: """ * What is the point of supporting SSL 3.0, TLS 1.0 and TLS 1.1 on the client side these days? How about we remove ancient and potentially dangerous TLS versions completely? * Would it be possible to validate the values during API initialization? """ See the full comment at https://github.com/freeipa/freeipa/pull/396#issuecomment-273189049 From freeipa-github-notification at redhat.com Tue Jan 17 15:08:45 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 17 Jan 2017 16:08:45 +0100 Subject: [Freeipa-devel] [freeipa PR#347][synchronized] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Author: martbab Title: #347: Improvements in {get|set}_directive functions Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/347/head:pr347 git checkout pr347 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-347.patch Type: text/x-diff Size: 12317 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 17 15:09:09 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 17 Jan 2017 16:09:09 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions martbab commented: """ Thanks, I have fixed the docstrings. I have also made directive unquoting less silly. """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-273194982 From freeipa-github-notification at redhat.com Tue Jan 17 15:45:24 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 16:45:24 +0100 Subject: [Freeipa-devel] [freeipa PR#389][comment] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock tomaskrizek commented: """ Thanks for the fix and explanation! """ See the full comment at https://github.com/freeipa/freeipa/pull/389#issuecomment-273206316 From freeipa-github-notification at redhat.com Tue Jan 17 15:45:26 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 17 Jan 2017 16:45:26 +0100 Subject: [Freeipa-devel] [freeipa PR#389][+ack] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock Label: +ack From freeipa-github-notification at redhat.com Tue Jan 17 19:37:49 2017 From: freeipa-github-notification at redhat.com (mbasti-rh) Date: Tue, 17 Jan 2017 20:37:49 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command mbasti-rh commented: """ Shouldn't be namespaces named using unicode strings? """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273275568 From freeipa-github-notification at redhat.com Tue Jan 17 23:32:19 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Wed, 18 Jan 2017 00:32:19 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 82496 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 06:29:40 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 07:29:40 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command HonzaCholasta commented: """ @mbasti-rh, no. Classes aren't named using unicode strings either. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273395287 From freeipa-github-notification at redhat.com Wed Jan 18 07:52:55 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 08:52:55 +0100 Subject: [Freeipa-devel] [freeipa PR#179][comment] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/6d52c0fe6acb09f3b8525840dfacc3f0885eac37 """ See the full comment at https://github.com/freeipa/freeipa/pull/179#issuecomment-273407044 From freeipa-github-notification at redhat.com Wed Jan 18 07:52:57 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 08:52:57 +0100 Subject: [Freeipa-devel] [freeipa PR#179][+pushed] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 07:52:58 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 08:52:58 +0100 Subject: [Freeipa-devel] [freeipa PR#179][closed] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Author: Akasurde Title: #179: Fix for handling CalledProcessError in authconfig Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/179/head:pr179 git checkout pr179 From freeipa-github-notification at redhat.com Wed Jan 18 08:16:14 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:16:14 +0100 Subject: [Freeipa-devel] [freeipa PR#390][comment] WebUI: Fix Coverity JS bugs In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/390 Title: #390: WebUI: Fix Coverity JS bugs martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a69c4448c58b2438952fd806e2515eea7575b27b https://fedorahosted.org/freeipa/changeset/9d2ef64fb9e1357dc4a3cde8d93c796daefd2f6e """ See the full comment at https://github.com/freeipa/freeipa/pull/390#issuecomment-273410950 From freeipa-github-notification at redhat.com Wed Jan 18 08:16:16 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:16:16 +0100 Subject: [Freeipa-devel] [freeipa PR#390][+pushed] WebUI: Fix Coverity JS bugs In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/390 Title: #390: WebUI: Fix Coverity JS bugs Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 08:16:17 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:16:17 +0100 Subject: [Freeipa-devel] [freeipa PR#390][closed] WebUI: Fix Coverity JS bugs In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/390 Author: pvomacka Title: #390: WebUI: Fix Coverity JS bugs Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/390/head:pr390 git checkout pr390 From freeipa-github-notification at redhat.com Wed Jan 18 08:17:09 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:17:09 +0100 Subject: [Freeipa-devel] [freeipa PR#389][comment] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/5c18feaa206bbaee692fc3640b7b79c8d9d6a638 https://fedorahosted.org/freeipa/changeset/3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 https://fedorahosted.org/freeipa/changeset/b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 """ See the full comment at https://github.com/freeipa/freeipa/pull/389#issuecomment-273411119 From freeipa-github-notification at redhat.com Wed Jan 18 08:17:10 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:17:10 +0100 Subject: [Freeipa-devel] [freeipa PR#389][closed] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Author: lslebodn Title: #389: Fix build in mock Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/389/head:pr389 git checkout pr389 From freeipa-github-notification at redhat.com Wed Jan 18 08:17:18 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:17:18 +0100 Subject: [Freeipa-devel] [freeipa PR#389][+pushed] Fix build in mock In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/389 Title: #389: Fix build in mock Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 08:20:07 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:20:07 +0100 Subject: [Freeipa-devel] [freeipa PR#378][comment] Clean / ignore make check artefact In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Title: #378: Clean / ignore make check artefact martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d8343a96dd206c9f25cf032a50f3b48fb8166db1 """ See the full comment at https://github.com/freeipa/freeipa/pull/378#issuecomment-273411645 From freeipa-github-notification at redhat.com Wed Jan 18 08:20:08 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:20:08 +0100 Subject: [Freeipa-devel] [freeipa PR#378][closed] Clean / ignore make check artefact In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Author: tiran Title: #378: Clean / ignore make check artefact Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/378/head:pr378 git checkout pr378 From freeipa-github-notification at redhat.com Wed Jan 18 08:20:09 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:20:09 +0100 Subject: [Freeipa-devel] [freeipa PR#378][+pushed] Clean / ignore make check artefact In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/378 Title: #378: Clean / ignore make check artefact Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 08:30:59 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 09:30:59 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) tiran commented: """ @LiptonB thanks a lot for resuming your work! Please add jinja2 to ``` ipaclient/setup.py```, too. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-273413601 From freeipa-github-notification at redhat.com Wed Jan 18 08:31:08 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Wed, 18 Jan 2017 09:31:08 +0100 Subject: [Freeipa-devel] [freeipa PR#398][opened] Support for Certificate Identity Mapping Message-ID: URL: https://github.com/freeipa/freeipa/pull/398 Author: flo-renaud Title: #398: Support for Certificate Identity Mapping Action: opened PR body: """ See design http://www.freeipa.org/page/V4/Certificate_Identity_Mapping https://fedorahosted.org/freeipa/ticket/6542 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/398/head:pr398 git checkout pr398 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-398.patch Type: text/x-diff Size: 48126 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 08:34:48 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:34:48 +0100 Subject: [Freeipa-devel] [freeipa PR#210][comment] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Title: #210: Tests: Stage User Tracker implementation martbab commented: """ @gkaihorodova the PR cannot be pushed in current form because the first commit 298e1a136c6a430e8deaa558a946ba51874ffd95 is already pushed to master. So to rebase it correctly please do the following: Pull the changes from the remote repo (or any other label you have for it) into your local master branch: ```shell $ git checkout master; git pull ``` Then do the rebase against the refreshed master branch. The first commit should now disappear as git should detect that it is already there. If not, then abort the current rebase, re-start it in interactive mode (git rebase -i master) and remove the first commit manually (just remove the first line). Then force-push the changes into your fork: ```shell $ git push -f origin fix-for-6448 ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/210#issuecomment-273414412 From freeipa-github-notification at redhat.com Wed Jan 18 08:36:45 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 09:36:45 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values MartinBasti commented: """ @gkaihorodova you haven't pushed the changes to github repo ``` git push --force ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-273414761 From freeipa-github-notification at redhat.com Wed Jan 18 08:40:34 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:40:34 +0100 Subject: [Freeipa-devel] [freeipa PR#387][+ack] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Title: #387: Update warning message for ipa server uninstall Label: +ack From freeipa-github-notification at redhat.com Wed Jan 18 08:41:43 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:41:43 +0100 Subject: [Freeipa-devel] [freeipa PR#387][+pushed] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Title: #387: Update warning message for ipa server uninstall Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 08:41:44 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:41:44 +0100 Subject: [Freeipa-devel] [freeipa PR#387][comment] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Title: #387: Update warning message for ipa server uninstall martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/ae2d0a221772267ecda30896dc8897a3f4b4a97b """ See the full comment at https://github.com/freeipa/freeipa/pull/387#issuecomment-273415717 From freeipa-github-notification at redhat.com Wed Jan 18 08:41:46 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:41:46 +0100 Subject: [Freeipa-devel] [freeipa PR#387][closed] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Author: Akasurde Title: #387: Update warning message for ipa server uninstall Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/387/head:pr387 git checkout pr387 From freeipa-github-notification at redhat.com Wed Jan 18 08:43:19 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 18 Jan 2017 09:43:19 +0100 Subject: [Freeipa-devel] [freeipa PR#399][opened] Certificate mapping test Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6542 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 12344 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 08:43:38 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 09:43:38 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command martbab commented: """ @Akasurde are you OK with writing a simple regression test for this command as a part of this PR? """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273416076 From freeipa-github-notification at redhat.com Wed Jan 18 08:44:44 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 09:44:44 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tiran commented: """ What's the hold up here? Martin and I discussed the necessity to raise the version requirements. Python 3 packages for PKI simply do not exist until 10.3. I don't want to depend on a non-existing package. In case there are some issues with our CI and proper updates of build requirements, then the issue should be handled by a separate ticket. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273416279 From freeipa-github-notification at redhat.com Wed Jan 18 08:44:53 2017 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 18 Jan 2017 09:44:53 +0100 Subject: [Freeipa-devel] [freeipa PR#400][opened] WebUI: Certificate Mapping Message-ID: URL: https://github.com/freeipa/freeipa/pull/400 Author: pvomacka Title: #400: WebUI: Certificate Mapping Action: opened PR body: """ Add WebUI for certificate mapping """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/400/head:pr400 git checkout pr400 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-400.patch Type: text/x-diff Size: 21279 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 08:45:03 2017 From: freeipa-github-notification at redhat.com (pvomacka) Date: Wed, 18 Jan 2017 09:45:03 +0100 Subject: [Freeipa-devel] [freeipa PR#400][edited] WebUI: Certificate Mapping In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/400 Author: pvomacka Title: #400: WebUI: Certificate Mapping Action: edited Changed field: body Original value: """ Add WebUI for certificate mapping """ From freeipa-github-notification at redhat.com Wed Jan 18 08:53:29 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 09:53:29 +0100 Subject: [Freeipa-devel] [freeipa PR#372][comment] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py tiran commented: """ I have updated the ticket https://fedorahosted.org/freeipa/ticket/6540#comment:5 with the result of this discussion. I'm going to close the PR. Let's start a new one to remove it and update ```ipaserver/install/cainstance.py``` plus builds. """ See the full comment at https://github.com/freeipa/freeipa/pull/372#issuecomment-273418019 From freeipa-github-notification at redhat.com Wed Jan 18 08:53:31 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 09:53:31 +0100 Subject: [Freeipa-devel] [freeipa PR#372][closed] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Author: tiran Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/372/head:pr372 git checkout pr372 From dkupka at redhat.com Wed Jan 18 08:59:49 2017 From: dkupka at redhat.com (David Kupka) Date: Wed, 18 Jan 2017 09:59:49 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping Message-ID: Hello everyone! I would like to bring your attention to just published PRs implementing FreeIPA part of Certificate Identity Mapping feature [0]: - certmap plugin [1] by Flo - WebUI for certmap plugin [3] by Pavel - tests for certmap plugin [2] by me Also please think about names of the commands, parameters, entries and attributes. We've figured them somehow but if you have any suggestion that would improve the understanding please share. Please review them thoroughly, thanks! [0] https://www.freeipa.org/page/V4/Certificate_Identity_Mapping [1] https://github.com/freeipa/freeipa/pull/398 [2] https://github.com/freeipa/freeipa/pull/399 [3] https://github.com/freeipa/freeipa/pull/400 -- David Kupka From freeipa-github-notification at redhat.com Wed Jan 18 09:01:14 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 18 Jan 2017 10:01:14 +0100 Subject: [Freeipa-devel] [freeipa PR#179][comment] Fix for handling CalledProcessError in authconfig In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/179 Title: #179: Fix for handling CalledProcessError in authconfig Akasurde commented: """ @tomaskrizek @martbab Thanks for review. """ See the full comment at https://github.com/freeipa/freeipa/pull/179#issuecomment-273419730 From freeipa-github-notification at redhat.com Wed Jan 18 09:01:36 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 18 Jan 2017 10:01:36 +0100 Subject: [Freeipa-devel] [freeipa PR#387][comment] Update warning message for ipa server uninstall In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/387 Title: #387: Update warning message for ipa server uninstall Akasurde commented: """ @martbab Thanks for review. """ See the full comment at https://github.com/freeipa/freeipa/pull/387#issuecomment-273419794 From freeipa-github-notification at redhat.com Wed Jan 18 09:02:49 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Wed, 18 Jan 2017 10:02:49 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command Akasurde commented: """ @martbab Yes, I will write a test case for this scenario and attach here. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273420038 From freeipa-github-notification at redhat.com Wed Jan 18 09:06:15 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 10:06:15 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] HonzaCholasta commented: """ @tiran, the dependency says `>= 10.2.1`, not `== 10.2.1`, so we are not depending on any non-existent packages. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273420737 From freeipa-github-notification at redhat.com Wed Jan 18 09:07:27 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:07:27 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command tiran commented: """ Why should *Python 2 class names are str instances* prevent us from making the namespace keys text? In Python 2 ASCII str and ASCII unicode are equivalent dict keys (same hash, compare equaly). In Python 3 the keys are going to be text anyway. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273420986 From freeipa-github-notification at redhat.com Wed Jan 18 09:08:48 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:08:48 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command tiran commented: """ Why should *Python 2 class names are str instances* prevent us from making the namespace keys text? In Python 2 ASCII str and ASCII unicode are equivalent dict keys (same hash, compare equaly). In Python 3 the keys are going to be text anyway. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273420986 From freeipa-github-notification at redhat.com Wed Jan 18 09:15:20 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 10:15:20 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command HonzaCholasta commented: """ The namespace keys *are* text (`str`) in both Python 2 and 3. The issue here is that the RPC layer assumes that `str` is binary data, which the patch correctly fixes by converting the keys to `unicode` before they enter the RPC layer. There is no benefit in making the keys themselves `unicode`. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273422664 From freeipa-github-notification at redhat.com Wed Jan 18 09:25:07 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:25:07 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command tiran commented: """ In Python 2 str is a Chimera with the head of a text object and the body of a bytes object. It's just text if all text you got is ASCII. For clean polyglot code it's highly recommended to avoid Python 2 str and use Python 2's unicode for all text. Most of FreeIPA's Python code has been adopted to unicode for text very well. This one of the few places that slipped through. The benefits are consistent treatment of text as Python 2 unicode, which leads to a proper fix instead of a patch (in this case decoding with six.text_type). """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273424928 From freeipa-github-notification at redhat.com Wed Jan 18 09:26:58 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 10:26:58 +0100 Subject: [Freeipa-devel] [freeipa PR#386][comment] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Title: #386: Tests: Add tree root domain role in legacy client tests martbab commented: """ Looks good, let's see if it fixes our CI """ See the full comment at https://github.com/freeipa/freeipa/pull/386#issuecomment-273425390 From freeipa-github-notification at redhat.com Wed Jan 18 09:26:59 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 10:26:59 +0100 Subject: [Freeipa-devel] [freeipa PR#386][+ack] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Title: #386: Tests: Add tree root domain role in legacy client tests Label: +ack From freeipa-github-notification at redhat.com Wed Jan 18 09:27:56 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:27:56 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tiran commented: """ ```pki-base-python3 >= 10.2.1``` would mean that FreeIPA is compatible with ```pki-base-python2 == 10.2.1``` which clearly does not exist. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273425618 From freeipa-github-notification at redhat.com Wed Jan 18 09:30:11 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:30:11 +0100 Subject: [Freeipa-devel] [freeipa PR#393][comment] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 tiran commented: """ @MartinBasti cert tests are failing. I have restarted the failing job. Let's see if the error persists or was just caused by a Travis hick up. """ See the full comment at https://github.com/freeipa/freeipa/pull/393#issuecomment-273426124 From freeipa-github-notification at redhat.com Wed Jan 18 09:30:50 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 10:30:50 +0100 Subject: [Freeipa-devel] [freeipa PR#379][synchronized] Packaging: Add placeholder and IPA commands packages In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Author: tiran Title: #379: Packaging: Add placeholder and IPA commands packages Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/379/head:pr379 git checkout pr379 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-379.patch Type: text/x-diff Size: 17442 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 09:38:36 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 10:38:36 +0100 Subject: [Freeipa-devel] [freeipa PR#398][comment] Support for Certificate Identity Mapping In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/398 Title: #398: Support for Certificate Identity Mapping MartinBasti commented: """ I put some inline commets, @flo-renaud if you don't know where to register OIDs feel free to ping me """ See the full comment at https://github.com/freeipa/freeipa/pull/398#issuecomment-273428118 From freeipa-github-notification at redhat.com Wed Jan 18 09:43:43 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 10:43:43 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command HonzaCholasta commented: """ @tiran, namespace keys are always ASCII. But feel free to open a ticket to convert all remaining uses of `str` as text to `unicode`, changing it for one random bit in this unrelated PR isn't particularly helpful when you take the big picture into account. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273429342 From sbose at redhat.com Wed Jan 18 09:54:44 2017 From: sbose at redhat.com (Sumit Bose) Date: Wed, 18 Jan 2017 10:54:44 +0100 Subject: [Freeipa-devel] Certificate Identity Mapping In-Reply-To: References: Message-ID: <20170118095444.GB3389@p.Speedport_W_724V_Typ_A_05011603_00_011> On Wed, Jan 18, 2017 at 09:59:49AM +0100, David Kupka wrote: > Hello everyone! > I would like to bring your attention to just published PRs implementing > FreeIPA part of Certificate Identity Mapping feature [0]: > > - certmap plugin [1] by Flo > - WebUI for certmap plugin [3] by Pavel > - tests for certmap plugin [2] by me > > Also please think about names of the commands, parameters, entries and > attributes. We've figured them somehow but if you have any suggestion that > would improve the understanding please share. Hi, thank you for the patches. Just a general comment about an open question in the design. Honza suggested to use a priority instead of an issuer name to make sure that only specific rules are used for a given issuer. The latest mail in the thread about it is https://www.redhat.com/archives/freeipa-devel/2017-January/msg00229.html. Do you have any opinions here? I think it won't change much in your patches but we should find an agreement before e.g. the OID are registered. bye, Sumit > > Please review them thoroughly, thanks! > > [0] https://www.freeipa.org/page/V4/Certificate_Identity_Mapping > [1] https://github.com/freeipa/freeipa/pull/398 > [2] https://github.com/freeipa/freeipa/pull/399 > [3] https://github.com/freeipa/freeipa/pull/400 > > -- > David Kupka > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code From freeipa-github-notification at redhat.com Wed Jan 18 10:04:46 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 11:04:46 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command tiran commented: """ **namespace keys are always ASCII** and **use the proper text datatype to represent text** are not a contradiction. At least two IPA developers (@MartinBasti and me) feel that it is strange to Python 2 str for name spaces keys. One of them just happens to be one of the Python core developers that made the text/bytes spilt in Python 3000 happen about 8, 9 year ago. *wink wink, nudge nudge* The big picture is Python 3 support with working Python 2 support for the interim period. Python 2 code should follow Python 3 coding principals to give consistent results. This PR provides a quick patch to work around the symptoms of a flaw. It's not a solution for the core issue. Are we OK with a patch or do we prefer to understand and fix the root cause? """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273434413 From freeipa-github-notification at redhat.com Wed Jan 18 10:14:22 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 11:14:22 +0100 Subject: [Freeipa-devel] [freeipa PR#113][comment] ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/113 Title: #113: ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri tiran commented: """ I would appreciate to have this fix landed in master rather sooner than later. The questionable default values have triggered hard to find bugs in one of my integration efforts. It took me a while to track them down and find the root cause. I wasted half an hour to an hour on the problem. """ See the full comment at https://github.com/freeipa/freeipa/pull/113#issuecomment-273436538 From freeipa-github-notification at redhat.com Wed Jan 18 10:17:19 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 11:17:19 +0100 Subject: [Freeipa-devel] [freeipa PR#244][closed] Add templating to ipaplatform path [RFC] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/244 Author: tiran Title: #244: Add templating to ipaplatform path [RFC] Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/244/head:pr244 git checkout pr244 From freeipa-github-notification at redhat.com Wed Jan 18 10:17:21 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 11:17:21 +0100 Subject: [Freeipa-devel] [freeipa PR#244][comment] Add templating to ipaplatform path [RFC] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/244 Title: #244: Add templating to ipaplatform path [RFC] tiran commented: """ My PoC is a bit too magic and complicated. PR #373 for Debian support comes along nicely without additional magic. I'm closing the PR. I'll keep the branch around in case we want to tackle the problem in the future. """ See the full comment at https://github.com/freeipa/freeipa/pull/244#issuecomment-273437189 From freeipa-github-notification at redhat.com Wed Jan 18 11:11:52 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 12:11:52 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command HonzaCholasta commented: """ We are OK with the patch because fixing the root cause is out of the scope of this PR. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273448687 From freeipa-github-notification at redhat.com Wed Jan 18 11:20:07 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 12:20:07 +0100 Subject: [Freeipa-devel] [freeipa PR#394][comment] Add fix for ipa plugins command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/394 Title: #394: Add fix for ipa plugins command MartinBasti commented: """ I would like to have `py3 str` <=> `py2 unicode`, `py3 bytes` <=> `py2 str`, but framework is far away from this ideal state. So I have no strong opinion, and once we will drop py2, so I'm not sure if we want to migrate everything in py2 to unicode if it work in other cases. """ See the full comment at https://github.com/freeipa/freeipa/pull/394#issuecomment-273450333 From freeipa-github-notification at redhat.com Wed Jan 18 12:07:33 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 13:07:33 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] HonzaCholasta commented: """ That is of no concern to us. `pki-base-python3 >= 10.2.1` will get us the correct package in all cases and under no circumstances will it cause an attempt to install a non-existent package. Note that `pki-base-python2 >= 10.2.1` means that FreeIPA is also compatible with `pki-base-python2-10.2.1.0.1.2.3`, which clearly doesn't exist either, but that doesn't make the dependency wrong in any way whatsoever. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273459096 From freeipa-github-notification at redhat.com Wed Jan 18 12:40:12 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 13:40:12 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tiran commented: """ I can't see a valid argument in your response. As a co-maintainer of PKI's Python packages I'm strictly against claiming compatibility with a non-existing package version range. The PR is fine as it stands and I'm going to ACK it tomorrow. If you still like to veto against my ACK, please start a motion on the developer list and ask the rest of the team for their opinion. You also mentioned that CI might not pick up build requirements correctly. I agree that this is a problem and must be fixed ASAP. We must be able to rely on CI tests. Please open a separate ticket. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273465183 From freeipa-github-notification at redhat.com Wed Jan 18 12:58:48 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 18 Jan 2017 13:58:48 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tomaskrizek commented: """ I agree with @tiran here. Even though `>= 10.2.1` will match the correct package, I don't think it's a good practice to use non-existent package numbers in `BuildRequires`. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273468841 From freeipa-github-notification at redhat.com Wed Jan 18 13:02:49 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 18 Jan 2017 14:02:49 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 12377 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 14:26:50 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 15:26:50 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] HonzaCholasta commented: """ @tiran, I'm sorry to have to point this out, but the decision whether this PR is accepted or not is not yours to make, you are not a member of the core team and this is in no way related to your integration work. As a maintainer of IPA packages in RHEL I obviously prefer it my way. What you prefer when you co-maintain PKI Python packages is your bussiness and is not relevant here. A compromise I would be willing to accept is that the `pki-base-python3` dependency will be unversioned, but `pki-base-python2` must stay `>= 10.2.1`. @tomaskrizek, why do you think it's a bad practice? The condition merely limits the set of package versions that satisfy the dependency, but the set is still infinite and an infinite number of non-existents packages *always* fall in the set. Strictly speaking, `10.3.5-6` is not an existing package version either, you won't find an `pki-base-python2-10.3.5-6.rpm` anywhere. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273488422 From freeipa-github-notification at redhat.com Wed Jan 18 14:44:30 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Wed, 18 Jan 2017 15:44:30 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tiran commented: """ You would still depend on potentially non-existing package. ```pki-base-python2``` was introduced in 10.3. ```pki-base``` will switch to Python 3 as soon as RHEL has Python 3 in its base distribution. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273493381 From freeipa-github-notification at redhat.com Wed Jan 18 15:02:14 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 18 Jan 2017 16:02:14 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] HonzaCholasta commented: """ I see, didn't notice that. In this case, IMO either the current `pki-base >= 10.2.1` or an unversioned `pki-base-python2` is fine. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273498651 From freeipa-github-notification at redhat.com Wed Jan 18 15:40:52 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 16:40:52 +0100 Subject: [Freeipa-devel] [freeipa PR#386][+pushed] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Title: #386: Tests: Add tree root domain role in legacy client tests Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 18 15:40:54 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 16:40:54 +0100 Subject: [Freeipa-devel] [freeipa PR#386][comment] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Title: #386: Tests: Add tree root domain role in legacy client tests martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/822a119100f8ab93aacdb14b982609f1dc69531d ipa-4-4: https://fedorahosted.org/freeipa/changeset/52527d6323eec1a2ae4bf01dd64412a3822c516d """ See the full comment at https://github.com/freeipa/freeipa/pull/386#issuecomment-273510158 From freeipa-github-notification at redhat.com Wed Jan 18 15:40:55 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 18 Jan 2017 16:40:55 +0100 Subject: [Freeipa-devel] [freeipa PR#386][closed] Tests: Add tree root domain role in legacy client tests In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/386 Author: gkaihorodova Title: #386: Tests: Add tree root domain role in legacy client tests Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/386/head:pr386 git checkout pr386 From freeipa-github-notification at redhat.com Wed Jan 18 16:17:12 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 18 Jan 2017 17:17:12 +0100 Subject: [Freeipa-devel] [freeipa PR#336][comment] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Title: #336: [py3] pki: add missing depedency pki-base[-python3] tomaskrizek commented: """ @HonzaCholasta Perhaps it's more of a personal preference, but I'd rather see an existing version of a certain package. Since the spec file is processed automatically, I guess it doesn't make a difference. But it could confuse someone who reads the file and looks for a certain version of the mentioned package. """ See the full comment at https://github.com/freeipa/freeipa/pull/336#issuecomment-273521294 From freeipa-github-notification at redhat.com Wed Jan 18 16:20:02 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 17:20:02 +0100 Subject: [Freeipa-devel] [freeipa PR#401][synchronized] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Author: MartinBasti Title: #401: [4.4] Wait until http principal entry is replicated to replica Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/401/head:pr401 git checkout pr401 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-401.patch Type: text/x-diff Size: 3869 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 16:33:55 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 17:33:55 +0100 Subject: [Freeipa-devel] [freeipa PR#401][synchronized] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Author: MartinBasti Title: #401: [4.4] Wait until http principal entry is replicated to replica Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/401/head:pr401 git checkout pr401 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-401.patch Type: text/x-diff Size: 5539 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 16:54:42 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Wed, 18 Jan 2017 17:54:42 +0100 Subject: [Freeipa-devel] [freeipa PR#398][synchronized] Support for Certificate Identity Mapping In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/398 Author: flo-renaud Title: #398: Support for Certificate Identity Mapping Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/398/head:pr398 git checkout pr398 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-398.patch Type: text/x-diff Size: 49809 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 17:10:36 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Wed, 18 Jan 2017 18:10:36 +0100 Subject: [Freeipa-devel] [freeipa PR#113][comment] ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/113 Title: #113: ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri pvoborni commented: """ @HonzaCholasta with @pspacek no longer caring about this PR, we should close it. But before we do it, what are your thoughts on what should be the right approach. Are you going to amend this path or replace it with something different? """ See the full comment at https://github.com/freeipa/freeipa/pull/113#issuecomment-273537412 From freeipa-github-notification at redhat.com Wed Jan 18 17:11:02 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 18:11:02 +0100 Subject: [Freeipa-devel] [freeipa PR#401][synchronized] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Author: MartinBasti Title: #401: [4.4] Wait until http principal entry is replicated to replica Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/401/head:pr401 git checkout pr401 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-401.patch Type: text/x-diff Size: 5559 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 17:41:26 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 18 Jan 2017 18:41:26 +0100 Subject: [Freeipa-devel] [freeipa PR#402][opened] [master] wait_for_entry improvements Message-ID: URL: https://github.com/freeipa/freeipa/pull/402 Author: MartinBasti Title: #402: [master] wait_for_entry improvements Action: opened PR body: """ Backport useful commits from #401 to master """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/402/head:pr402 git checkout pr402 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-402.patch Type: text/x-diff Size: 3917 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 19:59:09 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Wed, 18 Jan 2017 20:59:09 +0100 Subject: [Freeipa-devel] [freeipa PR#210][synchronized] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Author: gkaihorodova Title: #210: Tests: Stage User Tracker implementation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/210/head:pr210 git checkout pr210 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-210.patch Type: text/x-diff Size: 4717 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 20:27:34 2017 From: freeipa-github-notification at redhat.com (gkaihorodova) Date: Wed, 18 Jan 2017 21:27:34 +0100 Subject: [Freeipa-devel] [freeipa PR#181][synchronized] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-181.patch Type: text/x-diff Size: 4495 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 18 23:17:49 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Thu, 19 Jan 2017 00:17:49 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 237148 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 01:37:57 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Thu, 19 Jan 2017 02:37:57 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 83115 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 01:44:12 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Thu, 19 Jan 2017 02:44:12 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) LiptonB commented: """ @tiran Thanks to the team for resuming the review, too! Added the dependency, does that look right? """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-273658159 From freeipa-github-notification at redhat.com Thu Jan 19 03:55:11 2017 From: freeipa-github-notification at redhat.com (redhatrises) Date: Thu, 19 Jan 2017 04:55:11 +0100 Subject: [Freeipa-devel] [freeipa PR#403][opened] Add new ipa passwd-generate command Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Author: redhatrises Title: #403: Add new ipa passwd-generate command Action: opened PR body: """ This PR adds a new command line option `ipa passwd-generate` that uses the refactored `ipa_password_generate()` function. This is useful for generating secure passwords for service and system accounts or passwords for applications that may not be able to handle all character types. This could also be useful in the future for generating a temporary password for any portal efforts. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/403/head:pr403 git checkout pr403 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-403.patch Type: text/x-diff Size: 5235 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 06:53:39 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 19 Jan 2017 07:53:39 +0100 Subject: [Freeipa-devel] [freeipa PR#113][comment] ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/113 Title: #113: ipalib.constants: Remove default domain, realm, basedn, xmlrpc_uri, ldap_uri HonzaCholasta commented: """ @pvoborni, my plan is to amend / extend this patch. """ See the full comment at https://github.com/freeipa/freeipa/pull/113#issuecomment-273696077 From freeipa-github-notification at redhat.com Thu Jan 19 07:03:11 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 08:03:11 +0100 Subject: [Freeipa-devel] [freeipa PR#403][comment] Add new ipa passwd-generate command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Title: #403: Add new ipa passwd-generate command stlaz commented: """ Hello and thank you for the contribution! However, I do not see what's in this for us. I do not think FreeIPA is intended to be used as a password generator. There are other tools that do this just right, `pwgen` being just an example. """ See the full comment at https://github.com/freeipa/freeipa/pull/403#issuecomment-273697438 From freeipa-github-notification at redhat.com Thu Jan 19 07:55:04 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 08:55:04 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) tiran commented: """ @LiptonB yes, it's correct. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-273705203 From freeipa-github-notification at redhat.com Thu Jan 19 09:01:59 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 10:01:59 +0100 Subject: [Freeipa-devel] [freeipa PR#396][comment] Explicitly remove support of SSLv2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/396 Title: #396: Explicitly remove support of SSLv2 stlaz commented: """ - I think we may need to discuss the support on Monday meeting, generally I think SSL 3.0 and TLS 1.0 should not be supported but there might be troubles with connectivity to legacy IPA servers - Yes, although in that case we would have to fail instead of falling back to "reasonable defaults" as Env object attribute values cannot be changed once set """ See the full comment at https://github.com/freeipa/freeipa/pull/396#issuecomment-273717304 From freeipa-github-notification at redhat.com Thu Jan 19 09:11:43 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 19 Jan 2017 10:11:43 +0100 Subject: [Freeipa-devel] [freeipa PR#404][opened] tests: Add LDAP URI to ldappasswd explicitelly Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Author: dkupka Title: #404: tests: Add LDAP URI to ldappasswd explicitelly Action: opened PR body: """ Test should always respect api.env.* values. https://fedorahosted.org/freeipa/ticket/6622 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/404/head:pr404 git checkout pr404 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-404.patch Type: text/x-diff Size: 818 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 10:00:08 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 11:00:08 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) tiran commented: """ Let's reiterate. It's obviously wrong to assume that request data such as JSON are encoded as UTF-8. It can be just any encoding. Outside the Western world, JSON and XML are often encoded as UTF-16. That doesn't mean we have to support other encodings than UTF-8 right now. It's fine to restrict requests and responses to UTF-8 as only supported encoding. The check should be performed early in the WSGI layer. A client sends can send the request type as part of the content type. The framework should check for the presence of an encoding hint and refuse encodings that are ```encoding.lower() not in {'utf8', 'utf-8'}```. """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-273730248 From freeipa-github-notification at redhat.com Thu Jan 19 10:05:32 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Thu, 19 Jan 2017 11:05:32 +0100 Subject: [Freeipa-devel] [freeipa PR#398][synchronized] Support for Certificate Identity Mapping In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/398 Author: flo-renaud Title: #398: Support for Certificate Identity Mapping Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/398/head:pr398 git checkout pr398 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-398.patch Type: text/x-diff Size: 49838 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 10:09:15 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 11:09:15 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: MartinBasti Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 30324 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 10:13:38 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 11:13:38 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) MartinBasti commented: """ I left json_decode() only in places where external JSON request are coming, all other internal usages of JSON should be in utf-8 encoding. Other requests are out of scope of this PR and should be resolved in separate tickets/PRs """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-273733412 From freeipa-github-notification at redhat.com Thu Jan 19 10:19:38 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 11:19:38 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: MartinBasti Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 30314 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 10:19:52 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 11:19:52 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) MartinBasti commented: """ I left json_decode() only in places where external JSON request are coming, all other internal usages of JSON should be in utf-8 encoding. Other requests are out of scope of this PR and should be resolved in separate tickets/PRs """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-273733412 From freeipa-github-notification at redhat.com Thu Jan 19 10:21:17 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 11:21:17 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) tiran commented: """ I have opened ticket https://fedorahosted.org/freeipa/ticket/6624 to track the matter. """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-273735484 From freeipa-github-notification at redhat.com Thu Jan 19 10:28:06 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Thu, 19 Jan 2017 11:28:06 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ @simo5, I can confirm that the ldapi error occurs every other install. I can also confirm that it does not occur during the initial server install on a clean machine, so I agree it can be fixed later. * CA-less install is still broken. To reproduce the bug, make sure to delete all certificates from `/etc/httpd/alias` before running the install, otherwise [ticket 4639](https://fedorahosted.org/freeipa/ticket/4639) will hide the bug. I use: ```bash certutil -d /etc/httpd/alias -L | tail -n +5 | sed -r 's/ +[^ ]+ *$//' | xargs -I nickname -r sh -c "certutil -d /etc/httpd/alias -D -n 'nickname'" ``` * Replica install fails when `/var/lib/ipa/radb` does not exist prior to running the install: ``` [28/45]: retrieving DS Certificate [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) ``` * `/var/lib/ipa/radb` should be removed on uninstall. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-273737162 From freeipa-github-notification at redhat.com Thu Jan 19 12:29:32 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 13:29:32 +0100 Subject: [Freeipa-devel] [freeipa PR#372][+rejected] Restore IPA 3.0 compatibility of copy-schema-to-ca.py In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/372 Title: #372: Restore IPA 3.0 compatibility of copy-schema-to-ca.py Label: +rejected From freeipa-github-notification at redhat.com Thu Jan 19 13:13:14 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 14:13:14 +0100 Subject: [Freeipa-devel] [freeipa PR#364][synchronized] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Author: tiran Title: #364: Client-only builds with --disable-server Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/364/head:pr364 git checkout pr364 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-364.patch Type: text/x-diff Size: 18991 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 13:13:50 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 14:13:50 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: MartinBasti Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 29825 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 13:19:36 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 14:19:36 +0100 Subject: [Freeipa-devel] [freeipa PR#404][comment] tests: Add LDAP URI to ldappasswd explicitelly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Title: #404: tests: Add LDAP URI to ldappasswd explicitelly tiran commented: """ ```ipatests/test_integration/util.py``` calls ldappasswd without ```-H``` option, too. Related to the issue at hand, ```ipaserver/install/service.py``` has a similar issue with ldapmodify. """ See the full comment at https://github.com/freeipa/freeipa/pull/404#issuecomment-273774110 From freeipa-github-notification at redhat.com Thu Jan 19 13:45:25 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 14:45:25 +0100 Subject: [Freeipa-devel] [freeipa PR#379][synchronized] Packaging: Add placeholder and IPA commands packages In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Author: tiran Title: #379: Packaging: Add placeholder and IPA commands packages Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/379/head:pr379 git checkout pr379 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-379.patch Type: text/x-diff Size: 20641 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 13:51:50 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 19 Jan 2017 14:51:50 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. tiran commented: """ @stlaz the patch looks fine to me now. I can't comment on the path values, though. Do you like to see additional modifications? """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-273781036 From freeipa-github-notification at redhat.com Thu Jan 19 14:54:09 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 15:54:09 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. stlaz commented: """ @tiran I would like to test this in a Vagrant box before pushing it """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-273796530 From freeipa-github-notification at redhat.com Thu Jan 19 15:03:34 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 16:03:34 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. stlaz commented: """ @tiran I would like to test this in a Vagrant box before pushing it """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-273796530 From freeipa-github-notification at redhat.com Thu Jan 19 15:20:56 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 16:20:56 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. stlaz commented: """ The patch seems fine, I could have some nitpicks but nothing really imporant. ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-273803873 From freeipa-github-notification at redhat.com Thu Jan 19 15:21:03 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 16:21:03 +0100 Subject: [Freeipa-devel] [freeipa PR#373][+ack] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. Label: +ack From freeipa-github-notification at redhat.com Thu Jan 19 15:25:38 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:25:38 +0100 Subject: [Freeipa-devel] [freeipa PR#393][comment] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 MartinBasti commented: """ @tiran we found the issue that caues random test fails, @HonzaCholasta will provide PR with fix, that should be pushed before these commits """ See the full comment at https://github.com/freeipa/freeipa/pull/393#issuecomment-273805191 From freeipa-github-notification at redhat.com Thu Jan 19 15:27:12 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:27:12 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 52908 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 19 15:46:10 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:46:10 +0100 Subject: [Freeipa-devel] [freeipa PR#373][comment] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/e04b75cb9e71fb2b9faa49aea7f2244b01fddbcb """ See the full comment at https://github.com/freeipa/freeipa/pull/373#issuecomment-273811327 From freeipa-github-notification at redhat.com Thu Jan 19 15:46:11 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:46:11 +0100 Subject: [Freeipa-devel] [freeipa PR#373][+pushed] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Title: #373: ipaplatform: Add Debian platform module. Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 19 15:46:12 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:46:12 +0100 Subject: [Freeipa-devel] [freeipa PR#373][closed] ipaplatform: Add Debian platform module. In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/373 Author: tjaalton Title: #373: ipaplatform: Add Debian platform module. Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/373/head:pr373 git checkout pr373 From freeipa-github-notification at redhat.com Thu Jan 19 15:57:51 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 16:57:51 +0100 Subject: [Freeipa-devel] [freeipa PR#404][edited] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Author: dkupka Title: #404: tests: Add LDAP URI to ldappasswd explicitly Action: edited Changed field: title Original value: """ tests: Add LDAP URI to ldappasswd explicitelly """ From freeipa-github-notification at redhat.com Thu Jan 19 16:37:13 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:37:13 +0100 Subject: [Freeipa-devel] [freeipa PR#210][comment] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Title: #210: Tests: Stage User Tracker implementation MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a336de630e9d1ef95a507cc3ee9200c001ab9193 https://fedorahosted.org/freeipa/changeset/c391f6ba58a61e046e49e1b4526b62d7ce250301 """ See the full comment at https://github.com/freeipa/freeipa/pull/210#issuecomment-273826976 From freeipa-github-notification at redhat.com Thu Jan 19 16:37:15 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:37:15 +0100 Subject: [Freeipa-devel] [freeipa PR#210][+pushed] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Title: #210: Tests: Stage User Tracker implementation Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 19 16:37:16 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:37:16 +0100 Subject: [Freeipa-devel] [freeipa PR#210][closed] Tests: Stage User Tracker implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/210 Author: gkaihorodova Title: #210: Tests: Stage User Tracker implementation Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/210/head:pr210 git checkout pr210 From freeipa-github-notification at redhat.com Thu Jan 19 16:39:39 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:39:39 +0100 Subject: [Freeipa-devel] [freeipa PR#181][+pushed] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values Label: +pushed From freeipa-github-notification at redhat.com Thu Jan 19 16:39:40 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:39:40 +0100 Subject: [Freeipa-devel] [freeipa PR#181][comment] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Title: #181: Tests : User Tracker creation of user with minimal values MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/fa7aaef1de2c97ac9d24925ca9adb25c7151055f https://fedorahosted.org/freeipa/changeset/91c050b4e093802d8c6b510a22d6e435faba965f """ See the full comment at https://github.com/freeipa/freeipa/pull/181#issuecomment-273827674 From freeipa-github-notification at redhat.com Thu Jan 19 16:39:42 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 17:39:42 +0100 Subject: [Freeipa-devel] [freeipa PR#181][closed] Tests : User Tracker creation of user with minimal values In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/181 Author: gkaihorodova Title: #181: Tests : User Tracker creation of user with minimal values Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/181/head:pr181 git checkout pr181 From freeipa-github-notification at redhat.com Thu Jan 19 17:17:10 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Thu, 19 Jan 2017 18:17:10 +0100 Subject: [Freeipa-devel] [freeipa PR#376][comment] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Title: #376: client install: correctly report all failures stlaz commented: """ I suspect we are suffering the same "always return 0" error as we've already got reported in other installers, right? """ See the full comment at https://github.com/freeipa/freeipa/pull/376#issuecomment-273838624 From freeipa-github-notification at redhat.com Thu Jan 19 17:43:45 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Thu, 19 Jan 2017 18:43:45 +0100 Subject: [Freeipa-devel] [freeipa PR#139][comment] WebUI: Vault Management In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/139 Title: #139: WebUI: Vault Management MartinBasti commented: """ Works for me """ See the full comment at https://github.com/freeipa/freeipa/pull/139#issuecomment-273845743 From freeipa-github-notification at redhat.com Thu Jan 19 20:39:44 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Thu, 19 Jan 2017 21:39:44 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ I cannot get a replica install to fail like your did, can you post some logs ? """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-273891819 From freeipa-github-notification at redhat.com Fri Jan 20 04:07:39 2017 From: freeipa-github-notification at redhat.com (redhatrises) Date: Fri, 20 Jan 2017 05:07:39 +0100 Subject: [Freeipa-devel] [freeipa PR#403][synchronized] Add new ipa passwd-generate command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Author: redhatrises Title: #403: Add new ipa passwd-generate command Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/403/head:pr403 git checkout pr403 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-403.patch Type: text/x-diff Size: 5357 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 20 06:56:09 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Fri, 20 Jan 2017 07:56:09 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ Here's what I did ``` # certutil -d /etc/httpd/alias -L | tail -n +5 | sed -r 's/ +[^ ]+ *$//' | xargs -I nickname -r sh -c "certutil -d /etc/httpd/alias -D -n 'nickname'" # rm -rf /var/lib/ipa/radb # ipa-replica-install --domain abc.idm.lab.eng.brq.redhat.com --server vm-226.abc.idm.lab.eng.brq.redhat.com --principal admin --password blablabla ... [28/45]: retrieving DS Certificate [error] RuntimeError: Certificate issuance failed (CA_UNREACHABLE) Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR Certificate issuance failed (CA_UNREACHABLE) ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information # getcert list Number of certificates and requests being tracked: 1. Request ID '20170120063423': status: CA_UNREACHABLE ca-error: Server at https://vm-226.abc.idm.lab.eng.brq.redhat.com/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://vm-226.abc.idm.lab.eng.brq.redhat.com:443/ca/rest/account/login': (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format.). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-ABC-IDM-LAB-ENG-BRQ-REDHAT-COM',nickname='Server-Cert' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes # certutil -d /var/lib/ipa/radb -L certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. # stat /var/lib/ipa/radb stat: cannot stat '/var/lib/ipa/radb': No such file or directory ``` Here's the full replica install log: http://pastebin.com/kwj8nFcC """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-273991634 From freeipa-github-notification at redhat.com Fri Jan 20 07:45:29 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Fri, 20 Jan 2017 08:45:29 +0100 Subject: [Freeipa-devel] [freeipa PR#405][opened] ipa-restore must stop tracking PKINIT cert in the preparation phase Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Author: flo-renaud Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase Action: opened PR body: """ ipa-restore calls certmonger to stop tracking the PKI certs, HTTP and DS certs. It must also stop tracking the newly introduced PKINIT cert (stored in /var/kerberos/krb5kdc/kdc.crt). Otherwise the restore operation ends up with PKINIT cert tracked twice and uninstallation fails. https://fedorahosted.org/freeipa/ticket/6570 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/405/head:pr405 git checkout pr405 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-405.patch Type: text/x-diff Size: 1678 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 20 08:13:14 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 20 Jan 2017 09:13:14 +0100 Subject: [Freeipa-devel] [freeipa PR#379][synchronized] Packaging: Add placeholder and IPA commands packages In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Author: tiran Title: #379: Packaging: Add placeholder and IPA commands packages Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/379/head:pr379 git checkout pr379 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-379.patch Type: text/x-diff Size: 19190 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 20 08:14:07 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 20 Jan 2017 09:14:07 +0100 Subject: [Freeipa-devel] [freeipa PR#376][comment] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Title: #376: client install: correctly report all failures stlaz commented: """ Alright, that's a known issue from the refactorings. Other than that the patch is fine. ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/376#issuecomment-274004926 From freeipa-github-notification at redhat.com Fri Jan 20 08:14:11 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Fri, 20 Jan 2017 09:14:11 +0100 Subject: [Freeipa-devel] [freeipa PR#376][+ack] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Title: #376: client install: correctly report all failures Label: +ack From mbabinsk at redhat.com Fri Jan 20 09:05:13 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Jan 2017 10:05:13 +0100 Subject: [Freeipa-devel] [IMPORTANT] nss-3.28.1-1.2.fc25 from updates-testing breaks FreeIPA Message-ID: <7e160747-1eeb-c7d8-28f1-f0f057c52130@redhat.com> Hi list, I have noticed the following failures in our Travis CI during server installation phase: https://paste.fedoraproject.org/531238/84902361/ After inspecting ipaclient-install.log the following error can be observed: """ 2017-01-20T08:47:51Z DEBUG Verifying that master.ipa.test (realm IPA.TEST) is an IPA server 2017-01-20T08:47:51Z DEBUG Init LDAP connection to: ldap://master.ipa.test:389 2017-01-20T08:47:51Z DEBUG Error checking LDAP: Connect error: TLS error -12286:Cannot communicate securely with peer: no common encryption algorithm(s). 2017-01-20T08:47:51Z WARNING Skip master.ipa.test: cannot verify if this is an IPA server 2017-01-20T08:47:51Z DEBUG Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.test, kdc=master.ipa.test, basedn=None """ Digging deeper into the issue reveals that it is caused by recent addition of nss-3.28.1-1.2.fc25.x86_64 (since the installation works fine using older 3.27.0-1.3.fc25 package). I was unable to find this build in Bodhi so it seems that it was pushed to updates-testing directly, probably as a security update. Should I open a bugzilla against NSS so that the maintainers know about this issue? Or is it caused on FreeIPA side and we need to update our codebase? Interestingly, a packaging bug[1] prevented me to downgrade to working version, so after update we are left with unusable environment with no easy way to revert to a working configuration. In the meanwhile I advise you to disable updates-testing on F25 altogether until the issue is resolved. I will also prepare and test a new Docker Image for Travis that will (hopefully) restore CI to working state. [1] https://paste.fedoraproject.org/531240/49028321/ -- Martin^3 Babinsky From mbabinsk at redhat.com Fri Jan 20 09:13:22 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Jan 2017 10:13:22 +0100 Subject: [Freeipa-devel] [IMPORTANT] nss-3.28.1-1.2.fc25 from updates-testing breaks FreeIPA In-Reply-To: <7e160747-1eeb-c7d8-28f1-f0f057c52130@redhat.com> References: <7e160747-1eeb-c7d8-28f1-f0f057c52130@redhat.com> Message-ID: <841d7ae5-5e30-5db1-54ba-a11984a1bbe0@redhat.com> On 01/20/2017 10:05 AM, Martin Babinsky wrote: > Hi list, > > I have noticed the following failures in our Travis CI during server > installation phase: > > https://paste.fedoraproject.org/531238/84902361/ > > After inspecting ipaclient-install.log the following error can be observed: > """ > 2017-01-20T08:47:51Z DEBUG Verifying that master.ipa.test (realm > IPA.TEST) is an IPA server > 2017-01-20T08:47:51Z DEBUG Init LDAP connection to: > ldap://master.ipa.test:389 > 2017-01-20T08:47:51Z DEBUG Error checking LDAP: Connect error: TLS error > -12286:Cannot communicate securely with peer: no common encryption > algorithm(s). > 2017-01-20T08:47:51Z WARNING Skip master.ipa.test: cannot verify if this > is an IPA server > 2017-01-20T08:47:51Z DEBUG Discovery result: UNKNOWN_ERROR; server=None, > domain=ipa.test, kdc=master.ipa.test, basedn=None > """ > > Digging deeper into the issue reveals that it is caused by recent > addition of nss-3.28.1-1.2.fc25.x86_64 (since the installation works > fine using older 3.27.0-1.3.fc25 package). I was unable to find this > build in Bodhi so it seems that it was pushed to updates-testing > directly, probably as a security update. > > Should I open a bugzilla against NSS so that the maintainers know about > this issue? Or is it caused on FreeIPA side and we need to update our > codebase? > > Interestingly, a packaging bug[1] prevented me to downgrade to working > version, so after update we are left with unusable environment with no > easy way to revert to a working configuration. In the meanwhile I advise > you to disable updates-testing on F25 altogether until the issue is > resolved. I will also prepare and test a new Docker Image for Travis > that will (hopefully) restore CI to working state. > > [1] https://paste.fedoraproject.org/531240/49028321/ > update: I have found the respective build in Bodhi[1] marked as unpushed, so we just have to wait until it is kicked out of updates-testing. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 -- Martin^3 Babinsky From wibrown at redhat.com Wed Jan 18 02:27:13 2017 From: wibrown at redhat.com (William Brown) Date: Wed, 18 Jan 2017 12:27:13 +1000 Subject: [Freeipa-devel] GetEffectiveRights and add ACIs In-Reply-To: <587CF023.9090500@redhat.com> References: <20170113062116.GF4539@dhcp-40-8.bne.redhat.com> <58788BD9.8020904@redhat.com> <5878A579.8020807@redhat.com> <58790D55.5070602@redhat.com> <587CF023.9090500@redhat.com> Message-ID: <1484706433.21856.24.camel@redhat.com> On Mon, 2017-01-16 at 17:09 +0100, Ludwig Krispenz wrote: > On 01/13/2017 06:24 PM, thierry bordaz wrote: > > Hello, > > > > The option specifies the value of 'objectclass' attribute during the > > GER. That is evaluated at attributeLevelRights but not at the > > entryLevelRights. I was not able to fix the test case using this option. > > > > For information I opened that ticket > > https://fedorahosted.org/freeipa/ticket/6609 > I think we need a 389-ds ticket as well. Looking into it, the aci code > contains parts to construct a template entry to evaluate access to a non > existent entry, but it is not called because either entries are found > and processed or the search returns no such object. > It should be possible to make this work. Agreed, lets make a ds ticket for this. It sounds like Fraser is blocked on this, so we should probably work it out sooner than later, but I think that can be discussed at triage. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From sbose at redhat.com Fri Jan 20 09:34:46 2017 From: sbose at redhat.com (Sumit Bose) Date: Fri, 20 Jan 2017 10:34:46 +0100 Subject: [Freeipa-devel] [RFC] Matching and Mapping Certificates In-Reply-To: References: <20161011113709.GC4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <20161013165235.GH4864@p.Speedport_W_724V_Typ_A_05011603_00_009> <8fa31830-3f04-6a99-596c-5d05421b07cf@redhat.com> <5804E54E.4050707@redhat.com> <20170105093934.GA3710@p.Speedport_W_724V_Typ_A_05011603_00_011> <0b522bc7-de1f-f81b-cfad-ba418c93d414@redhat.com> <20170106093037.GG3710@p.Speedport_W_724V_Typ_A_05011603_00_011> Message-ID: <20170120093446.GD21016@p.Speedport_W_724V_Typ_A_05011603_00_011> On Mon, Jan 09, 2017 at 08:46:22AM +0100, Jan Cholasta wrote: > On 6.1.2017 10:30, Sumit Bose wrote: > > On Fri, Jan 06, 2017 at 08:50:14AM +0100, Jan Cholasta wrote: > > > On 5.1.2017 10:39, Sumit Bose wrote: > > > > On Mon, Jan 02, 2017 at 09:18:47AM +0100, Jan Cholasta wrote: > > > > > On 18.10.2016 07:34, Jan Cholasta wrote: > > > > > > On 17.10.2016 16:50, Rob Crittenden wrote: > > > > > > > Jan Cholasta wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On 13.10.2016 18:52, Sumit Bose wrote: > > > > > > > > > ===== Issuer specific matching ===== > > > > > > > > > Although the MIT Kerberos rules allow to select the issuer of a > > > > > > > > > certificate there are use cases where a more specific selection is > > > > > > > > > needed. E.g. if there are some default matching rules for all issuers > > > > > > > > > and some other issuer specific rules where the default rules should > > > > > > > > > not apply. To make this possible with the above scheme the default > > > > > > > > > rules must have an clause which matches all but the issuer > > > > > > > > > with the specific rules. Writing regular-expressions to not match a > > > > > > > > > specific string or a list of strings is at least error-prone if not > > > > > > > > > impossible. > > > > > > > > > > > > > > > > > > To make it easier to define issuer specific rules and default rules at > > > > > > > > > the same time and optional issuer string can be added to the rule to > > > > > > > > > indicate that for the given issuer only those rules should be > > > > > > > > > considered. Given the use-case I think it is acceptable to require > > > > > > > > > that the full issuer must be specified here in LDAP order (see below) > > > > > > > > > and case-sensitive matching is used. > > > > > > > > > > > > > > > > This could also be solved by adding priority to rules - if two rules > > > > > > > > match, the one with higher priority (the issuer specific rule) is > > > > > > > > preferred over the one with lower priority (the default rule). IMO this > > > > > > > > is better than an optional issuer string as it offers greater > > > > > > > > flexibility. > > > > > > > > > > > > > > The use cases I've seen haven't had to do with priority, though that > > > > > > > would be a nice enhancement, but with only allowing certificates issued > > > > > > > by a specific CA to be allowed (this is pretty common in web servers). > > > > > > > Being able to say "only do the matching on certificates issued by foo" > > > > > > > is valuable. > > > > > > > > > > > > Sure, I'm not suggesting that matching by issuer should be removed, only > > > > > > that rule precedence should not be determined by the issuer field setting. > > > > > > > > > > > > > > > > Bump. Sumit, what is your opinion on this? > > > > > > > > I'm fine with an optional(?) priority as well. Since priorities are > > > > already used in the pwpolicies this should be already known to the > > > > experienced admin. I guess we just have stick with "A lower value > > > > indicates a higher priority" to not confuse users. That's why I think > > > > that the priority should be optional here and a missing value indicates > > > > the lowest priority (default rules). > > > > > > In pwpolicy and sudorule, the priority is required and has to be unique. > > > Maybe we should do this for certificate mapping rules as well? > > > > I think there is no requirement that only a single rule should match > > hence I think the priority here must not be unique. > > Is there a requirement that it must be possible for multiple rules to match? > If not, we could begin with a simpler (for admin) solution with unique > priorities and lift the restriction later when/if it becomes necessary. But > I don't have a strong opinion on this. me neither (I was hoping other people might chime in as well) My reasoning just was that not requiring uniqueness is more flexible (but of course it is easier to lift the restriction later than enforce it later). Additionally imo it would be simpler for the admin because the admin does not have to think about how to order a list of rules which are logically on the same level (e.g. rules for different issuers). But as said I do not have a strong opinion here either. bye, Sumit > > > > > > > > > > > > > > Are you thinking of using the CoS scheme here as well would a priority > > > > attribute be sufficient because we do not want to reference internal > > > > objects in the mapping rules? > > > > > > I'm not sure how CoS would be helpful here, I think a simple interger > > > attribute would be perfectly sufficient. > > > > I agree. > > > > bye, > > Sumit > > > > > > > > > > > > > bye, > > > > Sumit > > > > > > > > > > > > > > -- > > > > > Jan Cholasta > > > > > > > > > -- > > > Jan Cholasta > > > -- > Jan Cholasta From freeipa-github-notification at redhat.com Fri Jan 20 12:26:10 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Fri, 20 Jan 2017 13:26:10 +0100 Subject: [Freeipa-devel] [freeipa PR#406][opened] _resolve_records: fix assert, nameserver_ip can be none Message-ID: URL: https://github.com/freeipa/freeipa/pull/406 Author: MartinBasti Title: #406: _resolve_records: fix assert, nameserver_ip can be none Action: opened PR body: """ """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/406/head:pr406 git checkout pr406 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-406.patch Type: text/x-diff Size: 830 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Fri Jan 20 12:32:38 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Fri, 20 Jan 2017 13:32:38 +0100 Subject: [Freeipa-devel] [freeipa PR#364][synchronized] Client-only builds with --disable-server In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/364 Author: tiran Title: #364: Client-only builds with --disable-server Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/364/head:pr364 git checkout pr364 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-364.patch Type: text/x-diff Size: 18991 bytes Desc: not available URL: From mbabinsk at redhat.com Fri Jan 20 14:57:37 2017 From: mbabinsk at redhat.com (Martin Babinsky) Date: Fri, 20 Jan 2017 15:57:37 +0100 Subject: [Freeipa-devel] [IMPORTANT] nss-3.28.1-1.2.fc25 from updates-testing breaks FreeIPA In-Reply-To: <841d7ae5-5e30-5db1-54ba-a11984a1bbe0@redhat.com> References: <7e160747-1eeb-c7d8-28f1-f0f057c52130@redhat.com> <841d7ae5-5e30-5db1-54ba-a11984a1bbe0@redhat.com> Message-ID: On 01/20/2017 10:13 AM, Martin Babinsky wrote: > On 01/20/2017 10:05 AM, Martin Babinsky wrote: >> Hi list, >> >> I have noticed the following failures in our Travis CI during server >> installation phase: >> >> https://paste.fedoraproject.org/531238/84902361/ >> >> After inspecting ipaclient-install.log the following error can be >> observed: >> """ >> 2017-01-20T08:47:51Z DEBUG Verifying that master.ipa.test (realm >> IPA.TEST) is an IPA server >> 2017-01-20T08:47:51Z DEBUG Init LDAP connection to: >> ldap://master.ipa.test:389 >> 2017-01-20T08:47:51Z DEBUG Error checking LDAP: Connect error: TLS error >> -12286:Cannot communicate securely with peer: no common encryption >> algorithm(s). >> 2017-01-20T08:47:51Z WARNING Skip master.ipa.test: cannot verify if this >> is an IPA server >> 2017-01-20T08:47:51Z DEBUG Discovery result: UNKNOWN_ERROR; server=None, >> domain=ipa.test, kdc=master.ipa.test, basedn=None >> """ >> >> Digging deeper into the issue reveals that it is caused by recent >> addition of nss-3.28.1-1.2.fc25.x86_64 (since the installation works >> fine using older 3.27.0-1.3.fc25 package). I was unable to find this >> build in Bodhi so it seems that it was pushed to updates-testing >> directly, probably as a security update. >> >> Should I open a bugzilla against NSS so that the maintainers know about >> this issue? Or is it caused on FreeIPA side and we need to update our >> codebase? >> >> Interestingly, a packaging bug[1] prevented me to downgrade to working >> version, so after update we are left with unusable environment with no >> easy way to revert to a working configuration. In the meanwhile I advise >> you to disable updates-testing on F25 altogether until the issue is >> resolved. I will also prepare and test a new Docker Image for Travis >> that will (hopefully) restore CI to working state. >> >> [1] https://paste.fedoraproject.org/531240/49028321/ >> > > update: I have found the respective build in Bodhi[1] marked as > unpushed, so we just have to wait until it is kicked out of > updates-testing. > > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2017-e42b513012 > update: I have re-built the test runner image with disabled updates testing. The Travis CI jobs should be green again if you restart them. -- Martin^3 Babinsky From freeipa-github-notification at redhat.com Fri Jan 20 16:34:29 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 17:34:29 +0100 Subject: [Freeipa-devel] [freeipa PR#376][closed] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Author: HonzaCholasta Title: #376: client install: correctly report all failures Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/376/head:pr376 git checkout pr376 From freeipa-github-notification at redhat.com Fri Jan 20 16:34:31 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 17:34:31 +0100 Subject: [Freeipa-devel] [freeipa PR#376][comment] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Title: #376: client install: correctly report all failures martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/26630db9d0fb1d9c8a02840b71b3fb3e8bdf3e0d """ See the full comment at https://github.com/freeipa/freeipa/pull/376#issuecomment-274116801 From freeipa-github-notification at redhat.com Fri Jan 20 16:34:32 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 17:34:32 +0100 Subject: [Freeipa-devel] [freeipa PR#376][+pushed] client install: correctly report all failures In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/376 Title: #376: client install: correctly report all failures Label: +pushed From freeipa-github-notification at redhat.com Fri Jan 20 18:14:26 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 19:14:26 +0100 Subject: [Freeipa-devel] [freeipa PR#405][comment] ipa-restore must stop tracking PKINIT cert in the preparation phase In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase martbab commented: """ Thanks, the patch looks ok and backup-restore tests passed. """ See the full comment at https://github.com/freeipa/freeipa/pull/405#issuecomment-274140616 From freeipa-github-notification at redhat.com Fri Jan 20 18:15:35 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 19:15:35 +0100 Subject: [Freeipa-devel] [freeipa PR#405][+ack] ipa-restore must stop tracking PKINIT cert in the preparation phase In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase Label: +ack From freeipa-github-notification at redhat.com Fri Jan 20 18:16:49 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 19:16:49 +0100 Subject: [Freeipa-devel] [freeipa PR#405][+pushed] ipa-restore must stop tracking PKINIT cert in the preparation phase In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase Label: +pushed From freeipa-github-notification at redhat.com Fri Jan 20 18:16:51 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 19:16:51 +0100 Subject: [Freeipa-devel] [freeipa PR#405][comment] ipa-restore must stop tracking PKINIT cert in the preparation phase In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/ceec512b09002e8cf9388873418644ec584db30a """ See the full comment at https://github.com/freeipa/freeipa/pull/405#issuecomment-274141186 From freeipa-github-notification at redhat.com Fri Jan 20 18:16:52 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Fri, 20 Jan 2017 19:16:52 +0100 Subject: [Freeipa-devel] [freeipa PR#405][closed] ipa-restore must stop tracking PKINIT cert in the preparation phase In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/405 Author: flo-renaud Title: #405: ipa-restore must stop tracking PKINIT cert in the preparation phase Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/405/head:pr405 git checkout pr405 From freeipa-github-notification at redhat.com Sat Jan 21 18:42:35 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Sat, 21 Jan 2017 19:42:35 +0100 Subject: [Freeipa-devel] [freeipa PR#407][opened] New lite-server implementation Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Author: tiran Title: #407: New lite-server implementation Action: opened PR body: """ The new development server depends on werkzeug instead of paste. The werkzeug WSGI server comes with some additional features, most noticeable multi-processing server. The IPA framework is not compatible with threaded servers. Werkzeug can serve static files easily and has a fast auto-reloader. The new lite-server implementation depends on PR 314 (privilege separation). For Python 3 support, it additionally depends on PR 393. Signed-off-by: Christian Heimes """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/407/head:pr407 git checkout pr407 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-407.patch Type: text/x-diff Size: 10900 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Sat Jan 21 18:47:15 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Sat, 21 Jan 2017 19:47:15 +0100 Subject: [Freeipa-devel] [freeipa PR#407][edited] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Author: tiran Title: #407: New lite-server implementation Action: edited Changed field: body Original value: """ The new development server depends on werkzeug instead of paste. The werkzeug WSGI server comes with some additional features, most noticeable multi-processing server. The IPA framework is not compatible with threaded servers. Werkzeug can serve static files easily and has a fast auto-reloader. The new lite-server implementation depends on PR 314 (privilege separation). For Python 3 support, it additionally depends on PR 393. Signed-off-by: Christian Heimes """ From freeipa-github-notification at redhat.com Sun Jan 22 13:07:21 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Sun, 22 Jan 2017 14:07:21 +0100 Subject: [Freeipa-devel] [freeipa PR#407][synchronized] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Author: tiran Title: #407: New lite-server implementation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/407/head:pr407 git checkout pr407 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-407.patch Type: text/x-diff Size: 11467 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 08:42:32 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 23 Jan 2017 09:42:32 +0100 Subject: [Freeipa-devel] [freeipa PR#407][synchronized] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Author: tiran Title: #407: New lite-server implementation Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/407/head:pr407 git checkout pr407 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-407.patch Type: text/x-diff Size: 11530 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 09:27:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 23 Jan 2017 10:27:19 +0100 Subject: [Freeipa-devel] [freeipa PR#408][opened] ipaldap: properly escape raw binary values in LDAP filters Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Author: HonzaCholasta Title: #408: ipaldap: properly escape raw binary values in LDAP filters Action: opened PR body: """ Manually escape each byte in the value, do not use ldap.filter.escape_filter_chars() as it does not work with bytes in Python 3. https://fedorahosted.org/freeipa/ticket/4985 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/408/head:pr408 git checkout pr408 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-408.patch Type: text/x-diff Size: 1299 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 11:12:33 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 23 Jan 2017 12:12:33 +0100 Subject: [Freeipa-devel] [freeipa PR#379][synchronized] Packaging: Add placeholder and IPA commands packages In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Author: tiran Title: #379: Packaging: Add placeholder and IPA commands packages Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/379/head:pr379 git checkout pr379 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-379.patch Type: text/x-diff Size: 19284 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 11:19:17 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 23 Jan 2017 12:19:17 +0100 Subject: [Freeipa-devel] [freeipa PR#408][synchronized] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Author: HonzaCholasta Title: #408: ipaldap: properly escape raw binary values in LDAP filters Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/408/head:pr408 git checkout pr408 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-408.patch Type: text/x-diff Size: 1615 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 11:26:05 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 23 Jan 2017 12:26:05 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ @LiptonB, there's still one issue which I'd like to be resolved in this PR, and that's that currently CSR templates are tied to certificate profiles. IMO this needs to be changed, as certificate profiles in IPA are Dogtag-specific, but Dogtag is not required to generate CSRs with this feature, and it should be possible to use this feature even in CA-less mode when Dogtag is not installed and certificate profiles are not available. Luckily this PR has no hard dependency on certificate profiles, with the exception of the `validate_profile_id()` call and the inclusion of the `userCert` profile, both of which I would like to be removed before the PR is merged. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-274463063 From freeipa-github-notification at redhat.com Mon Jan 23 12:30:46 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 23 Jan 2017 13:30:46 +0100 Subject: [Freeipa-devel] [freeipa PR#408][synchronized] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Author: HonzaCholasta Title: #408: ipaldap: properly escape raw binary values in LDAP filters Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/408/head:pr408 git checkout pr408 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-408.patch Type: text/x-diff Size: 1613 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 12:40:54 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 23 Jan 2017 13:40:54 +0100 Subject: [Freeipa-devel] [freeipa PR#379][comment] Packaging: Add placeholder and IPA commands packages In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/379 Title: #379: Packaging: Add placeholder and IPA commands packages tiran commented: """ The ```ipa``` and ```freeipa``` packages are necessary to prevent typo squatting or name squatting attacks, e.g. http://arstechnica.com/security/2016/06/college-student-schools-govs-and-mils-on-perils-of-arbitrary-code-execution/ . We want to make sure that a developer gets FreeIPA when he does ```pip install freeipa```. I already reserved the names on PyPI. It is necessary to upload new packages for ```ipa``` and ```freeipa``` regularly. Otherwise PyPI considers our packages obsolete and may remove them. See https://www.python.org/dev/peps/pep-0541/ """ See the full comment at https://github.com/freeipa/freeipa/pull/379#issuecomment-274478485 From freeipa-github-notification at redhat.com Mon Jan 23 13:34:38 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Mon, 23 Jan 2017 14:34:38 +0100 Subject: [Freeipa-devel] [freeipa PR#397][synchronized] Improve wheel building and provide ipaserver wheel for local testing In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/397 Author: tiran Title: #397: Improve wheel building and provide ipaserver wheel for local testing Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/397/head:pr397 git checkout pr397 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-397.patch Type: text/x-diff Size: 10879 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 13:35:32 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Mon, 23 Jan 2017 14:35:32 +0100 Subject: [Freeipa-devel] [freeipa PR#395][synchronized] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Author: flo-renaud Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/395/head:pr395 git checkout pr395 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-395.patch Type: text/x-diff Size: 1702 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 13:40:10 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Mon, 23 Jan 2017 14:40:10 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" flo-renaud commented: """ This PR has been modified to be consistent with PKI fix for [2570](https://fedorahosted.org/pki/ticket/2570). PKI now defines by default the AJP redirection to "localhost", meaning that we do not need any more to override this setting. Upgrade is also handled by PKI. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-274490123 From freeipa-github-notification at redhat.com Mon Jan 23 14:39:16 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Mon, 23 Jan 2017 15:39:16 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates tomaskrizek commented: """ The behavior of the command seems to be correct now, but I'm also not sure about the WebUI. There seems to be a limit of 20 items when displayed in WebUI (with pagination). I'm not sure if it's possible to configure that. @pvomacka Were there any recent changes in the WebUI pagination? Is it possible to configure how many items should be displayed? """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-274504322 From freeipa-github-notification at redhat.com Mon Jan 23 14:41:53 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Mon, 23 Jan 2017 15:41:53 +0100 Subject: [Freeipa-devel] [freeipa PR#403][comment] Add new ipa passwd-generate command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Title: #403: Add new ipa passwd-generate command abbra commented: """ @redhatrises, could you please explain more why you need this command as it is? FreeIPA allows to have multiple password policies. If you want to generate passwords that conform to a particular policy, it would be more reasonable to retrieve the password policy and use it to supply as arguments of the password generator. The generated password does not need to be transferred over the network. As you are adding a command to IPA, it could be a client-side plugin because Python client side code always has access to ipapython.util module. There could be multiple password generators. For example, on Linux systems you can simply use `pwqgen` utility from passwdqc package to generate passwords compatible with FreeIPA password policies. Granted, a configuration file needs to be created that translates a FreeIPA password policy but this is at least something that a command in IPA could do on the client side after fetching a policy. If the password generation is based on a particular policy and is moved to the client side, why not creating a plugin to ipa-advise instead? It would actually generate a script that calls pwqgen or other generator tool. This would be more useful to other environments as the script would also contain a reference to the password policy parameters and can be run independent of the FreeIPA infrastructure. Let me know what do you think about it. """ See the full comment at https://github.com/freeipa/freeipa/pull/403#issuecomment-274505035 From freeipa-github-notification at redhat.com Mon Jan 23 16:32:52 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 23 Jan 2017 17:32:52 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation pvoborni commented: """ Shouldn't we rather remove lite sever completely? """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274538664 From freeipa-github-notification at redhat.com Mon Jan 23 17:09:37 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Mon, 23 Jan 2017 18:09:37 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation rcritten commented: """ I always found the lite-server to be incredibly helpful for server-side plugin development. If it isn't being used any more then I'd wonder what is being used instead. """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274550653 From freeipa-github-notification at redhat.com Mon Jan 23 18:08:17 2017 From: freeipa-github-notification at redhat.com (celestian) Date: Mon, 23 Jan 2017 19:08:17 +0100 Subject: [Freeipa-devel] [freeipa PR#409][opened] ipatests: nested netgroups (intg) Message-ID: URL: https://github.com/freeipa/freeipa/pull/409 Author: celestian Title: #409: ipatests: nested netgroups (intg) Action: opened PR body: """ Adds a test case for issue in SSSD that manifested in an inability to resolve nested membership in netgroups The test case tests for direct and indirect membership. https://fedorahosted.org/freeipa/ticket/6439 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/409/head:pr409 git checkout pr409 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-409.patch Type: text/x-diff Size: 7004 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 18:38:31 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 23 Jan 2017 19:38:31 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 237488 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 23 18:39:12 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Mon, 23 Jan 2017 19:39:12 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ The latest rebase installs a replica correctly here, haven't got to fix ca-less yet, but everything else should be ready to go. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-274577459 From freeipa-github-notification at redhat.com Tue Jan 24 02:38:20 2017 From: freeipa-github-notification at redhat.com (redhatrises) Date: Tue, 24 Jan 2017 03:38:20 +0100 Subject: [Freeipa-devel] [freeipa PR#403][comment] Add new ipa passwd-generate command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Title: #403: Add new ipa passwd-generate command redhatrises commented: """ Sorry for the delayed response. This is useful for environments where utilities like `pwgen` may not be allowed to be installed due to compliance/environment reasons. It is also especially useful for handling service accounts whose passwords have to be changed regularly or for managing passwords for shared user accounts where user's only access to the accounts is through sudo. Plus if no one is logging into the accounts, service or user, which are required to have passwords change regularly, why not have the authentication tool come up with one that is sufficient for the organizational requirements (28 different random different passwords) without having to come up with a password or having to remember x utility (which may not be allowed to be installed) from doing it? However, the final iteration of this (which I have not added yet) is to add `--user` and/or `--service-account` to handle changing those passwords with a generated password for user accounts or service accounts. Another option would be to just add an option that behaves the same way such as `--generate` to `ipa passwd` e.g. `ipa passwd user1 --generate` """ See the full comment at https://github.com/freeipa/freeipa/pull/403#issuecomment-274684765 From freeipa-github-notification at redhat.com Tue Jan 24 02:40:02 2017 From: freeipa-github-notification at redhat.com (redhatrises) Date: Tue, 24 Jan 2017 03:40:02 +0100 Subject: [Freeipa-devel] [freeipa PR#403][comment] Add new ipa passwd-generate command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/403 Title: #403: Add new ipa passwd-generate command redhatrises commented: """ Sorry for the delayed response. This is useful for environments where utilities like `pwgen` may not be allowed to be installed due to compliance/environment reasons. It is also especially useful for handling service accounts whose passwords have to be changed regularly or for managing passwords for shared user accounts where user's only access to the accounts is through sudo. Plus if no one is logging into the accounts, service or user, which are required to have passwords change regularly, why not have the authentication tool come up with one that is sufficient for the organizational requirements (28 different random different passwords) without having to come up with a password or having to remember x utility (which may not be allowed to be installed) from doing it? However, the final iteration of this (which I have not added yet) is to add `--user` and/or `--service-account` to handle changing those passwords with a generated password for user accounts or service accounts. Another option would be to just add an option that behaves the same way such as `--generate` to `ipa passwd` e.g. `ipa passwd user1 --generate` """ See the full comment at https://github.com/freeipa/freeipa/pull/403#issuecomment-274684765 From freeipa-github-notification at redhat.com Tue Jan 24 05:21:05 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Tue, 24 Jan 2017 06:21:05 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) LiptonB commented: """ @HonzaCholasta, I think I see what you mean about these templates not being dependent on dogtag, and I'm fine with removing the `userCert` dogtag profile from this PR if you don't think it's relevant. Is it ok to leave the `userCert` CSR generation profile, as an example of what the tool can do? So, do you mean we should no longer consider CSR generation profiles to be associated with IPA profiles? In https://github.com/LiptonB/freeipa/tree/local-cert-build I have code that allows you to run `ipa cert-request --autogenerate --principal someserver --profile-id caIPAserviceCert` and get a cert for the server back in one step. It uses the `caIPAserviceCert` CSR profile to make a CSR that works with the `caIPAserviceCert` IPA profile. So it seems to me that having the profiles linked makes the cert generation experience simpler, and that was the original way this feature was proposed to me. But, if you'd rather have them not be linked, should I modify this command so the CSR profile is specified with a separate flag from the IPA one? """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-274712673 From freeipa-github-notification at redhat.com Tue Jan 24 06:42:03 2017 From: freeipa-github-notification at redhat.com (celestian) Date: Tue, 24 Jan 2017 07:42:03 +0100 Subject: [Freeipa-devel] [freeipa PR#409][comment] ipatests: nested netgroups (intg) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/409 Title: #409: ipatests: nested netgroups (intg) celestian commented: """ I see there are some issues: 1. It seems Travis hit some kind of time out. Maybe it is not connected to my proposed test. 2. The QuantifiedCode issues are clear. I have PTO now and I will be back in work on Friday. But I hope I find a time to fix it sooner. """ See the full comment at https://github.com/freeipa/freeipa/pull/409#issuecomment-274722816 From freeipa-github-notification at redhat.com Tue Jan 24 07:11:19 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 24 Jan 2017 08:11:19 +0100 Subject: [Freeipa-devel] [freeipa PR#410][opened] ipa-kdb: support KDB DAL version 6.1 Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Author: abbra Title: #410: ipa-kdb: support KDB DAL version 6.1 Action: opened PR body: """ DAL version 6.0 removed support for a callback to free principal. This broke KDB drivers which had complex e_data structure within the principal structure. As result, FreeIPA KDB driver was leaking memory with DAL version 6.0 (krb5 1.15). DAL version 6.1 added a special callback for freeing e_data structure. See details at https://github.com/krb5/krb5/pull/596 Restructure KDB driver code to provide this callback in case we are built against DAL version that supports it. For DAL version prior to 6.0 use this callback in the free_principal callback to tidy the code. https://fedorahosted.org/freeipa/ticket/6619 On Fedora the required interface is available in krb5-1.15-5.fc26 package. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/410/head:pr410 git checkout pr410 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-410.patch Type: text/x-diff Size: 5364 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 07:18:30 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 24 Jan 2017 08:18:30 +0100 Subject: [Freeipa-devel] [freeipa PR#411][opened] Remove deprecated ipa-upgradeconfig command Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Author: Akasurde Title: #411: Remove deprecated ipa-upgradeconfig command Action: opened PR body: """ Fixes https://fedorahosted.org/freeipa/ticket/6620 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/411/head:pr411 git checkout pr411 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-411.patch Type: text/x-diff Size: 5208 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 07:33:37 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 08:33:37 +0100 Subject: [Freeipa-devel] [freeipa PR#409][comment] ipatests: nested netgroups (intg) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/409 Title: #409: ipatests: nested netgroups (intg) MartinBasti commented: """ Travis: ``` PEP-8 errors: ./ipatests/test_integration/test_netgroup.py:87:80: E501 line too long (84 > 79 characters) ./ipatests/test_integration/test_netgroup.py:96:80: E501 line too long (88 > 79 characters) Pylint: Pylint is running, please wait ... ************* Module ipatests.test_integration.test_netgroup ipatests/test_integration/test_netgroup.py:2: [W0512(invalid-encoded-data), ] Cannot decode using encoding "ascii", unexpected byte at position 9) ipatests/test_integration/test_netgroup.py:87: [E1101(no-member), TestNetgroups.check_users_in_netgroups] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:96: [E1101(no-member), TestNetgroups.check_nested_netgroup_hierarchy] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:125: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:130: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:131: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:132: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:147: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:148: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) ipatests/test_integration/test_netgroup.py:149: [E1101(no-member), TestNetgroups.test_remove_nested_netgroup] Class 'domain' has no 'name' member) make: *** [pylint] Error 6 ``` I'm afraid that pylint cannot handle it, so probably you have to disable problematic lines. """ See the full comment at https://github.com/freeipa/freeipa/pull/409#issuecomment-274729999 From freeipa-github-notification at redhat.com Tue Jan 24 07:54:09 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 08:54:09 +0100 Subject: [Freeipa-devel] [freeipa PR#196][comment] ipatests: unresolvable nested netgroups In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/196 Title: #196: ipatests: unresolvable nested netgroups martbab commented: """ Since the re-implementation of this test suite is done by @celestian in https://github.com/freeipa/freeipa/pull/409 can I close this PR? """ See the full comment at https://github.com/freeipa/freeipa/pull/196#issuecomment-274733248 From freeipa-github-notification at redhat.com Tue Jan 24 08:24:41 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:24:41 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation martbab commented: """ @rcritten AFAIK most of us develop plugins locally, then build RPMs which we sync to a VM, install IPA server and use ipa-run-tests to test the new plugin. I personally used lite-server only once or twice when I started out with my contribution. We had some discussion earlier in which we concluded that lite-server is not used anymore and should be removed (this is probably what @pvoborni is referring to). If you can provide compelling arguments against this decision then we can reconsider. """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274738523 From freeipa-github-notification at redhat.com Tue Jan 24 08:25:24 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Tue, 24 Jan 2017 09:25:24 +0100 Subject: [Freeipa-devel] [freeipa PR#196][comment] ipatests: unresolvable nested netgroups In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/196 Title: #196: ipatests: unresolvable nested netgroups apophys commented: """ Yes. """ See the full comment at https://github.com/freeipa/freeipa/pull/196#issuecomment-274738684 From freeipa-github-notification at redhat.com Tue Jan 24 08:25:26 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Tue, 24 Jan 2017 09:25:26 +0100 Subject: [Freeipa-devel] [freeipa PR#196][closed] ipatests: unresolvable nested netgroups In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/196 Author: apophys Title: #196: ipatests: unresolvable nested netgroups Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/196/head:pr196 git checkout pr196 From freeipa-github-notification at redhat.com Tue Jan 24 08:35:16 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 24 Jan 2017 09:35:16 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ @LiptonB, I think certificate profiles and CSR generation profiles / templates *should* be associated, but not by sharing the same logical `certprofile` object, as it creates an unwarranted dependency on Dogtag. Instead CSR templates should be represented by their own dedicated objects separate from `certprofile` objects, which can contain a reference to the default CSR template object. This way it will be possible to extend `cert-request` as you described, but it will also be possible to generate a CSR and submit it to an external CA, even in CA-less IPA deployment. As for `userCert`, removing just the dogtag profile but keeping the CSR template is exactly what I meant. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-274740750 From freeipa-github-notification at redhat.com Tue Jan 24 08:38:42 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 24 Jan 2017 09:38:42 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ @simo5, replica install still fails for me in the same way as before. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-274741477 From freeipa-github-notification at redhat.com Tue Jan 24 08:47:18 2017 From: freeipa-github-notification at redhat.com (sumit-bose) Date: Tue, 24 Jan 2017 09:47:18 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 sumit-bose commented: """ Are there any plans how to handle 6.0? Should configure at least show a warning if KRB5_KDB_DAL_MAJOR_VERSION == 6 but no free e_data callback was found? Should the .min_ver in the kdb_function_table be set to '1' if there is a free e_data callback? """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274743181 From freeipa-github-notification at redhat.com Tue Jan 24 08:51:19 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:51:19 +0100 Subject: [Freeipa-devel] [freeipa PR#411][+ack] Remove deprecated ipa-upgradeconfig command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Title: #411: Remove deprecated ipa-upgradeconfig command Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 08:52:08 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:52:08 +0100 Subject: [Freeipa-devel] [freeipa PR#411][+pushed] Remove deprecated ipa-upgradeconfig command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Title: #411: Remove deprecated ipa-upgradeconfig command Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 24 08:52:10 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:52:10 +0100 Subject: [Freeipa-devel] [freeipa PR#411][comment] Remove deprecated ipa-upgradeconfig command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Title: #411: Remove deprecated ipa-upgradeconfig command martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/c56e02b3c5257edbfd3709848ca7eda07e271e38 """ See the full comment at https://github.com/freeipa/freeipa/pull/411#issuecomment-274744170 From freeipa-github-notification at redhat.com Tue Jan 24 08:52:11 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:52:11 +0100 Subject: [Freeipa-devel] [freeipa PR#411][closed] Remove deprecated ipa-upgradeconfig command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Author: Akasurde Title: #411: Remove deprecated ipa-upgradeconfig command Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/411/head:pr411 git checkout pr411 From freeipa-github-notification at redhat.com Tue Jan 24 08:54:00 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 09:54:00 +0100 Subject: [Freeipa-devel] [freeipa PR#196][+rejected] ipatests: unresolvable nested netgroups In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/196 Title: #196: ipatests: unresolvable nested netgroups Label: +rejected From freeipa-github-notification at redhat.com Tue Jan 24 08:57:01 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:57:01 +0100 Subject: [Freeipa-devel] [freeipa PR#406][+ack] _resolve_records: fix assert, nameserver_ip can be none In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/406 Title: #406: _resolve_records: fix assert, nameserver_ip can be none Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 08:58:25 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:58:25 +0100 Subject: [Freeipa-devel] [freeipa PR#406][comment] _resolve_records: fix assert, nameserver_ip can be none In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/406 Title: #406: _resolve_records: fix assert, nameserver_ip can be none martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/ccea23138ba6e9b54c08d472341ddbd64ffc45df """ See the full comment at https://github.com/freeipa/freeipa/pull/406#issuecomment-274745599 From freeipa-github-notification at redhat.com Tue Jan 24 08:58:27 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:58:27 +0100 Subject: [Freeipa-devel] [freeipa PR#406][+pushed] _resolve_records: fix assert, nameserver_ip can be none In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/406 Title: #406: _resolve_records: fix assert, nameserver_ip can be none Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 24 08:58:28 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 09:58:28 +0100 Subject: [Freeipa-devel] [freeipa PR#406][closed] _resolve_records: fix assert, nameserver_ip can be none In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/406 Author: MartinBasti Title: #406: _resolve_records: fix assert, nameserver_ip can be none Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/406/head:pr406 git checkout pr406 From freeipa-github-notification at redhat.com Tue Jan 24 09:02:15 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 24 Jan 2017 10:02:15 +0100 Subject: [Freeipa-devel] [freeipa PR#411][comment] Remove deprecated ipa-upgradeconfig command In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/411 Title: #411: Remove deprecated ipa-upgradeconfig command Akasurde commented: """ @martbab Thanks for review. """ See the full comment at https://github.com/freeipa/freeipa/pull/411#issuecomment-274746405 From freeipa-github-notification at redhat.com Tue Jan 24 09:09:34 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 10:09:34 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: ci: send build log to paste.fedoraproject.org martbab commented: """ LGTM, it would be nice if you could temporarily sneak in some breaking commit so that we can see how the paste looks like. """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-274747924 From freeipa-github-notification at redhat.com Tue Jan 24 09:21:27 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 24 Jan 2017 10:21:27 +0100 Subject: [Freeipa-devel] [freeipa PR#353][comment] [RFE] Pwdpolicy In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/353 Title: #353: [RFE] Pwdpolicy martbab commented: """ LGTM, but the PR needs some more love since it breaks CI. """ See the full comment at https://github.com/freeipa/freeipa/pull/353#issuecomment-274750406 From freeipa-github-notification at redhat.com Tue Jan 24 09:34:18 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 24 Jan 2017 10:34:18 +0100 Subject: [Freeipa-devel] [freeipa PR#410][synchronized] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Author: abbra Title: #410: ipa-kdb: support KDB DAL version 6.1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/410/head:pr410 git checkout pr410 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-410.patch Type: text/x-diff Size: 8207 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 09:37:19 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 24 Jan 2017 10:37:19 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 abbra commented: """ Thanks for the suggestions. I've updated the configure check to explicitly warn when both .free_principal and .free_principal_e_data are missing. DAL version 5 had .free_principal and we do not support any other DAL versions yet, so this should be enough. I also merged definitions of the kdb_function_table for both DAL versions by adding corresponding initializers in the right places wrapped with the #ifdef-s. I think it will be better than the current duplication, considering we need to support three different API variations. """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274754127 From freeipa-github-notification at redhat.com Tue Jan 24 10:19:41 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Tue, 24 Jan 2017 11:19:41 +0100 Subject: [Freeipa-devel] [freeipa PR#412][opened] Define template version in certmap.conf Message-ID: URL: https://github.com/freeipa/freeipa/pull/412 Author: flo-renaud Title: #412: Define template version in certmap.conf Action: opened PR body: """ A previous commit (ffb9a09a0d63f7edae2b647b5c1d503d1d4d7a6e) removed the definition of VERSION 2 in certmap.conf.template. ipa-server-upgrade tool compares the template version with the version in certmap.conf. As VERSION is not defined in either file, it concludes that version = 0 for both and does not make a backup of certmap.conf even though it prints that it will. The fix re-defines VERSION in the template and adapts the code because the template has changed (it is using $ISSUER_DN instead of CN=Certificate Authority,$SUBJECT_BASE). The fix also logs an error when a template file is not versioned. https://fedorahosted.org/freeipa/ticket/6354 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/412/head:pr412 git checkout pr412 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-412.patch Type: text/x-diff Size: 2417 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 10:49:12 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:49:12 +0100 Subject: [Freeipa-devel] [freeipa PR#408][comment] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Title: #408: ipaldap: properly escape raw binary values in LDAP filters MartinBasti commented: """ Works for me. """ See the full comment at https://github.com/freeipa/freeipa/pull/408#issuecomment-274770016 From freeipa-github-notification at redhat.com Tue Jan 24 10:49:17 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:49:17 +0100 Subject: [Freeipa-devel] [freeipa PR#408][+ack] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Title: #408: ipaldap: properly escape raw binary values in LDAP filters Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 10:50:27 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:50:27 +0100 Subject: [Freeipa-devel] [freeipa PR#408][comment] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Title: #408: ipaldap: properly escape raw binary values in LDAP filters MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/84a9611cb885f04c72cd657c3a3e7bc4aff39d93 """ See the full comment at https://github.com/freeipa/freeipa/pull/408#issuecomment-274770296 From freeipa-github-notification at redhat.com Tue Jan 24 10:50:29 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:50:29 +0100 Subject: [Freeipa-devel] [freeipa PR#408][+pushed] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Title: #408: ipaldap: properly escape raw binary values in LDAP filters Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 24 10:50:31 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:50:31 +0100 Subject: [Freeipa-devel] [freeipa PR#408][closed] ipaldap: properly escape raw binary values in LDAP filters In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/408 Author: HonzaCholasta Title: #408: ipaldap: properly escape raw binary values in LDAP filters Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/408/head:pr408 git checkout pr408 From freeipa-github-notification at redhat.com Tue Jan 24 10:53:38 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 11:53:38 +0100 Subject: [Freeipa-devel] [freeipa PR#382][synchronized] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: MartinBasti Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-382.patch Type: text/x-diff Size: 29634 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 11:07:46 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 24 Jan 2017 12:07:46 +0100 Subject: [Freeipa-devel] [freeipa PR#401][comment] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Title: #401: [4.4] Wait until http principal entry is replicated to replica stlaz commented: """ Seems to work in the problematic ca-less environment, ACK. """ See the full comment at https://github.com/freeipa/freeipa/pull/401#issuecomment-274774373 From freeipa-github-notification at redhat.com Tue Jan 24 11:08:00 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 24 Jan 2017 12:08:00 +0100 Subject: [Freeipa-devel] [freeipa PR#401][+ack] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Title: #401: [4.4] Wait until http principal entry is replicated to replica Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 11:21:31 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 12:21:31 +0100 Subject: [Freeipa-devel] [freeipa PR#336][synchronized] [py3] pki: add missing depedency pki-base[-python3] In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/336 Author: MartinBasti Title: #336: [py3] pki: add missing depedency pki-base[-python3] Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/336/head:pr336 git checkout pr336 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-336.patch Type: text/x-diff Size: 2770 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 11:28:34 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 24 Jan 2017 12:28:34 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates tomaskrizek commented: """ We examined the WebUI side and it behaves as expected - the size limit is respected when viewing certificates. """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-274779025 From freeipa-github-notification at redhat.com Tue Jan 24 11:28:43 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 24 Jan 2017 12:28:43 +0100 Subject: [Freeipa-devel] [freeipa PR#359][+ack] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 11:55:12 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 12:55:12 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 52717 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 12:25:15 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 24 Jan 2017 13:25:15 +0100 Subject: [Freeipa-devel] [freeipa PR#382][+ack] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 12:26:14 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 13:26:14 +0100 Subject: [Freeipa-devel] [freeipa PR#382][comment] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/23239bccc18f2fdc10431134a1c6a777f450704e https://fedorahosted.org/freeipa/changeset/e0641092770530e3b93c00de415172751d031210 https://fedorahosted.org/freeipa/changeset/63b5d4a8594c5c6bc9ade69996fbbc1bcf19a2bf https://fedorahosted.org/freeipa/changeset/bbe8849a654ed0764e1834f24d1837df41a79881 https://fedorahosted.org/freeipa/changeset/7ae5e5f66919141821fdffbd6f8683c6d7afddd7 https://fedorahosted.org/freeipa/changeset/0d4074b4f1a57ed6545d819aa5a48e4b35237568 https://fedorahosted.org/freeipa/changeset/2547bca8df69e6c4d5f4c67a63fbc3c06ccc95c6 https://fedorahosted.org/freeipa/changeset/232ceed5bbfb0afa45078d8e95b84dabe4d7cafd https://fedorahosted.org/freeipa/changeset/c0b5c6709d9e3a51117994fc8b605ba54e6263d7 https://fedorahosted.org/freeipa/changeset/51578882fc8456788d69a57de1a1d45ead58ba14 https://fedorahosted.org/freeipa/changeset/0a1d7f2e01819ad6e4a19d0416b3a01883dea7d0 https://fedorahosted.org/freeipa/changeset/4b148c8ca3d022020fa6caccf02729c090c8dbcb https://fedorahosted.org/freeipa/changeset/746d4ffc583a847834a592150644fa4270486c89 https://fedorahosted.org/freeipa/changeset/1e0f98a146ecedf84b8e3e07fbd41a897ddd399d https://fedorahosted.org/freeipa/changeset/0eb5a0e0ec2d232d2921ae5f9e8d0885146a5610 https://fedorahosted.org/freeipa/changeset/18337bf7f7c31a47fe0c7280f82fca043b548bd5 """ See the full comment at https://github.com/freeipa/freeipa/pull/382#issuecomment-274790051 From freeipa-github-notification at redhat.com Tue Jan 24 12:26:16 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 13:26:16 +0100 Subject: [Freeipa-devel] [freeipa PR#382][closed] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Author: MartinBasti Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/382/head:pr382 git checkout pr382 From freeipa-github-notification at redhat.com Tue Jan 24 12:26:18 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 13:26:18 +0100 Subject: [Freeipa-devel] [freeipa PR#382][+pushed] [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/382 Title: #382: [Py3] ipa-server-install fixes (working NTP, DS, CA install steps) Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 24 12:27:28 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 13:27:28 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 23082 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 12:27:55 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 24 Jan 2017 13:27:55 +0100 Subject: [Freeipa-devel] [freeipa PR#393][comment] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 MartinBasti commented: """ Rebased, ready to be reviewed """ See the full comment at https://github.com/freeipa/freeipa/pull/393#issuecomment-274790391 From freeipa-github-notification at redhat.com Tue Jan 24 12:47:37 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 24 Jan 2017 13:47:37 +0100 Subject: [Freeipa-devel] [freeipa PR#359][comment] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/d84edc43e55c2f7c30614a4a5268aeb58e33a087 https://fedorahosted.org/freeipa/changeset/85834abad655c6aed54c0253bc194ece81d78774 """ See the full comment at https://github.com/freeipa/freeipa/pull/359#issuecomment-274794236 From freeipa-github-notification at redhat.com Tue Jan 24 12:47:38 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 24 Jan 2017 13:47:38 +0100 Subject: [Freeipa-devel] [freeipa PR#359][+pushed] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Title: #359: dogtag: search past the first 100 certificates Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 24 12:47:40 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 24 Jan 2017 13:47:40 +0100 Subject: [Freeipa-devel] [freeipa PR#359][closed] dogtag: search past the first 100 certificates In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/359 Author: HonzaCholasta Title: #359: dogtag: search past the first 100 certificates Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/359/head:pr359 git checkout pr359 From freeipa-github-notification at redhat.com Tue Jan 24 13:31:23 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 14:31:23 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 237488 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 13:31:48 2017 From: freeipa-github-notification at redhat.com (rcritten) Date: Tue, 24 Jan 2017 14:31:48 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation rcritten commented: """ Right, and IMHO that development process is inefficient and prone to error. Rather than copying bits around and doing full installs over and over you can run the server in-tree and have vastly improved debugging available. Certainly a "final" test of a full server install loop is necessary but for initial development and testing the lite-server is far easier and efficient. At one time the tests were also run almost exclusively in-tree (which was faster at the time). """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274803025 From freeipa-github-notification at redhat.com Tue Jan 24 13:48:30 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 14:48:30 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 simo5 commented: """ abbra, we should also change how spec deps work I asked @rharwood to add a provides that is the dal version number we should stop having a dep on the krb5 major version number and instead have a dependecy on this provide """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274806881 From freeipa-github-notification at redhat.com Tue Jan 24 13:53:30 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 14:53:30 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 simo5 commented: """ Also I know you can use ifdefs to avoid copy&pasting large parts of the structure initialization but I would prefer 3 separate full inits based only on ifdefs on the DAL version numbers. in pseudo: if v5: vtable = { ... } elif v6.0: vtable = { ... } elid v6.1: vtable = { ... } else: error! Those tables cannot change so using ifdefs in them can only risk to introduce bugs in one of the versions rather than help reduce code duplication. """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274808126 From freeipa-github-notification at redhat.com Tue Jan 24 14:01:40 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 24 Jan 2017 15:01:40 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 abbra commented: """ @simo5 spec dependencies are separate from the code -- the spec will not help on Debian, for example. We need both the spec dependencies and the proper checks in the code. """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274810069 From freeipa-github-notification at redhat.com Tue Jan 24 14:33:20 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 15:33:20 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 238322 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 14:48:14 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 15:48:14 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 simo5 commented: """ Doesn't kdb.h also export a MINOR version to test against ? """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274823821 From freeipa-github-notification at redhat.com Tue Jan 24 14:55:18 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 15:55:18 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 simo5 commented: """ I checked and can't find it ... facepalm """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274826331 From freeipa-github-notification at redhat.com Tue Jan 24 14:56:00 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Tue, 24 Jan 2017 15:56:00 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation pvoborni commented: """ When I was still developing server-side then I used lsyncd to rsync files from my local laptop working git repo to their location on vm in a lab. So the process for me was just: * change file * restart httpd * test Lite sever covers only API changes. Solution above covered also installs and updates (to some extend). So it was much more usable because API changes is only a small part of FreeIPA development. For Web UI, there is older /install/ui/util/sync.sh which does similar thing. Build system refactoring enabled to use `make install` method ``` $ mkdir /tmp/vm $ sshfs -o transform_symlinks root@:/ /tmp/vm $ make install DESTDIR=/tmp/vm ``` This covers all use cases. So it might be better to talk if we should rather promote this method with e.g. containerized IPA instance. I.e. Before we ACK or NACK this PR. I'd rather have a conversation, what is the issue and what is the right solution. How we can make the whole process better. And then update http://www.freeipa.org/page/Contribute/Code which is rather obsolete and doesn't describe any method. """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274826574 From freeipa-github-notification at redhat.com Tue Jan 24 14:57:51 2017 From: freeipa-github-notification at redhat.com (abbra) Date: Tue, 24 Jan 2017 15:57:51 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 abbra commented: """ No, no minor DAL version. That's why I had to resort to structure member checks in autoconf. """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274827207 From freeipa-github-notification at redhat.com Tue Jan 24 15:00:16 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Tue, 24 Jan 2017 16:00:16 +0100 Subject: [Freeipa-devel] [freeipa PR#10][closed] Client-side CSR autogeneration In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/10 Author: LiptonB Title: #10: Client-side CSR autogeneration Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/10/head:pr10 git checkout pr10 From freeipa-github-notification at redhat.com Tue Jan 24 15:01:24 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 16:01:24 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 238323 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 15:16:01 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 24 Jan 2017 16:16:01 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ Ok, with this latest push I can install servers and replicas both with CA and CA-less. I cannot reproduce the failure @HonzaCholasta sees, so from my side I am done. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-274832504 From freeipa-github-notification at redhat.com Tue Jan 24 15:20:30 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 24 Jan 2017 16:20:30 +0100 Subject: [Freeipa-devel] [freeipa PR#395][-ack] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" Label: -ack From freeipa-github-notification at redhat.com Tue Jan 24 15:21:00 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 24 Jan 2017 16:21:00 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" stlaz commented: """ Removed the ACK label since this is not yet reviewed. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-274833994 From freeipa-github-notification at redhat.com Tue Jan 24 15:23:33 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 24 Jan 2017 16:23:33 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation tiran commented: """ I put some effort into the dev server because I find it very useful during development. The werkzeug WSGI adds some useful features, e.g. auto-reloader and through-the-web debugger (soon). I can maintain a copy of the dev server for me personally but I'd rather have a copy in the source tree. It doesn't have to be ```/lite-server.py```. How about ```contrib/dev-server```? """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274834789 From freeipa-github-notification at redhat.com Tue Jan 24 15:25:00 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 24 Jan 2017 16:25:00 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 66206 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 15:27:28 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 24 Jan 2017 16:27:28 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 22519 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 15:31:41 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Tue, 24 Jan 2017 16:31:41 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 83115 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 24 15:32:05 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Tue, 24 Jan 2017 16:32:05 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) LiptonB commented: """ @HonzaCholasta, I think we're on the same page, then. I removed the dogtag profile and the validation from the `profile_id` parameter, and rebased the PR against master. For the `cert-request --autogenerate` functionality, I will think about where in the CSR profile to store a link to the IPA profile to use. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-274837474 From freeipa-github-notification at redhat.com Tue Jan 24 17:01:08 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 24 Jan 2017 18:01:08 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions tomaskrizek commented: """ I wasn't able to find any more issues with the quoting of certificate names. The directive quoting seems to work properly now. """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-274867155 From freeipa-github-notification at redhat.com Tue Jan 24 17:01:13 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Tue, 24 Jan 2017 18:01:13 +0100 Subject: [Freeipa-devel] [freeipa PR#347][+ack] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions Label: +ack From freeipa-github-notification at redhat.com Tue Jan 24 17:08:32 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Tue, 24 Jan 2017 18:08:32 +0100 Subject: [Freeipa-devel] [freeipa PR#407][comment] New lite-server implementation In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/407 Title: #407: New lite-server implementation pvoborni commented: """ Maybe the lite-server approach is great and other people would appreciate that. I shouldn't be the one to judge it. What about demonstrating it to the rest of the team and showing the value? """ See the full comment at https://github.com/freeipa/freeipa/pull/407#issuecomment-274869463 From freeipa-github-notification at redhat.com Tue Jan 24 19:55:01 2017 From: freeipa-github-notification at redhat.com (frozencemetery) Date: Tue, 24 Jan 2017 20:55:01 +0100 Subject: [Freeipa-devel] [freeipa PR#410][comment] ipa-kdb: support KDB DAL version 6.1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/410 Title: #410: ipa-kdb: support KDB DAL version 6.1 frozencemetery commented: """ There was talk of exporting a minor dal version but I think upstream explicitly doesn't want it. freeipa.spec.in should be modified if I understand correctly; otherwise this looks good. """ See the full comment at https://github.com/freeipa/freeipa/pull/410#issuecomment-274919521 From freeipa-github-notification at redhat.com Wed Jan 25 04:32:06 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 25 Jan 2017 05:32:06 +0100 Subject: [Freeipa-devel] [freeipa PR#370][comment] ci: send build log to paste.fedoraproject.org In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/370 Title: #370: ci: send build log to paste.fedoraproject.org frasertweedale commented: """ @martbab the paste looks like gobbledygook; it's gzipped. We will see it in action soon enough :) """ See the full comment at https://github.com/freeipa/freeipa/pull/370#issuecomment-275016649 From freeipa-github-notification at redhat.com Wed Jan 25 08:08:16 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Wed, 25 Jan 2017 09:08:16 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ @simo5, it turns out the request fails not on the replica, but on the initial master, so it's actually `ipa-server-install` which is broken - if you install server from current master and replica from this PR it works fine. Steps to reproduce: ``` server# certutil -d /etc/httpd/alias -L | tail -n +5 | sed -r 's/ +[^ ]+ *$//' | xargs -I nickname -r sh -c "certutil -d /etc/httpd/alias -D -n 'nickname'" server# rm -rf /etc/ipa/ca.crt /etc/httpd/alias/kra-agent.pem /var/lib/ipa/radb server# ipa-server-install -n abc.idm.lab.eng.brq.redhat.com -r ABC.IDM.LAB.ENG.BRQ.REDHAT.COM -p blablabla -a blablabla -U ... replica# certutil -d /etc/httpd/alias -L | tail -n +5 | sed -r 's/ +[^ ]+ *$//' | xargs -I nickname -r sh -c "certutil -d /etc/httpd/alias -D -n 'nickname'" replica# rm -rf /etc/ipa/ca.crt /etc/httpd/alias/kra-agent.pem /var/lib/ipa/radb replica# ipa-replica-install -n abc.idm.lab.eng.brq.redhat.com --server vm-226.abc.idm.lab.eng.brq.redhat.com -P admin -p blablabla ``` Note that you won't actually be able to do the above, as the `ipa-server-install` step will fail with: ``` Restarting the KDC Please add records in this file to your DNS system: /tmp/ipa.system.records.xLK2pI.db Unable to set admin password Command '/usr/bin/ldappasswd -h vm-226.abc.idm.lab.eng.brq.redhat.com -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpKyxwZX -T /var/lib/ipa/tmpMY13CP uid=admin,cn=users,cn=accounts,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' returned non-zero exit status 1 Configuring client side components Using existing certificate '/etc/ipa/ca.crt'. Skip vm-226.abc.idm.lab.eng.brq.redhat.com: cannot verify if this is an IPA server Failed to verify that vm-226.abc.idm.lab.eng.brq.redhat.com is an IPA Server. This may mean that the remote server is not up or is not reachable due to network or firewall settings. Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR Configuration of client side components failed! ipa.ipapython.install.cli.install_tool(CompatServerMasterInstall): ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` This does not happen with current master. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-275044170 From freeipa-github-notification at redhat.com Wed Jan 25 09:41:07 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 25 Jan 2017 10:41:07 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tomaskrizek commented: """ Since the bug is completely fixed on the PKI side, shouldn't we bump the `Requires` to require the fixed version of PKI? Installation in IPV6-only environment will not work without the updated PKI, since 127.0.0.1 was used as a default before [3a49b9b3738befc03914b0a96aad61f9650fb935](https://git.fedorahosted.org/cgit/pki.git/commit/?id=3a49b9b3738befc03914b0a96aad61f9650fb935). """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-275062210 From freeipa-github-notification at redhat.com Wed Jan 25 09:54:36 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Wed, 25 Jan 2017 10:54:36 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" pvoborni commented: """ Yes, but in different patch please. PKI with the fix was not released yet. So it should not block review of this patch. We can leave the ticket open until it is bumped. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-275065152 From freeipa-github-notification at redhat.com Wed Jan 25 10:02:46 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 25 Jan 2017 11:02:46 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tomaskrizek commented: """ **ACK** for z-stream with the patched PKI. Waiting for the PKI release and bump of `Requires` to ack and merge upstream. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-275066963 From freeipa-github-notification at redhat.com Wed Jan 25 11:26:24 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 12:26:24 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 22407 bytes Desc: not available URL: From tkrizek at redhat.com Wed Jan 25 11:46:00 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Wed, 25 Jan 2017 12:46:00 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <2d4f4629-27f0-86e2-abc9-5455a009cf0c@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> <859df0d5-f002-2b22-9336-5ca904a35ecd@redhat.com> <2d4f4629-27f0-86e2-abc9-5455a009cf0c@redhat.com> Message-ID: <5d43b71b-beaf-f6dd-859f-97b90b4d28d5@redhat.com> On 01/13/2017 05:44 PM, Petr Vobornik wrote: > On 01/13/2017 03:49 PM, Rob Crittenden wrote: >> Tomas Krizek wrote: >>> On 01/12/2017 04:17 PM, Rob Crittenden wrote: >>>> Tomas Krizek wrote: >>>>> On 12/19/2016 04:41 PM, Standa Laznicka wrote: >>>>>> On 12/19/2016 03:07 PM, John Dennis wrote: >>>>>>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>>>>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>>>>>> Standa Laznicka wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>>>>>> >>>>>>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>>>>>> managed >>>>>>>>>> to install and run patched FreeIPA server and client and connect them >>>>>>>>>> together. >>>>>>>>>> >>>>>>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>>>>>> the >>>>>>>>>> client altogether. >>>>>>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>>>>>> access to a private key. What connection(s) are you talking about, and >>>>>>>>> what would you replace NSSConnection with? >>>>>>>>> >>>>>>>>> rob >>>>>>>> Hello Rob, >>>>>>>> >>>>>>>> Thank you for this excellent question, in order to cut the email >>>>>>>> short I >>>>>>>> seem to have omitted quite a few information. >>>>>>>> >>>>>>>> One of the very first problems I had with FreeIPA with FIPS was that >>>>>>>> NSS >>>>>>>> was always asking for password/pin. I was discussing this with the NSS >>>>>>>> guys on their IRC chat last week and it turns out that NSS tries to >>>>>>>> create a private key every time you want to use it as a backend for an >>>>>>>> SSL connection on FIPS. I still don't think this is quite right so I >>>>>>>> may >>>>>>>> open a bugzilla for that. >>>>>>> I don't understand, I thought the case you were having problems with >>>>>>> was the FreeIPA client, not the server. I assume when you use the >>>>>>> term "backend" you mean server, and yes when NSS is in server mode it >>>>>>> will access to keys. So isn't the problem NSS is not being >>>>>>> initialized correctly so that it recognizes it is in client mode and >>>>>>> not server mode? >>>>>>> >>>>>> What I meant was "a client backend for an SSL connection" - we're >>>>>> using NSS implementation of SSL (via python-nss) for HTTPS connections >>>>>> from client to server during which we're getting a CA cert from an NSS >>>>>> database but this eventually leads to a password prompt. >>>>>>>> Anyway, the guys suggested me that we could try to create the database >>>>>>>> with an empty password and everything will work. I don't quite like >>>>>>>> that, too, but it's at least something if you don't want the `ipa` >>>>>>>> command to always bug you for password you have no way knowing if >>>>>>>> you're >>>>>>>> just a regular user. >>>>>>>> >>>>>>>> What I think would be a better way to go is to use >>>>>>>> httplib.HTTPSConnection. We have the needed certificates in >>>>>>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>>>>>> with Honza this morning and it seems that with this approach we may get >>>>>>>> rid of the NSSConnection class altogether (although I still need to >>>>>>>> check a few spots) and start the process of moving away from NSS which >>>>>>>> was discussed some year ago in an internal mailing list (for some >>>>>>>> reason). >>>>>>>> >>>>>>>> Will be happy to hear thoughts on this, >>>>>>>> Standa >>>>>>> I'm not a big fan of NSS, it has it's issues. As the author of the >>>>>>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>>>>>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>>>>>> has it's own issues too. If you remove NSS you're also removing the >>>>>>> option to support smart cards, HSM's etc. Perhaps before removing >>>>>>> functionality it would be good to assess what the requirements are. >>>>>>> >>>>>> I'm sorry I generalized too much, the original topic was moving away >>>>>> from python-nss (of which I am even more sorry as you're the author). >>>>>> >>>>> We could use some ideas on how to handle replica installations in FIPS. >>>>> >>>>> We might use some flag in LDAP to indicate that a topology is >>>>> FIPS-enabled. It seems like a good idea to force all servers in >>>>> FIPS-enabled topology to also be FIPS-enabled. At the start of replica >>>>> installation, a check could be performed to verify the FIPS topology >>>>> status is the same as the current system's FIPS status. However, this >>>>> proposal has a flaw. It is possible to simply install a FIPS-enabled >>>>> replica and then turn FIPS off. This would result in non-FIPS systems >>>>> being part of a FIPS-enabled topology. >>>>> >>>>> So we have a couple questions: >>>>> >>>>> Does it make sense to require all the servers in the topology to be >>>>> either FIPS-enabled or FIPS-disabled? >>>>> What would be a good approach to achieve this? Simply checking during >>>>> installation does not guarantee that FIPS will stay turned on. >>>>> >>>> You could set some value in the replicated tree on FIPS status and write >>>> a 389-ds plugin to refuse to start if the environment doesn't match. >>>> Given this is started first it should cause a cascade of failures so no >>>> services are available. >>>> >>>> rob >>> Based on an offline discussion, we might just omit this feature >>> entirely. Our goal is to enable FreeIPA installation of FIPS configured >>> systems. It should be up to the customer to make sure other FIPS >>> requirements are met, i.e. all servers are configured to use FIPS. >>> >> Up to you but this is bound to be an RFE and seems like quite a weakness >> to me. >> >> You'll want to be sure to enforce that any additional masters get FIPS >> by default if the initial master has it. In other words, they shouldn't >> need to remember to pass an option, it should be automatic. >> >> rob >> > +1 to Rob. > > We could operate between the two extremes: > * Extreme 1: Ensuring that FIPS will remain enabled on all existing > replica. > * Extreme 2: Do not validate anything > > I.e. we could only: > * Note in LDAP that first server was installed with FIPS > * Check it at install time > - prevent from installation of non-FIPS > - prevent from installation of FIPS replica in non-FIPS topology > > It won't be bullet proof but it will check major mistakes which the > admin can do by accident. I've updated the design document [1], sections Multiple Servers in Topology (in Design and Implementation). Instead of the originally proposed LDAP flag, we are proposing to check //proc/sys/crypto/fips_enabled /on the master (via RPC call) and on replica. Installation will proceed only if these match. See the design for more details. [1] - http://www.freeipa.org/page/V4/FreeIPA-on-FIPS -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Jan 25 11:59:36 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 12:59:36 +0100 Subject: [Freeipa-devel] [freeipa PR#413][opened] Complete stageuser API Message-ID: URL: https://github.com/freeipa/freeipa/pull/413 Author: dkupka Title: #413: Complete stageuser API Action: opened PR body: """ https://fedorahosted.org/freeipa/ticket/6623 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/413/head:pr413 git checkout pr413 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-413.patch Type: text/x-diff Size: 28919 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 12:10:43 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 25 Jan 2017 13:10:43 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 23150 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 12:43:23 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 13:43:23 +0100 Subject: [Freeipa-devel] [freeipa PR#401][comment] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Title: #401: [4.4] Wait until http principal entry is replicated to replica martbab commented: """ Fixed upstream ipa-4-4: https://fedorahosted.org/freeipa/changeset/3d0a0728766aed7245427b9eaf210e31fd40e440 https://fedorahosted.org/freeipa/changeset/5bddcdb47b40baeae7379e00e8d87297ed3f1cd4 https://fedorahosted.org/freeipa/changeset/74020d07dbf14202f696a0c8521829abc735d4c7 """ See the full comment at https://github.com/freeipa/freeipa/pull/401#issuecomment-275098857 From freeipa-github-notification at redhat.com Wed Jan 25 12:43:25 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 13:43:25 +0100 Subject: [Freeipa-devel] [freeipa PR#401][+pushed] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Title: #401: [4.4] Wait until http principal entry is replicated to replica Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 25 12:43:26 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 13:43:26 +0100 Subject: [Freeipa-devel] [freeipa PR#401][closed] [4.4] Wait until http principal entry is replicated to replica In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/401 Author: MartinBasti Title: #401: [4.4] Wait until http principal entry is replicated to replica Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/401/head:pr401 git checkout pr401 From freeipa-github-notification at redhat.com Wed Jan 25 12:44:57 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 13:44:57 +0100 Subject: [Freeipa-devel] [freeipa PR#413][synchronized] Complete stageuser API In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/413 Author: dkupka Title: #413: Complete stageuser API Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/413/head:pr413 git checkout pr413 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-413.patch Type: text/x-diff Size: 28823 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 12:46:43 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 13:46:43 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions martbab commented: """ Thank's, let's hope that all this code will be replaced by some proper configuration parsing mechanism in the future. """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-275099477 From freeipa-github-notification at redhat.com Wed Jan 25 12:50:11 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 13:50:11 +0100 Subject: [Freeipa-devel] [freeipa PR#347][synchronized] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Author: martbab Title: #347: Improvements in {get|set}_directive functions Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/347/head:pr347 git checkout pr347 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-347.patch Type: text/x-diff Size: 12317 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 12:50:32 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 25 Jan 2017 13:50:32 +0100 Subject: [Freeipa-devel] [freeipa PR#353][synchronized] [RFE] Pwdpolicy In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/353 Author: simo5 Title: #353: [RFE] Pwdpolicy Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/353/head:pr353 git checkout pr353 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-353.patch Type: text/x-diff Size: 8617 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 12:58:05 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 25 Jan 2017 13:58:05 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ Ok reproduced, it is not clar how to me yet, but at some point ca.crt get zeroed out and that's why the ldap command fails, investigating """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-275101642 From freeipa-github-notification at redhat.com Wed Jan 25 13:23:23 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 25 Jan 2017 14:23:23 +0100 Subject: [Freeipa-devel] [freeipa PR#353][comment] [RFE] Pwdpolicy In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/353 Title: #353: [RFE] Pwdpolicy simo5 commented: """ I found two subtle bugs that cause the install failure, with the rebased patches install completes correctly for me. """ See the full comment at https://github.com/freeipa/freeipa/pull/353#issuecomment-275106444 From freeipa-github-notification at redhat.com Wed Jan 25 14:02:43 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 15:02:43 +0100 Subject: [Freeipa-devel] [freeipa PR#347][comment] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions martbab commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/e1ed8b5eff40331ba532d37f3fb08814d8a55b77 https://fedorahosted.org/freeipa/changeset/517d43e78b8d8ea0b796a6ff6a379236eaae21df https://fedorahosted.org/freeipa/changeset/2831b30e9a9de947481c058d8d32e174f951b1c0 https://fedorahosted.org/freeipa/changeset/86f4a93fb3aeb6742acab5abaa1c17b525ea4223 """ See the full comment at https://github.com/freeipa/freeipa/pull/347#issuecomment-275115080 From freeipa-github-notification at redhat.com Wed Jan 25 14:02:44 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 15:02:44 +0100 Subject: [Freeipa-devel] [freeipa PR#347][+pushed] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Title: #347: Improvements in {get|set}_directive functions Label: +pushed From freeipa-github-notification at redhat.com Wed Jan 25 14:02:46 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Wed, 25 Jan 2017 15:02:46 +0100 Subject: [Freeipa-devel] [freeipa PR#347][closed] Improvements in {get|set}_directive functions In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/347 Author: martbab Title: #347: Improvements in {get|set}_directive functions Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/347/head:pr347 git checkout pr347 From freeipa-github-notification at redhat.com Wed Jan 25 14:25:44 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 15:25:44 +0100 Subject: [Freeipa-devel] [freeipa PR#413][synchronized] Complete stageuser API In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/413 Author: dkupka Title: #413: Complete stageuser API Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/413/head:pr413 git checkout pr413 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-413.patch Type: text/x-diff Size: 29096 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 15:09:08 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Wed, 25 Jan 2017 16:09:08 +0100 Subject: [Freeipa-devel] [freeipa PR#393][synchronized] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-393.patch Type: text/x-diff Size: 23143 bytes Desc: not available URL: From tkrizek at redhat.com Wed Jan 25 15:39:13 2017 From: tkrizek at redhat.com (Tomas Krizek) Date: Wed, 25 Jan 2017 16:39:13 +0100 Subject: [Freeipa-devel] [DESIGN] FreeIPA on FIPS + NSS question In-Reply-To: <5d43b71b-beaf-f6dd-859f-97b90b4d28d5@redhat.com> References: <3ea71617-5479-018c-835e-c951cec75e4e@redhat.com> <5853F8EA.7060104@redhat.com> <54dddd8f-37e0-6dec-1cf7-aee1e70cb745@redhat.com> <1a2119a8-8dd0-1652-56f1-dc95c8685287@redhat.com> <9de04cbd-3c4b-2fc5-4c81-5bb9f5a237f9@redhat.com> <859df0d5-f002-2b22-9336-5ca904a35ecd@redhat.com> <2d4f4629-27f0-86e2-abc9-5455a009cf0c@redhat.com> <5d43b71b-beaf-f6dd-859f-97b90b4d28d5@redhat.com> Message-ID: On 01/25/2017 12:46 PM, Tomas Krizek wrote: > On 01/13/2017 05:44 PM, Petr Vobornik wrote: >> On 01/13/2017 03:49 PM, Rob Crittenden wrote: >>> Tomas Krizek wrote: >>>> On 01/12/2017 04:17 PM, Rob Crittenden wrote: >>>>> Tomas Krizek wrote: >>>>>> On 12/19/2016 04:41 PM, Standa Laznicka wrote: >>>>>>> On 12/19/2016 03:07 PM, John Dennis wrote: >>>>>>>> On 12/19/2016 03:12 AM, Standa Laznicka wrote: >>>>>>>>> On 12/16/2016 03:23 PM, Rob Crittenden wrote: >>>>>>>>>> Standa Laznicka wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I started a design page for FreeIPA on FIPS-enabled systems: >>>>>>>>>>> https://www.freeipa.org/page/V4/FreeIPA-on-FIPS >>>>>>>>>>> >>>>>>>>>>> Me and Tom?? are still investigating what of all things will need to >>>>>>>>>>> change in order to have FreeIPA on FIPS-enabled RHEL. So far I >>>>>>>>>>> managed >>>>>>>>>>> to install and run patched FreeIPA server and client and connect them >>>>>>>>>>> together. >>>>>>>>>>> >>>>>>>>>>> There are some issues with NSS when trying to create an HTTPS request >>>>>>>>>>> (apparently, NSS requires an NSS database password to set up an SSL >>>>>>>>>>> connection). I am actually thinking of removing NSSConnection from >>>>>>>>>>> the >>>>>>>>>>> client altogether. >>>>>>>>>> Can you expand on this a bit? NSS should only need a pin when it needs >>>>>>>>>> access to a private key. What connection(s) are you talking about, and >>>>>>>>>> what would you replace NSSConnection with? >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> Hello Rob, >>>>>>>>> >>>>>>>>> Thank you for this excellent question, in order to cut the email >>>>>>>>> short I >>>>>>>>> seem to have omitted quite a few information. >>>>>>>>> >>>>>>>>> One of the very first problems I had with FreeIPA with FIPS was that >>>>>>>>> NSS >>>>>>>>> was always asking for password/pin. I was discussing this with the NSS >>>>>>>>> guys on their IRC chat last week and it turns out that NSS tries to >>>>>>>>> create a private key every time you want to use it as a backend for an >>>>>>>>> SSL connection on FIPS. I still don't think this is quite right so I >>>>>>>>> may >>>>>>>>> open a bugzilla for that. >>>>>>>> I don't understand, I thought the case you were having problems with >>>>>>>> was the FreeIPA client, not the server. I assume when you use the >>>>>>>> term "backend" you mean server, and yes when NSS is in server mode it >>>>>>>> will access to keys. So isn't the problem NSS is not being >>>>>>>> initialized correctly so that it recognizes it is in client mode and >>>>>>>> not server mode? >>>>>>>> >>>>>>> What I meant was "a client backend for an SSL connection" - we're >>>>>>> using NSS implementation of SSL (via python-nss) for HTTPS connections >>>>>>> from client to server during which we're getting a CA cert from an NSS >>>>>>> database but this eventually leads to a password prompt. >>>>>>>>> Anyway, the guys suggested me that we could try to create the database >>>>>>>>> with an empty password and everything will work. I don't quite like >>>>>>>>> that, too, but it's at least something if you don't want the `ipa` >>>>>>>>> command to always bug you for password you have no way knowing if >>>>>>>>> you're >>>>>>>>> just a regular user. >>>>>>>>> >>>>>>>>> What I think would be a better way to go is to use >>>>>>>>> httplib.HTTPSConnection. We have the needed certificates in >>>>>>>>> /etc/ipa/ca.crt anyway so why not use them instead. We had a discussion >>>>>>>>> with Honza this morning and it seems that with this approach we may get >>>>>>>>> rid of the NSSConnection class altogether (although I still need to >>>>>>>>> check a few spots) and start the process of moving away from NSS which >>>>>>>>> was discussed some year ago in an internal mailing list (for some >>>>>>>>> reason). >>>>>>>>> >>>>>>>>> Will be happy to hear thoughts on this, >>>>>>>>> Standa >>>>>>>> I'm not a big fan of NSS, it has it's issues. As the author of the >>>>>>>> Python binding I'm quite aware of all the nasty behaviors NSS has and >>>>>>>> needs to be worked around. I wouldn't be sad to see it go but OpenSSL >>>>>>>> has it's own issues too. If you remove NSS you're also removing the >>>>>>>> option to support smart cards, HSM's etc. Perhaps before removing >>>>>>>> functionality it would be good to assess what the requirements are. >>>>>>>> >>>>>>> I'm sorry I generalized too much, the original topic was moving away >>>>>>> from python-nss (of which I am even more sorry as you're the author). >>>>>>> >>>>>> We could use some ideas on how to handle replica installations in FIPS. >>>>>> >>>>>> We might use some flag in LDAP to indicate that a topology is >>>>>> FIPS-enabled. It seems like a good idea to force all servers in >>>>>> FIPS-enabled topology to also be FIPS-enabled. At the start of replica >>>>>> installation, a check could be performed to verify the FIPS topology >>>>>> status is the same as the current system's FIPS status. However, this >>>>>> proposal has a flaw. It is possible to simply install a FIPS-enabled >>>>>> replica and then turn FIPS off. This would result in non-FIPS systems >>>>>> being part of a FIPS-enabled topology. >>>>>> >>>>>> So we have a couple questions: >>>>>> >>>>>> Does it make sense to require all the servers in the topology to be >>>>>> either FIPS-enabled or FIPS-disabled? >>>>>> What would be a good approach to achieve this? Simply checking during >>>>>> installation does not guarantee that FIPS will stay turned on. >>>>>> >>>>> You could set some value in the replicated tree on FIPS status and write >>>>> a 389-ds plugin to refuse to start if the environment doesn't match. >>>>> Given this is started first it should cause a cascade of failures so no >>>>> services are available. >>>>> >>>>> rob >>>> Based on an offline discussion, we might just omit this feature >>>> entirely. Our goal is to enable FreeIPA installation of FIPS configured >>>> systems. It should be up to the customer to make sure other FIPS >>>> requirements are met, i.e. all servers are configured to use FIPS. >>>> >>> Up to you but this is bound to be an RFE and seems like quite a weakness >>> to me. >>> >>> You'll want to be sure to enforce that any additional masters get FIPS >>> by default if the initial master has it. In other words, they shouldn't >>> need to remember to pass an option, it should be automatic. >>> >>> rob >>> >> +1 to Rob. >> >> We could operate between the two extremes: >> * Extreme 1: Ensuring that FIPS will remain enabled on all existing >> replica. >> * Extreme 2: Do not validate anything >> >> I.e. we could only: >> * Note in LDAP that first server was installed with FIPS >> * Check it at install time >> - prevent from installation of non-FIPS >> - prevent from installation of FIPS replica in non-FIPS topology >> >> It won't be bullet proof but it will check major mistakes which the >> admin can do by accident. > I've updated the design document [1], sections Multiple Servers in > Topology (in Design and Implementation). > > Instead of the originally proposed LDAP flag, we are proposing to > check //proc/sys/crypto/fips_enabled /on the master (via RPC call) and > on replica. Installation will proceed only if these match. See the > design for more details. > > [1] - http://www.freeipa.org/page/V4/FreeIPA-on-FIPS One more change from an offline discussion: we're going to use env.fips_mode variable instead of a dedicated RPC call. -- Tomas Krizek -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa-github-notification at redhat.com Wed Jan 25 15:57:51 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Wed, 25 Jan 2017 16:57:51 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" tomaskrizek commented: """ **ACK** for z-stream with the patched PKI. Waiting for the PKI release and bump of `Requires` to ack and merge upstream. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-275066963 From freeipa-github-notification at redhat.com Wed Jan 25 16:04:28 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 17:04:28 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 71756 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 16:06:17 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 17:06:17 +0100 Subject: [Freeipa-devel] [freeipa PR#399][synchronized] Certificate mapping test In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/399 Author: dkupka Title: #399: Certificate mapping test Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/399/head:pr399 git checkout pr399 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-399.patch Type: text/x-diff Size: 22527 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 16:14:46 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 17:14:46 +0100 Subject: [Freeipa-devel] [freeipa PR#404][synchronized] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Author: dkupka Title: #404: tests: Add LDAP URI to ldappasswd explicitly Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/404/head:pr404 git checkout pr404 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-404.patch Type: text/x-diff Size: 1404 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 16:18:56 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 17:18:56 +0100 Subject: [Freeipa-devel] [freeipa PR#404][synchronized] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Author: dkupka Title: #404: tests: Add LDAP URI to ldappasswd explicitly Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/404/head:pr404 git checkout pr404 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-404.patch Type: text/x-diff Size: 1611 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 16:19:04 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Wed, 25 Jan 2017 17:19:04 +0100 Subject: [Freeipa-devel] [freeipa PR#404][comment] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Title: #404: tests: Add LDAP URI to ldappasswd explicitly dkupka commented: """ @tiran Nice catch, I've added it to ipaserver/install/service.py, too. but I would rather not extend this outside of tests. """ See the full comment at https://github.com/freeipa/freeipa/pull/404#issuecomment-275153569 From freeipa-github-notification at redhat.com Wed Jan 25 17:07:42 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 25 Jan 2017 18:07:42 +0100 Subject: [Freeipa-devel] [freeipa PR#314][synchronized] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Author: simo5 Title: #314: RFC: privilege separation for ipa framework code Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/314/head:pr314 git checkout pr314 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-314.patch Type: text/x-diff Size: 240162 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Wed Jan 25 17:08:04 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Wed, 25 Jan 2017 18:08:04 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ With this last rebase I can install again both ca and ca-less without issues. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-275168299 From freeipa-github-notification at redhat.com Thu Jan 26 06:46:22 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 26 Jan 2017 07:46:22 +0100 Subject: [Freeipa-devel] [freeipa PR#404][comment] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Title: #404: tests: Add LDAP URI to ldappasswd explicitly dkupka commented: """ @tiran Nice catch, I've added it to ipaserver/install/service.py, too. but I would rather not extend this outside of tests. """ See the full comment at https://github.com/freeipa/freeipa/pull/404#issuecomment-275153569 From bind-dyndb-ldap-github-notification at redhat.com Thu Jan 26 09:25:25 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Thu, 26 Jan 2017 10:25:25 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#7][synchronized] Added named.conf API transformation script to spec In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/7 Author: tomaskrizek Title: #7: Added named.conf API transformation script to spec Action: synchronized To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/7/head:pr7 git checkout pr7 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-7.patch Type: text/x-diff Size: 2572 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 26 10:13:43 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 26 Jan 2017 11:13:43 +0100 Subject: [Freeipa-devel] [freeipa PR#351][synchronized] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Author: tomaskrizek Title: #351: [fedora-26] named.conf template: update API for bind 9.11 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/351/head:pr351 git checkout pr351 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-351.patch Type: text/x-diff Size: 8292 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 26 10:17:02 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 26 Jan 2017 11:17:02 +0100 Subject: [Freeipa-devel] [freeipa PR#351][synchronized] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Author: tomaskrizek Title: #351: [fedora-26] named.conf template: update API for bind 9.11 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/351/head:pr351 git checkout pr351 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-351.patch Type: text/x-diff Size: 8302 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Thu Jan 26 10:21:30 2017 From: freeipa-github-notification at redhat.com (tomaskrizek) Date: Thu, 26 Jan 2017 11:21:30 +0100 Subject: [Freeipa-devel] [freeipa PR#351][comment] [fedora-26] named.conf template: update API for bind 9.11 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/351 Title: #351: [fedora-26] named.conf template: update API for bind 9.11 tomaskrizek commented: """ I've updated the version of BIND and the patch should be complete. I suggest we do a review (you can use https://copr.fedorainfracloud.org/coprs/tkrizek/bind-9.11/ for F24/F25), but delay merging this patch so we do not have to use the COPR for our upstream development until necessary. """ See the full comment at https://github.com/freeipa/freeipa/pull/351#issuecomment-275354258 From freeipa-github-notification at redhat.com Thu Jan 26 11:26:11 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Thu, 26 Jan 2017 12:26:11 +0100 Subject: [Freeipa-devel] [freeipa PR#404][comment] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Title: #404: tests: Add LDAP URI to ldappasswd explicitly dkupka commented: """ @tiran After a closer look I believe that it's handled correctly in ipaserver/install/service.py https://github.com/freeipa/freeipa/blob/master/ipaserver/install/service.py#L205:L208 """ See the full comment at https://github.com/freeipa/freeipa/pull/404#issuecomment-275366693 From freeipa-github-notification at redhat.com Thu Jan 26 11:31:43 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Thu, 26 Jan 2017 12:31:43 +0100 Subject: [Freeipa-devel] [freeipa PR#404][comment] tests: Add LDAP URI to ldappasswd explicitly In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/404 Title: #404: tests: Add LDAP URI to ldappasswd explicitly tiran commented: """ I stand corrected! Thanks David. """ See the full comment at https://github.com/freeipa/freeipa/pull/404#issuecomment-275367590 From bind-dyndb-ldap-github-notification at redhat.com Thu Jan 26 21:34:49 2017 From: bind-dyndb-ldap-github-notification at redhat.com (pemensik) Date: Thu, 26 Jan 2017 22:34:49 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#8][opened] Log when pointers are different Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/8 Author: pemensik Title: #8: Log when pointers are different Action: opened PR body: """ Log both different addresses when it is needed to register isc and dns libraries and set their log context. """ To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/8/head:pr8 git checkout pr8 -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pr-8.patch Type: text/x-diff Size: 750 bytes Desc: not available URL: From mbasti at redhat.com Fri Jan 27 12:37:14 2017 From: mbasti at redhat.com (Martin Basti) Date: Fri, 27 Jan 2017 13:37:14 +0100 Subject: [Freeipa-devel] [design] add nsupdate output format to dns-update-system-records Message-ID: Hello all, I'm working on adding support of nsupdate format to output of `ipa dns-update-system-records` command, that will allow to copy&paste output to nsupdate utility and update IPA DNS records on external server. I propose following: 1) new option --nsupdate-format This option will replace standard output with nsupdate format output. Feel free to propose better name. 2) client or server side plugin? I'd like to implement this behavior only at client side. But this will not work in cases when only server api or RPC calls are used. Do you think that we should support this uses case (in server side plugin)? Martin From abokovoy at redhat.com Fri Jan 27 20:17:58 2017 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Jan 2017 15:17:58 -0500 (EST) Subject: [Freeipa-devel] [design] add nsupdate output format to dns-update-system-records In-Reply-To: References: Message-ID: <1599379881.21535964.1485548278966.JavaMail.zimbra@redhat.com> Top post (sorry). Is suggest use --out option and document that it writes nsupdate-compatible content. ----- Martin Basti wrote: > Hello all, > > I'm working on adding support of nsupdate format to output of `ipa > dns-update-system-records` command, that will allow to copy&paste output > to nsupdate utility and update IPA DNS records on external server. I > propose following: > > 1) new option --nsupdate-format > > This option will replace standard output with nsupdate format output. > Feel free to propose better name. > > > 2) client or server side plugin? > > I'd like to implement this behavior only at client side. But this will > not work in cases when only server api or RPC calls are used. Do you > think that we should support this uses case (in server side plugin)? > > > Martin > > -- > Manage your subscription for the Freeipa-devel mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-devel > Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- / Alexander Bokovoy From pvoborni at redhat.com Fri Jan 27 21:45:11 2017 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 27 Jan 2017 22:45:11 +0100 Subject: [Freeipa-devel] [design] add nsupdate output format to dns-update-system-records In-Reply-To: References: Message-ID: <7c0c83f5-7c69-1b83-0796-e8cdf6b342d8@redhat.com> On 01/27/2017 01:37 PM, Martin Basti wrote: > Hello all, > > I'm working on adding support of nsupdate format to output of `ipa > dns-update-system-records` command, that will allow to copy&paste output > to nsupdate utility and update IPA DNS records on external server. I > propose following: > > 1) new option --nsupdate-format > > This option will replace standard output with nsupdate format output. > Feel free to propose better name. > > > 2) client or server side plugin? > > I'd like to implement this behavior only at client side. But this will > not work in cases when only server api or RPC calls are used. Do you > think that we should support this uses case (in server side plugin)? > > > Martin > The main ideal was to allow piping into nsupdate. i don't remember if server side returns in human readable form or in structured way. If in structured, then implementation in client side plugin would make better sense. +1 to Alexander on '--out nsupdate' option -- Petr Vobornik From freeipa-github-notification at redhat.com Sat Jan 28 10:35:41 2017 From: freeipa-github-notification at redhat.com (lslebodn) Date: Sat, 28 Jan 2017 11:35:41 +0100 Subject: [Freeipa-devel] [freeipa PR#414][opened] SPEC: Update SELinux file context of ipa-otpd Message-ID: URL: https://github.com/freeipa/freeipa/pull/414 Author: lslebodn Title: #414: SPEC: Update SELinux file context of ipa-otpd Action: opened PR body: """ The ipa-otpd binary was moved but SELinux was not updated. This is a workaround for developers who develop on platforms with older SELinux policy. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/414/head:pr414 git checkout pr414 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-414.patch Type: text/x-diff Size: 1174 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 05:43:53 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Mon, 30 Jan 2017 06:43:53 +0100 Subject: [Freeipa-devel] [freeipa PR#415][opened] ca-del: require CA to already be disabled Message-ID: URL: https://github.com/freeipa/freeipa/pull/415 Author: frasertweedale Title: #415: ca-del: require CA to already be disabled Action: opened PR body: """ Currently ca-del disables the target CA before deleting it. Conceptually, this involves two separate permissions: modify and delete. A user with delete permission does not necessarily have modify permission. As we move toward enforcing IPA permissions in Dogtag, it is necessary to decouple disablement from deletion, otherwise the disable operation would fail if the user does not have modify permission. Although it introduces an additional step for administrators, the process is consistent, required permissions are clear, and errors are human-friendly. Part of: https://fedorahosted.org/freeipa/ticket/5011 freeipa-devel discussion: https://www.redhat.com/archives/freeipa-devel/2017-January/msg00435.html """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/415/head:pr415 git checkout pr415 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-415.patch Type: text/x-diff Size: 2398 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 05:46:39 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Mon, 30 Jan 2017 06:46:39 +0100 Subject: [Freeipa-devel] [freeipa PR#416][opened] replica install: relax domain level check for promotion Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Author: frasertweedale Title: #416: replica install: relax domain level check for promotion Action: opened PR body: """ promote_check currently requires DL == 1. Relax the check to require DL >= 1, so that things will work for future DL increases. Part of: https://fedorahosted.org/freeipa/ticket/5011 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/416/head:pr416 git checkout pr416 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-416.patch Type: text/x-diff Size: 2469 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 05:56:41 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Mon, 30 Jan 2017 06:56:41 +0100 Subject: [Freeipa-devel] [freeipa PR#417][opened] private_ccache: yield ccache name Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Author: frasertweedale Title: #417: private_ccache: yield ccache name Action: opened PR body: """ When using private_ccache, yield 'path' from the context manager. This is cleaner than inspecting 'os.environ['KRB5CCNAME']' within the context. Part of: https://fedorahosted.org/freeipa/ticket/5011 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/417/head:pr417 git checkout pr417 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-417.patch Type: text/x-diff Size: 873 bytes Desc: not available URL: From jcholast at redhat.com Mon Jan 30 06:27:48 2017 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 30 Jan 2017 07:27:48 +0100 Subject: [Freeipa-devel] [design] add nsupdate output format to dns-update-system-records In-Reply-To: <7c0c83f5-7c69-1b83-0796-e8cdf6b342d8@redhat.com> References: <7c0c83f5-7c69-1b83-0796-e8cdf6b342d8@redhat.com> Message-ID: <5c6c89d9-07a2-786d-5b3c-a73654d19d04@redhat.com> On 27.1.2017 22:45, Petr Vobornik wrote: > On 01/27/2017 01:37 PM, Martin Basti wrote: >> Hello all, >> >> I'm working on adding support of nsupdate format to output of `ipa >> dns-update-system-records` command, that will allow to copy&paste output >> to nsupdate utility and update IPA DNS records on external server. I >> propose following: >> >> 1) new option --nsupdate-format >> >> This option will replace standard output with nsupdate format output. >> Feel free to propose better name. >> >> >> 2) client or server side plugin? >> >> I'd like to implement this behavior only at client side. But this will >> not work in cases when only server api or RPC calls are used. Do you >> think that we should support this uses case (in server side plugin)? >> >> >> Martin >> > > > The main ideal was to allow piping into nsupdate. i don't remember if > server side returns in human readable form or in structured way. If in > structured, then implementation in client side plugin would make better > sense. > > +1 to Alexander on '--out nsupdate' option +1 to both --out and client-side implementation. -- Jan Cholasta From freeipa-github-notification at redhat.com Mon Jan 30 06:30:45 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Mon, 30 Jan 2017 07:30:45 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion frasertweedale commented: """ Build failure is unrelated to patch. """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-275988778 From mbasti at redhat.com Mon Jan 30 08:17:15 2017 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Jan 2017 09:17:15 +0100 Subject: [Freeipa-devel] [design] add nsupdate output format to dns-update-system-records In-Reply-To: <5c6c89d9-07a2-786d-5b3c-a73654d19d04@redhat.com> References: <7c0c83f5-7c69-1b83-0796-e8cdf6b342d8@redhat.com> <5c6c89d9-07a2-786d-5b3c-a73654d19d04@redhat.com> Message-ID: <4cf5e888-fde2-81ef-5f9c-391aa4592c86@redhat.com> On 30.01.2017 07:27, Jan Cholasta wrote: > On 27.1.2017 22:45, Petr Vobornik wrote: >> On 01/27/2017 01:37 PM, Martin Basti wrote: >>> Hello all, >>> >>> I'm working on adding support of nsupdate format to output of `ipa >>> dns-update-system-records` command, that will allow to copy&paste >>> output >>> to nsupdate utility and update IPA DNS records on external server. I >>> propose following: >>> >>> 1) new option --nsupdate-format >>> >>> This option will replace standard output with nsupdate format output. >>> Feel free to propose better name. >>> >>> >>> 2) client or server side plugin? >>> >>> I'd like to implement this behavior only at client side. But this will >>> not work in cases when only server api or RPC calls are used. Do you >>> think that we should support this uses case (in server side plugin)? >>> >>> >>> Martin >>> >> >> >> The main ideal was to allow piping into nsupdate. i don't remember if >> server side returns in human readable form or in structured way. If in >> structured, then implementation in client side plugin would make better >> sense. >> >> +1 to Alexander on '--out nsupdate' option > > +1 to both --out and client-side implementation. > I see agreement here so PR should land soon :) Martin^2 From freeipa-github-notification at redhat.com Mon Jan 30 10:51:08 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 11:51:08 +0100 Subject: [Freeipa-devel] [freeipa PR#418][opened] replica install: do not log host OTP Message-ID: URL: https://github.com/freeipa/freeipa/pull/418 Author: HonzaCholasta Title: #418: replica install: do not log host OTP Action: opened PR body: """ Do not log the value of the --password option of ipa-client-install when it is run from ipa-replica-install before replica promotion. https://fedorahosted.org/freeipa/ticket/6633 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/418/head:pr418 git checkout pr418 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-418.patch Type: text/x-diff Size: 1690 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 10:54:26 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 11:54:26 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code HonzaCholasta commented: """ Both replica install and CA-less install now work, but: * `ipa-replica-install` creates `/var/lib/ipa/radb` owned by `root` rather than `ipaapi`. * `/var/lib/ipa/radb` should not be created in CA-less install. * Upgrade from 4.4 fails in various ways: * on the first master: https://transfer.sh/JgKTV/ipaupgrade.log * on a replica: https://transfer.sh/LTMvO/ipaupgrade.log * Could you please add a command to enable your COPR repositories to `.test_runner_config.yaml` so that CI starts working properly? @martbab can advise. @MartinBasti: we agreed to document all new functions last week, this PR was first submitted months ago, so IMO the rule does not apply here. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-276032900 From freeipa-github-notification at redhat.com Mon Jan 30 12:31:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 13:31:19 +0100 Subject: [Freeipa-devel] [freeipa PR#419][opened] ipa-ca-install: do not fail without --subject-base and --ca-subject Message-ID: URL: https://github.com/freeipa/freeipa/pull/419 Author: HonzaCholasta Title: #419: ipa-ca-install: do not fail without --subject-base and --ca-subject Action: opened PR body: """ When --subject-base and --ca-subject are not specified in ipa-ca-install, default values are used. DN objects are used as the default values in ipa-ca-install, but the CA installer expects the values to be strings. This causes ipa-ca-install to fail unless both --subject-base and --ca-subject are specified. Convert the DN objects to strings to fix the issue. https://fedorahosted.org/freeipa/ticket/2614 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/419/head:pr419 git checkout pr419 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-419.patch Type: text/x-diff Size: 1566 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 12:36:03 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 30 Jan 2017 13:36:03 +0100 Subject: [Freeipa-devel] [freeipa PR#420][opened] WIP: Allow login to WebUI using Kerberos aliases/enterprise principals Message-ID: URL: https://github.com/freeipa/freeipa/pull/420 Author: martbab Title: #420: WIP: Allow login to WebUI using Kerberos aliases/enterprise principals Action: opened PR body: """ The logic of the extraction/validation of principal from the request and subsequent authentication was simplified and most of the guesswork will be done by KDC during kinit. This allows for using principal aliases/enterprise principals to log into WebUI and also lays foundation for enabling logons from users from trusted domains. https://fedorahosted.org/freeipa/ticket/6343 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/420/head:pr420 git checkout pr420 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-420.patch Type: text/x-diff Size: 6291 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 12:41:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 13:41:19 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ @LiptonB, I meant it the other way around - `certprofile` should have an (optional) attribute which points to the associated CSR template. """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-276053188 From freeipa-github-notification at redhat.com Mon Jan 30 12:51:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 13:51:19 +0100 Subject: [Freeipa-devel] [freeipa PR#337][+ack] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) Label: +ack From freeipa-github-notification at redhat.com Mon Jan 30 12:55:36 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Mon, 30 Jan 2017 13:55:36 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code martbab commented: """ @simo5 the simplest way to fix CI is to add WIP commit that enables your COPR repos during 'builddep' step like this (untested): ```diff diff --git a/.test_runner_config.yaml b/.test_runner_config.yaml index dc08d79..da64631 100644 --- a/.test_runner_config.yaml +++ b/.test_runner_config.yaml @@ -27,6 +27,8 @@ steps: - make V=0 ${make_target} builddep: - rm -rf /var/cache/dnf/* + - dnf copr enable -y simo/mod_auth_gssapi + - dnf copr enable -y simo/gssproxy - "dnf makecache fast || :" - dnf builddep -y ${builddep_opts} --spec freeipa.spec.in --best --allowerasing cleanup: ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-276055855 From freeipa-github-notification at redhat.com Mon Jan 30 12:57:15 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 13:57:15 +0100 Subject: [Freeipa-devel] [freeipa PR#337][-ack] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) Label: -ack From freeipa-github-notification at redhat.com Mon Jan 30 13:01:33 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Mon, 30 Jan 2017 14:01:33 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ Before I push this, could you please: * squash "Fix broken tests in CSR autogeneration" into "Add tests for CSR autogeneration", * add module prefix to commit subjects ("csrgen:", "tests:", etc.), * make the terminology used in commit messages consistent ("CSR generation" vs. "CSR autogeneration", "certificate mapping" vs. "cert profile" vs. "CSR generation profile" vs. "CSR template" vs. ... - FTR my favorites are "CSR generation" and "CSR template") ? """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-276056949 From freeipa-github-notification at redhat.com Mon Jan 30 14:12:41 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Mon, 30 Jan 2017 15:12:41 +0100 Subject: [Freeipa-devel] [freeipa PR#421][opened] Update warning message for replica install Message-ID: URL: https://github.com/freeipa/freeipa/pull/421 Author: Akasurde Title: #421: Update warning message for replica install Action: opened PR body: """ New warning message in replica install describes more about "insufficient privilege" error Fixes https://fedorahosted.org/freeipa/ticket/6352 Signed-off-by: Abhijeet Kasurde """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/421/head:pr421 git checkout pr421 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-421.patch Type: text/x-diff Size: 1456 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 14:58:23 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 30 Jan 2017 15:58:23 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 74283 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 15:23:44 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 30 Jan 2017 16:23:44 +0100 Subject: [Freeipa-devel] [freeipa PR#337][synchronized] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-337.patch Type: text/x-diff Size: 74283 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Mon Jan 30 15:33:01 2017 From: freeipa-github-notification at redhat.com (LiptonB) Date: Mon, 30 Jan 2017 16:33:01 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) LiptonB commented: """ @HonzaCholasta, updated, please take a look. I standardized on "CSR generation profile" because the names of the objects in the code and the directory that stores them are already "profiles," and because "template" is what the code calls the Jinja2 syntax that's built from the profile and the rules. But if you strongly prefer "template" to mean the collection of rules to use for generation I'm ok with changing it, I'd just want to change the code and filenames to be consistent as well. Thanks for clarifying about the reference from `certprofile` to the CSR profile rather than the other way around. That seems fine to me too, especially if it's considered a default CSR profile rather than the only allowable one. Should I add that field to `certprofile` when I make the PR that adds `cert-request --autogenerate`? """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-276093846 From freeipa-github-notification at redhat.com Mon Jan 30 16:13:58 2017 From: freeipa-github-notification at redhat.com (pvoborni) Date: Mon, 30 Jan 2017 17:13:58 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code pvoborni commented: """ Could we rather add the mod_auth_gssapi and gssproxy packages into @freeipa/freeipa-master copr repo? Without the rpms in master copr repo, other people's automation will be broken after merging the PR. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-276106097 From freeipa-github-notification at redhat.com Tue Jan 31 00:58:05 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 31 Jan 2017 01:58:05 +0100 Subject: [Freeipa-devel] [freeipa PR#417][comment] private_ccache: yield ccache name In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Title: #417: private_ccache: yield ccache name frasertweedale commented: """ Build failure is unrelated to patch. """ See the full comment at https://github.com/freeipa/freeipa/pull/417#issuecomment-276241458 From freeipa-github-notification at redhat.com Tue Jan 31 01:31:02 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 31 Jan 2017 02:31:02 +0100 Subject: [Freeipa-devel] [freeipa PR#422][opened] Fix reference before assignment Message-ID: URL: https://github.com/freeipa/freeipa/pull/422 Author: frasertweedale Title: #422: Fix reference before assignment Action: opened PR body: """ In 'store_session_cookie', if the server does not set the session cookie for some reason, the 'session_cookie' variable does not get assigned, resulting in UnboundLocalError. Set an initial value of 'None'. Fixes: https://fedorahosted.org/freeipa/ticket/6636 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/422/head:pr422 git checkout pr422 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-422.patch Type: text/x-diff Size: 913 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 01:42:18 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 31 Jan 2017 02:42:18 +0100 Subject: [Freeipa-devel] [freeipa PR#416][synchronized] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Author: frasertweedale Title: #416: replica install: relax domain level check for promotion Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/416/head:pr416 git checkout pr416 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-416.patch Type: text/x-diff Size: 2470 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 01:55:45 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Tue, 31 Jan 2017 02:55:45 +0100 Subject: [Freeipa-devel] [freeipa PR#419][+ack] ipa-ca-install: do not fail without --subject-base and --ca-subject In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/419 Title: #419: ipa-ca-install: do not fail without --subject-base and --ca-subject Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 06:13:04 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 07:13:04 +0100 Subject: [Freeipa-devel] [freeipa PR#419][+pushed] ipa-ca-install: do not fail without --subject-base and --ca-subject In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/419 Title: #419: ipa-ca-install: do not fail without --subject-base and --ca-subject Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 06:13:06 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 07:13:06 +0100 Subject: [Freeipa-devel] [freeipa PR#419][comment] ipa-ca-install: do not fail without --subject-base and --ca-subject In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/419 Title: #419: ipa-ca-install: do not fail without --subject-base and --ca-subject HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/87400cdec1054971f50f90a0c63f18ab045f3833 """ See the full comment at https://github.com/freeipa/freeipa/pull/419#issuecomment-276283725 From freeipa-github-notification at redhat.com Tue Jan 31 06:13:08 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 07:13:08 +0100 Subject: [Freeipa-devel] [freeipa PR#419][closed] ipa-ca-install: do not fail without --subject-base and --ca-subject In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/419 Author: HonzaCholasta Title: #419: ipa-ca-install: do not fail without --subject-base and --ca-subject Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/419/head:pr419 git checkout pr419 From freeipa-github-notification at redhat.com Tue Jan 31 06:50:37 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 07:50:37 +0100 Subject: [Freeipa-devel] [freeipa PR#395][comment] Configure PKI ajp redirection to use "localhost" instead of "::1" In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/395 Title: #395: Configure PKI ajp redirection to use "localhost" instead of "::1" HonzaCholasta commented: """ @pvoborni, there is no benefit in bumping `Requires` in a separate patch, as this patch is blocked by it anyway and cannot be pushed as is. Please update the current patch once the fixed `pki-core` is released. """ See the full comment at https://github.com/freeipa/freeipa/pull/395#issuecomment-276288283 From freeipa-github-notification at redhat.com Tue Jan 31 08:11:28 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 09:11:28 +0100 Subject: [Freeipa-devel] [freeipa PR#423][opened] dns-update-system-records: add support for nsupdate output format Message-ID: URL: https://github.com/freeipa/freeipa/pull/423 Author: MartinBasti Title: #423: dns-update-system-records: add support for nsupdate output format Action: opened PR body: """ Option --out does the trick """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/423/head:pr423 git checkout pr423 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-423.patch Type: text/x-diff Size: 6553 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 08:38:29 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 09:38:29 +0100 Subject: [Freeipa-devel] [freeipa PR#424][opened] Tests: fix wait_for_replication task Message-ID: URL: https://github.com/freeipa/freeipa/pull/424 Author: MartinBasti Title: #424: Tests: fix wait_for_replication task Action: opened PR body: """ DS changed a format of replication status attribute. Now it is with prefix "Error (x)" where x is the error code. Both formats were kept to allow tests run on older and new versions of DS. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/424/head:pr424 git checkout pr424 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-424.patch Type: text/x-diff Size: 1522 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 08:40:47 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 09:40:47 +0100 Subject: [Freeipa-devel] [freeipa PR#422][+ack] Fix reference before assignment In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/422 Title: #422: Fix reference before assignment Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 08:45:19 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 09:45:19 +0100 Subject: [Freeipa-devel] [freeipa PR#416][+ack] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 08:47:37 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 09:47:37 +0100 Subject: [Freeipa-devel] [freeipa PR#423][synchronized] dns-update-system-records: add support for nsupdate output format In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/423 Author: MartinBasti Title: #423: dns-update-system-records: add support for nsupdate output format Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/423/head:pr423 git checkout pr423 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-423.patch Type: text/x-diff Size: 6555 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 08:53:55 2017 From: freeipa-github-notification at redhat.com (stlaz) Date: Tue, 31 Jan 2017 09:53:55 +0100 Subject: [Freeipa-devel] [freeipa PR#402][+ack] [master] wait_for_entry improvements In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/402 Title: #402: [master] wait_for_entry improvements Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 08:58:19 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 09:58:19 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion HonzaCholasta commented: """ Excuse me, but what is the point of checking for an exact domain level? Shouldn't `check_domain_level()` rather always check for a minimum domain level? """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-276308946 From freeipa-github-notification at redhat.com Tue Jan 31 09:12:09 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 10:12:09 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ @LiptonB, "CSR generation profile" works for me. Once the new design is implemented though, "CSR template" will be more fitting IMO. I would not add the `certprofile` field before CSR generation is moved to server. For now it should be sufficient to assume that associated certificate profile and CSR generation profile have the same name (i.e. what this PR does). """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-276311633 From freeipa-github-notification at redhat.com Tue Jan 31 09:14:17 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 10:14:17 +0100 Subject: [Freeipa-devel] [freeipa PR#337][+ack] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 09:15:18 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 10:15:18 +0100 Subject: [Freeipa-devel] [freeipa PR#337][+pushed] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 09:15:20 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 10:15:20 +0100 Subject: [Freeipa-devel] [freeipa PR#337][closed] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Author: LiptonB Title: #337: Client-side CSR autogeneration (take 2) Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/337/head:pr337 git checkout pr337 From freeipa-github-notification at redhat.com Tue Jan 31 09:15:22 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 10:15:22 +0100 Subject: [Freeipa-devel] [freeipa PR#337][comment] Client-side CSR autogeneration (take 2) In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/337 Title: #337: Client-side CSR autogeneration (take 2) HonzaCholasta commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/10ef5947860f5098182b1f95c08c1158e2da15f9 https://fedorahosted.org/freeipa/changeset/fc58eff6a3d7fe805e612b8b002304d8b9cd4ba9 https://fedorahosted.org/freeipa/changeset/f1a1c6eca1b294f24174d7b0e1f78de46d9d5b05 https://fedorahosted.org/freeipa/changeset/afd7c05d11432304bfdf183832a21d419f363689 https://fedorahosted.org/freeipa/changeset/a26cf0d7910dd4c0a4da08682b4be8d3d94ba520 """ See the full comment at https://github.com/freeipa/freeipa/pull/337#issuecomment-276312283 From freeipa-github-notification at redhat.com Tue Jan 31 09:22:44 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 10:22:44 +0100 Subject: [Freeipa-devel] [freeipa PR#421][comment] Update warning message for replica install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/421 Title: #421: Update warning message for replica install MartinBasti commented: """ Hello, I'd not omit the fact, that insufficient privilege error can be be caused by user credentials as well, I also wouldn't mention that hostgroup must exists explicitly. I propose something like this, but I'm open to any suggestions and improvements ``` Insufficient privileges to promote the server. Possible issues: - a user has insufficient privileges - this client has insufficient privileges to become replica (is the host member of "ipaservers" group) ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/421#issuecomment-276313860 From freeipa-github-notification at redhat.com Tue Jan 31 09:26:12 2017 From: freeipa-github-notification at redhat.com (Akasurde) Date: Tue, 31 Jan 2017 10:26:12 +0100 Subject: [Freeipa-devel] [freeipa PR#421][comment] Update warning message for replica install In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/421 Title: #421: Update warning message for replica install Akasurde commented: """ @MartinBasti I am OK for changing the warning message. I will wait for other to comment. """ See the full comment at https://github.com/freeipa/freeipa/pull/421#issuecomment-276314536 From freeipa-github-notification at redhat.com Tue Jan 31 09:42:25 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 10:42:25 +0100 Subject: [Freeipa-devel] [freeipa PR#423][synchronized] dns-update-system-records: add support for nsupdate output format In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/423 Author: MartinBasti Title: #423: dns-update-system-records: add support for nsupdate output format Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/423/head:pr423 git checkout pr423 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-423.patch Type: text/x-diff Size: 6378 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 09:45:48 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 31 Jan 2017 10:45:48 +0100 Subject: [Freeipa-devel] [freeipa PR#402][+pushed] [master] wait_for_entry improvements In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/402 Title: #402: [master] wait_for_entry improvements Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 09:45:49 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 31 Jan 2017 10:45:49 +0100 Subject: [Freeipa-devel] [freeipa PR#402][comment] [master] wait_for_entry improvements In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/402 Title: #402: [master] wait_for_entry improvements dkupka commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/38fd8b356d66553d21a3e64374fdc39427a05baf https://fedorahosted.org/freeipa/changeset/f2ec44f2705fe87b71c6290ae8b35bc0a05f68d2 """ See the full comment at https://github.com/freeipa/freeipa/pull/402#issuecomment-276318805 From freeipa-github-notification at redhat.com Tue Jan 31 09:45:51 2017 From: freeipa-github-notification at redhat.com (dkupka) Date: Tue, 31 Jan 2017 10:45:51 +0100 Subject: [Freeipa-devel] [freeipa PR#402][closed] [master] wait_for_entry improvements In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/402 Author: MartinBasti Title: #402: [master] wait_for_entry improvements Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/402/head:pr402 git checkout pr402 From freeipa-github-notification at redhat.com Tue Jan 31 09:50:51 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 10:50:51 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion MartinBasti commented: """ expected is for domain level 0, because there are different expectations about replica file, it must exactly match domain level 0, you cannot have higher DL. """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-276319884 From freeipa-github-notification at redhat.com Tue Jan 31 09:58:14 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 10:58:14 +0100 Subject: [Freeipa-devel] [freeipa PR#417][+ack] private_ccache: yield ccache name In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Title: #417: private_ccache: yield ccache name Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 11:01:15 2017 From: freeipa-github-notification at redhat.com (HonzaCholasta) Date: Tue, 31 Jan 2017 12:01:15 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion HonzaCholasta commented: """ I see. The point is, `check_domain_level()` is supposed to check whether replica promotion is possible or not in the current domain level, so it's weird it has an expected domain level argument and even weirder to introduce additional minimum domain level argument, when all it should have is a single boolean argument saying wheter you want to promote or not: ```python def check_domain_level(api, want_promote): ... promote = current >= constants.DOMAIN_LEVEL_1 if promote != want_promote: raise RuntimeError(message) ... ``` """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-276334410 From freeipa-github-notification at redhat.com Tue Jan 31 11:32:43 2017 From: freeipa-github-notification at redhat.com (simo5) Date: Tue, 31 Jan 2017 12:32:43 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code simo5 commented: """ The correct packages are now in updates-testing in Fedora 25, pick from there. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-276340645 From freeipa-github-notification at redhat.com Tue Jan 31 12:17:00 2017 From: freeipa-github-notification at redhat.com (martbab) Date: Tue, 31 Jan 2017 13:17:00 +0100 Subject: [Freeipa-devel] [freeipa PR#314][comment] RFC: privilege separation for ipa framework code In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/314 Title: #314: RFC: privilege separation for ipa framework code martbab commented: """ I have disabled updates-testing in the CI because of multitude of unrelated breakages (recent openldap-client vs. nss breakage comes to mind), but we may take the SRPMS from koji and stick them to copr. """ See the full comment at https://github.com/freeipa/freeipa/pull/314#issuecomment-276348713 From freeipa-github-notification at redhat.com Tue Jan 31 12:34:25 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 13:34:25 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion MartinBasti commented: """ IMO the whole `check_domain_level` is somehow broken, AFAIK the main purpose of it is to print correct error message related to replica file option, depending on current and expected domain level. @stlaz may know more details """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-276351845 From freeipa-github-notification at redhat.com Tue Jan 31 12:37:45 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 13:37:45 +0100 Subject: [Freeipa-devel] [freeipa PR#416][-ack] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion Label: -ack From bind-dyndb-ldap-github-notification at redhat.com Tue Jan 31 12:52:14 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Tue, 31 Jan 2017 13:52:14 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#8][+ack] Log when pointers are different In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/8 Title: #8: Log when pointers are different Label: +ack From bind-dyndb-ldap-github-notification at redhat.com Tue Jan 31 12:52:21 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Tue, 31 Jan 2017 13:52:21 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#8][comment] Log when pointers are different In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/8 Title: #8: Log when pointers are different tomaskrizek commented: """ Thanks, this should help with the future debugging efforts. Fixed upstream: [ec2e125ed1b81c41448f699c8df54da66fbc5e8c](https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/commit/?id=ec2e125ed1b81c41448f699c8df54da66fbc5e8c) """ See the full comment at https://github.com/freeipa/bind-dyndb-ldap/pull/8#issuecomment-276355366 From bind-dyndb-ldap-github-notification at redhat.com Tue Jan 31 12:52:22 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Tue, 31 Jan 2017 13:52:22 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#8][closed] Log when pointers are different In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/8 Author: pemensik Title: #8: Log when pointers are different Action: closed To pull the PR as Git branch: git remote add ghbind-dyndb-ldap https://github.com/freeipa/bind-dyndb-ldap git fetch ghbind-dyndb-ldap pull/8/head:pr8 git checkout pr8 From bind-dyndb-ldap-github-notification at redhat.com Tue Jan 31 12:52:25 2017 From: bind-dyndb-ldap-github-notification at redhat.com (tomaskrizek) Date: Tue, 31 Jan 2017 13:52:25 +0100 Subject: [Freeipa-devel] [bind-dyndb-ldap PR#8][+pushed] Log when pointers are different In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/bind-dyndb-ldap/pull/8 Title: #8: Log when pointers are different Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 13:32:10 2017 From: freeipa-github-notification at redhat.com (apophys) Date: Tue, 31 Jan 2017 14:32:10 +0100 Subject: [Freeipa-devel] [freeipa PR#415][comment] ca-del: require CA to already be disabled In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/415 Title: #415: ca-del: require CA to already be disabled apophys commented: """ Could you please extend the tests with the invalid order of the commands on a ca entry? """ See the full comment at https://github.com/freeipa/freeipa/pull/415#issuecomment-276363432 From freeipa-github-notification at redhat.com Tue Jan 31 14:24:01 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 15:24:01 +0100 Subject: [Freeipa-devel] [freeipa PR#413][comment] Complete stageuser API In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/413 Title: #413: Complete stageuser API MartinBasti commented: """ LGTM except first commit that shouldn't be here and `ipalib.x509: Handle missing SAN gracefully` has no ticket in commit message """ See the full comment at https://github.com/freeipa/freeipa/pull/413#issuecomment-276376015 From freeipa-github-notification at redhat.com Tue Jan 31 15:39:58 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 31 Jan 2017 16:39:58 +0100 Subject: [Freeipa-devel] [freeipa PR#393][+ack] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 16:14:55 2017 From: freeipa-github-notification at redhat.com (flo-renaud) Date: Tue, 31 Jan 2017 17:14:55 +0100 Subject: [Freeipa-devel] [freeipa PR#425][opened] ipa-kra-install must create directory if it does not exist Message-ID: URL: https://github.com/freeipa/freeipa/pull/425 Author: flo-renaud Title: #425: ipa-kra-install must create directory if it does not exist Action: opened PR body: """ ipa-kra-install creates an admin cert file in /root/.dogtag/pki-tomcat/ca_admin.cert but does not check that the parent directory exists. This situation can happen when uninstall + restore has been run. The fix creates the directory if not present. https://fedorahosted.org/freeipa/ticket/6606 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/425/head:pr425 git checkout pr425 From freeipa-github-notification at redhat.com Tue Jan 31 16:22:55 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 17:22:55 +0100 Subject: [Freeipa-devel] [freeipa PR#426][opened] DNSSEC: forwarders validation improvement Message-ID: URL: https://github.com/freeipa/freeipa/pull/426 Author: MartinBasti Title: #426: DNSSEC: forwarders validation improvement Action: opened PR body: """ Some DNS servers behaves oddly and instead sending result without RRSIG records don't reply at all when DNSSEC flag is enabled (timeout). Instead of hard error IPA should this handle as DNSSEC error and continue with installation/adding forwarders. """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/426/head:pr426 git checkout pr426 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-426.patch Type: text/x-diff Size: 1102 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 17:34:00 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:34:00 +0100 Subject: [Freeipa-devel] [freeipa PR#393][+pushed] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 17:34:01 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:34:01 +0100 Subject: [Freeipa-devel] [freeipa PR#393][comment] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Title: #393: [Py3] allow to run wsgi - part1 MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a9fec1de1aa2b3c0f4c4ec6eff25ff2e75c774b0 https://fedorahosted.org/freeipa/changeset/9739d0354a8ac5fd357f7d131b3f75aa05df058b https://fedorahosted.org/freeipa/changeset/7e8eb533752bbf5e2f05ec6bfb0ffefa8e9dcddf https://fedorahosted.org/freeipa/changeset/35e135c4e3a7f0bf21ed4c838b8f76b43701a047 https://fedorahosted.org/freeipa/changeset/cca9aa43e146f15e235eee1197209d0ca88eb39c https://fedorahosted.org/freeipa/changeset/aa036e5f332ef0b1ebbff6b824e236b1eeaf076e https://fedorahosted.org/freeipa/changeset/dd3d9f1ca61946ea5d7daa17ba1d8a883922d526 https://fedorahosted.org/freeipa/changeset/49333058c869dd4bd654a7974e6e144ffd3f0dc3 https://fedorahosted.org/freeipa/changeset/b37d18288d40b4ec0b5a8df676456e09ae5f26c1 https://fedorahosted.org/freeipa/changeset/deaf9ae2473833dacb64c4961db3ae9f7c570ebd https://fedorahosted.org/freeipa/changeset/1023cfebff99af165212dee94290a05754297270 https://fedorahosted.org/freeipa/changeset/d5ab0637fe89cbcb61491fe08b7376aeaf7ccdb8 https://fedorahosted.org/freeipa/changeset/47e76e16ef2e5d714881f3cce204611a95b4e5c8 https://fedorahosted.org/freeipa/changeset/b8d6524d43dd0667184aebc79fb77a9b8a46939a https://fedorahosted.org/freeipa/changeset/980c8a5f9e4ccbcd3c11def9cab33d0e61e945ae """ See the full comment at https://github.com/freeipa/freeipa/pull/393#issuecomment-276433723 From freeipa-github-notification at redhat.com Tue Jan 31 17:34:03 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:34:03 +0100 Subject: [Freeipa-devel] [freeipa PR#393][closed] [Py3] allow to run wsgi - part1 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/393 Author: MartinBasti Title: #393: [Py3] allow to run wsgi - part1 Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/393/head:pr393 git checkout pr393 From freeipa-github-notification at redhat.com Tue Jan 31 17:41:03 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:41:03 +0100 Subject: [Freeipa-devel] [freeipa PR#427][opened] [Py3] WSGI part 2 Message-ID: URL: https://github.com/freeipa/freeipa/pull/427 Author: MartinBasti Title: #427: [Py3] WSGI part 2 Action: opened PR body: """ with this PR: * server can be installed with python3-mod_wsgi * any xmlrpc test can be executed to find a new py3 issues (still a lot of them there) """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/427/head:pr427 git checkout pr427 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-427.patch Type: text/x-diff Size: 9820 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 17:46:09 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:46:09 +0100 Subject: [Freeipa-devel] [freeipa PR#417][+pushed] private_ccache: yield ccache name In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Title: #417: private_ccache: yield ccache name Label: +pushed From freeipa-github-notification at redhat.com Tue Jan 31 17:46:10 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:46:10 +0100 Subject: [Freeipa-devel] [freeipa PR#417][closed] private_ccache: yield ccache name In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Author: frasertweedale Title: #417: private_ccache: yield ccache name Action: closed To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/417/head:pr417 git checkout pr417 From freeipa-github-notification at redhat.com Tue Jan 31 17:46:12 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 18:46:12 +0100 Subject: [Freeipa-devel] [freeipa PR#417][comment] private_ccache: yield ccache name In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/417 Title: #417: private_ccache: yield ccache name MartinBasti commented: """ Fixed upstream master: https://fedorahosted.org/freeipa/changeset/caca181d3b73c045abd72e464a195c6b61c251c7 """ See the full comment at https://github.com/freeipa/freeipa/pull/417#issuecomment-276437158 From freeipa-github-notification at redhat.com Tue Jan 31 20:39:59 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 21:39:59 +0100 Subject: [Freeipa-devel] [freeipa PR#428][opened] [WIP] [Py3] ipa-server-install Message-ID: URL: https://github.com/freeipa/freeipa/pull/428 Author: MartinBasti Title: #428: [WIP] [Py3] ipa-server-install Action: opened PR body: """ This PR allows to install ipa server using PY3 (CA, no DNS, no KRA, no CA-less, no external CA) and uninstall it (ipa-server-install --uninstall) Functionality depends on #427 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/428/head:pr428 git checkout pr428 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-428.patch Type: text/x-diff Size: 26614 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 21:01:19 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 22:01:19 +0100 Subject: [Freeipa-devel] [freeipa PR#427][synchronized] [Py3] WSGI part 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/427 Author: MartinBasti Title: #427: [Py3] WSGI part 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/427/head:pr427 git checkout pr427 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-427.patch Type: text/x-diff Size: 10016 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 21:56:34 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 22:56:34 +0100 Subject: [Freeipa-devel] [freeipa PR#429][opened] [py3] ipactl restart: log httplib failues as debug Message-ID: URL: https://github.com/freeipa/freeipa/pull/429 Author: MartinBasti Title: #429: [py3] ipactl restart: log httplib failues as debug Action: opened PR body: """ With python3 there are several excerptions ConnectionRefusedError raised before ipactl is able to connect to dogtag after restart. These exception should be logged on debug level until timeout is reached. https://fedorahosted.org/freeipa/ticket/4985 """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/429/head:pr429 git checkout pr429 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-429.patch Type: text/x-diff Size: 1206 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 22:22:22 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 23:22:22 +0100 Subject: [Freeipa-devel] [freeipa PR#427][synchronized] [Py3] WSGI part 2 In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/427 Author: MartinBasti Title: #427: [Py3] WSGI part 2 Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/427/head:pr427 git checkout pr427 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-427.patch Type: text/x-diff Size: 9874 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 22:35:33 2017 From: freeipa-github-notification at redhat.com (tiran) Date: Tue, 31 Jan 2017 23:35:33 +0100 Subject: [Freeipa-devel] [freeipa PR#425][+ack] ipa-kra-install must create directory if it does not exist In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/425 Title: #425: ipa-kra-install must create directory if it does not exist Label: +ack From freeipa-github-notification at redhat.com Tue Jan 31 22:45:18 2017 From: freeipa-github-notification at redhat.com (MartinBasti) Date: Tue, 31 Jan 2017 23:45:18 +0100 Subject: [Freeipa-devel] [freeipa PR#429][synchronized] [py3] ipactl restart: log httplib failues as debug In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/429 Author: MartinBasti Title: #429: [py3] ipactl restart: log httplib failues as debug Action: synchronized To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/429/head:pr429 git checkout pr429 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pr-429.patch Type: text/x-diff Size: 1049 bytes Desc: not available URL: From freeipa-github-notification at redhat.com Tue Jan 31 23:41:57 2017 From: freeipa-github-notification at redhat.com (frasertweedale) Date: Wed, 01 Feb 2017 00:41:57 +0100 Subject: [Freeipa-devel] [freeipa PR#416][comment] replica install: relax domain level check for promotion In-Reply-To: References: Message-ID: URL: https://github.com/freeipa/freeipa/pull/416 Title: #416: replica install: relax domain level check for promotion frasertweedale commented: """ So, what do we want the behaviour of `check_domain_level` to be? I just want to make a small change so that replica install does not break if DL > 1. """ See the full comment at https://github.com/freeipa/freeipa/pull/416#issuecomment-276529816