Re: [Freeipa-devel] Moving our wiki back to password login

[Martin Kosek]

On 05/09/2017 04:29 PM, Martin Kosek wrote:
> Hello all,
> 
> As some of you noticed, FreeIPA wiki authentication via OpenID was
> broken in the last days. I suspect (but did get reply from Patrick who
> running the Fedora infra yet) that it was caused by Fedora moving to
> mode modern authentication protocol, i.e. from OpenID to OpenID Connect
> (OIDC):
> https://fedoraproject.org/wiki/Infrastructure/Authentication
> 
> Unfortunately, I cannot make the OIDC login for our current FreeIPA
> instance available, given that our wiki runs on OpenShift v2 which uses
> PHP 5.3.3 cartridge, which can get us only as far as to Mediawiki 1.26.
> OIDC mediawiki authentication plugin is supported from 1.27 forward.
> 
> So the wiki needs to be either:
> - migrated to newer PHP cartridge on current Red Hat OpenShift v2 instance
> - migrated to OpenShift v3 (preferred)
> to unblock us from this situation and get to proper OIDC authentication.
> 
> However, this will need more time and preparation (which I do not even
> have right now). For now, I simply disabled OpenID authentication in our
> wiki and enabled password logins again! Anonymous account creation is
> disabled to avoid spammers. However, given that we now enforce people to
> be in a special group (editors) to fight the spammers, there is actually
> no big functionality lost in this, except having to use yet another
> password.
> 
> To summarize, if you want to access the wiki again, please use the
> password you may have had before we migrated to Fedora OpenID. If you do
> not have the password yet, you should be able to simply reset it before
> logging in and you should get an email (the mail part did not work for
> martbab this afternoon, though). In the worst case, I can reset the
> password for you, just shoot me an email.

After finally reaching Patrick, I found out that Fedora still supports
plain OpenID and it was likely just some interim error. I thus reverted
the patch for simple password login and re-enabled OpenID logins again.

Still, current situation with FreeIPA.org mediawiki version stays, we
will be unable to upgrade the wiki or most of it's plugins until we move
to a newer OpenShift instance.

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

[Freeipa-devel] Moving our wiki back to password login

[Martin Kosek]

Hello all,

As some of you noticed, FreeIPA wiki authentication via OpenID was
broken in the last days. I suspect (but did get reply from Patrick who
running the Fedora infra yet) that it was caused by Fedora moving to
mode modern authentication protocol, i.e. from OpenID to OpenID Connect
(OIDC):
https://fedoraproject.org/wiki/Infrastructure/Authentication

Unfortunately, I cannot make the OIDC login for our current FreeIPA
instance available, given that our wiki runs on OpenShift v2 which uses
PHP 5.3.3 cartridge, which can get us only as far as to Mediawiki 1.26.
OIDC mediawiki authentication plugin is supported from 1.27 forward.

So the wiki needs to be either:
- migrated to newer PHP cartridge on current Red Hat OpenShift v2 instance
- migrated to OpenShift v3 (preferred)
to unblock us from this situation and get to proper OIDC authentication.

However, this will need more time and preparation (which I do not even
have right now). For now, I simply disabled OpenID authentication in our
wiki and enabled password logins again! Anonymous account creation is
disabled to avoid spammers. However, given that we now enforce people to
be in a special group (editors) to fight the spammers, there is actually
no big functionality lost in this, except having to use yet another
password.

To summarize, if you want to access the wiki again, please use the
password you may have had before we migrated to Fedora OpenID. If you do
not have the password yet, you should be able to simply reset it before
logging in and you should get an email (the mail part did not work for
martbab this afternoon, though). In the worst case, I can reset the
password for you, just shoot me an email.

Thanks!

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] KDC proxy URI records

[Martin Kosek]

On 04/27/2017 04:16 PM, Simo Sorce wrote:
> On Thu, 2017-04-27 at 15:56 +0200, Petr Vobornik wrote:
>> On 04/27/2017 02:19 PM, Christian Heimes wrote:
>>> On 2017-04-27 14:00, Martin Bašti wrote:
 I would like to discuss consequences of adding kdc URI records:

 1. basically all ipa clients enrolled using autodiscovery will
 use
 kdcproxy instead of KDC on port 88, because URI takes precedence
 over
 SRV in KRB5 client implementation. Are we ok with such a big
 change?
>>>
>>> Does the client also prefer KKDCP if you give the Kerberos 88/UDP
>>> and
>>> 88/TCP URIs a higher priority than the KKDCP HTTPS URIs?
>>>
 2. probably client installer must be updated because currently
 with
 CA-full installation it is not working.

 ipa-client-install (with autodiscovery) failed on kinit, see
 KRB5_TRACE
 bellow that it refuses self signed certificate
>>>
>>> Actually it is not a self-sigend EE certificate. The validation
>>> message
>>> is bogus because FreeIPA TLS configuration is slightly buggy. We
>>> send
>>> the trust anchor (root CA) although a server should not include its
>>> trust anchor in its ServerHello message. OpenSSL detects an
>>> untrusted
>>> root CA in the ServerHello peer chain and emits the message.
>>>
>>> If I read the 600 lines (!) function
>>> ipaclient.install.client._install
>>> correctly, then ipa-client-install first attempts to negotiate a
>>> TGT and
>>> then installs the trust anchor in the global trust store. It should
>>> be
>>> enough to reverse the order and inject the trust anchor first.
>>>
>>> Christian
>>>
>>
>> By reading this, even if we do the change in client install, I'd
>> rather 
>> not generate the DNS records in 4.5.1 release and rather make sure
>> that 
>> everything works during 4.6 development.

I agree. My original assumption why I suggested this RFE was that it would be
very contained change and only used only by clients that do not have classic
Kerberos ports available. Given how much it influences rest of the framework,
we indeed should not push on it in a bugfix release.

>> The reason is that there might also be something else not working and
>> it 
>> is better to time test it + the fix would not fix older clients.
>>
>> If anybody wants to use/try it, then the records can be created
>> manually.
> 
> 
> 
> We need to ix clients regardless, o someone enabling it will find the
> same issues.

Right. Can someone please file the ticket so that it can be triaged later?


Thanks,
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

[Freeipa-devel] Release: script for updating contributors

[Martin Kosek]

Hi all,

Based on my recent Contributors.txt update and on Martin Basti's request in the
pull request:
https://github.com/freeipa/freeipa/pull/493#issuecomment-281938080

I added my (hacky) script for updating the file in the freeipa-tools repo and
updated our Release page:

http://www.freeipa.org/page/Release#Update_Contributors.txt

HTH!

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

On 02/20/2017 06:03 AM, Fraser Tweedale wrote:
> On Fri, Feb 10, 2017 at 11:48:39AM +0100, Martin Kosek wrote:
>> On 02/10/2017 10:37 AM, Fraser Tweedale wrote:
>>> On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote:
>>>> On 02/09/2017 10:44 PM, Fraser Tweedale wrote:
>>>>> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote:
>>>>>> On 02/09/2017 02:12 AM, Fraser Tweedale wrote:
>>>>>>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
>>>>>>>> On ke, 08 helmi 2017, Martin Kosek wrote:
>>>>>>>>> Hi Fraser and the list,
>>>>>>>>>
>>>>>>>>> I recently was in a conversation about integrating OpenShift with 
>>>>>>>>> FreeIPA. One
>>>>>>>>> of the gaps was around generating a wildcard certificate by FreeIPA 
>>>>>>>>> that will
>>>>>>>>> be used in the default OpenShift router for applications that do not 
>>>>>>>>> deploy own
>>>>>>>>> certificates [1].
>>>>>>>>>
>>>>>>>>> Is there any way that FreeIPA can generate it? I was thinking that 
>>>>>>>>> uploading
>>>>>>>>> some custom certificate profile in FreeIPA may let us get such 
>>>>>>>>> certificate...
>>>>>>>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, 
>>>>>>>>> tracked in
>>>>>>>>> [2]?
>>>>>>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
>>>>>>>> certificates to be issued:
>>>>>>>>
>>>>>>>> - we ensure subject 'cn' of the certificate matches a Kerberos 
>>>>>>>> principal
>>>>>>>>   specified in the request
>>>>>>>>
>>>>>>>> - we validate that host object exists in IPA when the Kerberos
>>>>>>>>   principal is host/...
>>>>>>>>
>>>>>>>> We could lift off these two limitations for 'cn=*,$suffix' but there is
>>>>>>>> still a need to apply proper ACLs when issuing the cert -- e.g. some
>>>>>>>> object has to be used for performing access rights check. The wildcard
>>>>>>>> certificate does not need to be stored anywhere in the tree, but a
>>>>>>>> check still needs to be done.
>>>>>>>>
>>>>>>>> For example, for Kerberos PKINIT certificate which is issued to KDC we
>>>>>>>> don't store public certificate in LDAP either but we do two checks:
>>>>>>>> - a special KDC certificate profile is used to issue the cert
>>>>>>>> - a special hostname check is done so that only IPA masters are able to
>>>>>>>>   request this certificate
>>>>>>>>
>>>>>>>> For the wildcard certificate I think we could have following:
>>>>>>>> - use a separate profile for the wildcard, associated with a sub-CA
>>>>>>>> - hardcode CN default in the profile to always be 'CN=*, 
>>>>>>>> O=$SUB_CA_SUBJECT' so that
>>>>>>>>   actual certificate ignores requested CN.
>>>>>>>> - a special check to be done so that only wildcard-based subject
>>>>>>>>   alternative names can be added to a wildcard certificate request
>>>>>>>> - all Kerberos principal / hostname checks are skipped.
>>>>>>>> - actual ACL check is done by CA ACL.
>>>>>>>>
>>>>>>> Issuing wildcard certs is a deprecated practice[1].  I am not
>>>>>>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in
>>>>>>> general) but I'd like to have a discussion with them about how
>>>>>>> they're currently dealing with certs and whether a different
>>>>>>> direction other than wildcard certs is feasible.  Martin, who should
>>>>>>> I reach out to?  Feel free to copy them into this discussion.
>>>>>>
>>>>>> Right now, I am talking to a Solution Architect, i.e. someone who is 
>>>>>> building
>>>>>>

Re: [Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

On 02/10/2017 10:37 AM, Fraser Tweedale wrote:
> On Fri, Feb 10, 2017 at 09:23:10AM +0100, Martin Kosek wrote:
>> On 02/09/2017 10:44 PM, Fraser Tweedale wrote:
>>> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote:
>>>> On 02/09/2017 02:12 AM, Fraser Tweedale wrote:
>>>>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
>>>>>> On ke, 08 helmi 2017, Martin Kosek wrote:
>>>>>>> Hi Fraser and the list,
>>>>>>>
>>>>>>> I recently was in a conversation about integrating OpenShift with 
>>>>>>> FreeIPA. One
>>>>>>> of the gaps was around generating a wildcard certificate by FreeIPA 
>>>>>>> that will
>>>>>>> be used in the default OpenShift router for applications that do not 
>>>>>>> deploy own
>>>>>>> certificates [1].
>>>>>>>
>>>>>>> Is there any way that FreeIPA can generate it? I was thinking that 
>>>>>>> uploading
>>>>>>> some custom certificate profile in FreeIPA may let us get such 
>>>>>>> certificate...
>>>>>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, 
>>>>>>> tracked in
>>>>>>> [2]?
>>>>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
>>>>>> certificates to be issued:
>>>>>>
>>>>>> - we ensure subject 'cn' of the certificate matches a Kerberos principal
>>>>>>   specified in the request
>>>>>>
>>>>>> - we validate that host object exists in IPA when the Kerberos
>>>>>>   principal is host/...
>>>>>>
>>>>>> We could lift off these two limitations for 'cn=*,$suffix' but there is
>>>>>> still a need to apply proper ACLs when issuing the cert -- e.g. some
>>>>>> object has to be used for performing access rights check. The wildcard
>>>>>> certificate does not need to be stored anywhere in the tree, but a
>>>>>> check still needs to be done.
>>>>>>
>>>>>> For example, for Kerberos PKINIT certificate which is issued to KDC we
>>>>>> don't store public certificate in LDAP either but we do two checks:
>>>>>> - a special KDC certificate profile is used to issue the cert
>>>>>> - a special hostname check is done so that only IPA masters are able to
>>>>>>   request this certificate
>>>>>>
>>>>>> For the wildcard certificate I think we could have following:
>>>>>> - use a separate profile for the wildcard, associated with a sub-CA
>>>>>> - hardcode CN default in the profile to always be 'CN=*, 
>>>>>> O=$SUB_CA_SUBJECT' so that
>>>>>>   actual certificate ignores requested CN.
>>>>>> - a special check to be done so that only wildcard-based subject
>>>>>>   alternative names can be added to a wildcard certificate request
>>>>>> - all Kerberos principal / hostname checks are skipped.
>>>>>> - actual ACL check is done by CA ACL.
>>>>>>
>>>>> Issuing wildcard certs is a deprecated practice[1].  I am not
>>>>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in
>>>>> general) but I'd like to have a discussion with them about how
>>>>> they're currently dealing with certs and whether a different
>>>>> direction other than wildcard certs is feasible.  Martin, who should
>>>>> I reach out to?  Feel free to copy them into this discussion.
>>>>
>>>> Right now, I am talking to a Solution Architect, i.e. someone who is 
>>>> building
>>>> GAed solutions, not developers. This is not something we would change
>>>> short-term anyway, this is how current OpenShift v2 or v3 behaves, despite 
>>>> the RFC.
>>>>
>>>> While I understand why having certificate *.lab.example.com and using it 
>>>> for my
>>>> lab machines is a bad idea and increases the attack vector, I do not see it
>>>> that way for OpenShift. There, applications get URL like
>>>> ".myopenshift.test" and all is routed by one entity, the OpenShift
>>>> broker. So the key.cert is on one location, just serving different 

Re: [Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

On 02/09/2017 10:44 PM, Fraser Tweedale wrote:
> On Thu, Feb 09, 2017 at 08:37:23AM +0100, Martin Kosek wrote:
>> On 02/09/2017 02:12 AM, Fraser Tweedale wrote:
>>> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
>>>> On ke, 08 helmi 2017, Martin Kosek wrote:
>>>>> Hi Fraser and the list,
>>>>>
>>>>> I recently was in a conversation about integrating OpenShift with 
>>>>> FreeIPA. One
>>>>> of the gaps was around generating a wildcard certificate by FreeIPA that 
>>>>> will
>>>>> be used in the default OpenShift router for applications that do not 
>>>>> deploy own
>>>>> certificates [1].
>>>>>
>>>>> Is there any way that FreeIPA can generate it? I was thinking that 
>>>>> uploading
>>>>> some custom certificate profile in FreeIPA may let us get such 
>>>>> certificate...
>>>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, 
>>>>> tracked in
>>>>> [2]?
>>>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
>>>> certificates to be issued:
>>>>
>>>> - we ensure subject 'cn' of the certificate matches a Kerberos principal
>>>>   specified in the request
>>>>
>>>> - we validate that host object exists in IPA when the Kerberos
>>>>   principal is host/...
>>>>
>>>> We could lift off these two limitations for 'cn=*,$suffix' but there is
>>>> still a need to apply proper ACLs when issuing the cert -- e.g. some
>>>> object has to be used for performing access rights check. The wildcard
>>>> certificate does not need to be stored anywhere in the tree, but a
>>>> check still needs to be done.
>>>>
>>>> For example, for Kerberos PKINIT certificate which is issued to KDC we
>>>> don't store public certificate in LDAP either but we do two checks:
>>>> - a special KDC certificate profile is used to issue the cert
>>>> - a special hostname check is done so that only IPA masters are able to
>>>>   request this certificate
>>>>
>>>> For the wildcard certificate I think we could have following:
>>>> - use a separate profile for the wildcard, associated with a sub-CA
>>>> - hardcode CN default in the profile to always be 'CN=*, 
>>>> O=$SUB_CA_SUBJECT' so that
>>>>   actual certificate ignores requested CN.
>>>> - a special check to be done so that only wildcard-based subject
>>>>   alternative names can be added to a wildcard certificate request
>>>> - all Kerberos principal / hostname checks are skipped.
>>>> - actual ACL check is done by CA ACL.
>>>>
>>> Issuing wildcard certs is a deprecated practice[1].  I am not
>>> dismissing the needs of OpenShift (or PaaS/IaaS solutions in
>>> general) but I'd like to have a discussion with them about how
>>> they're currently dealing with certs and whether a different
>>> direction other than wildcard certs is feasible.  Martin, who should
>>> I reach out to?  Feel free to copy them into this discussion.
>>
>> Right now, I am talking to a Solution Architect, i.e. someone who is building
>> GAed solutions, not developers. This is not something we would change
>> short-term anyway, this is how current OpenShift v2 or v3 behaves, despite 
>> the RFC.
>>
>> While I understand why having certificate *.lab.example.com and using it for 
>> my
>> lab machines is a bad idea and increases the attack vector, I do not see it
>> that way for OpenShift. There, applications get URL like
>> ".myopenshift.test" and all is routed by one entity, the OpenShift
>> broker. So the key.cert is on one location, just serving different names that
>> are provisioned with OpenShift.
>>
>> I can understand that issuing a new certificate for every application
>> provisioned by OpenShift and then renewing it complicates the design
>> significantly. I am trying to be creative and see if current OpenShift could
>> leverage FreeIPA CA and issue the broker cert, with current profile
>> capabilities or with small change.
>>
> I believe OpenShift supports per-application certificates (i.e. when
> app developers/maintainers supply their own cert for a custom
> domain).  So it might be possible in v2 or v3 to provision a cert
> for every app.

Right, it supports this

Re: [Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

On 02/09/2017 02:12 AM, Fraser Tweedale wrote:
> On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:
>> On ke, 08 helmi 2017, Martin Kosek wrote:
>>> Hi Fraser and the list,
>>>
>>> I recently was in a conversation about integrating OpenShift with FreeIPA. 
>>> One
>>> of the gaps was around generating a wildcard certificate by FreeIPA that 
>>> will
>>> be used in the default OpenShift router for applications that do not deploy 
>>> own
>>> certificates [1].
>>>
>>> Is there any way that FreeIPA can generate it? I was thinking that uploading
>>> some custom certificate profile in FreeIPA may let us get such 
>>> certificate...
>>> Or is the the only way we can add it by adding a new RFE in FreeIPA, 
>>> tracked in
>>> [2]?
>> Yes, we need a new RFE. There are checks in IPA that prevent wildcard
>> certificates to be issued:
>>
>> - we ensure subject 'cn' of the certificate matches a Kerberos principal
>>   specified in the request
>>
>> - we validate that host object exists in IPA when the Kerberos
>>   principal is host/...
>>
>> We could lift off these two limitations for 'cn=*,$suffix' but there is
>> still a need to apply proper ACLs when issuing the cert -- e.g. some
>> object has to be used for performing access rights check. The wildcard
>> certificate does not need to be stored anywhere in the tree, but a
>> check still needs to be done.
>>
>> For example, for Kerberos PKINIT certificate which is issued to KDC we
>> don't store public certificate in LDAP either but we do two checks:
>> - a special KDC certificate profile is used to issue the cert
>> - a special hostname check is done so that only IPA masters are able to
>>   request this certificate
>>
>> For the wildcard certificate I think we could have following:
>> - use a separate profile for the wildcard, associated with a sub-CA
>> - hardcode CN default in the profile to always be 'CN=*, O=$SUB_CA_SUBJECT' 
>> so that
>>   actual certificate ignores requested CN.
>> - a special check to be done so that only wildcard-based subject
>>   alternative names can be added to a wildcard certificate request
>> - all Kerberos principal / hostname checks are skipped.
>> - actual ACL check is done by CA ACL.
>>
> Issuing wildcard certs is a deprecated practice[1].  I am not
> dismissing the needs of OpenShift (or PaaS/IaaS solutions in
> general) but I'd like to have a discussion with them about how
> they're currently dealing with certs and whether a different
> direction other than wildcard certs is feasible.  Martin, who should
> I reach out to?  Feel free to copy them into this discussion.

Right now, I am talking to a Solution Architect, i.e. someone who is building
GAed solutions, not developers. This is not something we would change
short-term anyway, this is how current OpenShift v2 or v3 behaves, despite the 
RFC.

While I understand why having certificate *.lab.example.com and using it for my
lab machines is a bad idea and increases the attack vector, I do not see it
that way for OpenShift. There, applications get URL like
".myopenshift.test" and all is routed by one entity, the OpenShift
broker. So the key.cert is on one location, just serving different names that
are provisioned with OpenShift.

I can understand that issuing a new certificate for every application
provisioned by OpenShift and then renewing it complicates the design
significantly. I am trying to be creative and see if current OpenShift could
leverage FreeIPA CA and issue the broker cert, with current profile
capabilities or with small change.

> [1] https://tools.ietf.org/html/rfc6125#section-7.2
> 
> If we do go ahead with wildcard cert support in FreeIPA, some of my
> initial questions are:
> 
> - For the OpenShift use case, what is the "parent" domain name and
>   is it the same as the IPA domain name?  Is it a subdomain of the
>   IPA domain name?
> 
> - Do we need to support issuing "*.${IPA_DOMAIN}"? i.e. wildcard
>   cert under entire IPA domain name.
> 
> - Do we need to support issuing "*.${IPA_HOSTNAME}"?  i.e. wildcard
>   certs under names of IPA host principals.

I do not know, but I can ask if it is important for you :-)

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

[Freeipa-devel] FreeIPA and wildcard certificates

[Martin Kosek]

Hi Fraser and the list,

I recently was in a conversation about integrating OpenShift with FreeIPA. One
of the gaps was around generating a wildcard certificate by FreeIPA that will
be used in the default OpenShift router for applications that do not deploy own
certificates [1].

Is there any way that FreeIPA can generate it? I was thinking that uploading
some custom certificate profile in FreeIPA may let us get such certificate...
Or is the the only way we can add it by adding a new RFE in FreeIPA, tracked in
[2]?

Thanks!

[1]
https://docs.openshift.com/container-platform/3.4/install_config/router/default_haproxy_router.html#using-wildcard-certificates
[2] https://fedorahosted.org/freeipa/ticket/3475

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] FedoraHosted.org sunset

[Martin Kosek]

On 09/23/2016 09:54 AM, Jakub Hrozek wrote:
> On Thu, Sep 22, 2016 at 06:09:43PM +0200, Petr Vobornik wrote:
>> Hi all,
>>
>> As you know, FedoraHosted.org will be decommissioned.
>>  https://communityblog.fedoraproject.org/fedorahosted-sunset-2017-02-28/
>>
>> We use Trac instance there. Let's discuss where we should migrate and
>> what are our requirements. Then put results on one place. For that I've
>> created:
>>   http://www.freeipa.org/page/FedoraHosted_Migration
> 
> That you for writing this up, there are some good points I didn't think
> about, like migrating the ticket numbers. Did you already file an issue
> that tracks this in Pagure (or asked if this is already possible)?

I think the achieving the same ticket numbers should not be difficult. During
the migration, we would just need to make sure we insert dummy
Pagure/Github/... tickets on when the original ticket was deleted, like

https://fedorahosted.org/freeipa/ticket/2

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

Re: [Freeipa-devel] FreeIPA wiki - fighting the spammers

[Martin Kosek]

On 08/19/2016 08:43 AM, Petr Spacek wrote:
> On 18.8.2016 16:25, Martin Kosek wrote:
>> Hello everyone,
>>
>> As some of you noticed, we had lately an increasing number of spam attacks
>> against FreeIPA.org wiki. Even though we did not accept user registration
>> through the standard Mediawiki User Creation form (which is often misused by
>> attacked) and only allow Fedora users logged in by OpenID, the spam producers
>> started to favor this authentication mode too.
>>
>> This week and especially yesterday, the spam activity was high enough to
>> warrant a "drastic change" in how we allow wiki modifications. Me and Petr
>> Vobornik had to react quickly yesterday to hundreds of new spam-based pages
>> (thanks to Petr for deleting the spam pages, Stephen for altering us and
>> Patrick Uiterwijk for advising us!).
>>
>> As a prevention for future attacks, I also needed to chose the most simple 
>> and
>> convenient method to stop spammers from editing wiki. This is the result:
>>
>> - Anonymous and regular users are no longer allowed to create or edit wiki 
>> pages
>> - Anyone who wants to be able to edit wiki needs to be in a new "editor" 
>> group
>>
>> The full description of new group rights is here:
>> http://www.freeipa.org/page/Special:ListGroupRights
>>
>> I added the contributors active in the last 30 days to the editor group. If
>> more people are needed, wiki "Bureaucrats" can it through this form:
>> http://www.freeipa.org/page/Special:UserRights
>>
>> If you do not know who is in the Bureaucrat group, this is the list:
>> http://www.freeipa.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50
>>
>> The model I had in mind was that new wiki contributors would ask for access 
>> on
>> #freeipa IRC channel, when they have some content to be added to the pages. 
>> We
>> should probably add that suggestion to the wiki somewhere.
>>
>> I hope this works for you. If you have comments on above or even better ideas
>> what is the easiest way to fight spam on our precious wiki, please let me 
>> know.
> 
> In general I agree.
> 
> My attempt to edit "permission denied" error using
> http://www.freeipa.org/page/Special:AllMessages
> failed so I do not know.
> 
> For the beginning, I added note about this new process to
> http://www.freeipa.org/page/Contribute#Contribute_documentation
> and link to the process page to
> http://www.freeipa.org/page/HowTo/Writing_how_to_documentation_on_the_wiki
> 
> 
> Now the question is how to make information about getting edit access *really
> visible*. Is this enough? I'm not sure.

Thanks Petr! I just made the warning into admonition box and fixed the wording
a bit. It seems pretty visible now.

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

[Freeipa-devel] FreeIPA wiki - fighting the spammers

[Martin Kosek]

Hello everyone,

As some of you noticed, we had lately an increasing number of spam attacks
against FreeIPA.org wiki. Even though we did not accept user registration
through the standard Mediawiki User Creation form (which is often misused by
attacked) and only allow Fedora users logged in by OpenID, the spam producers
started to favor this authentication mode too.

This week and especially yesterday, the spam activity was high enough to
warrant a "drastic change" in how we allow wiki modifications. Me and Petr
Vobornik had to react quickly yesterday to hundreds of new spam-based pages
(thanks to Petr for deleting the spam pages, Stephen for altering us and
Patrick Uiterwijk for advising us!).

As a prevention for future attacks, I also needed to chose the most simple and
convenient method to stop spammers from editing wiki. This is the result:

- Anonymous and regular users are no longer allowed to create or edit wiki pages
- Anyone who wants to be able to edit wiki needs to be in a new "editor" group

The full description of new group rights is here:
http://www.freeipa.org/page/Special:ListGroupRights

I added the contributors active in the last 30 days to the editor group. If
more people are needed, wiki "Bureaucrats" can it through this form:
http://www.freeipa.org/page/Special:UserRights

If you do not know who is in the Bureaucrat group, this is the list:
http://www.freeipa.org/index.php?title=Special%3AListUsers&username=&group=bureaucrat&limit=50

The model I had in mind was that new wiki contributors would ask for access on
#freeipa IRC channel, when they have some content to be added to the pages. We
should probably add that suggestion to the wiki somewhere.

I hope this works for you. If you have comments on above or even better ideas
what is the easiest way to fight spam on our precious wiki, please let me know.

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

[Martin Kosek]

On 08/16/2016 08:12 PM, Alexander Bokovoy wrote:
> On Tue, 16 Aug 2016, Ben Lipton wrote:
>> On 08/10/2016 08:52 AM, Ben Lipton wrote:
>>> The pull request at https://github.com/LiptonB/freeipa/pull/4/commits has
>>> been brought up to date (with a force push), and also includes 3 more
>>> patches, described below.
>>>
>>> The patchset is also attached. To make sure that everything applies, I just
>>> regenerated the whole set, though there may not be meaningful changes.
>>>
>> After a discussion about how to address some of the concerns that have been
>> voiced about this project, there have been some changes to the project
>> direction. So, I wanted to provide an update about what the plans are. If you
>> have objections or feel that I'm not representing it correctly, please let me
>> know.
>>
>> Since we have yet to see all the ways people will want to use this feature,
>> the immediate goal is to provide something that we can iterate on. To make
>> this easier, we will avoid storing rule data on the server or modifying the
>> server schema, as those changes would need to be supported long term/handled
>> correctly on update. I plan to approach this as follows:
>> - Separate the provider of mapping rules into a separate component from the
>> generation of a config based on those rules
>> - Build an alternative rule provider that reads local files rather than
>> querying IPA
>> - Move the implementation of CSR config formatting from the server API into a
>> library (where should this go? ipalib? ipapython?), and then provide a
>> client-side command that builds a config using the library.
> Up to you -- ipapython is traditionally used for very basic dependencies
> when nothing is configured and is used by both installers and the
> framework, ipalib -- for common code in the framework itself.
> 
>> - Templates for at least two profiles ("user" profile with
>> CN=, subject and email address SAN, "service" profile
>> with CN=, subject and DNS SAN) will be provided. Users
>> will be able to build custom profiles by putting files in the appropriate
>> directories on their client machines (but we will not guarantee backward
>> compatibility for the format of these files).
>> - If we decide to move forward with storing rules on the server, the library
>> call can be referenced from the server code, using the rule provider that
>> pulls rules from the API. However, at that point we may also go in the
>> direction of making automatic cert generation fully the responsibility of
>> Dogtag, and keep the CSR-generation approach client-side only.
>>
>> Comments welcome! Unless the changes are more complex than I anticipate, I
>> hope to have a prototype of this approach for review by the end of this week.
> The summary above looks fine.

+1, this looks good to me too. Thanks Ben, good job!

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

Re: [Freeipa-devel] [PATCH] 0078-82: webui tests: tests for new certificate widget

[Martin Kosek]

On 07/29/2016 03:00 PM, Pavel Vomacka wrote:
> 
> 
> On 07/28/2016 08:16 AM, Lenka Doudova wrote:
>>
>>
>>
>> On 07/20/2016 04:51 PM, Pavel Vomacka wrote:
>>> Please review attached patches, which add tests for new certificate widget 
>>> in 
>>> WebUI.
>>>
>>> https://fedorahosted.org/freeipa/ticket/6064
>>>
>>>
>>>
>> Hi,
>> thanks for patches.
>> Functionally ok, but you have lots of PEP8 errors in patches 78, 80, 81 and 
>> 82 
>> -> NACK.
>> Also in patch 82, method test_arbitrary_certificate, comment says user needs 
>> to have "arbitrary_cert" configured, but the property in config file is 
>> correctly "arbitrary_cert_path", so it's a bit misleading.
>>
>> Patch 79 is OK, ACK.
>>
>> Lenka
>>
>>
> Thank you for review. Attaching patches which have fixed all pep8 erros. Bad 
> property of config file was also mentioned in patch 81. These are also fixed.

It looks like these patches had wrong author set. Pavel, you may want to
revisit your work environment management scripts :-)

(I wonder if this is worth updating .mailmap to avoid wrong git shortlog)

-- 
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

Re: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate

[Martin Kosek]

On 08/08/2016 01:31 PM, Jan Pazdziora wrote:
> On Mon, Aug 08, 2016 at 12:52:33PM +0200, Martin Kosek wrote:
>>
>> I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so 
>> let
>> me repeat my suggestion here. I still think it is premature to add plugins 
>> like
>> that to FreeIPA core git. We are not agreed yet how we will distribute 
>> FreeIPA
>> plugins, so I would not rush adding this plugin to FreeIPA core, especially
>> since it is very experimental and not even secure yet. FreeIPA plugin
>> distribution should be more thought through and discussed.
>>
>> As I proposed, this plugin can now live outside of FreeIPA core git, in it's
>> own life cycle (maybe in freeipa-plugins github git repo we create?) so that 
>> it
>> can be updated without updating whole FreeIPA core. In this effort, I would
>> suggest to only consider updates of
>>
>> * ipaserver/plugins/xmlserver.py
>> * ipaserver/rpcserver.py
>>
>> as these would have to patched by admin deploying this feature and would be
>> overwritten by RPM updates. The plugin itself or server.conf can be deployed
>> and installed separatenly, even via other RPM.
> 
> We want the feature (albeit experimental) to be available to upstream
> users and downstream customers, with as few steps to take and as few
> hoops to jump through as possible. Any bits we can get to users' and
> customers' hands via standard means are bits that they don't need to
> get from elsewhere, via nonstandard means, with us inventing and
> supporting these nonstandards processes.
> 
> Assuming the mere existence of the functionality (which will be
> disabled by default) does not decrease security of the default
> installations and configuration, I don't see why carrying it poses
> a problem.

I see your reasoning, I just think it is not strong enough to rush this new
method of delivering plugins in before discussing it more broadly.

Also, as I mentioned, we may want different life cycle for FreeIPA plugins that
we want for FreeIPA core bits. Thus the different repository suggestion. This
whole feature is (still) non-standard and experimental, so I do not personally
see that big problem in non-standard delivery mechanism.

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

Re: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate

[Martin Kosek]

On 08/05/2016 02:57 PM, Tibor Dudlak wrote:
> Hi,
> 
> I have extended my previous patch for authentication with user 
> certificate/smartcard. This patch includes patches and plugin described here: 
> http://www.freeipa.org/page/V4/External_Authentication/Setup
> Page also contains steps to configure and test this feature. Once this patch 
> is 
> merged and released we will simplify this page to not confuse customers.
> Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764
> 
> Thanks.

I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let
me repeat my suggestion here. I still think it is premature to add plugins like
that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA
plugins, so I would not rush adding this plugin to FreeIPA core, especially
since it is very experimental and not even secure yet. FreeIPA plugin
distribution should be more thought through and discussed.

As I proposed, this plugin can now live outside of FreeIPA core git, in it's
own life cycle (maybe in freeipa-plugins github git repo we create?) so that it
can be updated without updating whole FreeIPA core. In this effort, I would
suggest to only consider updates of

* ipaserver/plugins/xmlserver.py
* ipaserver/rpcserver.py

as these would have to patched by admin deploying this feature and would be
overwritten by RPM updates. The plugin itself or server.conf can be deployed
and installed separatenly, even via other RPM.

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

Re: [Freeipa-devel] FreeIPA Sub-CA: certificate subject

[Martin Kosek]

On 06/28/2016 02:05 PM, Fraser Tweedale wrote:
> On Tue, Jun 28, 2016 at 12:49:26PM +0200, Martin Kosek wrote:
>> On 06/28/2016 12:49 PM, Jan Cholasta wrote:
>>> On 28.6.2016 12:33, Martin Kosek wrote:
>>>> On 06/28/2016 12:23 PM, Fraser Tweedale wrote:
>>>>> On Tue, Jun 28, 2016 at 11:00:17AM +0200, Martin Kosek wrote:
>>>>>> Hi Fraser,
>>>>>>
>>>>>> I was testing FreeIPA Sub-CA feature and setup a Sub-CA:
>>>>>>
>>>>>> CN=Certificate Authority,O=VPN,O=DEMO1.FREEIPA.ORG
>>>>>>
>>>>>> Then I set up ACL and generated a certificate request by:
>>>>>>
>>>>>> $ certutil -R -d . -a -g 2048 -s
>>>>>> 'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8
>>>>>> 'ipa.demo1.freeipa.org'
>>>>>>
>>>>>> The resulting certificate is attached. What I pondering about is
>>>>>>
>>>>>> Issuer: O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority
>>>>>> ...
>>>>>> Subject: O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org
>>>>>>
>>>>>> Shouldn't the subject have O=VPN in it also?
>>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> (Cc freeipa-devel@ ; this info may be of general interest)
>>>>>
>>>>> The subject is determined by the certificate profile.  In the case
>>>>> of caIPAserviceCert, the pattern is:
>>>>>
>>>>> CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O
>>>>>
>>>>> The CN comes from the CSR, and the Organisation is the IPA
>>>>> certificate subject base (as a literal string in the profile
>>>>> configuration).
>>>>>
>>>>> There are no substitution variables available to say "use such and
>>>>> such from the issuer DN".  If the default pattern is not suitable,
>>>>> you can define a profile with the subject DN pattern having exactly
>>>>> the O=... parts of DN you want (and/or other attributes), then
>>>>> associate the profile with the CA through CA ACLs.  (This approach
>>>>> is not elegant and does not scale well to many CAs).
>>>>>
>>>>> Hope that my explanation is helpful.
>>>>
>>>> The explanation is helpful, I just do not I like the answer :-) What do you
>>>> think would make most sense for Sub-CA users?
>>>>
>>>> I would like to see pattern like "$$issuer.suffix$$" where the Dogtag would
>>>> fill the non-CN part of issuer DN, i.e. in this case:
>>>>
>>>> O=DEMO1.FREEIPA.ORG, O=VPN
>>>>
>>>> which would make this profile flexible and usable in any Sub-CA.
>>>
>>>>
>>>> Should I file a ticket? Can you scope if it fits in some FreeIPA 4.4.x and
>>>> respective Dogtag release? I am just afraid that given we release this 
>>>> feature
>>>> in 4.4, people would have to very creative and duplicate lot of certificate
>>>> profiles for different sub-CAs just to workaround the Subject patter
>>>> limitation, as you mentioned.
>>>
>>> What is the use case?
>>
>> This is what I am trying to find out.
>>
>>> The certificate is equally good with both the current and
>>> your suggested issuer name. There is no relation between issuer name and
>>> subject name in general, and AFAIK the current recommendation is to omit
>>> subject name for end-entity certificate entirely and instead rely on SAN, so
>>> why should we bother?
>>
>> I am aware of the SAN related change, regarding hostnames. So this proposal
>> would apparently not add that much value in this case. What about user
>> certificates (S/MIME certs, Smart Card certs), are there cases where admin
>> would need to get issuer to subject name?
>>
> I do not think it is so important... the issuer name appears on the
> certificate too, and all issuers appear in the cert chain.  Unless
> there is some particular software or a customer that expects/needs a
> particular relationship between Issuer DN and Subject DN... but I do
> not know of a such a case.
> 
> I agree it would possibly be useful to have variables for info in
> the Issuer DN, that can be referenced in the Subject DN pattern.
> It probably won't fit into v4.4 timeframe, though.

Right. I would file that ticket when someone really requests it. Looks like no
change is needed in this case, I thus consider this question successfully 
resolved.

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

Re: [Freeipa-devel] FreeIPA Sub-CA: certificate subject

[Martin Kosek]

On 06/28/2016 12:49 PM, Jan Cholasta wrote:
> On 28.6.2016 12:33, Martin Kosek wrote:
>> On 06/28/2016 12:23 PM, Fraser Tweedale wrote:
>>> On Tue, Jun 28, 2016 at 11:00:17AM +0200, Martin Kosek wrote:
>>>> Hi Fraser,
>>>>
>>>> I was testing FreeIPA Sub-CA feature and setup a Sub-CA:
>>>>
>>>> CN=Certificate Authority,O=VPN,O=DEMO1.FREEIPA.ORG
>>>>
>>>> Then I set up ACL and generated a certificate request by:
>>>>
>>>> $ certutil -R -d . -a -g 2048 -s
>>>> 'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8
>>>> 'ipa.demo1.freeipa.org'
>>>>
>>>> The resulting certificate is attached. What I pondering about is
>>>>
>>>> Issuer: O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority
>>>> ...
>>>> Subject: O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org
>>>>
>>>> Shouldn't the subject have O=VPN in it also?
>>>>
>>> Hi Martin,
>>>
>>> (Cc freeipa-devel@ ; this info may be of general interest)
>>>
>>> The subject is determined by the certificate profile.  In the case
>>> of caIPAserviceCert, the pattern is:
>>>
>>> CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O
>>>
>>> The CN comes from the CSR, and the Organisation is the IPA
>>> certificate subject base (as a literal string in the profile
>>> configuration).
>>>
>>> There are no substitution variables available to say "use such and
>>> such from the issuer DN".  If the default pattern is not suitable,
>>> you can define a profile with the subject DN pattern having exactly
>>> the O=... parts of DN you want (and/or other attributes), then
>>> associate the profile with the CA through CA ACLs.  (This approach
>>> is not elegant and does not scale well to many CAs).
>>>
>>> Hope that my explanation is helpful.
>>
>> The explanation is helpful, I just do not I like the answer :-) What do you
>> think would make most sense for Sub-CA users?
>>
>> I would like to see pattern like "$$issuer.suffix$$" where the Dogtag would
>> fill the non-CN part of issuer DN, i.e. in this case:
>>
>> O=DEMO1.FREEIPA.ORG, O=VPN
>>
>> which would make this profile flexible and usable in any Sub-CA.
> 
>>
>> Should I file a ticket? Can you scope if it fits in some FreeIPA 4.4.x and
>> respective Dogtag release? I am just afraid that given we release this 
>> feature
>> in 4.4, people would have to very creative and duplicate lot of certificate
>> profiles for different sub-CAs just to workaround the Subject patter
>> limitation, as you mentioned.
> 
> What is the use case?

This is what I am trying to find out.

> The certificate is equally good with both the current and
> your suggested issuer name. There is no relation between issuer name and
> subject name in general, and AFAIK the current recommendation is to omit
> subject name for end-entity certificate entirely and instead rely on SAN, so
> why should we bother?

I am aware of the SAN related change, regarding hostnames. So this proposal
would apparently not add that much value in this case. What about user
certificates (S/MIME certs, Smart Card certs), are there cases where admin
would need to get issuer to subject name?

-- 
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

Re: [Freeipa-devel] FreeIPA Sub-CA: certificate subject

[Martin Kosek]

On 06/28/2016 12:23 PM, Fraser Tweedale wrote:
> On Tue, Jun 28, 2016 at 11:00:17AM +0200, Martin Kosek wrote:
>> Hi Fraser,
>>
>> I was testing FreeIPA Sub-CA feature and setup a Sub-CA:
>>
>> CN=Certificate Authority,O=VPN,O=DEMO1.FREEIPA.ORG
>>
>> Then I set up ACL and generated a certificate request by:
>>
>> $ certutil -R -d . -a -g 2048 -s
>> 'CN=ipa.demo1.freeipa.org,O=VPN,O=DEMO1.FREEIPA.ORG' -8 
>> 'ipa.demo1.freeipa.org'
>>
>> The resulting certificate is attached. What I pondering about is
>>
>> Issuer: O=DEMO1.FREEIPA.ORG, O=VPN, CN=Certificate Authority
>> ...
>> Subject: O=DEMO1.FREEIPA.ORG, CN=ipa.demo1.freeipa.org
>>
>> Shouldn't the subject have O=VPN in it also?
>>
> Hi Martin,
> 
> (Cc freeipa-devel@ ; this info may be of general interest)
> 
> The subject is determined by the certificate profile.  In the case
> of caIPAserviceCert, the pattern is:
> 
> CN=$$request.req_subject_name.cn$$, $SUBJECT_DN_O
> 
> The CN comes from the CSR, and the Organisation is the IPA
> certificate subject base (as a literal string in the profile
> configuration).
> 
> There are no substitution variables available to say "use such and
> such from the issuer DN".  If the default pattern is not suitable,
> you can define a profile with the subject DN pattern having exactly
> the O=... parts of DN you want (and/or other attributes), then
> associate the profile with the CA through CA ACLs.  (This approach
> is not elegant and does not scale well to many CAs).
> 
> Hope that my explanation is helpful.

The explanation is helpful, I just do not I like the answer :-) What do you
think would make most sense for Sub-CA users?

I would like to see pattern like "$$issuer.suffix$$" where the Dogtag would
fill the non-CN part of issuer DN, i.e. in this case:

O=DEMO1.FREEIPA.ORG, O=VPN

which would make this profile flexible and usable in any Sub-CA.

Should I file a ticket? Can you scope if it fits in some FreeIPA 4.4.x and
respective Dogtag release? I am just afraid that given we release this feature
in 4.4, people would have to very creative and duplicate lot of certificate
profiles for different sub-CAs just to workaround the Subject patter
limitation, as you mentioned.

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

Re: [Freeipa-devel] [PATCH] 498 Update Contributors.txt

[Martin Kosek]

On 06/23/2016 07:39 PM, Lukas Slebodnik wrote:
> On (23/06/16 15:22), Martin Kosek wrote:
>> Update .mailmap to fix wrong commit author and re-generate
>> the Developer contributor list.
>>
>> -- 
>> Martin Kosek 
>> Manager, Software Engineering - Identity Management Team
>> Red Hat, Inc.
> 
>>From 4271bdb36d111b90da3daf3f4312ec40d7db590f Mon Sep 17 00:00:00 2001
>> From: Martin Kosek 
>> Date: Thu, 23 Jun 2016 15:19:59 +0200
>> Subject: [PATCH] Update Contributors.txt
>>
>> Update .mailmap to fix wrong commit author and re-generate
>> the Developer contributor list.
>> ---
>> .mailmap | 1 +
>> Contributors.txt | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/.mailmap b/.mailmap
>> index 
>> 422a0089cc6f7de4aaed6a446a5d090bcee3fee8..4fe0587a4550b9ca4b89501a55d96540df4c10cf
>>  100644
>> --- a/.mailmap
>> +++ b/.mailmap
>> @@ -51,6 +51,7 @@ Sumit Bose   
>> 
>> Thierry Bordaz  
>> Thierry Bordaz 
>> 
>> Thierry Bordaz 
>> 
>> +Thierry Bordaz 
>> 
> I know that it's autogenrated.
> But does Thierry need to be there 4 times?

This is not autogenerated, I had to add a correct author mapping for every
patch that was send and commited with a wrong author.

> 
>> Tomáš Babej 
>> Tomáš Babej 
>> William Jon McCann 
>> diff --git a/Contributors.txt b/Contributors.txt
>> index 
>> 71be27da5ab415deb11589d5bf82d684b2d85f9a..a003a3edb5c1f291b94402f6784b70fa7bcb1298
>>  100644
>> --- a/Contributors.txt
>> +++ b/Contributors.txt
>> @@ -10,6 +10,7 @@ Developers:
>>  Tomáš Babej
>>  Martin Babinsky
>>  Kyle Baker
>> +Jan Barta
>>  Martin Bašti
>>  Sylvain Baubeau
>>  Florence Blanc-Renaud
>> -- 
>> 2.5.5
>>
> 
>> -- 
>> 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
> 

-- 
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

[Freeipa-devel] [PATCH] 498 Update Contributors.txt

[Martin Kosek]

Update .mailmap to fix wrong commit author and re-generate
the Developer contributor list.

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.
From 4271bdb36d111b90da3daf3f4312ec40d7db590f Mon Sep 17 00:00:00 2001
From: Martin Kosek 
Date: Thu, 23 Jun 2016 15:19:59 +0200
Subject: [PATCH] Update Contributors.txt

Update .mailmap to fix wrong commit author and re-generate
the Developer contributor list.
---
 .mailmap | 1 +
 Contributors.txt | 1 +
 2 files changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 422a0089cc6f7de4aaed6a446a5d090bcee3fee8..4fe0587a4550b9ca4b89501a55d96540df4c10cf 100644
--- a/.mailmap
+++ b/.mailmap
@@ -51,6 +51,7 @@ Sumit Bose   
 Thierry Bordaz  
 Thierry Bordaz 
 Thierry Bordaz 
+Thierry Bordaz 
 Tomáš Babej 
 Tomáš Babej 
 William Jon McCann 
diff --git a/Contributors.txt b/Contributors.txt
index 71be27da5ab415deb11589d5bf82d684b2d85f9a..a003a3edb5c1f291b94402f6784b70fa7bcb1298 100644
--- a/Contributors.txt
+++ b/Contributors.txt
@@ -10,6 +10,7 @@ Developers:
 	Tomáš Babej
 	Martin Babinsky
 	Kyle Baker
+	Jan Barta
 	Martin Bašti
 	Sylvain Baubeau
 	Florence Blanc-Renaud
-- 
2.5.5

-- 
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

Re: [Freeipa-devel] I plan to delete my FreeIPA COPR repos

[Martin Kosek]

On 05/13/2016 01:43 PM, Martin Kosek wrote:
> Hi all,
> 
> When we were starting building FreeIPA in the Fedora COPR service [1], the
> service did not support the organizations as it can do now and we did the
> official repos in my personal name space [2] as I was the common denominator
> for the project at the time.
> 
> However, since that time, COPR support supports organizations, we created the
> FreeIPA organization [3] and do the official builds there. FreeIPA should have
> all currently supported repos, usually around 4.3 and master FreeIPA versions.
> 
> Now, is anyone still using any of my FreeIPA related repos? Can I delete them
> so that it does not confuse people about what is the official repo? Comparing
> what I see in FreeIPA organization repos and personal repos, the FreeIPA
> organization miss FreeIPA 4.0 and 4.1 versions, but I think these can be 
> safely
> removed.
> 
> So my current plan is to delete all my personal FreeIPA repos unless I hear 
> any
> blocker. So please holler if you depend on some of my repos.
> 
> [1] https://copr.fedorainfracloud.org
> [2] https://copr.fedorainfracloud.org/coprs/mkosek/
> [3] https://copr.fedorainfracloud.org/groups/g/freeipa/coprs/

I heard no concerns, my personal previously official COPR repos were deleted.

https://copr.fedorainfracloud.org/groups/g/freeipa/coprs/
for the win!

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

[Freeipa-devel] [PATCH] 497 Update Developers in Contributors.txt

[Martin Kosek]

Since we are close to 4.4 release, let's add the latest contributors. (master
branch should be enough).

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.
From 2f3b4706fbdf4319a54ef679042cdf1b156787b5 Mon Sep 17 00:00:00 2001
From: Martin Kosek 
Date: Thu, 16 Jun 2016 15:49:16 +0200
Subject: [PATCH] Update Developers in Contributors.txt

Add the most recent development contributors to FreeIPA.
---
 Contributors.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Contributors.txt b/Contributors.txt
index 8858724fab4febf01e19d8660786c10ddcc7a3b6..71be27da5ab415deb11589d5bf82d684b2d85f9a 100644
--- a/Contributors.txt
+++ b/Contributors.txt
@@ -12,6 +12,7 @@ Developers:
 	Kyle Baker
 	Martin Bašti
 	Sylvain Baubeau
+	Florence Blanc-Renaud
 	Alexander Bokovoy
 	Thierry Bordaz
 	Sumit Bose
@@ -30,9 +31,12 @@ Developers:
 	Endi Sukma Dewata
 	Lenka Doudova
 	Benjamin Drung
+	Patrice Duc-Jacquet
 	Drew Erny
 	Oleg Fayans
+	Jérôme Fenal
 	Stephen Gallagher
+	James Groffen
 	Ondřej Hamada
 	Nick Hatch
 	Christian Heimes
@@ -48,6 +52,7 @@ Developers:
 	Ian Kumlien
 	David Kupka
 	Robert Kuska
+	Peter Lacko
 	Stanislav Laznicka
 	Ade Lee
 	Karl MacMillan
@@ -70,12 +75,14 @@ Developers:
 	W. Michael Petullo
 	Gowrishankar Rajaiyan
 	Lubomír Rintel
+	Matt Rogers
 	Lynn Root
 	Pete Rowley
 	Lenka Ryznarova
 	Thorsten Scherf
 	Michael Simacek
 	Lars Sjostrom
+	Filip Skola
 	Lukáš Slebodník
 	Simo Sorce
 	Petr Špaček
@@ -84,6 +91,7 @@ Developers:
 	Fraser Tweedale
 	Petr Viktorin
 	Petr Voborník
+	Pavel Vomacka
 	Andrew Wnuk
 	Jason Woods
 	Adam Young
-- 
2.5.5

-- 
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

Re: [Freeipa-devel] Using JSON for tlog config files

[Martin Kosek]

Removing the secondary list from this discussion.

On 06/15/2016 01:29 PM, Nikolai Kondrashov wrote:
> Hi Simo,
> 
> On 06/15/2016 12:25 AM, Simo Sorce wrote:
>> On Tue, 2016-06-14 at 16:40 +0300, Nikolai Kondrashov wrote:
>>> Although this was mentioned several times before, I'd like to bring 
>>> additional
>>> attention to the idea of using config files written in JSON for tlog, 
>>> because
>>> there were some concerns over that being appropriate.
>>
>> What was the reasoning behind this questioning ?
> 
> The concern that JSON in those files might be inconvenient for administrators.
> 
>> In order to understand whether json is appropriate I need to ask who do
>> you think will be the primary user of the configuration file.
>> - Is it going to be mainly sysadmins manually setting things up ?
> 
> At first, yes. Later minimally, because we plan to implement central control
> of most (if not all) of the parameters.

Yes, but AFAIK, tlog will still also exist as standalone component and could be
configured without integration with FreeIPA. This means admins main
configuration file would still be the config file.

> The suggestions so far were to have
> the same JSON simply stored in HBAC-bound LDAP entries verbatim. Although, I'm
> not sure if that would be best.
> 
>> - Is this going to be something that may need to be templated and
>> delivered via things like puppet ansible ?
> 
> I didn't plan specifically for that. I expect the chances of that are about
> the same as for any other config file.
> 
>> - Is it going to be a file generated by some other program (like sssd or
>> similar) based on rules stored in a central system ?
> 
> I'd like to avoid requiring any program controlling tlog to write any files.
> That's why I implemented passing the whole or part of the configuration via an
> environment variable value, overriding the global config. However, yes, that
> value is expected to be the same JSON at the moment.
> 
>> The answer to these questions will help understanding what format is
>> better suited.
> 
> Thanks, Simo!
> 
> Nick
> 

-- 
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

Re: [Freeipa-devel] [PATCH] 0203 adtrust: remove ipanttrustpartner parameter

[Martin Kosek]

On 06/10/2016 10:01 AM, Martin Basti wrote:
> 
> 
> On 09.06.2016 21:45, Alexander Bokovoy wrote:
>> On Thu, 09 Jun 2016, Martin Basti wrote:
>>>
>>>
>>> On 09.06.2016 17:56, Martin Babinsky wrote:
 On 06/06/2016 01:37 PM, Alexander Bokovoy wrote:
> On Mon, 06 Jun 2016, Jan Cholasta wrote:
>> On 6.6.2016 13:22, Martin Basti wrote:
>>>
>>>
>>> On 06.06.2016 13:14, Alexander Bokovoy wrote:
 On Mon, 06 Jun 2016, Martin Basti wrote:
>
>
> On 06.06.2016 12:36, Alexander Bokovoy wrote:
>> Hi,
>>
>> MS-ADTS spec requires that TrustPartner field should be equal to the
>> commonName (cn) of the trust. We used it a bit wrongly to express
>> trust relationship between parent and child domains. In fact, we
>> have parent-child relationship recorded in the DN (child domains
>> are part of the parent domain's container).
>>
>> Remove the argument that was never used externally but only
>> supplied by
>> trust-specific code inside the IPA framework.
>>
>> Part of https://fedorahosted.org/freeipa/ticket/5354
>>
>>
>>
>
> Hello, how is handled backward compatibility here, you just removes
> the option from API, without any additional logic for older clients.
 This is not used by the external clients at all. It is part of internal
 logic of the code in trust.py+com.redhat.trust.fetch-domains which
 always talk to the same server they are running on.

 @register()
 class trustdomain_add(LDAPCreate):
  __doc__ = _('Allow access from the trusted domain')
  NO_CLI = True


>>>
>>> Yes sorry, not old IPA clients, but it was part of API, shown in API
>>> browser, and since this was in API, it is set to stone. So If you think
>>> that it is safe to be removed and nobody can hit this, I'm okay for
>>> removing that option. Maybe we should at least wrote it to release notes
>>> (I'll let Honza to express his feelings as API versioning/compatibility
>>> sensei)
>>
>> IMHO it is safe to remove.
>>
>>>
>>> And you forgot to increment api version in VERSION file
> Updated patch attached, with a VERSION change.
>
>
>
 ACK

>>>
>>> Is there any ticket for this?
>> As I wrote in the commit message and in the email,
>> it is part of https://fedorahosted.org/freeipa/ticket/5354
>>
> Sorry I misread that ticket in the commit message, because ipatool was unable
> to parse it from commit message
> 
> Pushed to master: 185806432d6dfccc5cdd73815471ce60a575b073

I see no link to this ticket in the commit message in
https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=185806432d6dfccc5cdd73815471ce60a575b073
Did you push old version of this patch?

In general, I would suggest using the patch format from
http://www.freeipa.org/page/Contribute/Patch_Format
It makes automation easier...

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

Re: [Freeipa-devel] [PATCH 0473-0476, 0478-0482]DNS Locations: Prologue

[Martin Kosek]

On 06/03/2016 12:51 PM, Martin Basti wrote:
> 
> 
> On 03.06.2016 08:53, Petr Spacek wrote:
>> On 2.6.2016 17:53, Martin Basti wrote:
>>> 
 Typo - redundant ' ' at the end.


 Conditional NACK, warnings mentioned in
 http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CLI
 are not there.

 I'm open to changing this to ACK if you open a separate ticket for this
 omission so we do not forget to add them later on.
>>> I forgot to add, this will be in next batch of patches (you may see that 
>>> there
>>> are not marked DNS servers in output of location show), I do not see reason 
>>> to
>>> open ticket when the current one is not finished.
>>>
>>> +1
>>>
 Done

>>> Patch 480:
>>>
>>> 1) The code in location_show.execute() looks like it could be moved to
>>> location_show.post_callback()
>>>
 I had to add it to execute because I modifies result entry not just
 entry_attrs

>>> 2) Before calling super().output_for_cli(), pop 'servers' from result, 
>>> so
>>> that
>>> it is not displayed with --all.
>>>
>>>
 Done

>>> Patch 481:
>>>
>>> 1) Could we rename --force to --nonempty (or something better)? I would
>>> like
>>> to reserve --force for "ignore NotFound when deleting the entry", which
>>> is not
>>> the case here.
>> IMHO option is unnecessary. Just delete the location (and unset location
>> from
>> all member servers). The design does not contain --force anyway :-)
> OK, that's even better :-)
>
 Done

 Updated patches attached
>> I had to add top object class to the plugin and tests to make tests pass.
>> Patch is attached.
>>
>> CondACK: Fix this before pushing somehow.
>>
> 
> Updated and heavily rebased patches attached.

Hi guys,

I saw the patches were merged, great! I just noticed that you added referential
integrity for dnslocation attribute. In that case, you will want to also add
QE, PRES index for it, to keep performance on reasonable level. Or was the
omission of index already discussed and justified?

Thanks,
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

Re: [Freeipa-devel] Questions on git

[Martin Kosek]

On 05/25/2016 11:55 AM, Christian Heimes wrote:
> On 2016-05-25 11:46, Martin Kosek wrote:
>> On 05/25/2016 10:03 AM, Jan Pazdziora wrote:
>>> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote:
>>>>
>>>> - I start working on a specific issue and decide to create a branch on my
>>>> git repository (on my laptop)
>>>> git clone git://git.fedorahosted.org/git/freeipa.git
>>>> git branch -b issue
>>>
>>> This likely needs to be
>>>
>>>  git checkout -b issue
>>>
>>>> - When the tests are ok and I want to submit a patch, can I stay on the
>>>> branch "issue" to create the patch or should I merge first with the main
>>>> branch? If a merge is required, is it recommended to pull then merge or
>>>> merge then pull?
>>>
>>> As mentioned by Martin, you are looking for rebase, not merge. Rebase
>>> will re-create commits from the branch on top of other branch (master,
>>> most likely), omitting changes that got to master in the mean time,
>>> and giving you chance to resolve conflicts with whatever other changes
>>> might have gone to master, so that others have as clean experience as
>>> possible.
>>>
>>> If you look at FreeIPA's history (I like gitk for that), you will see
>>> that merge commits are very rarely used. The reason for keeping the
>>> history linear (and thus rebasing on master often) is that it forces
>>> the author to be explicit about the diffs, plus git tools for
>>> introspecting history often choke on parallel branches that get
>>> merged.
>>
>> +1, we want to keep that. For example, even though we already had some
>> discussions about adopting github workflow (pull reuqests) as the main 
>> vehicle
>> for patch reviews, we would still prefer to avoid merging and keep rebasing -
>> the history is much cleaner that way.
> 
> +1 against merge commits
> 
> A couple of months ago github introduced a new option. The green merge
> button can be configured to either do a merge commit, squash all commits
> in the branch or both.
> https://help.github.com/articles/about-pull-request-merge-squashing/

Interesting. Do you know why github forces the squashing? It would be better if
we can simply have the commits rebased and applied to master branch.

> I guess we can use squashed merges for the majority of simple PRs.

I expect we will anyway end up with extending "ipatool push" command to do some
magic with github API, Trac and Bugzilla as we are used now. Except that it
won't accept list of patches in file, but rathe a link/PR number. But this is
of course up to dicsussion.

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

Re: [Freeipa-devel] Questions on git

[Martin Kosek]

On 05/25/2016 10:03 AM, Jan Pazdziora wrote:
> On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote:
>>
>> - I start working on a specific issue and decide to create a branch on my
>> git repository (on my laptop)
>> git clone git://git.fedorahosted.org/git/freeipa.git
>> git branch -b issue
> 
> This likely needs to be
> 
>  git checkout -b issue
> 
>> - When the tests are ok and I want to submit a patch, can I stay on the
>> branch "issue" to create the patch or should I merge first with the main
>> branch? If a merge is required, is it recommended to pull then merge or
>> merge then pull?
> 
> As mentioned by Martin, you are looking for rebase, not merge. Rebase
> will re-create commits from the branch on top of other branch (master,
> most likely), omitting changes that got to master in the mean time,
> and giving you chance to resolve conflicts with whatever other changes
> might have gone to master, so that others have as clean experience as
> possible.
> 
> If you look at FreeIPA's history (I like gitk for that), you will see
> that merge commits are very rarely used. The reason for keeping the
> history linear (and thus rebasing on master often) is that it forces
> the author to be explicit about the diffs, plus git tools for
> introspecting history often choke on parallel branches that get
> merged.

+1, we want to keep that. For example, even though we already had some
discussions about adopting github workflow (pull reuqests) as the main vehicle
for patch reviews, we would still prefer to avoid merging and keep rebasing -
the history is much cleaner that way.

-- 
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

Re: [Freeipa-devel] [PATCH 0094] Migrate from #ifndef guards to #pragma once

[Martin Kosek]

On 05/24/2016 04:29 PM, Nathaniel McCallum wrote:
> Using a pragma instead of guards is easier to write, less error prone
> and avoids name clashes (a source of very subtle bugs). This pragma
> is supported on almost all compilers, including all the compilers we
> care about: https://en.wikipedia.org/wiki/Pragma_once#Portability.
> 
> 
> 

Makes sense to me. I did not test, just saw a potential typo/omission:

--- a/daemons/ipa-otpd/internal.h
+++ b/daemons/ipa-otpd/internal.h
@@ -20,9 +20,6 @@
  * along with this program.  If not, see .
  */

-#ifndef INTERNAL_H_
-#define INTERNAL_H_
-


... no pragma there.

-- 
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

[Freeipa-devel] FreeIPA.org mediawiki upgraded to 1.26.3

[Martin Kosek]

Hi all,

As there was a security release of Mediawiki software and FreeIPA.org run an
obsoleted version of Mediawiki (1.24), I had to upgrade it to the latest and
greatest version - 1.26.3.

The upgrade is now live:
http://www.freeipa.org/page/Special:Version

If you have any issue with the wiki, please let me know.

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] Reviving FreeIPA translations

[Martin Kosek]

On 05/15/2016 09:34 PM, Yuri Chornoivan wrote:
> написане Sun, 15 May 2016 21:51:45 +0300, Martin Kosek :
> 
>> On 05/14/2016 01:29 PM, Yuri Chornoivan wrote:
>>> написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal :
>>>
>>>> 2016-05-13 13:32 GMT+02:00 Martin Kosek :
>>>>
>>>>> Hello,
>>>>>
>>>>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
>>>>> employee, which of course does not mean he cannot contribute to the 
>>>>> FreeIPA
>>>>> project, but that he won't have as much time for contributions as
>>>>> previously.
>>>>>
>>>>> One of Tomas' responsibilities was taking care of FreeIPA translations
>>>>> (Translation Maintainer role). As far as I know, there 2 main tasks
>>>>> associated
>>>>> with the Translation Maintainer role:
>>>>>
>>>>> 1) Periodically uploading new upstream strings to the FreeIPA translation
>>>>> platform of choice, which is the Fedora Zanata instance:
>>>>> https://fedora.zanata.org/project/view/freeipa
>>>>> The upload should happen periodically, on the right occasions, so that the
>>>>> translators (especially the French and Ukrainian translations which have
>>>>> 100%
>>>>> translated) have sufficient time to translate strings for the next version
>>>>> and
>>>>> do not have to translate it all in couple days before release. (This was
>>>>> one of
>>>>> the feedback I heard recently).
>>>>>
>>>>> 2) Downloading translated strings, Tomas added a short HowTo to our
>>>>> Release page:
>>>>> http://www.freeipa.org/page/Release#Translations
>>>>>
>>>>> We will need a new volunteer who would help doing 1) and 2) for the 
>>>>> planned
>>>>> releases and making sure this process runs. The first task would be
>>>>> uploading
>>>>> current strings in master as the next release is FreeIPA 4.4 planned for
>>>>> June,
>>>>> so it may be nice to already upload new strings we have in FreeIPA already
>>>>> to
>>>>> Zanata, so that they can be translated in sufficient time.
>>>>>
>>>>> Volunteer(s)?
>>>>>
>>>>> As part of the learning process, I think it would be useful to do more
>>>>> documentation of the steps taken in every translation life-cycle, current
>>>>> HowTo
>>>>> in Release page is rather vague. I for example did not find information
>>>>> how to
>>>>> work with translation versions that I saw defined in Zanata (branching may
>>>>> work
>>>>> similarly as in current FreeIPA git).
>>>>
>>>>
>>>> ​Thanks to the two volunteers​!
>>>>
>>>> Looking forward to see this happen!
>>>>
>>>> To reiterate on Martin K. message on uploads, I'd really like to see
>>>> regular strings uploads to the master branch in Zanata, say once a week or
>>>> every two weeks, so that translators can work on smaller strings batches.
>>>> "Release early, release oftem" :)
>>>>
>>>> And strings that would be translated twice in a short time span wouldn't be
>>>> entirely lost because they may stay in the Zanata translation memory and
>>>> could help translators finalizing dot releases if the specific branches in
>>>> Zanata.
>>>>
>>>> ​And if ​we can see the upload to master soon, translators can start
>>>> working now before the branch for the 4.4 June release.
>>>>
>>>> ​Regards,
>>>>
>>>> J.
>>>
>>> Hi,
>>>
>>> Similar thoughts here.
>>
>> Thanks for feedback!
>>
>>> Just a note on branches, I think that it is worth to keep the translation 
>>> just
>>> for the current release because keeping several branches on Zanata (or any
>>> other translation platform) is proved to be not effective from both sides,
>>> developers and translators.
>>
>> I see. My expectation would be that these branches would be only used if 
>> there
>> is a bug in the translation, not for active translation. The thing is, 
>> strings
>> in master may change or may be deleted, so they may no longer be 

Re: [Freeipa-devel] Reviving FreeIPA translations

[Martin Kosek]

On 05/14/2016 01:29 PM, Yuri Chornoivan wrote:
> написане Sat, 14 May 2016 12:57:13 +0300, Jérôme Fenal :
> 
>> 2016-05-13 13:32 GMT+02:00 Martin Kosek :
>>
>>> Hello,
>>>
>>> As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
>>> employee, which of course does not mean he cannot contribute to the FreeIPA
>>> project, but that he won't have as much time for contributions as
>>> previously.
>>>
>>> One of Tomas' responsibilities was taking care of FreeIPA translations
>>> (Translation Maintainer role). As far as I know, there 2 main tasks
>>> associated
>>> with the Translation Maintainer role:
>>>
>>> 1) Periodically uploading new upstream strings to the FreeIPA translation
>>> platform of choice, which is the Fedora Zanata instance:
>>> https://fedora.zanata.org/project/view/freeipa
>>> The upload should happen periodically, on the right occasions, so that the
>>> translators (especially the French and Ukrainian translations which have
>>> 100%
>>> translated) have sufficient time to translate strings for the next version
>>> and
>>> do not have to translate it all in couple days before release. (This was
>>> one of
>>> the feedback I heard recently).
>>>
>>> 2) Downloading translated strings, Tomas added a short HowTo to our
>>> Release page:
>>> http://www.freeipa.org/page/Release#Translations
>>>
>>> We will need a new volunteer who would help doing 1) and 2) for the planned
>>> releases and making sure this process runs. The first task would be
>>> uploading
>>> current strings in master as the next release is FreeIPA 4.4 planned for
>>> June,
>>> so it may be nice to already upload new strings we have in FreeIPA already
>>> to
>>> Zanata, so that they can be translated in sufficient time.
>>>
>>> Volunteer(s)?
>>>
>>> As part of the learning process, I think it would be useful to do more
>>> documentation of the steps taken in every translation life-cycle, current
>>> HowTo
>>> in Release page is rather vague. I for example did not find information
>>> how to
>>> work with translation versions that I saw defined in Zanata (branching may
>>> work
>>> similarly as in current FreeIPA git).
>>
>>
>> ​Thanks to the two volunteers​!
>>
>> Looking forward to see this happen!
>>
>> To reiterate on Martin K. message on uploads, I'd really like to see
>> regular strings uploads to the master branch in Zanata, say once a week or
>> every two weeks, so that translators can work on smaller strings batches.
>> "Release early, release oftem" :)
>>
>> And strings that would be translated twice in a short time span wouldn't be
>> entirely lost because they may stay in the Zanata translation memory and
>> could help translators finalizing dot releases if the specific branches in
>> Zanata.
>>
>> ​And if ​we can see the upload to master soon, translators can start
>> working now before the branch for the 4.4 June release.
>>
>> ​Regards,
>>
>> J.
> 
> Hi,
> 
> Similar thoughts here.

Thanks for feedback!

> Just a note on branches, I think that it is worth to keep the translation just
> for the current release because keeping several branches on Zanata (or any
> other translation platform) is proved to be not effective from both sides,
> developers and translators.

I see. My expectation would be that these branches would be only used if there
is a bug in the translation, not for active translation. The thing is, strings
in master may change or may be deleted, so they may no longer be applied to the
branched FreeIPA x.y.z releases. So practically, we would not be able to update
the translations for branched release once we branch.

Do you see that expected and acceptable?

> It is a matter of just two commands (one for extraction and "zanata push" for
> pushing the catalog to Zanata). So, personally, I'd like to see the updates as
> soon as possible (something close to continuous integration). This allows us,
> translators, to react on any glitches in the initial strings and make the
> releases perfect.

I think this can be done, there is just the risk that some strings would be
added during master development and changed later when the code is revisited,
but I assume this is expected by you - correct?

> It would be good if each release preparation process is close to the
> libguestfs's one:
> 
> http://libguestfs.org/guestfs-hacking.1.html#making-a-stable-release
> 
> Just my 2 cents.

Thanks for the tip!

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

[Freeipa-devel] I plan to delete my FreeIPA COPR repos

[Martin Kosek]

Hi all,

When we were starting building FreeIPA in the Fedora COPR service [1], the
service did not support the organizations as it can do now and we did the
official repos in my personal name space [2] as I was the common denominator
for the project at the time.

However, since that time, COPR support supports organizations, we created the
FreeIPA organization [3] and do the official builds there. FreeIPA should have
all currently supported repos, usually around 4.3 and master FreeIPA versions.

Now, is anyone still using any of my FreeIPA related repos? Can I delete them
so that it does not confuse people about what is the official repo? Comparing
what I see in FreeIPA organization repos and personal repos, the FreeIPA
organization miss FreeIPA 4.0 and 4.1 versions, but I think these can be safely
removed.

So my current plan is to delete all my personal FreeIPA repos unless I hear any
blocker. So please holler if you depend on some of my repos.

[1] https://copr.fedorainfracloud.org
[2] https://copr.fedorainfracloud.org/coprs/mkosek/
[3] https://copr.fedorainfracloud.org/groups/g/freeipa/coprs/

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

[Freeipa-devel] Reviving FreeIPA translations

[Martin Kosek]

Hello,

As you may or may not know, Tomas Babej left the FreeIPA team as a Red Hat
employee, which of course does not mean he cannot contribute to the FreeIPA
project, but that he won't have as much time for contributions as previously.

One of Tomas' responsibilities was taking care of FreeIPA translations
(Translation Maintainer role). As far as I know, there 2 main tasks associated
with the Translation Maintainer role:

1) Periodically uploading new upstream strings to the FreeIPA translation
platform of choice, which is the Fedora Zanata instance:
https://fedora.zanata.org/project/view/freeipa
The upload should happen periodically, on the right occasions, so that the
translators (especially the French and Ukrainian translations which have 100%
translated) have sufficient time to translate strings for the next version and
do not have to translate it all in couple days before release. (This was one of
the feedback I heard recently).

2) Downloading translated strings, Tomas added a short HowTo to our Release 
page:
http://www.freeipa.org/page/Release#Translations

We will need a new volunteer who would help doing 1) and 2) for the planned
releases and making sure this process runs. The first task would be uploading
current strings in master as the next release is FreeIPA 4.4 planned for June,
so it may be nice to already upload new strings we have in FreeIPA already to
Zanata, so that they can be translated in sufficient time.

Volunteer(s)?

As part of the learning process, I think it would be useful to do more
documentation of the steps taken in every translation life-cycle, current HowTo
in Release page is rather vague. I for example did not find information how to
work with translation versions that I saw defined in Zanata (branching may work
similarly as in current FreeIPA git).

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] Provisioning throughput

[Martin Kosek]

On 05/12/2016 04:16 PM, Ludwig Krispenz wrote:
> 
> On 05/12/2016 03:45 PM, Ludwig Krispenz wrote:
>>
>> On 05/12/2016 02:16 PM, Petr Vobornik wrote:
>>> On 05/10/2016 05:50 PM, thierry bordaz wrote:

 On 05/05/2016 03:44 PM, Petr Vobornik wrote:
> On 05/04/2016 02:20 PM, thierry bordaz wrote:
>> Hello,
>>
>>   I have been doing some tests/measures using
>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.
>>
>>   The tool creates a set of typical users/hosts/groups... to
>> import with a
>>   ldapadd.
>>
>>   I wrote down some finding in
>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.
>>
>>
>>   I still have to do some cleanup around the performance but the
>> basic of a
>>   possible improvement is to do provisioning in several steps
>> (disabling
>>   plugins, provisioning, enabling plugin, running fixup tasks).
>>
>>   Before going further in the design I wanted to share those ideas
>> and know if
>>   it raise any concern.
>>
>>   thanks
>>   thierry
>>
> Hi Thierry,
>
> Thanks for the analysis. Very nice.
>
> Knowing this will help us suggesting workarounds also for old releases.
>
> Couple questions:
>
> Have you tested retrCL disabled with memberOf enabled. It seems that it
> would eliminate 550K adds and 0.8M searches. What would be the time
> improvement?
>
> Do you know what is the time when memberof is enabled but slapi-nis and
> retroCL are disabled?
 The culprit of the performance issue is very likely related to SRCH
 (internal) triggered by memberof.

 If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
 If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
 14.8
 When all of them are enabled the #SRCH is 15M.

 You are right if retroCL is disabled the #ADD drops but it has no
 significant effect on the duration.
>>> ok, thanks for the analysis
>>>
 Regarding the duration of the provisioning, values are not really stable
 as performance of VM fluctuates. But as soon as memberof is enabled the
 provisioning lasts > 4hours where the same provisioning lasts 6mins as
 soon as memberof is disabled.

 I need to confirm the average time for internal searches but assuming
 1ms per SRCH it consumes >90% of the provisioning.


>   From the text it was not clear to me, if you find or investigate
> possible improvements in memberof plugin which would improve the
> performance without stopping and starting DS.
>>> As was discussed at mtg, have you tried if the DS restart is really
>>> necessary?
>> memberof plugin can be enabled and disabled while the server is running, BUT
>> to achieve this the "enable-dynamic-plugins" feature has to be turned on. And
>> then any enable/disable of a plugin would try to do it dynamically an dnot
>> wait for the restart.
>> And I think not all plugins are able to handle this, TomasB was once working
>> on it for IPA plugins, but it was not completed as far as I know
> but enabling dynamic plugins can be done without restart, so what can be done 
> is.
> - enable dynamic plugins
> - disable memberof
> - do some work
> - enable memberof
> - disable dynamic plugins

Please see
https://fedorahosted.org/freeipa/ticket/4203#comment:9
I do not think this will be that easy. We would first need to invest into
updating FreeIPA plugins to work with dynamic plugins setting and then we could
do things alike above.

It looks like that for FreeIPA 4.4, we will need to live with DS restart unless
there is some workaround...

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

Re: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile

[Martin Kosek]

On 05/12/2016 12:56 AM, Fraser Tweedale wrote:
> On Wed, May 11, 2016 at 04:36:34PM +0200, Jan Cholasta wrote:
>> On 11.5.2016 15:04, Fraser Tweedale wrote:
>>> On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote:
...
 3) I would rather avoid adding new commands just to work around bugs. IMO
 "certprofile-import caIPAserviceCert
 /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this
 case.

>>> As discussed above, I'm afraid it is not, unless users manually do
>>> the substitutions.  If we provide some code to do the substitutions,
>>> we have essentially reach what I have proposed.
>>>
>>> Other suggestions are welcome.
>>>
>>> BTW, there is another option I did not already mention: do nothing
>>> in code, and help users on a case-by-case basis / point them to a
>>> guide / KB article?
>>
>> This option is my favorite :-) (If automatic fix during upgrade is indeed
>> out of the picture.)
>>
> Martin, if the profile is incorrect, do we have to fix it
> automatically?  What are our obligations / customer expectations
> here?

I would love to hear customer expectations, but in that case you should ask the
users/customers, not me :-) But having documented procedure in a KB/wiki
article how to fix a broken profile seems as a good enough for me, we can build
the API command later if we see a pressing need.

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

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Martin Kosek]

On 04/18/2016 10:31 AM, Martin Kosek wrote:
> On 04/08/2016 05:10 PM, Martin Babinsky wrote:
>> Hi list,
>>
>> I have put together a draft [1] outlining the effort to reimplement the
>> handling of Kerberos principals in both backend and frontend layers of 
>> FreeIPA
>> so that we may have multiple aliases per user, host or service and thus
>> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and
>> https://fedorahosted.org/freeipa/ticket/5413 .
>>
>> Since much of the plumbing was already implemented,[2] the document mainly
>> describes what the patches do. Some parts required by other use cases may be
>> missing so please point these out.
>>
>> I would also be happy if you could correct all factual inacurracies, I did
>> research on this issue a long time ago and my knowledge turned a bit rusty.
>>
>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
>> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html
> 
> Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also
> see that you are using the Kerberos attributes in the raw name
> ("--krbprincipalname"). This is not consistent with the CLI form when they are
> used in other commands:
> 
> ...
> Str('krbprincipalname?', validate_principal,
> cli_name='principal',
> label=_('Kerberos principal'),
> default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm),
> autofill=True,
> flags=['no_update'],
> normalizer=lambda value: normalize_principal(value),
> ),
> DateTime('krbprincipalexpiration?',
> cli_name='principal_expiration',
> label=_('Kerberos principal expiration'),
> ),
> ...
> 
> IMO, it should be rather "--principal" and "--principal-alias".
> 
> Martin
> 

Bump.

-- 
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

Re: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity).

[Martin Kosek]

On 05/02/2016 02:28 PM, David Kupka wrote:
> https://fedorahosted.org/freeipa/ticket/2795

That patch looks suspiciously short given the struggles I saw in
http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html
:-)

Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid filling
"krbPasswordExpiration" attribute at all, i.e. have password *without*
expiration? Or is krbPasswordExpiration mandatory?

-- 
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

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Martin Kosek]

On 04/08/2016 05:10 PM, Martin Babinsky wrote:
> Hi list,
> 
> I have put together a draft [1] outlining the effort to reimplement the
> handling of Kerberos principals in both backend and frontend layers of FreeIPA
> so that we may have multiple aliases per user, host or service and thus
> implement stuff like https://fedorahosted.org/freeipa/ticket/3961 and
> https://fedorahosted.org/freeipa/ticket/5413 .
> 
> Since much of the plumbing was already implemented,[2] the document mainly
> describes what the patches do. Some parts required by other use cases may be
> missing so please point these out.
> 
> I would also be happy if you could correct all factual inacurracies, I did
> research on this issue a long time ago and my knowledge turned a bit rusty.
> 
> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
> [2] https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html

Thanks! Looking on the planned API/CLI, besides the typo ("prinicpal"), I also
see that you are using the Kerberos attributes in the raw name
("--krbprincipalname"). This is not consistent with the CLI form when they are
used in other commands:

...
Str('krbprincipalname?', validate_principal,
cli_name='principal',
label=_('Kerberos principal'),
default_from=lambda uid: '%s@%s' % (uid.lower(), api.env.realm),
autofill=True,
flags=['no_update'],
normalizer=lambda value: normalize_principal(value),
),
DateTime('krbprincipalexpiration?',
cli_name='principal_expiration',
label=_('Kerberos principal expiration'),
),
...

IMO, it should be rather "--principal" and "--principal-alias".

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

Re: [Freeipa-devel] URI in HBAC - design page

[Martin Kosek]

On 03/24/2016 01:24 PM, Jan Pazdziora wrote:
> On Thu, Mar 24, 2016 at 12:38:37PM +0100, Martin Kosek wrote:
>> On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
>>> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
>> ...
>>> You present two solutions to the problem -- deny rules, and regular
>>> expressions.
>>
>> For the record, HBAC deny rules is something we will want to avoid. Deny HBAC
> 
> Certainly. And for the current HBAC's model of user (groups), host
> (groups), service (groups), you can tell the admin to structure their
> environment and groups in such a way that they are not needed.

Right.

> But the question is, if you want for the admin to be able to control
> access to a website where longer URLs often need to be more restricted
> than the shorter ones, what mechanism do you propose? It is not
> possible to positively (for allow purposes) list only exhaustive list
> of URL prefixes that should have the broader access allowed -- new
> versions of the web application can introduce additional URLs into the
> namespace, and the URLs are not identities like users or hosts that
> FreeIPA would be aware of that that you could easily manage by putting
> them to groups.

I agree it is complicated. While Deny HBAC rules is something we do not want,
allowing exclusive rules for an HBAC URI rule may be acceptable. This would be
the same approach we chose with Exclusive Time rules in Time-Based HBAC:

http://www.freeipa.org/page/V4/Time-Based_Account_Policies#Time_Policies_Storage

For the URI identifiers, we should also try to reinvent the wheel here. Can
adopt an approach used in some of the most common frameworks for URL matching?
Take Django for example:

https://docs.djangoproject.com/en/1.9/topics/http/urls/

Using the pattern approach you mentioned elsewhere could work, I am just
worried how much user friendly it would be for non-developers. But we can also
make use these patterns as the raw storage format and build some nice UI/CLI on
top of it.

> The natural way to think about access to web URLs is to say "I only
> want admins to access /application/users/admin/". Which of course
> means "I want to deny everyone who has otherwise access to other URLs,
> except for admins".

Can we do the same as with current default "allow all" rule? I.a. allow "/" for
all sites by default and let admin to remove that for sites with access
controlled and restricted by FreeIPA HBAC. This would mean admin would
typically need to define some general rule the site accessible by all with the
exceptions defined in "exclude" access rules and then build the rules specific
to these excluded parts of the application URL tree.

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

Re: [Freeipa-devel] URI in HBAC - design page

[Martin Kosek]

On 03/24/2016 10:24 AM, Jan Pazdziora wrote:
> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote:
...
> You present two solutions to the problem -- deny rules, and regular
> expressions.

For the record, HBAC deny rules is something we will want to avoid. Deny HBAC
rules were removed in the past for good reasons:

https://www.redhat.com/archives/freeipa-users/2011-June/msg00256.html
https://fedorahosted.org/freeipa/ticket/1432

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

Re: [Freeipa-devel] URI in HBAC - design page

[Martin Kosek]

On 03/23/2016 04:41 PM, Lukáš Hellebrandt wrote:
> I created a design page for the feature:
> 
> http://www.freeipa.org/page/URI-based-HBAC-design

Technicality update:

- I changed the name and moved it to consistent location:
http://www.freeipa.org/page/V4/URI-based_HBAC

- I removed "version=0.1" from the "Feature box", so that design appears in the
right category:
http://www.freeipa.org/index.php?title=Category:FreeIPA_Design_Proposal
FIY - the version denotes the target version of the FreeIPA (when accepted) and
not version of the design.

-- 
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

Re: [Freeipa-devel] [DRAFT] FreeIPA 4.3.1 release notes

[Martin Kosek]

On 03/22/2016 06:35 PM, Petr Vobornik wrote:
> Hello all,
> 
> I prepared the release notes on FreeIPA.org wiki:
> http://www.freeipa.org/page/Releases/4.3.1
> 
> Updates or improvements to release notes page welcome. Particularly if
> you think some bug fixes/improvements deserves to be noted out as a
> highlight, please give a suggestion or edit the page directly

I would suggest to mention links to tickets and not just numbers. It will
provide much better user experience when somebody is interested for more 
details.

This is the "magic" I used:
$ sed -r 's/#([0-9]+)/[https:\/\/fedorahosted.org\/freeipa\/ticket\/\1 #\1]/g'
/tmp/highlights.txt

I also did minor updates to the highlights.

HTH,
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

Re: [Freeipa-devel] [DESIGN] Server Roles

[Martin Kosek]

On 03/18/2016 03:43 PM, Martin Babinsky wrote:
> On 03/18/2016 02:44 PM, Petr Vobornik wrote:
>> On 03/18/2016 10:59 AM, Martin Kosek wrote:
>>> On 03/18/2016 10:47 AM, Martin Babinsky wrote:
>>>> On 03/18/2016 10:21 AM, Martin Kosek wrote:
>>>>> On 03/17/2016 06:16 PM, Martin Babinsky wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP
>>>>>> design
>>>>>> document concerning the concept of Server Roles as a user-friendly
>>>>>> abstraction
>>>>>> of the services running on IPA masters.
>>>>>>
>>>>>> The main aim of this feature is to provide a higher level interface
>>>>>> to query
>>>>>> and manipulate service-related information stored in dirsrv backend.
>>>>>>
>>>>>> I have not touched the design much from the post-Devconf session,
>>>>>> mainly
>>>>>> because there are some points to clarify and agree upon.
>>>>>
>>>>> Initial thoughts:
>>>>>
>>>>> * Use Cases: these are rather vague points what you want to
>>>>> implement. In Use
>>>>> Case section, I would like to see what specific *user* use cases you
>>>>> are
>>>>> addressing, i.e. what user problems you are solving. Ideally in a
>>>>> form of a
>>>>> user story. Like here:
>>>>>
>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
>>>>> or here:
>>>>> http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
>>>>> or here:
>>>>> http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases
>>>>>
>>>> Ok I will thing of some clearer points.
>>>>
>>>>>> I have the following points to discuss:
>>>>>>
>>>>>> 1.) the design assumes that there is a distinction between roles
>>>>>> such as DNS
>>>>>> server, CA, etc. and the more specific sub-roles such as DNSSec key
>>>>>> master, CRL
>>>>>> master, etc. Now in the hindsight I think this distinction is quite
>>>>>> artificial
>>>>>> and just clutters the interface unnecessarily. We might implement
>>>>>> this kind of
>>>>>> hierarchy in the code itself but that is something the user needs
>>>>>> not be
>>>>>> aware of.
>>>>>
>>>>> Well, there are dependencies. A server cannot be a CRL master
>>>>> without also
>>>>> being a CA role. I assume same applies to DNSSEC master.
>>>>>
>>>>> I think we need to think more about distinguishing what is role,
>>>>> what is just
>>>>> an attribute of a role, etc. AD for example distinguishes roles,
>>>>> role service
>>>>> and features:
>>>>>
>>>>> https://technet.microsoft.com/en-us/library/cc754923.aspx
>>>>>
>>>> We will have to implement the role/subrole/unicorn hierarchy anyhow.
>>>> What I
>>>> would like to discuss is whether it is necessary to expose this
>>>> hierarchy to
>>>> the users. Consider a case when user wants to find which server is a
>>>> CA renewal
>>>> master:
>>>>
>>>> ipa server-role-find "CA renewal master"
>>>>
>>>> vs.
>>>>
>>>> ipa server-role-find --subrole "Renewal master"
>>>>
>>>> Behind the scenes, the code has to do the same thing (e.g. issue a
>>>> search using
>>>> (&(cn=CA)(ipaConfigString=enabledService)(ipaConfigString=caRenewalMaster))),
>>>>
>>>> but the UX is a bit different.
>>>
>>> Well, even the LDAP structure is different in this case. CA role is an
>>> object
>>> in cn=masters, caRenewalMaster is it's property. So they will likely be
>>> different user objects too.
>>>
>>> For your example, I can image a search like that:
>>>
>>> $ ipa server-role-find "CA" --subrole "renewal-master"
>>>
>>> (for the case when you have "DNS" role also with "renewal-master"
>>> sub-role).
>>>
>>> Martin
>>>
>>
>>

Re: [Freeipa-devel] [DESIGN] Server Roles

[Martin Kosek]

On 03/18/2016 03:58 PM, Simo Sorce wrote:
> On Fri, 2016-03-18 at 15:28 +0100, Petr Vobornik wrote:
>> On 03/18/2016 02:59 PM, Simo Sorce wrote:
...
>> Use cases I see:
>> 1. Administrator wants to know which servers are configured with 
>> CA|KRA|DNS.
>> 2. Administrator wants to know which server is CRL master.
>> 3. We want this info to be able to display it in topology graph (but 
>> this is for 4.5).
> 
> Ack, ack and ack.

+1. *This* is what I was looking for in the Design page Use Case section, that
I mentioned in my first reply. The rest of the design page should be written
with these use cases in mind.

>> Should there be an NTP server role?
> 
> Probably.
> 

-- 
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

Re: [Freeipa-devel] [DESIGN] Server Roles

[Martin Kosek]

On 03/18/2016 10:47 AM, Martin Babinsky wrote:
> On 03/18/2016 10:21 AM, Martin Kosek wrote:
>> On 03/17/2016 06:16 PM, Martin Babinsky wrote:
>>> Hi list,
>>>
>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP design
>>> document concerning the concept of Server Roles as a user-friendly 
>>> abstraction
>>> of the services running on IPA masters.
>>>
>>> The main aim of this feature is to provide a higher level interface to query
>>> and manipulate service-related information stored in dirsrv backend.
>>>
>>> I have not touched the design much from the post-Devconf session, mainly
>>> because there are some points to clarify and agree upon.
>>
>> Initial thoughts:
>>
>> * Use Cases: these are rather vague points what you want to implement. In Use
>> Case section, I would like to see what specific *user* use cases you are
>> addressing, i.e. what user problems you are solving. Ideally in a form of a
>> user story. Like here:
>>
>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
>> or here:
>> http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
>> or here:
>> http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases
>>
> Ok I will thing of some clearer points.
> 
>>> I have the following points to discuss:
>>>
>>> 1.) the design assumes that there is a distinction between roles such as DNS
>>> server, CA, etc. and the more specific sub-roles such as DNSSec key master, 
>>> CRL
>>> master, etc. Now in the hindsight I think this distinction is quite 
>>> artificial
>>> and just clutters the interface unnecessarily. We might implement this kind 
>>> of
>>> hierarchy in the code itself but that is something the user needs not be
>>> aware of.
>>
>> Well, there are dependencies. A server cannot be a CRL master without also
>> being a CA role. I assume same applies to DNSSEC master.
>>
>> I think we need to think more about distinguishing what is role, what is just
>> an attribute of a role, etc. AD for example distinguishes roles, role service
>> and features:
>>
>> https://technet.microsoft.com/en-us/library/cc754923.aspx
>>
> We will have to implement the role/subrole/unicorn hierarchy anyhow. What I
> would like to discuss is whether it is necessary to expose this hierarchy to
> the users. Consider a case when user wants to find which server is a CA 
> renewal
> master:
> 
> ipa server-role-find "CA renewal master"
> 
> vs.
> 
> ipa server-role-find --subrole "Renewal master"
> 
> Behind the scenes, the code has to do the same thing (e.g. issue a search 
> using
> (&(cn=CA)(ipaConfigString=enabledService)(ipaConfigString=caRenewalMaster))),
> but the UX is a bit different.

Well, even the LDAP structure is different in this case. CA role is an object
in cn=masters, caRenewalMaster is it's property. So they will likely be
different user objects too.

For your example, I can image a search like that:

$ ipa server-role-find "CA" --subrole "renewal-master"

(for the case when you have "DNS" role also with "renewal-master" sub-role).

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

Re: [Freeipa-devel] [DESIGN] Server Roles

[Martin Kosek]

On 03/17/2016 06:16 PM, Martin Babinsky wrote:
> Hi list,
> 
> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP design
> document concerning the concept of Server Roles as a user-friendly abstraction
> of the services running on IPA masters.
> 
> The main aim of this feature is to provide a higher level interface to query
> and manipulate service-related information stored in dirsrv backend.
> 
> I have not touched the design much from the post-Devconf session, mainly
> because there are some points to clarify and agree upon.

Initial thoughts:

* Use Cases: these are rather vague points what you want to implement. In Use
Case section, I would like to see what specific *user* use cases you are
addressing, i.e. what user problems you are solving. Ideally in a form of a
user story. Like here:

http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
or here:
http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
or here:
http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases

> I have the following points to discuss:
> 
> 1.) the design assumes that there is a distinction between roles such as DNS
> server, CA, etc. and the more specific sub-roles such as DNSSec key master, 
> CRL
> master, etc. Now in the hindsight I think this distinction is quite artificial
> and just clutters the interface unnecessarily. We might implement this kind of
> hierarchy in the code itself but that is something the user needs not be 
> aware of.

Well, there are dependencies. A server cannot be a CRL master without also
being a CA role. I assume same applies to DNSSEC master.

I think we need to think more about distinguishing what is role, what is just
an attribute of a role, etc. AD for example distinguishes roles, role service
and features:

https://technet.microsoft.com/en-us/library/cc754923.aspx

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

Re: [Freeipa-devel] [PATCH] 0050 caacl: correctly handle full user principal name

[Martin Kosek]

On 03/14/2016 06:18 AM, Alexander Bokovoy wrote:
> On Mon, 14 Mar 2016, Fraser Tweedale wrote:
>> The attached patch fixes
>> https://fedorahosted.org/freeipa/ticket/5733.  Thanks to Alexander
>> for finding and reporting.
>>
>> Cheers,
>> Fraser
> 
>> From 9bd7b74d9c928f386bd7dae59588580881ed1a9d Mon Sep 17 00:00:00 2001
>> From: Fraser Tweedale 
>> Date: Mon, 14 Mar 2016 14:49:47 +1100
>> Subject: [PATCH] caacl: correctly handle full user principal name
>>
>> The caacl HBAC request is correct when just the username is given,
>> but the full 'user@REALM' form was not handled correctly.
>>
>> Fixes: https://fedorahosted.org/freeipa/ticket/5733
> A context might be helpful here: if you are using certmonger's -K option
> to specify a user principal name to add to certificate, the name will
> get normalized to include the realm. This is how it gets to caacl check.
> 
> ACK.

Seeing the patch, I am curious - is the realm validated anywhere pr is it just
dropped and we just assume it is FreeIPA one?

I mean, do we make sure that REALM matches FreeIPA REALM and it is not trusted
AD realm for example?

-- 
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

Re: [Freeipa-devel] [PATCH 0434] log: add timestamp to filename of logs

[Martin Kosek]

On 03/11/2016 09:55 AM, Jan Cholasta wrote:
> On 11.3.2016 09:33, Martin Kosek wrote:
>> On 03/08/2016 07:07 PM, Martin Basti wrote:
>>>
>>>
>>> On 08.03.2016 16:37, Martin Basti wrote:
>>>>
>>>>
>>>> On 08.03.2016 16:31, Martin Basti wrote:
>>>>> https://fedorahosted.org/freeipa/ticket/4501
>>>>>
>>>>> Patch attached.
>>>>>
>>>>>
>>>> Rebased patch attached.
>>>>
>>>>
>>>
>>> self-NACK
>>>
>>> Scripts print to CLI unformatted strings, it should not be so easy.
>>> See /var/log/ipaupgrade-{timestamp}.log for more information
>>
>> second-NACK. We cannot break existing log file paths. The paths are mentioned
>> in a documentation and there may be also automation around that (gathering 
>> log
>> files). So there should be always symlink from the well known location to the
>> newest timestampe'd log.
> 
> Sorry, but this is absurd. What's the point of maintaining backward
> compatibility with obsolete documentation? Following this logic, we would not
> be able to change anything ever. What we should actually do is update the
> documentation. Ditto for automation.

+1 for updating the automation and documentation. But some backward
compatibility will need to be retained, at least for the stable systems like
RHEL where *other* people may have some automation or documentation around it,
not just us.

-- 
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

Re: [Freeipa-devel] [PATCH 0434] log: add timestamp to filename of logs

[Martin Kosek]

On 03/08/2016 07:07 PM, Martin Basti wrote:
> 
> 
> On 08.03.2016 16:37, Martin Basti wrote:
>>
>>
>> On 08.03.2016 16:31, Martin Basti wrote:
>>> https://fedorahosted.org/freeipa/ticket/4501
>>>
>>> Patch attached.
>>>
>>>
>> Rebased patch attached.
>>
>>
> 
> self-NACK
> 
> Scripts print to CLI unformatted strings, it should not be so easy.
> See /var/log/ipaupgrade-{timestamp}.log for more information

second-NACK. We cannot break existing log file paths. The paths are mentioned
in a documentation and there may be also automation around that (gathering log
files). So there should be always symlink from the well known location to the
newest timestampe'd log.

-- 
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

Re: [Freeipa-devel] [PATCH 0067-0069] Various IPA log fixes

[Martin Kosek]

On 03/10/2016 03:44 PM, Rob Crittenden wrote:
> Gabe Alford wrote:
>> Hello,
>>
>> Attached patches fix the following tickets related to IPA log files:
>>
>> https://fedorahosted.org/freeipa/ticket/5724
>> https://fedorahosted.org/freeipa/ticket/5726
>> https://fedorahosted.org/freeipa/ticket/5727
>>
>> Patch 0067 should be applied first, and patch 0069 applied last.
>>
> 
> NACK. The location is also in the man pages and referenced in at least
> the server install script.

Right. Also, before the admins get used to the new locations, we should provide
symlinks from current locations to the new log files. If there are log files
with timestamp, the symlink can point to the most recent log file.

This would prevent admins running currenet Fedora, RHEL, CentOS or other
distributions to still access the log files as they are used to.

-- 
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

Re: [Freeipa-devel] [PATCH 0137] spec: add conflict with bind-chroot to freeipa-server-dns

[Martin Kosek]

On 03/07/2016 03:17 PM, Petr Spacek wrote:
> On 7.3.2016 13:27, Jan Cholasta wrote:
>> Hi,
>>
>> On 7.3.2016 12:47, Martin Babinsky wrote:
>>> https://fedorahosted.org/freeipa/ticket/5696
>>
>> Shouldn't we rather fix IPA to work with bind running in chroot (which is
>> AFAIK considered good security practice)?
> 
> I would not invest into it:
> http://www.freeipa.org/page/Howto/FreeIPA_with_integrated_BIND_inside_chroot#NOTE:_Chroot_should_not_be_considered_a_security_feature

+1

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

Re: [Freeipa-devel] French translation for FreeIPA

[Martin Kosek]

On 03/07/2016 12:57 PM, Lukas Slebodnik wrote:
> On (07/03/16 12:20), Martin Kosek wrote:
>> On 03/07/2016 11:48 AM, Jérôme Fenal wrote:
>>> 2016-02-29 18:45 GMT+01:00 Jérôme Fenal :
>>>
>>>> Hi all,
>>>>
>>>> Just a quick note to let you that I completed the translation of what
>>>> was available to translate on Zanata.
>>>>
>>>> Can you please check it passes the QA, that the strings available on
>>>> Zanata are the latest ones, and that it can flow back into RHEL7?
>>>>
>>>
>>> ​Hello there,
>>>
>>> No news good news, or everybody is swamped in BZs? :-)​
>>
>> Hi Jérôme,
>>
>> Thanks for the translation! The new strings should get to FreeIPA 4.3.1, 
>> right
>> Tomas?
> FreeIPA 4.2.x will be released sooner :-)
> Do you plan to include new translation there?

As we do not have branches with our translations, I am actually not sure adding
new translations there is a good idea, there may be too big differences with
current master in Zanata and what is in FreeIPA 4.2.x.

Tomas should know better than I.

-- 
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

Re: [Freeipa-devel] French translation for FreeIPA

[Martin Kosek]

On 03/07/2016 11:48 AM, Jérôme Fenal wrote:
> 2016-02-29 18:45 GMT+01:00 Jérôme Fenal :
> 
>> Hi all,
>>
>> Just a quick note to let you that I completed the translation of what
>> was available to translate on Zanata.
>>
>> Can you please check it passes the QA, that the strings available on
>> Zanata are the latest ones, and that it can flow back into RHEL7?
>>
> 
> ​Hello there,
> 
> No news good news, or everybody is swamped in BZs? :-)​

Hi Jérôme,

Thanks for the translation! The new strings should get to FreeIPA 4.3.1, right
Tomas?

As for RHEL, there is not special process around adding the translated strings.
The new ones should get there whenever the FreeIPA is rebased.

-- 
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

Re: [Freeipa-devel] Feature template - proposed changes

[Martin Kosek]

On 03/04/2016 03:59 PM, Petr Spacek wrote:
> On 4.3.2016 15:23, Martin Kosek wrote:
>> On 03/04/2016 03:11 PM, Petr Spacek wrote:
>>> Hello,
>>>
>>> I've updated Feature template to make sure that important the design 
>>> decisions
>>> are recorded somewhere.
>>>
>>> Of course all this is open for discussion. I did this soon because I believe
>>> that it is better to actually see how it looks like instead of discussing
>>> vaporware. Wiki has revert button if necessary, feel free to use it.
>>>
>>> New texts:
>>> http://www.freeipa.org/page/Feature_template#Design_Assumptions
>>
>> Looks good to me.
>>
>>> http://www.freeipa.org/page/Feature_template#Use_Cases
>>
>> Does not look good to me. Practical examples of how features is used is in 
>> How
>> to Test section, ideally organized by Use Cases, like in
>> http://www.freeipa.org/page/V4/User_Certificates#How_to_Test
>>
>> If we start adding gory details and examples right in Use Cases section, we
>> would kill the clarity of that section that intends to just give you overview
>> of the use cases.
> 
> Okay, now I understand that.
> Funnily enough the only thing I changed is addition of bullet "* Explicitly
> list use cases which were considered but will not supported for some reason.
> Include the reason, too ;-)"
> 
> The text you are criticizing is there from the very first version of the page
> [2012-07-24T21:09:49 as can be seen on
> http://www.freeipa.org/index.php?title=Feature_template&oldid=5161].

Heh, sorry the extra rant then - I will therefore blame Rob instead ;-) In all
seriousness, we should clarify that in this Feature template improvement 
session.

> 
>> I would rather imagine something like
>>
>> http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authentication_on_Selected_System
>>
>> which is an impromptu format for the new User Story based approach. The
>> expectations is that rest of the page will then work with these User
>> Stories/Use Cases, whether it is Design, How To Test, UI examples or Test 
>> Plan.
> 
> Agreed.
> 
> 
>>> I also did one unrelated change:
>>> Now "Feature Management" chapter precedes "Design" chapter with all the gory
>>> details. This should make the page more useful for random users who find it
>>> using a search engine.
>>>
>>> Intents:
>>> 1. Consider usability *very* early in the design process.
>>> 2. Think about LDAP schema support for UI workflows very early.
>>
>> These are good intents. However, while I agree with the intents, I am curious
>> how this is supposed to work, because the CLI/UI often works with the terms
>> that are being defined in Design.
>>
>> See for example here:
>> http://www.freeipa.org/page/V4/User_Certificates#Feature_Management
>> It already assumes you know some parts of the design, like matching 
>> attribute.
>>
>> Or:
>> http://www.freeipa.org/page/V4/OTP#Feature_Management
>> It already assumes you know what OTP token is, what Radius Proxy server is 
>> and
>> how it relates, etc.
> 
> Well, that points to an interesting problem of user interface design.
> 
> Is the user assumed to read the *design* page before using the feature (so he
> knows the terms as you pointed out)? If it is true then we failed
> spectacularly at providing usable user interfaces.
> 
> Looking at
> https://www.nngroup.com/articles/ten-usability-heuristics/
> second principle:
> 
> # Match between system and the real world
> ## The system should speak the users' language, with words, phrases and
> concepts familiar to the user, rather than system-oriented terms. Follow
> real-world conventions, making information appear in a natural and logical 
> order.
> 
> 
> My understanding to this is that terms should be 'the usual' terms used in
> given field. FreeIPA did not invent neither of OTP, RADIUS, DNS, PKI, AD etc.
> 
> Interface should be self-describing. If it is not then we failed. If there is
> hard to understand but standard terminology, link to an external article and
> do not spend time on describing it 25th time (most likely using slightly
> inconsistent terms).
> 
> Obviously there will be exceptions but wiki has hyperlinks so this can be
> handled if absolutely necessary.

Hmm, that's a good point. I am not completely sold yet as I kind of liked the
original logical flow of the design page. But I think we will see that on the
first non-trivial example of design page.

Maybe you could hane

Re: [Freeipa-devel] [WIP] Time-Based HBAC Policies

[Martin Kosek]

On 03/04/2016 03:39 PM, Stanislav Laznicka wrote:
> Based on Alexander's suggestion  I created a copr repo with latest
> python-icalendar version.
> 
> https://copr.fedorainfracloud.org/coprs/stlaz/python-icalendar/packages/

Thanks. When we get to end-to-end functionality (again), it should again make
sense to have a repo including all changes packages, including freeipa and sssd.

-- 
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

Re: [Freeipa-devel] Feature template - proposed changes

[Martin Kosek]

On 03/04/2016 03:11 PM, Petr Spacek wrote:
> Hello,
> 
> I've updated Feature template to make sure that important the design decisions
> are recorded somewhere.
> 
> Of course all this is open for discussion. I did this soon because I believe
> that it is better to actually see how it looks like instead of discussing
> vaporware. Wiki has revert button if necessary, feel free to use it.
> 
> New texts:
> http://www.freeipa.org/page/Feature_template#Design_Assumptions
> http://www.freeipa.org/page/Feature_template#Use_Cases

On top of what Petr proposed, I would also like to propose new
"Troubleshooting" section that were often asked for by people supporting our
users or advising on the lists.

I would imagine we would specify any specific, logs, log levels or procedures
that could help people investigate what's wrong with the feature.

The SSSD project implemented that as "How To Debug" section, see here:
https://fedorahosted.org/sssd/wiki/PageTemplates/FeatureDesign

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

[Freeipa-devel] Proposing design template changes (Re: Feature template - proposed changes)

[Martin Kosek]

On 03/04/2016 03:11 PM, Petr Spacek wrote:
> Hello,
> 
> I've updated Feature template to make sure that important the design decisions
> are recorded somewhere.
> 
> Of course all this is open for discussion. I did this soon because I believe
> that it is better to actually see how it looks like instead of discussing
> vaporware. Wiki has revert button if necessary, feel free to use it.

Just for the record, I would be cautious when changing such an impactful page
like Design Template. Your way, if somebody now copies the Feature template,
he/she would be basing the design work on a template proposal that was not
discussed yet and that is subject to change.

I believe the Mediawiki approach for that is User name space, where you can do
the proposal by copying this page without affecting the "production design
template":

https://www.mediawiki.org/wiki/Help:Namespaces#User

Just 2 cents. Let me know if there is better way than what I proposed.

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

Re: [Freeipa-devel] Feature template - proposed changes

[Martin Kosek]

On 03/04/2016 03:11 PM, Petr Spacek wrote:
> Hello,
> 
> I've updated Feature template to make sure that important the design decisions
> are recorded somewhere.
> 
> Of course all this is open for discussion. I did this soon because I believe
> that it is better to actually see how it looks like instead of discussing
> vaporware. Wiki has revert button if necessary, feel free to use it.
> 
> New texts:
> http://www.freeipa.org/page/Feature_template#Design_Assumptions

Looks good to me.

> http://www.freeipa.org/page/Feature_template#Use_Cases

Does not look good to me. Practical examples of how features is used is in How
to Test section, ideally organized by Use Cases, like in
http://www.freeipa.org/page/V4/User_Certificates#How_to_Test

If we start adding gory details and examples right in Use Cases section, we
would kill the clarity of that section that intends to just give you overview
of the use cases.

I would rather imagine something like

http://www.freeipa.org/page/V4/Authentication_Indicators#Strong_Authentication_on_Selected_System

which is an impromptu format for the new User Story based approach. The
expectations is that rest of the page will then work with these User
Stories/Use Cases, whether it is Design, How To Test, UI examples or Test Plan.

> I also did one unrelated change:
> Now "Feature Management" chapter precedes "Design" chapter with all the gory
> details. This should make the page more useful for random users who find it
> using a search engine.
> 
> Intents:
> 1. Consider usability *very* early in the design process.
> 2. Think about LDAP schema support for UI workflows very early.

These are good intents. However, while I agree with the intents, I am curious
how this is supposed to work, because the CLI/UI often works with the terms
that are being defined in Design.

See for example here:
http://www.freeipa.org/page/V4/User_Certificates#Feature_Management
It already assumes you know some parts of the design, like matching attribute.

Or:
http://www.freeipa.org/page/V4/OTP#Feature_Management
It already assumes you know what OTP token is, what Radius Proxy server is and
how it relates, etc.

> DNS locations proved that UI is a nightmare which is better to think about in
> the very beginning, even before thinking about LDAP schema.
> 
> I hope it will help in long term.

While it may make sense to *think* about the interfaces first, why does it also
have to be in the design page as the first thing, given it breaks the natural
and logical flow of the text?

-- 
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

Re: [Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

On 03/04/2016 02:30 PM, Alexander Bokovoy wrote:
> On Fri, 04 Mar 2016, Martin Kosek wrote:
>> On 03/04/2016 01:09 PM, Alexander Bokovoy wrote:
>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>> On 03/04/2016 12:59 PM, Alexander Bokovoy wrote:
>>>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>>>> On 03/04/2016 10:10 AM, Alexander Bokovoy wrote:
>>>>>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>>>>>> Hi Alexander and others,
>>>>>>>>
>>>>>>>> As you know, SSSD 1.13.4 added support of reading the native SUDO tree
>>>>>>>> [1].
>>>>>>>> This means that FreeIPA deployments with all clients being SSSD 1.13.4 
>>>>>>>> or
>>>>>>>> older
>>>>>>>> will be able to disable the sudoers schema compatiblity tree
>>>>>>>> (cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).
>>>>>>>>
>>>>>>>> Right now, I am only aware of an attribute tu disable the whole Schema
>>>>>>>> Compat
>>>>>>>> plugin (exposed via ipa-compat-manage tool), but this would not fly for
>>>>>>>> people
>>>>>>>> with legacy clients reading from Compat tree.
>>>>>>>>
>>>>>>>> I am thinking, is there an easy way we can recommend to admins on how
>>>>>>>> to do
>>>>>>>> disable just certain Schema Compatibility rules? Ideally having a 
>>>>>>>> config
>>>>>>>> options something like:
>>>>>>>>
>>>>>>>> schema-compat-enabled: on|off
>>>>>>>>
>>>>>>>> That could be changed via ldapmodify.
>>>>>>>>
>>>>>>>> [1] https://fedorahosted.org/sssd/ticket/1108
>>>>>>> There is nothing like that in slapi-nis. If you want to remove container
>>>>>>> configuration, you just remove it.
>>>>>>>
>>>>>>> So, doing as DM 'ldapdelete "cn=sudoers,cn=Schema
>>>>>>> Compatibility,cn=plugins,cn=config"'
>>>>>>> is our simplest way.
>>>>>>>
>>>>>>> One can create an update file for ipa-ldap-updater, for example:
>>>>>>> --8<--8<--8<--8<--8<--8<--8<--
>>>>>>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>>>>> deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>>>>> -->8-->8-->8-->8-->8-->8-->8--
>>>>>>>
>>>>>>> and then run it as ipa-ldap-updater ./89-remove-sudo-compat-tree.update
>>>>>>
>>>>>> This is what I was afraid of...
>>>>>>
>>>>>>> I'm not sure if running server upgrade would not restore the
>>>>>>> configuration, though.
>>>>>>
>>>>>> I think it would.
>>>>>>
>>>>>>> On the other hand, if no users are going to use the configuration, it
>>>>>>> should not hurt anymore to have it enabled. With current slapi-nis state
>>>>>>> there should be no problems anymore.
>>>>>>
>>>>>> Well, slapi-nis will still maintain the memory cache, AFAIK.
>>>>>>
>>>>>> How difficult would it be to implement
>>>>>>
>>>>>> schema-compat-enabled: on|off
>>>>>>
>>>>>> ? It seems to me as the best way forward.
>>>>> The attribute itself is not hard to implement. It is much more complex
>>>>> to ensure the map is ignored if disabled.
>>>>
>>>> Even if we require 389-ds-base restart after this configuration? I would 
>>>> guess
>>>> that it should be then easy to simply ignore the disabled rule and do not
>>>> load it.
>>> It is not about restart. slapi-nis has long supported changing
>>> configuration on flight. You don't need to restart 389-ds on removal of
>>> the configuration.
>>>
>>> Removing this feature is certainly not welcomed.
>>>
>>> My observation about the complexity is basically questioning the need to
>>> do such switch at all -- by working on the switch we are delaying work
>>> on slapi-nis successor.
>>
>> My point is that if we do not have a nice and easy way of disabling the 
>> Schema
>> Compat rules, the whole value of not using Schema Compat trees by SSSD is
>> lower, as we cannot save the memory and CPU for 389-ds-base in maintaining 
>> this
>> extra trees - right?
>>
>> As you talk about the slapi-nis successor, is there any technical way of a
>> short-term approach that would let us do the proposed, before we get the
>> successor?
> Give me some time to look what I can do.

Thank you. First, we should just assess how much it would cost and that would
enable us compare the costs and benefits and choose to either wait for the
slapi-nis successor or do something now.

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

Re: [Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

On 03/04/2016 01:09 PM, Alexander Bokovoy wrote:
> On Fri, 04 Mar 2016, Martin Kosek wrote:
>> On 03/04/2016 12:59 PM, Alexander Bokovoy wrote:
>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>> On 03/04/2016 10:10 AM, Alexander Bokovoy wrote:
>>>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>>>> Hi Alexander and others,
>>>>>>
>>>>>> As you know, SSSD 1.13.4 added support of reading the native SUDO tree 
>>>>>> [1].
>>>>>> This means that FreeIPA deployments with all clients being SSSD 1.13.4 or
>>>>>> older
>>>>>> will be able to disable the sudoers schema compatiblity tree
>>>>>> (cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).
>>>>>>
>>>>>> Right now, I am only aware of an attribute tu disable the whole Schema
>>>>>> Compat
>>>>>> plugin (exposed via ipa-compat-manage tool), but this would not fly for
>>>>>> people
>>>>>> with legacy clients reading from Compat tree.
>>>>>>
>>>>>> I am thinking, is there an easy way we can recommend to admins on how to 
>>>>>> do
>>>>>> disable just certain Schema Compatibility rules? Ideally having a config
>>>>>> options something like:
>>>>>>
>>>>>> schema-compat-enabled: on|off
>>>>>>
>>>>>> That could be changed via ldapmodify.
>>>>>>
>>>>>> [1] https://fedorahosted.org/sssd/ticket/1108
>>>>> There is nothing like that in slapi-nis. If you want to remove container
>>>>> configuration, you just remove it.
>>>>>
>>>>> So, doing as DM 'ldapdelete "cn=sudoers,cn=Schema
>>>>> Compatibility,cn=plugins,cn=config"'
>>>>> is our simplest way.
>>>>>
>>>>> One can create an update file for ipa-ldap-updater, for example:
>>>>> --8<--8<--8<--8<--8<--8<--8<--
>>>>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>>> deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>>>> -->8-->8-->8-->8-->8-->8-->8--
>>>>>
>>>>> and then run it as ipa-ldap-updater ./89-remove-sudo-compat-tree.update
>>>>
>>>> This is what I was afraid of...
>>>>
>>>>> I'm not sure if running server upgrade would not restore the
>>>>> configuration, though.
>>>>
>>>> I think it would.
>>>>
>>>>> On the other hand, if no users are going to use the configuration, it
>>>>> should not hurt anymore to have it enabled. With current slapi-nis state
>>>>> there should be no problems anymore.
>>>>
>>>> Well, slapi-nis will still maintain the memory cache, AFAIK.
>>>>
>>>> How difficult would it be to implement
>>>>
>>>> schema-compat-enabled: on|off
>>>>
>>>> ? It seems to me as the best way forward.
>>> The attribute itself is not hard to implement. It is much more complex
>>> to ensure the map is ignored if disabled.
>>
>> Even if we require 389-ds-base restart after this configuration? I would 
>> guess
>> that it should be then easy to simply ignore the disabled rule and do not
>> load it.
> It is not about restart. slapi-nis has long supported changing
> configuration on flight. You don't need to restart 389-ds on removal of
> the configuration.
> 
> Removing this feature is certainly not welcomed.
> 
> My observation about the complexity is basically questioning the need to
> do such switch at all -- by working on the switch we are delaying work
> on slapi-nis successor.

My point is that if we do not have a nice and easy way of disabling the Schema
Compat rules, the whole value of not using Schema Compat trees by SSSD is
lower, as we cannot save the memory and CPU for 389-ds-base in maintaining this
extra trees - right?

As you talk about the slapi-nis successor, is there any technical way of a
short-term approach that would let us do the proposed, before we get the 
successor?

-- 
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

Re: [Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

On 03/04/2016 12:59 PM, Alexander Bokovoy wrote:
> On Fri, 04 Mar 2016, Martin Kosek wrote:
>> On 03/04/2016 10:10 AM, Alexander Bokovoy wrote:
>>> On Fri, 04 Mar 2016, Martin Kosek wrote:
>>>> Hi Alexander and others,
>>>>
>>>> As you know, SSSD 1.13.4 added support of reading the native SUDO tree [1].
>>>> This means that FreeIPA deployments with all clients being SSSD 1.13.4 or
>>>> older
>>>> will be able to disable the sudoers schema compatiblity tree
>>>> (cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).
>>>>
>>>> Right now, I am only aware of an attribute tu disable the whole Schema 
>>>> Compat
>>>> plugin (exposed via ipa-compat-manage tool), but this would not fly for 
>>>> people
>>>> with legacy clients reading from Compat tree.
>>>>
>>>> I am thinking, is there an easy way we can recommend to admins on how to do
>>>> disable just certain Schema Compatibility rules? Ideally having a config
>>>> options something like:
>>>>
>>>> schema-compat-enabled: on|off
>>>>
>>>> That could be changed via ldapmodify.
>>>>
>>>> [1] https://fedorahosted.org/sssd/ticket/1108
>>> There is nothing like that in slapi-nis. If you want to remove container
>>> configuration, you just remove it.
>>>
>>> So, doing as DM 'ldapdelete "cn=sudoers,cn=Schema
>>> Compatibility,cn=plugins,cn=config"'
>>> is our simplest way.
>>>
>>> One can create an update file for ipa-ldap-updater, for example:
>>> --8<--8<--8<--8<--8<--8<--8<--
>>> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>> deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
>>> -->8-->8-->8-->8-->8-->8-->8--
>>>
>>> and then run it as ipa-ldap-updater ./89-remove-sudo-compat-tree.update
>>
>> This is what I was afraid of...
>>
>>> I'm not sure if running server upgrade would not restore the
>>> configuration, though.
>>
>> I think it would.
>>
>>> On the other hand, if no users are going to use the configuration, it
>>> should not hurt anymore to have it enabled. With current slapi-nis state
>>> there should be no problems anymore.
>>
>> Well, slapi-nis will still maintain the memory cache, AFAIK.
>>
>> How difficult would it be to implement
>>
>> schema-compat-enabled: on|off
>>
>> ? It seems to me as the best way forward.
> The attribute itself is not hard to implement. It is much more complex
> to ensure the map is ignored if disabled.

Even if we require 389-ds-base restart after this configuration? I would guess
that it should be then easy to simply ignore the disabled rule and do not load 
it.

-- 
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

Re: [Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

On 03/04/2016 10:10 AM, Alexander Bokovoy wrote:
> On Fri, 04 Mar 2016, Martin Kosek wrote:
>> Hi Alexander and others,
>>
>> As you know, SSSD 1.13.4 added support of reading the native SUDO tree [1].
>> This means that FreeIPA deployments with all clients being SSSD 1.13.4 or 
>> older
>> will be able to disable the sudoers schema compatiblity tree
>> (cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).
>>
>> Right now, I am only aware of an attribute tu disable the whole Schema Compat
>> plugin (exposed via ipa-compat-manage tool), but this would not fly for 
>> people
>> with legacy clients reading from Compat tree.
>>
>> I am thinking, is there an easy way we can recommend to admins on how to do
>> disable just certain Schema Compatibility rules? Ideally having a config
>> options something like:
>>
>> schema-compat-enabled: on|off
>>
>> That could be changed via ldapmodify.
>>
>> [1] https://fedorahosted.org/sssd/ticket/1108
> There is nothing like that in slapi-nis. If you want to remove container
> configuration, you just remove it.
> 
> So, doing as DM 'ldapdelete "cn=sudoers,cn=Schema
> Compatibility,cn=plugins,cn=config"'
> is our simplest way.
> 
> One can create an update file for ipa-ldap-updater, for example:
> --8<--8<--8<--8<--8<--8<--8<--
> dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
> deleteentry: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
> -->8-->8-->8-->8-->8-->8-->8--
> 
> and then run it as ipa-ldap-updater ./89-remove-sudo-compat-tree.update

This is what I was afraid of...

> I'm not sure if running server upgrade would not restore the
> configuration, though.

I think it would.

> On the other hand, if no users are going to use the configuration, it
> should not hurt anymore to have it enabled. With current slapi-nis state
> there should be no problems anymore.

Well, slapi-nis will still maintain the memory cache, AFAIK.

How difficult would it be to implement

schema-compat-enabled: on|off

? It seems to me as the best way forward.

-- 
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

[Freeipa-devel] Disabling Schema Compatibility rule

[Martin Kosek]

Hi Alexander and others,

As you know, SSSD 1.13.4 added support of reading the native SUDO tree [1].
This means that FreeIPA deployments with all clients being SSSD 1.13.4 or older
will be able to disable the sudoers schema compatiblity tree
(cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config).

Right now, I am only aware of an attribute tu disable the whole Schema Compat
plugin (exposed via ipa-compat-manage tool), but this would not fly for people
with legacy clients reading from Compat tree.

I am thinking, is there an easy way we can recommend to admins on how to do
disable just certain Schema Compatibility rules? Ideally having a config
options something like:

schema-compat-enabled: on|off

That could be changed via ldapmodify.

[1] https://fedorahosted.org/sssd/ticket/1108

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Martin Kosek]

On 02/29/2016 11:35 PM, Nathaniel McCallum wrote:

On Fri, 2016-02-26 at 09:00 +0100, Martin Kosek wrote:

On 02/25/2016 10:51 PM, Simo Sorce wrote:


On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:


On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:


On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:



On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:




On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum
wrote:




On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:





On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum
wrote:






https://github.com/npmccallum/freeipa/pull/1

The above (pseudo) pull request contains four patches
against
FreeIPA
to enable the insertion of Authentication Indicators
into
Kerberos
tickets. The basic flow looks like this.

First, we patch ipa-pwd-extop to return a control
indicating
what
authentication method succeeded resulting in a
successful
bind.

Second, we patch ipa-otpd to check the returned
control to
ensure
that
the bind resulted from an otp validation.

Third, we patch ipa-kdb to enable the KDC to return
either
the
encrypted timestamp or encrypted challenge preauth
mechanism
when
the
user is configured for optional 2FA logins. Clients
can
then
decide
whether to do 1FA or 2FA login (for kinit, sane
behavior
already
exists).

Forth, we patch ipa-kdb again to insert hard-coded
authentication
indicators for either OTP or RADIUS.

Some explanation is required for the first two
patches.
Currently,
it
is possible to do a 1FA through the otp
preauthentication
mechanism
if
the user is configured for doing optional 2FA.
However,
because
we
want
to insert an authentication indicator in this code
path, we
need
to
guarantee that a request going through the otp
preauth
mechanism
actually validates an OTP. This is the purpose of the
control.

Items still on the TODO list:

   * Authentication Indicator enforcement
 - Upstream libkrb5 needs to grow funcs for
reading
indicators
 - Schema change to add indicators multi-value
attr to
services
 - ipa-kdb needs to implement check_policy_tgs()


   * SSSD needs to learn to handle optional 2FA

I will write up a project page for all of this
tomorrow.
But
this
small
code basically amounts to my brainstorming. It is not
ready
for
merge,
just basic review.


It looks mostly ok, however the LDAP control part needs
to be
done
as
a
request/response pair.
A client that wishes to know what kind of
authentication
happened
should
send a request control, and only in that case , the
server
will
send
the
associated reply control with the requested
information.

I just pushed a new version of the control (now merged
into a
single
patch): https://github.com/npmccallum/freeipa/commit/a781
91ee5d
31
e1de
39
f28eb637f66199da7e9225

In this version the client sends a critical control with
no
content
indicating that the server must validate an OTP. If the
LDAP
server
doesn't support the control (for whatever reason), bind
will
fail. If
the LDAP server doesn't validate an OTP (for whatever
reason),
bind
will fail.

This approach is simpler and doesn't require a
request/response
control
pair.

I need some design advice. My goal here is that we need a
way to
expose
the authentication indicators to services in the FreeIPA
UI/CLI.

Here is the good news: users can already set these values
in
FreeIPA
using kadmin. They do this by simply setting the
require_auth
string on
the target service principal. Our kdb plugin then encodes
these
with
the rest of the tl_data into the krbExtraData attribute.

I see two approaches here. First, we can try to manipulate
the
krbExtraData attribute directly. Second, we can create a
separate
attribute for the authentication indicator strings and then
synthesize
the tl_data internally in kdb. We would have to do this for
both
reads
and writes so as not to break existing kdb functionality.

The trade-off that I see is that the first method
complicates the
python framework side where the second method complicates
the kdb
plugin.

A third option, which I doubt is even possible, is to use
kadmin
to
manipulate this option rather than modifying LDAP directly.

Thoughts?

We should translate it, we need that to allow to delegate
access
only
to
the specific attribute via our standard means.

We already do this for other tl_data entries.

The krbExtraData access cannot always be delegated because it
would
be
open ended. also it is really obnoxious to have to manipulate
ASN.1
stuff in the framework.

kadmin could be used at some point, but we'd still want to
have
this
attribute extracted in order to be able to grant access
control
individually, as our ACL system and delegation system is more
fine
grained than what kadmin can offer.

After discussing this with MIT, Simo and Matt, it seems that
the best
option is to update the (MIT) upstream krbPrincipal objectClass
to
have
a new attribute. The reason for this is twofold. First, it has
upstream
value. Second

Re: [Freeipa-devel] [PATCH] 0001 Adding URL to HBAC rule

[Martin Kosek]

On 02/26/2016 04:38 PM, Lukáš Hellebrandt wrote:
> On 02/26/2016 01:30 PM, Martin Kosek wrote:
>> Greetings, welcome!
>>
>> On 02/26/2016 01:17 PM, Lukáš Hellebrandt wrote:
>> ...
>>> Btw, is there some better place to share patches than a pasting tool?
>>> Maybe some form of pull request?
>>
>> There is :-) Please see advise here:
>>
>> http://www.freeipa.org/page/Contribute/Code#Submit_a_patch
>>
>> It has more information on top of submitting patches. For example, I think it
>> would actually make sense to start with a design page where you would 
>> describe
>> the use cases, design, APIs, etc:
>>
>> http://www.freeipa.org/page/Contribute/Code#Prepare
>>
>> Martin
>>
> 
> Should I send it as an attachment?

Right.

> Ok, sending, but do not apply it yet
> (even if you don't find bugs), I just need some feedback - not
> everything is done yet.

The patch looks OK, but there is not much in the patch anyway, yet. But as I
written above I would suggest starting with a design document you share with
the other developers, so that you can be given an advise and feedback regarding
the approach and overall design.

-- 
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

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Martin Kosek]

Greetings, welcome!

On 02/26/2016 01:17 PM, Lukáš Hellebrandt wrote:
...
> Btw, is there some better place to share patches than a pasting tool?
> Maybe some form of pull request?

There is :-) Please see advise here:

http://www.freeipa.org/page/Contribute/Code#Submit_a_patch

It has more information on top of submitting patches. For example, I think it
would actually make sense to start with a design page where you would describe
the use cases, design, APIs, etc:

http://www.freeipa.org/page/Contribute/Code#Prepare

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

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Martin Kosek]

On 02/25/2016 10:51 PM, Simo Sorce wrote:
> On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:
>> On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:
>>> On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:

 On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:
>
>
> On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote:
>>
>>
>> On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
>>>
>>>
>>>
>>> On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote:




 https://github.com/npmccallum/freeipa/pull/1

 The above (pseudo) pull request contains four patches
 against
 FreeIPA
 to enable the insertion of Authentication Indicators into
 Kerberos
 tickets. The basic flow looks like this.

 First, we patch ipa-pwd-extop to return a control
 indicating
 what
 authentication method succeeded resulting in a successful
 bind.

 Second, we patch ipa-otpd to check the returned control to
 ensure
 that
 the bind resulted from an otp validation.

 Third, we patch ipa-kdb to enable the KDC to return either
 the
 encrypted timestamp or encrypted challenge preauth
 mechanism
 when
 the
 user is configured for optional 2FA logins. Clients can
 then
 decide
 whether to do 1FA or 2FA login (for kinit, sane behavior
 already
 exists).

 Forth, we patch ipa-kdb again to insert hard-coded
 authentication
 indicators for either OTP or RADIUS.

 Some explanation is required for the first two patches.
 Currently,
 it
 is possible to do a 1FA through the otp preauthentication
 mechanism
 if
 the user is configured for doing optional 2FA. However,
 because
 we
 want
 to insert an authentication indicator in this code path, we
 need
 to
 guarantee that a request going through the otp preauth
 mechanism
 actually validates an OTP. This is the purpose of the
 control.

 Items still on the TODO list:

   * Authentication Indicator enforcement
 - Upstream libkrb5 needs to grow funcs for reading
 indicators
 - Schema change to add indicators multi-value attr to
 services
 - ipa-kdb needs to implement check_policy_tgs()


   * SSSD needs to learn to handle optional 2FA

 I will write up a project page for all of this tomorrow.
 But
 this
 small
 code basically amounts to my brainstorming. It is not ready
 for
 merge,
 just basic review.

>>> It looks mostly ok, however the LDAP control part needs to be
>>> done
>>> as
>>> a
>>> request/response pair.
>>> A client that wishes to know what kind of authentication
>>> happened
>>> should
>>> send a request control, and only in that case , the server
>>> will
>>> send
>>> the
>>> associated reply control with the requested information.
>> I just pushed a new version of the control (now merged into a
>> single
>> patch): https://github.com/npmccallum/freeipa/commit/a78191ee5d
>> 31
>> e1de
>> 39
>> f28eb637f66199da7e9225
>>
>> In this version the client sends a critical control with no
>> content
>> indicating that the server must validate an OTP. If the LDAP
>> server
>> doesn't support the control (for whatever reason), bind will
>> fail. If
>> the LDAP server doesn't validate an OTP (for whatever reason),
>> bind
>> will fail.
>>
>> This approach is simpler and doesn't require a request/response
>> control
>> pair.
> I need some design advice. My goal here is that we need a way to
> expose
> the authentication indicators to services in the FreeIPA UI/CLI.
>
> Here is the good news: users can already set these values in
> FreeIPA
> using kadmin. They do this by simply setting the require_auth
> string on
> the target service principal. Our kdb plugin then encodes these
> with
> the rest of the tl_data into the krbExtraData attribute.
>
> I see two approaches here. First, we can try to manipulate the
> krbExtraData attribute directly. Second, we can create a separate
> attribute for the authentication indicator strings and then
> synthesize
> the tl_data internally in kdb. We would have to do this for both
> reads
> and writes so as not to break existing kdb functionality.
>
> The trade-off that I see is that the first method complicates the
> python f

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Martin Kosek]

On 02/23/2016 06:59 PM, Petr Spacek wrote:
> On 23.2.2016 18:14, Simo Sorce wrote:
...
>> More seriously I think it is a great idea, but too premature to get all
>> the way there now. We need to build schema and CLI that will allow us to
>> get there without having to completely change interfaces if at all
>> possible or minimizing any disruption in the tools.
> 
> Actually the backwards compatibility is the main worry which led to this idea
> with links.
> 
> If we release first version of locations with custom priorities etc. we will
> have support the schema (which will be different) and API (which will be later
> unnecessary) forever.
> 
> If we skip this intermediate phase with hand-made configuration we can save
> all the headache with upgrades to more automatic solution later on.
> 
> 
> Maybe we should invert the order:
> Start with locations + links with administrative metric and add hand-tweaking
> capabilities later (if necessary).
> 
> IMHO locations + links with administrative metric will be easier to implement
> than the first version.
> 
> Just thinking aloud ...

Makes sense to me, I would have the same worry as Petr, that we would break
something if we decide moving to links based solution later.

-- 
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

Re: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir.

[Martin Kosek]

On 02/23/2016 09:47 AM, David Kupka wrote:
> On 22/02/16 16:15, Martin Kosek wrote:
>> On 02/22/2016 04:04 PM, Jan Cholasta wrote:
>>> On 22.2.2016 15:56, David Kupka wrote:
>>>> On 22/02/16 07:28, Jan Cholasta wrote:
>>>>> On 18.2.2016 10:10, David Kupka wrote:
>>>>>> On 19/01/16 16:10, David Kupka wrote:
>>>>>>> On 19/01/16 14:38, Jan Cholasta wrote:
>>>>>>>> On 19.1.2016 14:26, Martin Kosek wrote:
>>>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote:
>>>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen.
>>>>>>>>>>
>>>>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed
>>>>>>>>>> unused import
>>>>>>>>>> but otherwise it works, ACK.
>>>>>>>>>>
>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586
>>>>>>>>>
>>>>>>>>> Won't this break existing certmonger requests depending on the old
>>>>>>>>> path?
>>>>>>>>
>>>>>>>> It will, I don't see any upgrade code.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger'
>>>>>>>>>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>>>> "auditSigningCert
>>>>>>>>> cert-pki-ca"
>>>>>>>>>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>>>> "ocspSigningCert
>>>>>>>>> cert-pki-ca"
>>>>>>>>>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>>>> "subsystemCert
>>>>>>>>> cert-pki-ca"
>>>>>>>>>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>>>> "caSigningCert
>>>>>>>>> cert-pki-ca"
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
>>>>>>>>>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>>>> "Server-Cert
>>>>>>>>> cert-pki-ca"
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
>>>>>>>>> RHEL72
>>>>>>>>>  post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> You're right it will break the upgrade. I haven't noticed that
>>>>>>> Server-Cert for DS and HTTPD are not handled by
>>>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all
>>>>>>> the other trackings are stopped and then configured again with the
>>>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated.
>>>>>>>
>>>>>>> Thanks for the catch.
>>>>>>>
>>>>>>
>>>>>> I've updated Timo's patch little more and added
>>>>>> start_tracking_certificates() for dsinstance and httpinstance. Now the
>>>>>> upgrade works as expected.
>>>>>
>>>>> The way the patches are split is kind of weird and apparently confusing
>>>>> (see the other thread). IMO there should be 2 patches: the first should
>>>>> add the ability to change DS and HTTP certmonger config during upgrade
>>>>> (i.e. the start_tracking_certificates() methods and
>>>>> certificate_renewal_update() changes), the second should move the
>>>>> helpers (i.e. the actual move and certificate_renewal_update() version
>>>>> bump).
>>>>>
>>>> Honza, do I understand it correctly that the code is OK but I did not
>>>> split it to the patches correctly?
>>>
>>> Yes.
>>
>> Before acking or pushing, can you please explain for me how the upgrade of
>> certmonger tracking requests work? I want to make sure this is right, so 
>> please
>> bear with me:
>>
>> 1) How does it edit existing tracking requests with the new helper paths?
>>
>> 2) Does it go and try to edit the requests on every upgrade? Or is there some
>> check that requests were updated?
>>
>> Thanks,
>> Martin
>>
> 
> Whole upgrade of renewal requests is done in
> ipaserver/install/server/upgrade.py in certificate_renewal_upgrade().
> 
> First there is version of requests and if it's the same as in state file
> upgrade is skipped.
> Then every request is searched over certmonger's DBus interface and if at 
> least
> one is not found it means that there was change in request configuration. All
> tracking requests are then stopped and started again with new configuration.
> 
> So to answer you questions:
> 1) By stopping the old request with the old parameters (including path) and
> starting new with new parameters.
> 
> 2) Only if version was bumped which happens only if some of the requests 
> changes.

Ah, so IIUC, if you bump the version, requests should be properly updated. The
change looks fine then.

-- 
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

Re: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir.

[Martin Kosek]

On 02/22/2016 04:04 PM, Jan Cholasta wrote:
> On 22.2.2016 15:56, David Kupka wrote:
>> On 22/02/16 07:28, Jan Cholasta wrote:
>>> On 18.2.2016 10:10, David Kupka wrote:
>>>> On 19/01/16 16:10, David Kupka wrote:
>>>>> On 19/01/16 14:38, Jan Cholasta wrote:
>>>>>> On 19.1.2016 14:26, Martin Kosek wrote:
>>>>>>> On 01/19/2016 01:47 PM, David Kupka wrote:
>>>>>>>> I've polished the patch attached to #5586 by Timo Aaltonen.
>>>>>>>>
>>>>>>>> Thanks for the patch. I've fixed the path in specfile and removed
>>>>>>>> unused import
>>>>>>>> but otherwise it works, ACK.
>>>>>>>>
>>>>>>>> https://fedorahosted.org/freeipa/ticket/5586
>>>>>>>
>>>>>>> Won't this break existing certmonger requests depending on the old
>>>>>>> path?
>>>>>>
>>>>>> It will, I don't see any upgrade code.
>>>>>>
>>>>>>>
>>>>>>> # getcert list | grep '/usr/lib64/ipa/certmonger'
>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>> "auditSigningCert
>>>>>>> cert-pki-ca"
>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>> "ocspSigningCert
>>>>>>> cert-pki-ca"
>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>> "subsystemCert
>>>>>>> cert-pki-ca"
>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>> "caSigningCert
>>>>>>> cert-pki-ca"
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
>>>>>>> pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
>>>>>>> "Server-Cert
>>>>>>> cert-pki-ca"
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
>>>>>>> RHEL72
>>>>>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> You're right it will break the upgrade. I haven't noticed that
>>>>> Server-Cert for DS and HTTPD are not handled by
>>>>> certificate_renewal_update (ipaserver.install.server.upgrade) where all
>>>>> the other trackings are stopped and then configured again with the
>>>>> paths.CERTMONGER_COMMAND_TEMPLATE already updated.
>>>>>
>>>>> Thanks for the catch.
>>>>>
>>>>
>>>> I've updated Timo's patch little more and added
>>>> start_tracking_certificates() for dsinstance and httpinstance. Now the
>>>> upgrade works as expected.
>>>
>>> The way the patches are split is kind of weird and apparently confusing
>>> (see the other thread). IMO there should be 2 patches: the first should
>>> add the ability to change DS and HTTP certmonger config during upgrade
>>> (i.e. the start_tracking_certificates() methods and
>>> certificate_renewal_update() changes), the second should move the
>>> helpers (i.e. the actual move and certificate_renewal_update() version
>>> bump).
>>>
>> Honza, do I understand it correctly that the code is OK but I did not
>> split it to the patches correctly?
> 
> Yes.

Before acking or pushing, can you please explain for me how the upgrade of
certmonger tracking requests work? I want to make sure this is right, so please
bear with me:

1) How does it edit existing tracking requests with the new helper paths?

2) Does it go and try to edit the requests on every upgrade? Or is there some
check that requests were updated?

Thanks,
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

Re: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins

[Martin Kosek]

On 02/19/2016 03:14 PM, Alexander Bokovoy wrote:
> On Fri, 19 Feb 2016, Martin Kosek wrote:
>>>> Why trust-add?
>>>>
>>>> I'm not a big fan of cluttering existing commands(find, show, mod) with 
>>>> logic
>>>> to fix one upgrade bug. But I understand a need to communicate it somehow.
>>>>
>>>> Would it make sense to move such logic to a separate command, e.g.
>>>> trust-check/trust-verify?  The command can do additional check in a future.
>>> No. What is the value of trust-add if it says you 'Trust established and
>>> verified' while in reality it didn't? This specific issue is very easy
>>> to catch.
>>
>> I think the point was that we are proposing and doing a non-trivial 
>> engineering
>> effort to do warning for one-off bug that will be fixed in next bugfix 
>> release.
>> I would agree if the check is more systematic, but doing a special LDAP 
>> search
>> (for example) from now on because of this one-off bug does not seem to me as
>> ideal path.
> I don't want to have a separate LDAP search. We do LDAP search *already*
> in trust_add because the object is actually created by Samba code as
> result of our interactions with local smbd, so we anyway are reading it.

Ok.

> The problem here is in the fact that somebody may restore a backup done
> before the package upgrade which means whole data in LDAP will be back
> to the old state even though we ran the upgrade before.

I think that is a highly unlikely situation to warrant any non-trivial
development effort. After such restore, when the admin notice that trust is not
working, they would start redoing trust-add anyway.

-- 
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

Re: [Freeipa-devel] [PATCH 0416][WIP] fix broken configuration of sidgen and extdom plugins

[Martin Kosek]

On 02/19/2016 03:02 PM, Alexander Bokovoy wrote:
> On Fri, 19 Feb 2016, Petr Vobornik wrote:
>> On 02/19/2016 11:12 AM, Alexander Bokovoy wrote:
>>> On Fri, 19 Feb 2016, Martin Basti wrote:
 WIP patch attached

 https://fedorahosted.org/freeipa/ticket/5665

>>> Comments inline.
>>>
 +# we need to run sidgen task
 +sidgen_task_dn = DN("cn=sidgen,cn=ipa-sidgen-task,cn=tasks,"
 +"cn=config")
 +sidgen_tasks_attr = {
 +"objectclass": ["top", "extensibleObject"],
 +"cn": ["sidgen"],
 +"delay": [0],
 +"nsslapd-basedn": [self.api.env.basedn],
 +}
>>> May be you are better to name this task more uniquely?
>>> Something like 'cn=generate domain sid,cn=...'?
>>>
 +
 +task_entry = ldap.make_entry(sidgen_task_dn,
 + **sidgen_tasks_attr)
 +try:
 +ldap.add_entry(task_entry)
 +except errors.DuplicateEntry:
 +self.log.debug("sidgen task already created")
 +else:
 +self.log.debug("sidgen task has been created")
>>> There could be multiple tasks running in parallel, that's why it could
>>> be good to use a different and unique name.
>>>
 +# we have to check all trusts domains which have been added
 after the
 +# upgrade that caused bug was done.
 +
 +base_dn = DN(self.api.env.container_adtrusts,
 self.api.env.basedn)
 +trust_domain_entries, truncated = ldap.find_entries(
 +base_dn=base_dn,
 +scope=ldap.SCOPE_ONELEVEL,
 +attrs_list=[attr_name, "cn"],
 +)
 +
 +if truncated:
 +self.log.warning("update_sids: Search results were
 truncated")
 +
 +for entry in trust_domain_entries:
 +if entry.single_value[attr_name] is None:
 +domain = entry.single_value["cn"]
 +self.log.error(
 +"Your trust to %s is broken. Please re-create it
 by "
 +"running 'ipa trust-add' again", domain)
 +
 +sysupgrade.set_upgrade_state('sidgen', 'update_sids', False)
 +return False, ()
>>> This part looks fine. Basically, a similar check needs to be added to
>>> trust_find, trust_show, and may be trust_add.
>>>
>>
>> Why trust-add?
>>
>> I'm not a big fan of cluttering existing commands(find, show, mod) with logic
>> to fix one upgrade bug. But I understand a need to communicate it somehow.
>>
>> Would it make sense to move such logic to a separate command, e.g.
>> trust-check/trust-verify?  The command can do additional check in a future.
> No. What is the value of trust-add if it says you 'Trust established and
> verified' while in reality it didn't? This specific issue is very easy
> to catch.

I think the point was that we are proposing and doing a non-trivial engineering
effort to do warning for one-off bug that will be fixed in next bugfix release.
I would agree if the check is more systematic, but doing a special LDAP search
(for example) from now on because of this one-off bug does not seem to me as
ideal path.

-- 
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

Re: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir.

[Martin Kosek]

On 02/18/2016 10:10 AM, David Kupka wrote:
> From 9952937f207f9a0afae8211276f1b7d7e762fd4e Mon Sep 17 00:00:00 2001
> From: Timo Aaltonen 
> Date: Tue, 19 Jan 2016 12:37:56 +0100
> Subject: [PATCH] Move freeipa certmonger helpers to libexecdir.
> 
> The scripts in this directory are simple python scripts, nothing arch-specific
> in them. Having them under libexec would simplify the code a bit too, since
> there would be no need to worry about lib vs lib64 (which also cause trouble
> on Debian).

Isn't this the patch which moves our scripts in different location and thus
breaks existing certmonger tracking requests *after upgrade*?

-- 
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

Re: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites

[Martin Kosek]

On 02/11/2016 10:45 AM, Martin Basti wrote:
> 
> 
> On 03.02.2016 15:35, Christian Heimes wrote:
>> On 2016-01-29 15:05, Martin Basti wrote:
>>>
>>> On 29.01.2016 14:42, Christian Heimes wrote:
>>>> On 2016-01-28 09:47, Martin Basti wrote:
>>>>> On 22.01.2016 12:32, Martin Kosek wrote:
>>>>>> On 01/21/2016 04:21 PM, Christian Heimes wrote:
>>>>>>> The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
>>>>>>> has been modernized. Insecure or less secure algorithms such as RC4,
>>>>>>> DES and 3DES are removed. Perfect forward secrecy suites with
>>>>>>> ephemeral
>>>>>>> ECDH key exchange have been added. IE 8 on Windows XP is no longer
>>>>>>> supported.
>>>>>>>
>>>>>>> The list of enabled cipher suites has been generated with the script
>>>>>>> contrib/nssciphersuite/nssciphersuite.py.
>>>>>>>
>>>>>>> The supported suites are currently:
>>>>>>>
>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA256
>>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA256
>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
>>>>>>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>>>>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>>>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>>>>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>>>>>> TLS_RSA_WITH_AES_128_GCM_SHA256
>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA
>>>>>>> TLS_RSA_WITH_AES_256_GCM_SHA384
>>>>>>> TLS_RSA_WITH_AES_256_CBC_SHA
>>>>>>>
>>>>>>> https://fedorahosted.org/freeipa/ticket/5589
>>>>>> Thanks for the patch! I updated the ticket to make sure this change is
>>>>>> release notes.
>>>>>>
>>>>> Hello,
>>>>>
>>>>> I'm not sure if I'm the right person to do review on this, but I will
>>>>> try :-)
>>>>>
>>>>> 1)
>>>>> Your patch adds whitespace error
>>>>>
>>>>> Applying: Modernize mod_nss's cipher suites
>>>>> /home/mbasti/work/freeipa-devel/.git/rebase-apply/patch:52: new blank
>>>>> line at EOF.
>>>>> +
>>>>> warning: 1 line adds whitespace errors.
>>>>>
>>>>>
>>>>> 2)
>>>>> +import urllib.request  # pylint: disable=E0611
>>>>>
>>>>> Please specify pylint disabled check by name
>>>>>
>>>>> 3)
>>>>> +def update_mod_nss_cipher_suite(http):
>>>>>
>>>>> in this upgrade, is there any possibility that ciphers might be upgraded
>>>>> again in future? (IMO yes).
>>>>>
>>>>> I think, it can be better to store revision of change instead of boolean
>>>>>
>>>>> LAST_REVISION =  1
>>>>>
>>>>> if revision >= LAST_REVISION:
>>>>>   return
>>>>>
>>>>> sysupgrade.set_upgrade_state('nss.conf', 'cipher_suite_revision',
>>>>> LAST_REVISION)
>>>> Thanks for the review. I have addressed the problems. Instead of a
>>>> revision number I'm using a date string. The sysupgrade module only
>>>> stores str and bool. With a date-based revision it's easy to see when
>>>> the cipher suite was checked last time.
>>>>
>>>> Christian
>>>>
>>> Thanks
>>>
>>> 1) Pylint :-)
>>> +with urllib.request.urlopen(SOURCE) as r:  # pylint: disable=E1101
>> Thanks! It was easier to change the import to get rid of the second
>> pylint stanza.
>>
>>> 2)
>>> +if revision == httpinstance.NSS_CIPHER_REVISION:
>>>
>>> may happen a case where just comparation with '==' can cause a issues
>>> (docker world)? Should not be there rather '>='?
>> Makes sense, I've changed the comparison operator to >=. This may still
>> override user settings, though.
>>
>>> 3)
>>> +root_logger.info("Cipher suite already updated")
>>>
>>> Sorry that I did not noticed earlier, this should be just debug level,
>>> IMO this message is not so important, it will cause only mess on output
>>> (we already have plenty of unneeded info messages in upgrade, they will
>>> be fixed once)
>> Fine with me :)
>>
>> Christian
> ACK
> 
> Pushed to:
> master: 5ac3a3cee534a16db86c541b9beff4939f03410e
> ipa-4-3: c3496a4a4893c75789bdf0c617e46923361fb43b
> 

Very cool! Thanks guys! Looking forward to deploying FreeIPA 4.3.1 on the
FreeIPA public demo :-)

-- 
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

Re: [Freeipa-devel] [PATCH 2/3] ASN1: Fix warning Wpointer-to-int-cast

[Martin Kosek]

On 01/29/2016 12:15 PM, Lukas Slebodnik wrote:
> ehlo,
> 
> the first patch is very simple and it just suppress warning.
> The second patch is either bug or dead code. I fixed it as a bug.
> I'm not sure how to test 2nd patch.
> 
> LS

Thanks. But isn't this the code generated by asn1 tool? Maybe it would be
better to fix the tool, or maybe regenerate it with a newer version of the
tool? Otherwise the improvements will get lost.

-- 
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

Re: [Freeipa-devel] [PATCH 0411] upgrade: log to ipaupgrade.log if ipa is not installed

[Martin Kosek]

On 01/29/2016 10:48 AM, Martin Basti wrote:
> Missing record in ipaupgrade.log that upgrade failed because IPA is not
> installed, causes harder time to debugging upgrade from log.
> 
> Patch attached.

I am thinking that in these general catch-all clauses, it could be also useful
to print the stack trace in the DEBUG log, especially for the cases when the
exception is re-raised to some general one, like here:

try:
data_upgrade.create_instance()
...
except RuntimeError:
raise RuntimeError('IPA upgrade failed.', 1)

-- 
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

Re: [Freeipa-devel] [PATCH 0030] Modernize mod_nss's cipher suites

[Martin Kosek]

On 01/21/2016 04:21 PM, Christian Heimes wrote:

The list of supported TLS cipher suites in /etc/httpd/conf.d/nss.conf
has been modernized. Insecure or less secure algorithms such as RC4,
DES and 3DES are removed. Perfect forward secrecy suites with ephemeral
ECDH key exchange have been added. IE 8 on Windows XP is no longer
supported.

The list of enabled cipher suites has been generated with the script
contrib/nssciphersuite/nssciphersuite.py.

The supported suites are currently:

TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA

https://fedorahosted.org/freeipa/ticket/5589


Thanks for the patch! I updated the ticket to make sure this change is release 
notes.


--
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

Re: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI

[Martin Kosek]

On 01/21/2016 04:22 PM, thierry bordaz wrote:
> On 01/21/2016 03:46 PM, Martin Kosek wrote:
>> On 01/21/2016 01:37 PM, thierry bordaz wrote:
>> Thanks! Couple comments:
>>
>> I miss ticket number of description.
> 
> Thanks Martin for looking at it.
> 
> Ouch... the ticket number is https://fedorahosted.org/freeipa/ticket/4026
>>
>> Does this patch mean that all blocker on DS side preventing remote DNA were
>> fixed? If yes, it may be worth updating Requires in the spec file in that 
>> case
>> and making sure the backport is in Fedora 23+ or at least FreeIPA 4.3 COPR 
>> repo.
> It required following 389-ds tickets that are now both fixed in 1.3.4.6
> 
>  * https://fedorahosted.org/389/ticket/47779
>  * https://fedorahosted.org/389/ticket/48362
> 
> Is it the change to do in the spec file ?
> 
> diff --git a/freeipa.spec.in b/freeipa.spec.in
> index 899af6c..87e80c9 100644
> --- a/freeipa.spec.in
> +++ b/freeipa.spec.in
> @@ -130,7 +130,7 @@ Requires: %{name}-client = %{version}-%{release}
>  Requires: %{name}-admintools = %{version}-%{release}
>  Requires: %{name}-common = %{version}-%{release}
>  Requires: python2-ipaserver = %{version}-%{release}
> -Requires: 389-ds-base >= 1.3.4.4
> +Requires: 389-ds-base >= 1.3.4.6
>  Requires: openldap-clients > 2.4.35-4
>  Requires: nss >= 3.14.3-12.0
>  Requires: nss-tools >= 3.14.3-12.0
> @@ -162,7 +162,7 @@ Requires: zip
>  Requires: policycoreutils >= 2.1.12-5
>  Requires: tar
>  Requires(pre): certmonger >= 0.78
> -Requires(pre): 389-ds-base >= 1.3.4.4
> +Requires(pre): 389-ds-base >= 1.3.4.6
>  Requires: fontawesome-fonts
>  Requires: open-sans-fonts
>  Requires: openssl

That spec file change should be OK, thanks. I did not do other testing, I would
leave that up to other developers.

-- 
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

Re: [Freeipa-devel] [PATCH] 0017 configure DNA shared config entry to allow connection with GSSAPI

[Martin Kosek]

On 01/21/2016 01:37 PM, thierry bordaz wrote:
> 

Thanks! Couple comments:

I miss ticket number of description.

Does this patch mean that all blocker on DS side preventing remote DNA were
fixed? If yes, it may be worth updating Requires in the spec file in that case
and making sure the backport is in Fedora 23+ or at least FreeIPA 4.3 COPR repo.

-- 
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

Re: [Freeipa-devel] [PATCH] 0049 Remove workaround for CA running check

[Martin Kosek]

On 01/20/2016 08:45 AM, Fraser Tweedale wrote:
> The attached patch removes a workaround introduced as part of
> https://fedorahosted.org/freeipa/ticket/4676.
> 
> Alternatively, if we want to keep the "workaround" I will submit a
> different patch that removes unused code and FIXME comments :)
> 
> Cheers,
> Fraser

You may also want to check FreeIPA spec file, if there is now no extra curl
dependency. I would leave it up to Martin Basti, to confirm that the original
issue cannot appear again. It was a nightmare to troubleshoot, as I heard :)

-- 
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

Re: [Freeipa-devel] [PATCH 0011] Move freeipa certmonger helpers to libexecdir.

[Martin Kosek]

On 01/19/2016 01:47 PM, David Kupka wrote:
> I've polished the patch attached to #5586 by Timo Aaltonen.
> 
> Thanks for the patch. I've fixed the path in specfile and removed unused 
> import
> but otherwise it works, ACK.
> 
> https://fedorahosted.org/freeipa/ticket/5586

Won't this break existing certmonger requests depending on the old path?

# getcert list | grep '/usr/lib64/ipa/certmonger'
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"auditSigningCert
cert-pki-ca"
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"ocspSigningCert
cert-pki-ca"
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"subsystemCert
cert-pki-ca"
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"caSigningCert
cert-pki-ca"
post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "Server-Cert
cert-pki-ca"
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv RHEL72
post-save command: /usr/lib64/ipa/certmonger/restart_httpd

-- 
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

Re: [Freeipa-devel] [PATCH 539] ipalib: assume version 2.0 when skip_version_check is enabled

[Martin Kosek]

On 01/12/2016 03:46 PM, Jan Cholasta wrote:
> Hi,
> 
> the attached patch fixes .
> 
> Honza

I see you set the version to 2.0. As I am reading
https://bugzilla.redhat.com/show_bug.cgi?id=1297811#c1
, shouldn't the minimal version be set to something higher than 2.49?

-- 
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

[Freeipa-devel] FreeIPA github mirror/repo (Fwd: [SSSD] The mirror at https://github.com/SSSD/sssd is now automatically updated)

[Martin Kosek]

FIY, I suspect FreeIPA will want follow the same approach for

https://github.com/freeipa/freeipa

(to be created) :-)

Martin

 Forwarded Message 
Subject: [SSSD] The mirror at https://github.com/SSSD/sssd is now automatically
updated
Date: Mon, 11 Jan 2016 11:33:06 +0100
From: Jakub Hrozek 
Reply-To: Development of the System Security Services Daemon

To: sssd-de...@lists.fedorahosted.org

Hi,

with the help of Patrick from the Fedora Infra team, our github repo:
https://github.com/SSSD/sssd
is now receiving automatic updates after patches are pushed to the
fedorahosted.org repo.

Since the push is implemented as a git hook which pushes with "--force
--mirror", you'll see a message in the git push output.

oh and Patrick managed to lock down the private key to the members of
the fedora 'sssdgit' group..
___
sssd-devel mailing list
sssd-de...@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-de...@lists.fedorahosted.org


-- 
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

Re: [Freeipa-devel] [PATCH 0124] ipa-csreplica-manage: remove extraneous ldap2 connection

[Martin Kosek]

On 01/08/2016 06:31 PM, Martin Babinsky wrote:
> On 01/08/2016 06:17 PM, Martin Basti wrote:
>>
>>
>> On 08.01.2016 17:18, Martin Babinsky wrote:
>>> fixes ipa-csreplica-manage del blowing up due
>>>
>>> https://fedorahosted.org/freeipa/ticket/5583
>>>
>>> for master and ipa-4-3 only.
>>>
>> Give me patch plese!!
> 
> Auto-attach plugin would be most welcome.. here's the patch.

Back my developer days, I used this script for sending patches :-)

https://github.com/freeipa/freeipa-tools/blob/master/sendpatch.py

This let me (almost never) forget attaching the file(s) in the right format.

-- 
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

Re: [Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

On 01/08/2016 03:02 PM, Rob Crittenden wrote:
> Alexander Bokovoy wrote:
>> On Fri, 08 Jan 2016, Martin Kosek wrote:
>>> On 01/08/2016 02:17 PM, Fraser Tweedale wrote:
>>>> On Fri, Jan 08, 2016 at 02:02:07PM +0100, Martin Kosek wrote:
>>>>> On 01/08/2016 01:56 PM, Fraser Tweedale wrote:
>>>>>> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote:
>>>>>>> Hi Fraser and other X.509 SMEs,
>>>>>>>
>>>>>>> I wanted to check with you on what we have or plan to have with
>>>>>>> respect to
>>>>>>> certificate/cipher strength in FreeIPA.
>>>>>>>
>>>>>>> When I visit the FreeIPA public demo for example, I usually see
>>>>>>> following
>>>>>>> errors with recent browsers:
>>>>>>>
>>>>>>> * Your connection to ipa.demo1.freeipa.org is encrypted using
>>>>>>> obsolete cypher
>>>>>>> suite.
>>>>>>>  - The connection uses TLS 1.2
>>>>>>>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1
>>>>>>> for message
>>>>>>> authentication and RSA as the key exchange mechanism
>>>>>>>
>>>>>> This is a cipher suite / ordering issue, not related to certificate.
>>>>>>
>>>>>>> I usually do not see the common
>>>>>>> * Certificate chain contains a certificate signed with SHA-1
>>>>>>> error, but I am not sure if we are covered for this one.
>>>>>>>
>>>>>> We are using sha256 for IPA CA and default profiles.  Customers
>>>>>> could still modify the profile or add profiles to sign using an
>>>>>> obsolete hash, if they wanted to, but our default is good.
>>>>>>
>>>>>>>
>>>>>>> When I tested the FreeIPA demo with
>>>>>>> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
>>>>>>> (and ignore the trust issues), we get the mark B with following
>>>>>>> warnings:
>>>>>>>
>>>>>>> * This server accepts RC4 cipher, but only with older protocol
>>>>>>> versions. Grade
>>>>>>> capped to B.
>>>>>>>
>>>>>>> * The server does not support Forward Secrecy with the reference
>>>>>>> browsers.
>>>>>>>
>>>>>> Again a cipher suite tweak will address this.
>>>>>>
>>>>>>>
>>>>>>> What do we miss to turn out Grade A, which is obviously something
>>>>>>> expected from
>>>>>>> security solution like FreeIPA? Is it just about ECC support
>>>>>>> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some
>>>>>>> change to our
>>>>>>> default certificate profiles?
>>>>>>>
>>>>>> Based on what you've written, it is just the cipher suite that needs
>>>>>> changing, and maybe a setting about favouring server cipher order
>>>>>> over client order.  ECC certificate support is not needed (yet) and
>>>>>> the default profile is fine, w.r.t. hash used for signing.
>>>>>>
>>>>>> One important modern certificate requirement is to always include a
>>>>>> SAN dnsName for the subject, as required by RFC 2818; this is ticket
>>>>>> #4970 and it is on my radar.
>>>>>>
>>>>>> Cheers,
>>>>>> Fraser
>>>>>
>>>>> Should I then file a ticket to fix the cipher suite? (I did not fully
>>>>> understand the specifics though).
>>>>>
>>>> Yes.  I have not checked yet, but we are possibly using
>>>> stock-standard mod_nss configuration (as shipped by the RPM).  If
>>>> so, we should file a ticket against mod_nss to improve their
>>>> defaults.
>>>
>>> Right. In nss.conf, I see this default cipher suite:
>>>
>>> NSSCipherSuite
>>> +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-
>>>
>>>
>>> rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
>>>
>>>
>>> It certainly makes me little nervous. In 389-ds-base case, we had a
>>> similar
>>> list and solved it my using the list directly from NSS:
>>>
>>> https://fedorahosted.org/389/ticket/47838
>>> https://fedorahosted.org/freeipa/ticket/4395
>>>
>>> CCing Rob here.
>> Here is what I have in my setup that goes to A- according to ssllabs:
>> NSSCipherSuite
>> -rsa_rc4_128_md5,-rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha
>>
>>
>> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
>>
>> This gets A- due to lack of forward secrecy support.
>>
> 
> An IPA ticket for this exists, https://fedorahosted.org/freeipa/ticket/4431

This is a refactoring type of a ticket, it may not be done fast enough. I
created a smaller task in new ticket:

https://fedorahosted.org/freeipa/ticket/5589

> For mod_nss I was going to do this as part of
> https://fedorahosted.org/mod_nss/ticket/5
> 
> If you add in some EC ciphers you'd probably get PFS too. DH ciphers
> aren't supported yet.
> 
> rob
> 

-- 
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

Re: [Freeipa-devel] import rpm causes failure during IPA caless install

[Martin Kosek]

On 01/08/2016 02:18 PM, Martin Babinsky wrote:
> On 01/08/2016 02:14 PM, Jan Cholasta wrote:
>> On 8.1.2016 14:09, Martin Basti wrote:
>>>
>>>
>>> On 08.01.2016 14:00, Martin Kosek wrote:
>>>> On 01/08/2016 01:45 PM, Martin Basti wrote:
>>>>> Hello all,
>>>>>
>>>>> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
>>>>> requires to import rpm module
>>>>>
>>>>> This import somehow breaks nsslib in IPA
>>>>> https://fedorahosted.org/freeipa/ticket/5572
>>>>>
>>>>>
>>>>> We have 2 ways how to fix it:
>>>>>
>>>>> 1) move import rpm to body of methods (attached patch)
>>>>> We are not sure how stable is this solution.
>>>>>
>>>>> 2) use solution with rpmdevtools proposed here:
>>>>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
>>>>>
>>>>> This should be rock stable but it needs many dependencies (rpm-python
>>>>> too, perl)
>>>>>
>>>>> The second way looks safer, so I would like to reimplement it, do you
>>>>> all agree
>>>>> or do you have better idea?
>>>>> Feedback welcome, please ASAP.
>>>>>
>>>>> Martin^2
>>>> Since it's Friday, I invested 15 minutes to practice my C skills and
>>>> use the
>>>> python-cffi library to call rpm rpmvercmp library call directly
>>>> (attached):
>>>>
>>>> $ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
>>>> 4.2.0-15.el7 < 4.2.0-15.el7_2.3
>>>>
>>>> This would not introduce any additional dependency besides rpm-devel,
>>>> right? :-)
>>
>> Not rpm-devel, but rpm-libs (you should dlopen "librpm.so.3").
>>
>>> I'm afraid that this can cause the same issue as import rpm, because the
>>> nsslib is used from C library
>>
>> I would be surprised if NSS was used in this particular function.
>>
> 
> If it would work then we could compare version like in this quickly hacked and
> untested patch.

BTW, I demand Acknowledgment statement for my Friday Idea in the patch
description, if this approach is used ;-)

-- 
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

Re: [Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

On 01/08/2016 02:24 PM, Christian Heimes wrote:
> On 2016-01-08 13:26, Martin Kosek wrote:
>> Hi Fraser and other X.509 SMEs,
>>
>> I wanted to check with you on what we have or plan to have with respect to
>> certificate/cipher strength in FreeIPA.
>>
>> When I visit the FreeIPA public demo for example, I usually see following
>> errors with recent browsers:
>>
>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher
>> suite.
>>  - The connection uses TLS 1.2
>>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message
>> authentication and RSA as the key exchange mechanism
>>
>> I usually do not see the common
>> * Certificate chain contains a certificate signed with SHA-1
>> error, but I am not sure if we are covered for this one.
>>
>>
>> When I tested the FreeIPA demo with
>> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
>> (and ignore the trust issues), we get the mark B with following warnings:
>>
>> * This server accepts RC4 cipher, but only with older protocol versions. 
>> Grade
>> capped to B.
>>
>> * The server does not support Forward Secrecy with the reference browsers.
>>
>>
>> What do we miss to turn out Grade A, which is obviously something expected 
>> from
>> security solution like FreeIPA? Is it just about ECC support
>> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change to 
>> our
>> default certificate profiles?
> 
> The cert has another issue. It relies on Subject CN for host name
> verification. This feature has been deprecated by RFC 2818 more than a
> decade ago. Instead of Subject CN modern certs should use dNSName in
> SubjectAltName x509v3 extension.
> 
> https://fedorahosted.org/pki/ticket/1464
> https://github.com/shazow/urllib3/issues/497

Right. Fraser should have it in his queue already:
https://fedorahosted.org/freeipa/ticket/4970

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

Re: [Freeipa-devel] import rpm causes failure during IPA caless install

[Martin Kosek]

On 01/08/2016 02:32 PM, Martin Kosek wrote:
> On 01/08/2016 02:22 PM, Jan Cholasta wrote:
>> On 8.1.2016 14:13, Martin Basti wrote:
>>>
>>>
>>> On 08.01.2016 14:14, Jan Cholasta wrote:
>>>> On 8.1.2016 14:09, Martin Basti wrote:
>>>>>
>>>>>
>>>>> On 08.01.2016 14:00, Martin Kosek wrote:
>>>>>> On 01/08/2016 01:45 PM, Martin Basti wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
>>>>>>> requires to import rpm module
>>>>>>>
>>>>>>> This import somehow breaks nsslib in IPA
>>>>>>> https://fedorahosted.org/freeipa/ticket/5572
>>>>>>>
>>>>>>>
>>>>>>> We have 2 ways how to fix it:
>>>>>>>
>>>>>>> 1) move import rpm to body of methods (attached patch)
>>>>>>> We are not sure how stable is this solution.
>>>>>>>
>>>>>>> 2) use solution with rpmdevtools proposed here:
>>>>>>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
>>>>>>>
>>>>>>> This should be rock stable but it needs many dependencies (rpm-python
>>>>>>> too, perl)
>>>>>>>
>>>>>>> The second way looks safer, so I would like to reimplement it, do you
>>>>>>> all agree
>>>>>>> or do you have better idea?
>>>>>>> Feedback welcome, please ASAP.
>>>>>>>
>>>>>>> Martin^2
>>>>>> Since it's Friday, I invested 15 minutes to practice my C skills and
>>>>>> use the
>>>>>> python-cffi library to call rpm rpmvercmp library call directly
>>>>>> (attached):
>>>>>>
>>>>>> $ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
>>>>>> 4.2.0-15.el7 < 4.2.0-15.el7_2.3
>>>>>>
>>>>>> This would not introduce any additional dependency besides rpm-devel,
>>>>>> right? :-)
>>>>
>>>> Not rpm-devel, but rpm-libs (you should dlopen "librpm.so.3").
>>>>
>>>>> I'm afraid that this can cause the same issue as import rpm, because the
>>>>> nsslib is used from C library
>>>>
>>>> I would be surprised if NSS was used in this particular function.
>>>>
>>> I will try it
>>
>> No NSS here:
>> <https://github.com/rpm-software-management/rpm/blob/master/lib/rpmvercmp.c>
> 
> What line? I must miss something...

Please ignore the above, I somehow read it as "No, NSS here" :-)

> 
>> Anyway, the function looks simple, so it might be safer to just rewrite it to
>> Python, with no new dependencies.
> 
> I would personally rather use the first proposal of rpmdevtools, rather than
> rewriting it ourselves. IMO, rewriting the function is the worst option 
> actually.

Still, how is reimplementing NSS function safer than calling their library
function? I checked that rpm-devel is not required, BTW.

-- 
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

Re: [Freeipa-devel] import rpm causes failure during IPA caless install

[Martin Kosek]

On 01/08/2016 02:22 PM, Jan Cholasta wrote:
> On 8.1.2016 14:13, Martin Basti wrote:
>>
>>
>> On 08.01.2016 14:14, Jan Cholasta wrote:
>>> On 8.1.2016 14:09, Martin Basti wrote:
>>>>
>>>>
>>>> On 08.01.2016 14:00, Martin Kosek wrote:
>>>>> On 01/08/2016 01:45 PM, Martin Basti wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
>>>>>> requires to import rpm module
>>>>>>
>>>>>> This import somehow breaks nsslib in IPA
>>>>>> https://fedorahosted.org/freeipa/ticket/5572
>>>>>>
>>>>>>
>>>>>> We have 2 ways how to fix it:
>>>>>>
>>>>>> 1) move import rpm to body of methods (attached patch)
>>>>>> We are not sure how stable is this solution.
>>>>>>
>>>>>> 2) use solution with rpmdevtools proposed here:
>>>>>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
>>>>>>
>>>>>> This should be rock stable but it needs many dependencies (rpm-python
>>>>>> too, perl)
>>>>>>
>>>>>> The second way looks safer, so I would like to reimplement it, do you
>>>>>> all agree
>>>>>> or do you have better idea?
>>>>>> Feedback welcome, please ASAP.
>>>>>>
>>>>>> Martin^2
>>>>> Since it's Friday, I invested 15 minutes to practice my C skills and
>>>>> use the
>>>>> python-cffi library to call rpm rpmvercmp library call directly
>>>>> (attached):
>>>>>
>>>>> $ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
>>>>> 4.2.0-15.el7 < 4.2.0-15.el7_2.3
>>>>>
>>>>> This would not introduce any additional dependency besides rpm-devel,
>>>>> right? :-)
>>>
>>> Not rpm-devel, but rpm-libs (you should dlopen "librpm.so.3").
>>>
>>>> I'm afraid that this can cause the same issue as import rpm, because the
>>>> nsslib is used from C library
>>>
>>> I would be surprised if NSS was used in this particular function.
>>>
>> I will try it
> 
> No NSS here:
> <https://github.com/rpm-software-management/rpm/blob/master/lib/rpmvercmp.c>

What line? I must miss something...

> Anyway, the function looks simple, so it might be safer to just rewrite it to
> Python, with no new dependencies.

I would personally rather use the first proposal of rpmdevtools, rather than
rewriting it ourselves. IMO, rewriting the function is the worst option 
actually.

-- 
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

Re: [Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

On 01/08/2016 02:17 PM, Fraser Tweedale wrote:
> On Fri, Jan 08, 2016 at 02:02:07PM +0100, Martin Kosek wrote:
>> On 01/08/2016 01:56 PM, Fraser Tweedale wrote:
>>> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote:
>>>> Hi Fraser and other X.509 SMEs,
>>>>
>>>> I wanted to check with you on what we have or plan to have with respect to
>>>> certificate/cipher strength in FreeIPA.
>>>>
>>>> When I visit the FreeIPA public demo for example, I usually see following
>>>> errors with recent browsers:
>>>>
>>>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete 
>>>> cypher
>>>> suite.
>>>>  - The connection uses TLS 1.2
>>>>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for 
>>>> message
>>>> authentication and RSA as the key exchange mechanism
>>>>
>>> This is a cipher suite / ordering issue, not related to certificate.
>>>
>>>> I usually do not see the common
>>>> * Certificate chain contains a certificate signed with SHA-1
>>>> error, but I am not sure if we are covered for this one.
>>>>
>>> We are using sha256 for IPA CA and default profiles.  Customers
>>> could still modify the profile or add profiles to sign using an
>>> obsolete hash, if they wanted to, but our default is good.
>>>
>>>>
>>>> When I tested the FreeIPA demo with
>>>> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
>>>> (and ignore the trust issues), we get the mark B with following warnings:
>>>>
>>>> * This server accepts RC4 cipher, but only with older protocol versions. 
>>>> Grade
>>>> capped to B.
>>>>
>>>> * The server does not support Forward Secrecy with the reference browsers.
>>>>
>>> Again a cipher suite tweak will address this.
>>>
>>>>
>>>> What do we miss to turn out Grade A, which is obviously something expected 
>>>> from
>>>> security solution like FreeIPA? Is it just about ECC support
>>>> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change 
>>>> to our
>>>> default certificate profiles?
>>>>
>>> Based on what you've written, it is just the cipher suite that needs
>>> changing, and maybe a setting about favouring server cipher order
>>> over client order.  ECC certificate support is not needed (yet) and
>>> the default profile is fine, w.r.t. hash used for signing.
>>>
>>> One important modern certificate requirement is to always include a
>>> SAN dnsName for the subject, as required by RFC 2818; this is ticket
>>> #4970 and it is on my radar.
>>>
>>> Cheers,
>>> Fraser
>>
>> Should I then file a ticket to fix the cipher suite? (I did not fully
>> understand the specifics though).
>>
> Yes.  I have not checked yet, but we are possibly using
> stock-standard mod_nss configuration (as shipped by the RPM).  If
> so, we should file a ticket against mod_nss to improve their
> defaults.

Right. In nss.conf, I see this default cipher suite:

NSSCipherSuite
+rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-

rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

It certainly makes me little nervous. In 389-ds-base case, we had a similar
list and solved it my using the list directly from NSS:

https://fedorahosted.org/389/ticket/47838
https://fedorahosted.org/freeipa/ticket/4395

CCing Rob here.

-- 
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

Re: [Freeipa-devel] import rpm causes failure during IPA caless install

[Martin Kosek]

On 01/08/2016 02:09 PM, Martin Basti wrote:
> 
> 
> On 08.01.2016 14:00, Martin Kosek wrote:
>> On 01/08/2016 01:45 PM, Martin Basti wrote:
>>> Hello all,
>>>
>>> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
>>> requires to import rpm module
>>>
>>> This import somehow breaks nsslib in IPA
>>> https://fedorahosted.org/freeipa/ticket/5572
>>>
>>>
>>> We have 2 ways how to fix it:
>>>
>>> 1) move import rpm to body of methods (attached patch)
>>> We are not sure how stable is this solution.
>>>
>>> 2) use solution with rpmdevtools proposed here:
>>> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
>>> This should be rock stable but it needs many dependencies (rpm-python too,
>>> perl)
>>>
>>> The second way looks safer, so I would like to reimplement it, do you all 
>>> agree
>>> or do you have better idea?
>>> Feedback welcome, please ASAP.
>>>
>>> Martin^2
>> Since it's Friday, I invested 15 minutes to practice my C skills and use the
>> python-cffi library to call rpm rpmvercmp library call directly (attached):
>>
>> $ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
>> 4.2.0-15.el7 < 4.2.0-15.el7_2.3
>>
>> This would not introduce any additional dependency besides rpm-devel, right? 
>> :-)
> I'm afraid that this can cause the same issue as import rpm, because the 
> nsslib
> is used from C library

This would need to be tested/figured out, I do not know the exact details of
how the NSS issue is triggered.

-- 
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

Re: [Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

On 01/08/2016 01:56 PM, Fraser Tweedale wrote:
> On Fri, Jan 08, 2016 at 01:26:57PM +0100, Martin Kosek wrote:
>> Hi Fraser and other X.509 SMEs,
>>
>> I wanted to check with you on what we have or plan to have with respect to
>> certificate/cipher strength in FreeIPA.
>>
>> When I visit the FreeIPA public demo for example, I usually see following
>> errors with recent browsers:
>>
>> * Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher
>> suite.
>>  - The connection uses TLS 1.2
>>  - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message
>> authentication and RSA as the key exchange mechanism
>>
> This is a cipher suite / ordering issue, not related to certificate.
> 
>> I usually do not see the common
>> * Certificate chain contains a certificate signed with SHA-1
>> error, but I am not sure if we are covered for this one.
>>
> We are using sha256 for IPA CA and default profiles.  Customers
> could still modify the profile or add profiles to sign using an
> obsolete hash, if they wanted to, but our default is good.
> 
>>
>> When I tested the FreeIPA demo with
>> https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
>> (and ignore the trust issues), we get the mark B with following warnings:
>>
>> * This server accepts RC4 cipher, but only with older protocol versions. 
>> Grade
>> capped to B.
>>
>> * The server does not support Forward Secrecy with the reference browsers.
>>
> Again a cipher suite tweak will address this.
> 
>>
>> What do we miss to turn out Grade A, which is obviously something expected 
>> from
>> security solution like FreeIPA? Is it just about ECC support
>> (https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change to 
>> our
>> default certificate profiles?
>>
> Based on what you've written, it is just the cipher suite that needs
> changing, and maybe a setting about favouring server cipher order
> over client order.  ECC certificate support is not needed (yet) and
> the default profile is fine, w.r.t. hash used for signing.
> 
> One important modern certificate requirement is to always include a
> SAN dnsName for the subject, as required by RFC 2818; this is ticket
> #4970 and it is on my radar.
> 
> Cheers,
> Fraser

Should I then file a ticket to fix the cipher suite? (I did not fully
understand the specifics though).

-- 
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

Re: [Freeipa-devel] import rpm causes failure during IPA caless install

[Martin Kosek]

On 01/08/2016 01:45 PM, Martin Basti wrote:
> Hello all,
> 
> fix for ticket https://fedorahosted.org/freeipa/ticket/5535
> requires to import rpm module
> 
> This import somehow breaks nsslib in IPA
> https://fedorahosted.org/freeipa/ticket/5572
> 
> 
> We have 2 ways how to fix it:
> 
> 1) move import rpm to body of methods (attached patch)
> We are not sure how stable is this solution.
> 
> 2) use solution with rpmdevtools proposed here:
> https://www.redhat.com/archives/freeipa-devel/2016-January/msg00092.html
> This should be rock stable but it needs many dependencies (rpm-python too, 
> perl)
> 
> The second way looks safer, so I would like to reimplement it, do you all 
> agree
> or do you have better idea?
> Feedback welcome, please ASAP.
> 
> Martin^2

Since it's Friday, I invested 15 minutes to practice my C skills and use the
python-cffi library to call rpm rpmvercmp library call directly (attached):

$ python rpm.py 4.2.0-15.el7 4.2.0-15.el7_2.3
4.2.0-15.el7 < 4.2.0-15.el7_2.3

This would not introduce any additional dependency besides rpm-devel, right? :-)
from cffi import FFI
import sys

ver1 = sys.argv[1]
ver2 = sys.argv[2]

ffi = FFI()
ffi.cdef("""
int rpmvercmp (const char *a, const char *b);
""")
C = ffi.dlopen("rpm")
arg1 = ffi.new("char[]", ver1)
arg2 = ffi.new("char[]", ver2)

x = C.rpmvercmp(arg1, arg2)

if x == 0:
print "%s = %s" % (ver1, ver2)
elif x == 1:
print "%s > %s" % (ver1, ver2)
elif x == -1:
print "%s < %s" % (ver1, ver2)
-- 
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

[Freeipa-devel] FreeIPA and modern requirements on certificates

[Martin Kosek]

Hi Fraser and other X.509 SMEs,

I wanted to check with you on what we have or plan to have with respect to
certificate/cipher strength in FreeIPA.

When I visit the FreeIPA public demo for example, I usually see following
errors with recent browsers:

* Your connection to ipa.demo1.freeipa.org is encrypted using obsolete cypher
suite.
 - The connection uses TLS 1.2
 - The connection is encrypted ising AES_128_CBC, with HMAC-SHA1 for message
authentication and RSA as the key exchange mechanism

I usually do not see the common
* Certificate chain contains a certificate signed with SHA-1
error, but I am not sure if we are covered for this one.


When I tested the FreeIPA demo with
https://www.ssllabs.com/ssltest/analyze.html?d=ipa.demo1.freeipa.org
(and ignore the trust issues), we get the mark B with following warnings:

* This server accepts RC4 cipher, but only with older protocol versions. Grade
capped to B.

* The server does not support Forward Secrecy with the reference browsers.


What do we miss to turn out Grade A, which is obviously something expected from
security solution like FreeIPA? Is it just about ECC support
(https://fedorahosted.org/freeipa/ticket/3951) or also maybe some change to our
default certificate profiles?

Thanks!

-- 
Martin Kosek 
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

-- 
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

Re: [Freeipa-devel] [PATCH 0373] Upgrade: Fix IPA version comparison

[Martin Kosek]

On 12/11/2015 09:36 AM, Martin Kosek wrote:
> On 12/10/2015 05:09 PM, Martin Basti wrote:
>>
>>
>> On 10.12.2015 15:49, Tomas Babej wrote:
>>>
>>> On 12/10/2015 11:23 AM, Martin Basti wrote:
>>>>
>>>> On 10.12.2015 09:13, Lukas Slebodnik wrote:
>>>>> On (09/12/15 19:22), Martin Basti wrote:
>>>>>> https://fedorahosted.org/freeipa/ticket/5535
>>>>>>
>>>>>> Patch attached.
>>>>> >From 8ef93485d61e8732166fb0c5b6c4559209740f3e Mon Sep 17 00:00:00 2001
>>>>>> From: Martin Basti 
>>>>>> Date: Wed, 9 Dec 2015 18:53:35 +0100
>>>>>> Subject: [PATCH] Fix version comparison
>>>>>>
>>>>>> Use RPM library to compare vendor versions of IPA for redhat platform
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/5535
>>>>>> ---
>>>>>> freeipa.spec.in |  2 ++
>>>>>> ipaplatform/redhat/tasks.py | 19 +++
>>>>>> 2 files changed, 21 insertions(+)
>>>>>>
>>>>>> diff --git a/freeipa.spec.in b/freeipa.spec.in
>>>>>> index
>>>>>> 9f82b3695fb10c4db65cc31278364b3b34e26098..09feba7b8324f5e645da3e8010de86b6c3ee5ab9
>>>>>>
>>>>>>
>>>>>> 100644
>>>>>> --- a/freeipa.spec.in
>>>>>> +++ b/freeipa.spec.in
>>>>>> @@ -166,6 +166,8 @@ Requires: %{etc_systemd_dir}
>>>>>> Requires: gzip
>>>>>> Requires: python-gssapi >= 1.1.0
>>>>>> Requires: custodia
>>>>>> +Requires: rpm-python
>>>>>> +Requires: rpmdevtools
>>>>> Could you explain why do you need the 2nd package?
>>>>> It does not contains any python modules
>>>>> and I cannot see usage of any binary in this patch
>>>>>
>>>>> LS
>>>> Thanks for this catch, it is actually located in yum package, I rather
>>>> copy stringToVersion function from there to IPA, to avoid dependency hell
>>>>
>>>> Updated patch attached.
>>>>
>>>>
>>> Looking good. The __cmp__ function, however, is not available in Python
>>> 3. As we will eventually support python3 in RHEL as well, maybe we
>>> should make sure even platform-dependent parts are python3 compatible?
>>> For the future's sake.
>>>
>>> Tomas
>>>
>> Thanks,
>>
>> python 3 compatible patch attached.
> 
> I wonder why we have to add so much code here and reimplement RPM version
> checking if it is already provided by rpmdevtools:
> 
> ~~~
> $ /usr/bin/rpmdev-vercmp ipa-4.2.0-15.el7 4.2.0-15.el7_2.3; echo $?
> WARNING: hyphen in release1: 4.2.0-15.el7
> 
> rpmdev-vercmp  
> rpmdev-vercmp  
> rpmdev-vercmp # with no arguments, prompt
> 
> Exit status is 0 if the EVR's are equal, 11 if EVR1 is newer, and 12 if EVR2
> is newer.  Other exit statuses indicate problems.
> 
> ipa-4.2.0-15.el7 < 4.2.0-15.el7_2.3
> 12
> ~~~
> 
> which could be directly called from __eq__ or __lt__, since we are in platform
> specific code anyway already.
> 
> Martin

The version comparing was discussed again as current way causes some issues.
JFTR, the example above is not correct, this is the right way of calling it:

$ rpmdev-vercmp 4.2.0-15.el7 4.2.0-15.el7_2.3; echo $?
4.2.0-15.el7 < 4.2.0-15.el7_2.3
12

One thing discussed is that rpmdevtools require Perl. Looking at currenet
FreeIPA dependencies, we do require it already, but in general, it would be
nice to get rid of it. But as for now, we did not come up with a better idea
for above other than reimplementing it all in FreeIPA python code.

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

Re: [Freeipa-devel] [PATCH 559] Fix kadmin for new users

[Martin Kosek]

On 01/06/2016 08:37 AM, Martin Babinsky wrote:
> On 11/25/2015 03:41 PM, Martin Kosek wrote:
>> On 11/25/2015 03:32 PM, Simo Sorce wrote:
>>> On Wed, 2015-11-25 at 14:13 +0100, Tomas Babej wrote:
>>>>
>>>> On 11/25/2015 02:13 PM, Tomas Babej wrote:
>>>>>
>>>>>
>>>>> On 11/25/2015 02:00 PM, Martin Babinsky wrote:
>>>>>> On 11/24/2015 11:32 PM, Simo Sorce wrote:
>>>>>>> Ticket #937 was reopened a while ago because one corner case, new users
>>>>>>> that have never been assigned a password cause kadmin/kadmin.local to
>>>>>>> throw a fit when they try to visualize information about those user's
>>>>>>> principals.
>>>>>>>
>>>>>>> This patch fakes up modification information when no krbExtraData is
>>>>>>> available for the principal so that kadmin is happy.
>>>>>>>
>>>>>>> Tested and working as designed.
>>>>>>>
>>>>>>> Simo.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ACK
>>>>>>
>>>>>
>>>>> Pushed to master: 0f52eddd1d2781ccc1941c191e9ab6e3ccf6919d
>>>>>
>>>>
>>>> On a related note, should we backport this to later branches?
>>>
>>> It wouldn't hurt, it should apply straight to any 4.x and probably
>>> latest 3.x branches too.
>>
>> I would not fix anything older than FreeIPA 4.1.x which is in F22, which is 
>> the
>> oldest supported Fedora (or rather fill be, one month after F23 GA).
>>
> 
> https://fedorahosted.org/freeipa/ticket/937 is included in 4.2.4 milestone 
> with
> priority critical. Shouldn't we backport the patch to ipa-4-2 branch?

We should... Petr?

-- 
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

[Freeipa-devel] New FreeIPA official COPR URL (Re: ipa-devel repos on jdennis.fedorapeople.org)

[Martin Kosek]

On 01/04/2016 09:51 AM, Martin Kosek wrote:
> On 12/22/2015 05:37 PM, Petr Vobornik wrote:
>> On 12/22/2015 05:19 PM, Petr Spacek wrote:
>>> On 22.12.2015 17:18, John Dennis wrote:
>>>> On 12/22/2015 09:50 AM, Petr Spacek wrote:
>>>>> John, the machines which used to generate the repos are basically dead 
>>>>> now.
>>>>>
>>>>> Could you remove the directories and replace them with a README with 
>>>>> sentence
>>>>> that the repos were discontinued, please?
>>>>
>>>> I'd be happy to, but shouldn't the README contain a pointer to the 
>>>> preferred
>>>> repo/copr whatever it is now? What is it?
>>>
>>> AFAIK we do not have nightly builds yet :-(
>>>
>>> Petr, could we have some nightly or post-commit builds in Fedora Copr?
>>>
>>
>> It is easy to setup a vm for nightly copr builds.
>>
>> We should investigate a possibility of getting a project copr account. It is
>> not good to build everything in mkosek's namespace.
> 
> Makes sense. I filed a ticket for Fedora infra:
> https://fedorahosted.org/fedora-infrastructure/ticket/5048
> 
> We will see what is their suggestion.

I talked to Mirek Suchy, creator of COPR service. It looks like COPR already
supports groups, which is exactly what we want:

https://fedorahosted.org/fedora-infrastructure/ticket/5048#comment:1

I created new "freeipa" COPR alias which allows all members of "gitfreeipa" FAS
group to manage FreeIPA COPRs:

https://copr.fedoraproject.org/groups/g/freeipa/coprs/

Let this be the new FreeIPA official COPR from now on! The new version repos
and the discussed nightly repos can be there.

HTH,
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

Re: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org

[Martin Kosek]

On 12/22/2015 05:37 PM, Petr Vobornik wrote:
> On 12/22/2015 05:19 PM, Petr Spacek wrote:
>> On 22.12.2015 17:18, John Dennis wrote:
>>> On 12/22/2015 09:50 AM, Petr Spacek wrote:
 John, the machines which used to generate the repos are basically dead now.

 Could you remove the directories and replace them with a README with 
 sentence
 that the repos were discontinued, please?
>>>
>>> I'd be happy to, but shouldn't the README contain a pointer to the preferred
>>> repo/copr whatever it is now? What is it?
>>
>> AFAIK we do not have nightly builds yet :-(
>>
>> Petr, could we have some nightly or post-commit builds in Fedora Copr?
>>
> 
> It is easy to setup a vm for nightly copr builds.
> 
> We should investigate a possibility of getting a project copr account. It is
> not good to build everything in mkosek's namespace.

Makes sense. I filed a ticket for Fedora infra:
https://fedorahosted.org/fedora-infrastructure/ticket/5048

We will see what is their suggestion.

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

Re: [Freeipa-devel] [PATCH 0069] Add 'review' target for make

[Martin Kosek]

On 12/16/2015 12:01 PM, Petr Spacek wrote:
> On 16.12.2015 11:15, Martin Kosek wrote:
>> On 12/16/2015 10:02 AM, Petr Spacek wrote:
>>> On 16.12.2015 09:53, Jan Cholasta wrote:
>>>> On 16.12.2015 09:45, Petr Spacek wrote:
>>>>> On 11.12.2015 15:50, Jan Cholasta wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10.12.2015 18:04, Petr Spacek wrote:
>>>>>>> On 9.12.2015 15:30, Petr Spacek wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> this patch automates some of sanity checks proposed by Petr Vobornik.
>>>>>>>>
>>>>>>>> 'make review' should be used in root of clean Git tree which has 
>>>>>>>> patches
>>>>>>>> under
>>>>>>>> review applied.
>>>>>>>>
>>>>>>>> Magic in review.sh attempts to detect nearest remote branch which can 
>>>>>>>> be
>>>>>>>> used
>>>>>>>> as diff base for review. Please see review.sh for further details.
>>>>>>>
>>>>>>> And here is the patch! :-)
>>>>>>
>>>>>> Nice, but I would rather see this in ipatool
>>>>>> (<https://github.com/freeipa/freeipa-tools>). Or is there any obvious 
>>>>>> benefit
>>>>>> in having this in freeipa itself that I'm missing?
>>>>>
>>>>> For me the obvious benefit is:
>>>>> git clone
>>>>> git am
>>>>> make review
>>>>>
>>>>> Done.
>>>>>
>>>>> No need to find & learn other tool, no risk of using wrong version of the 
>>>>> tool
>>>>> to wrong version of source tree etc.
>>>>
>>>> AFAIK all IPA developers are supposed to use ipatool, and it already has a
>>>
>>> Good to know. How does a newcomer learn about it? Honestly I never used
>>> ipatool (or not even cloned it).
>>
>> ipatool targets rather upstream members with write access, so they are hardly
>> newcomers.
> 
> I though that we want to make it easy to contribute, so why are you talking
> about core developers?

I was mostly refering to ipatool's "push" command that I mostly used, but it's
true there is also "start-review" or "am" commands that could be useful to
others too.

> Shouldn't we make it easy to self-review own patches for everyone? Including
> random people who want to submit few patches and go away? (Think how we can
> apply usability principles to development.)

We should, I hope my reply did not suggest otherwise.

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