[Freeipa-devel] [freeipa PR#542][comment] Implementation independent interface for CSR generation

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/542
Title: #542: Implementation independent interface for CSR generation

HonzaCholasta commented:
"""
* Maybe I'm missing something, but the intent behind the 
CertificationRequestInfo-based interface was to replace all of the different 
helpers with a single way of generating CSRs, so it seems a bit strange to me 
that you are adding another helper for it.
* I would rather avoid creating new, similar but slightly incompatible 
configuration format. If you can copy code from certmonger, you can copy code 
from openssl req too, no?
* The idea was indeed to implement this in Python using CFFI to call into 
OpenSSL library functions.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/542#issuecomment-284647475
-- 
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 PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/531
Title: #531: httpinstance: disable system trust module in /etc/httpd/alias

HonzaCholasta commented:
"""
The conflict between master and replica exists because on the master, client 
install is executed last, but on (domain level 1+) replica it is executed 
first, so on the master `/etc/httpd/alias` is populated first and 
`/etc/pki/ca-trust/source/ipa.p11-kit` is created later, but on (domain level 
1+) replica it is done the other way around.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/531#issuecomment-284626499
-- 
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] Karma Requests for pki-core-10.3.5-13

[Matthew Harmsen]

*The following updated candidate builds of pki-core 10.3.5 were generated:*

 * *Fedora 24:*
 o *pki-core-10.3.5-13.fc24
   
   *
 * *Fedora 25:*
 o *pki-core-10.3.5-13.fc25
   
   *
 * ***Fedora 26:*
 o *pki-core-10.3.5-13.fc26
   
   *
 * *Fedora 27 (rawhide):*
 o *pki-core-10.3.5-13.fc27
   *

*These builds address the following PKI TRAC tickets:*

 * *dogtagpki Pagure Issue #1710 - Add profile component that copies CN
   to SAN *

*Please provide Karma for the following builds:*

 * *Fedora 24:*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2017-9ded483357
   pki-core-10.3.5-13.fc24*
 * *Fedora 25:*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2017-4f3325addf
   pki-core-10.3.5-13.fc25
   *
 * *Fedora 26:*
 o *https://bodhi.fedoraproject.org/updates/FEDORA-2017-e0afc56a2c
   pki-core-10.3.5-13.fc26
   
   *

-- 
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 PR#543][synchronized] Add options to allow ticket caching

[simo5]

   URL: https://github.com/freeipa/freeipa/pull/543
Author: simo5
 Title: #543: Add options to allow ticket caching
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/543/head:pr543
git checkout pr543
From 513c118d741594bf6bab6302a4b24c23168c4c44 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 6 Mar 2017 13:46:44 -0500
Subject: [PATCH] Add options to allow ticket caching

This new option (planned to land in gssproxy 0.7) we cache the ldap
ticket properly and avoid a ticket lookup to the KDC on each and every
ldap connection. (Also requires krb5 libs 1.15.1 to benefit from caching).

Signed-off-by: Simo Sorce 
---
 install/share/gssproxy.conf.template | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/install/share/gssproxy.conf.template b/install/share/gssproxy.conf.template
index fbb158a..9d11100 100644
--- a/install/share/gssproxy.conf.template
+++ b/install/share/gssproxy.conf.template
@@ -4,6 +4,7 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_protocol_transition = true
+  allow_client_ccache_sync = true
   cred_usage = both
   euid = $HTTPD_USER
 
@@ -12,5 +13,6 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_constrained_delegation = true
+  allow_client_ccache_sync = true
   cred_usage = initiate
   euid = $IPAAPI_USER
-- 
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 PR#543][synchronized] Add options to allow ticket caching

[simo5]

   URL: https://github.com/freeipa/freeipa/pull/543
Author: simo5
 Title: #543: Add options to allow ticket caching
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/543/head:pr543
git checkout pr543
From 513c118d741594bf6bab6302a4b24c23168c4c44 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 6 Mar 2017 13:46:44 -0500
Subject: [PATCH 1/3] Add options to allow ticket caching

This new option (planned to land in gssproxy 0.7) we cache the ldap
ticket properly and avoid a ticket lookup to the KDC on each and every
ldap connection. (Also requires krb5 libs 1.15.1 to benefit from caching).

Signed-off-by: Simo Sorce 
---
 install/share/gssproxy.conf.template | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/install/share/gssproxy.conf.template b/install/share/gssproxy.conf.template
index fbb158a..9d11100 100644
--- a/install/share/gssproxy.conf.template
+++ b/install/share/gssproxy.conf.template
@@ -4,6 +4,7 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_protocol_transition = true
+  allow_client_ccache_sync = true
   cred_usage = both
   euid = $HTTPD_USER
 
@@ -12,5 +13,6 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_constrained_delegation = true
+  allow_client_ccache_sync = true
   cred_usage = initiate
   euid = $IPAAPI_USER

From 34553627ebd709dea371030b03607c9c167732b0 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 6 Mar 2017 14:19:30 -0500
Subject: [PATCH 2/3] Use GSS-SPNEGO if connecting locally

GSS-SPNEGO allows us to negotiate a sasl bind with less roundrtrips
therefore use it when possible.

We only enable it for local connections for now because we only
recently fixed Cyrus SASL to do proper GSS-SPNEGO negotiation. This
change means a newer and an older version are not compatible.

Restricting ourselves to the local host prevents issues with
incomaptible services, and it is ok for us as we are only really lloking
at speedups for the local shortlived connections performed by the
framework. Most other clients have llonger lived connections, so
peformance improvements there are not as important.

Signed-off-by: Simo Sorce 
---
 ipapython/ipaldap.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ipapython/ipaldap.py b/ipapython/ipaldap.py
index 82d45b9..b158598 100644
--- a/ipapython/ipaldap.py
+++ b/ipapython/ipaldap.py
@@ -52,6 +52,7 @@
 
 # Global variable to define SASL auth
 SASL_GSSAPI = ldap.sasl.sasl({}, 'GSSAPI')
+SASL_GSS_SPNEGO = ldap.sasl.sasl({}, 'GSS-SPNEGO')
 
 _debug_log_ldap = False
 
@@ -1112,7 +1113,10 @@ def gssapi_bind(self, server_controls=None, client_controls=None):
 Perform SASL bind operation using the SASL GSSAPI mechanism.
 """
 with self.error_handler():
-auth_tokens = ldap.sasl.sasl({}, 'GSSAPI')
+if self._protocol == 'ldapi':
+auth_tokens = SASL_GSS_SPNEGO
+else:
+auth_tokens = SASL_GSSAPI
 self._flush_schema()
 self.conn.sasl_interactive_bind_s(
 '', auth_tokens, server_controls, client_controls)

From 4a9b4a7769e36890f95d87053388579928088dd3 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 6 Mar 2017 18:47:56 -0500
Subject: [PATCH 3/3] Store session cookie in a ccache option

Instead of using the kernel keyring,s tore the session cookie within the
ccache. This way kdestroy will really wipe away all creedntials.

Ticket: https://pagure.io/freeipa/issue/6661

Signed-off-by: Simo Sorce 
---
 ipalib/rpc.py   |  30 ++
 ipapython/ccache_storage.py | 234 
 2 files changed, 242 insertions(+), 22 deletions(-)
 create mode 100644 ipapython/ccache_storage.py

diff --git a/ipalib/rpc.py b/ipalib/rpc.py
index 8d1bba5..be31333 100644
--- a/ipalib/rpc.py
+++ b/ipalib/rpc.py
@@ -56,7 +56,7 @@
 from ipalib.request import context, Connection
 from ipapython.ipa_log_manager import root_logger
 from ipapython import ipautil
-from ipapython import kernel_keyring
+from ipapython import ccache_storage
 from ipapython.cookie import Cookie
 from ipapython.dnsutil import DNSName
 from ipalib.text import _
@@ -84,19 +84,11 @@
 unicode = str
 
 COOKIE_NAME = 'ipa_session'
-KEYRING_COOKIE_NAME = '%s_cookie:%%s' % COOKIE_NAME
+CCACHE_COOKIE_KEY_NAME = 'X-IPA-Session-Cookie'
 
 errors_by_code = dict((e.errno, e) for e in public_errors)
 
 
-def client_session_keyring_keyname(principal):
-'''
-Return the key name used for storing the client session data for
-the given principal.
-'''
-
-return KEYRING_COOKIE_NAME % principal
-
 def update_persistent_client_session_data(principal, data):
 '''
 Given a principal create or update the session data for that
@@ 

Re: [Freeipa-devel] [DISCUSSION] checking *lint at configure time

[Lukas Slebodnik]

On (06/03/17 14:36), Tomas Krizek wrote:
>> I am sorry but I still did not get your point. Could you a little bit
>> ellaborate?
>In this case - build won't fail when you don't have the dependencies for
>linters.
But it will be *easier* to develop on other distributions if they run
"make lint". Therefore default should be yes.

And it there is a super-hero developers who wrote perfect code
and does not need run make lint then he/she can run
./configure --disable-pylint to skip check for installed pylint.

It would be clear enough after improving error message for missing pylint.

>> B) it is not just an optional dependency. I tried to explain in 1st mail
>> that it should be a recomended dependency.
>I agree it's recommended.
But would not be with current version of PR#502.

>> C) Could you explain how it will be easier to develop on debian/other
>> distribution if upstream does not recommend to run "make lint".
>It probably doesn't make it easier to develop for other distributions.
>But it may be easier for a new upstream contributor, when building the
>project doesn't require any extra dependencies.
>
The simplest way for new developers is to follow BUILD.txt. (use fedora :-)
And instructions there recommend to install all dependencies including pylint.
So they(new upstream contributors) would not be affected by missing pylint.
But people who would like to port freeipa on other distributions would be
affected by changing default from yes -> autodetect.

LS

-- 
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] [DISCUSSION] checking *lint at configure time

[Lukas Slebodnik]

On (06/03/17 14:38), Christian Heimes wrote:
>> B) it is not just an optional dependency. I tried to explain in 1st mail
>> that it should be a recomended dependency.
>
>Recommended != required
>
{Py,js}lint are not required ATM.
Just error message from configure is poorly phrased.

>Linting is a recommended tool for development. It's a totally optional
>thing for building and installing FreeIPA. The RPM spec is the best
>proof for that. Linting is not even a required tool for development. CI
>takes care of linting.
>
CI does not care of linting on other distributions.
At the moment lint is executed only on f25 in travis
(f26 of fedora rawhide, el7 are not covered)

ATM everything is fedora focused even BUILD.txt which is not ideal
from upstream POV. Therefore default checks in configure should not be focused
just for fedora.

>> C) Could you explain how it will be easier to develop on debian/other
>> distribution if upstream does not recommend to run "make lint".
>
>My PR does not discourage `make lint`.
>
But it does not recommend it; because missing pylint it is skipped with
combo "./configure && make install." in PR#502

So potential developers on other distributions needn't notice it
and with your PR they will not be able to run "make pylint"
in such situation; because the target will be disabled in case of
missing pylint.

Summary:
rcrit, jcholast[1] and lslebodn think that it is better for upstream
to have default yes.

cheimes(you) and tkrizek prefer autodetection.

Democracy works. Please do not change default value and
improve error messages with hint how to disable the optional
*lint dependencies at configure time.

LS

[1] https://github.com/freeipa/freeipa/pull/502#issuecomment-283569745

-- 
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 PR#543][opened] Add options to allow ticket caching

[simo5]

   URL: https://github.com/freeipa/freeipa/pull/543
Author: simo5
 Title: #543: Add options to allow ticket caching
Action: opened

PR body:
"""
This new option (planned to land in gssproxy 0.7) we cache the ldap
ticket properly and avoid a ticket lookup to the KDC on each and every
ldap connection. (Also requires krb5 libs 1.15.1 to benefit from caching).

NOTE: It is safe to apply this to master, if gssproxy does not support this 
option it simply is ignored.
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/543/head:pr543
git checkout pr543
From 513c118d741594bf6bab6302a4b24c23168c4c44 Mon Sep 17 00:00:00 2001
From: Simo Sorce 
Date: Mon, 6 Mar 2017 13:46:44 -0500
Subject: [PATCH] Add options to allow ticket caching

This new option (planned to land in gssproxy 0.7) we cache the ldap
ticket properly and avoid a ticket lookup to the KDC on each and every
ldap connection. (Also requires krb5 libs 1.15.1 to benefit from caching).

Signed-off-by: Simo Sorce 
---
 install/share/gssproxy.conf.template | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/install/share/gssproxy.conf.template b/install/share/gssproxy.conf.template
index fbb158a..9d11100 100644
--- a/install/share/gssproxy.conf.template
+++ b/install/share/gssproxy.conf.template
@@ -4,6 +4,7 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_protocol_transition = true
+  allow_client_ccache_sync = true
   cred_usage = both
   euid = $HTTPD_USER
 
@@ -12,5 +13,6 @@
   cred_store = keytab:$HTTP_KEYTAB
   cred_store = client_keytab:$HTTP_KEYTAB
   allow_constrained_delegation = true
+  allow_client_ccache_sync = true
   cred_usage = initiate
   euid = $IPAAPI_USER
-- 
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 PR#516][comment] IdM Server: list all Employees with matching Smart Card

[flo-renaud]

  URL: https://github.com/freeipa/freeipa/pull/516
Title: #516: IdM Server: list all Employees with matching Smart Card

flo-renaud commented:
"""
Hi @HonzaCholasta 
thank you for your comments. Patch rebased.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/516#issuecomment-284487975
-- 
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 PR#516][synchronized] IdM Server: list all Employees with matching Smart Card

[flo-renaud]

   URL: https://github.com/freeipa/freeipa/pull/516
Author: flo-renaud
 Title: #516: IdM Server: list all Employees with matching Smart Card
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/516/head:pr516
git checkout pr516
From b3ec9b90d80171bda58dbeded59ae6e400dbc7ec Mon Sep 17 00:00:00 2001
From: Florence Blanc-Renaud 
Date: Thu, 23 Feb 2017 18:04:47 +0100
Subject: [PATCH] IdM Server: list all Employees with matching Smart Card

Implement a new IPA command allowing to retrieve the list of users matching
the provided certificate.
The command is using SSSD Dbus interface, thus including users from IPA
domain and from trusted domains. This requires sssd-dbus package to be
installed on IPA server.

https://fedorahosted.org/freeipa/ticket/6646
---
 API.txt  |  12 
 freeipa.spec.in  |   2 +
 ipaserver/plugins/certmap.py | 160 ++-
 3 files changed, 173 insertions(+), 1 deletion(-)

diff --git a/API.txt b/API.txt
index a8f8ff1..ace3101 100644
--- a/API.txt
+++ b/API.txt
@@ -824,6 +824,16 @@ option: Str('version?')
 output: Entry('result')
 output: Output('summary', type=[, ])
 output: PrimaryKey('value')
+command: certmap_match/1
+args: 1,3,4
+arg: Bytes('certificate', cli_name='certificate')
+option: Flag('all', autofill=True, cli_name='all', default=False)
+option: Flag('raw', autofill=True, cli_name='raw', default=False)
+option: Str('version?')
+output: Output('count', type=[])
+output: ListOfEntries('result')
+output: Output('summary', type=[, ])
+output: Output('truncated', type=[])
 command: certmapconfig_mod/1
 args: 0,8,3
 option: Str('addattr*', cli_name='addattr')
@@ -6517,6 +6527,8 @@ default: cert_request/1
 default: cert_revoke/1
 default: cert_show/1
 default: cert_status/1
+default: certmap/1
+default: certmap_match/1
 default: certmapconfig/1
 default: certmapconfig_mod/1
 default: certmapconfig_show/1
diff --git a/freeipa.spec.in b/freeipa.spec.in
index 5b736b6..cc7422a 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -284,6 +284,8 @@ Requires: gzip
 Requires: oddjob
 # Require 0.6.0 for the new delegation access control features
 Requires: gssproxy >= 0.6.0
+# Require 1.15.1 for the certificate identity mapping feature
+Requires: sssd-dbus >= 1.15.1
 
 Provides: %{alt_name}-server = %{version}
 Conflicts: %{alt_name}-server
diff --git a/ipaserver/plugins/certmap.py b/ipaserver/plugins/certmap.py
index c37eae3..f04b3fc 100644
--- a/ipaserver/plugins/certmap.py
+++ b/ipaserver/plugins/certmap.py
@@ -17,9 +17,14 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
 
+import base64
+import dbus
 import six
 
-from ipalib import api, errors
+from ipalib import api, errors, x509
+from ipalib import Bytes
+from ipalib.crud import Search
+from ipalib.frontend import Object
 from ipalib.parameters import Bool, DNSNameParam, Flag, Int, Str
 from ipalib.plugable import Registry
 from .baseldap import (
@@ -33,6 +38,7 @@
 pkey_to_value)
 from ipalib import _, ngettext
 from ipalib import output
+from ipaserver.plugins.service import validate_certificate
 
 
 if six.PY3:
@@ -389,3 +395,155 @@ def execute(self, cn, **options):
 result=True,
 value=pkey_to_value(cn, options),
 )
+
+
+DBUS_SSSD_NAME = 'org.freedesktop.sssd.infopipe'
+DBUS_PROPERTY_IF = 'org.freedesktop.DBus.Properties'
+DBUS_SSSD_USERS_PATH = '/org/freedesktop/sssd/infopipe/Users'
+DBUS_SSSD_USERS_IF = 'org.freedesktop.sssd.infopipe.Users'
+DBUS_SSSD_USER_IF = 'org.freedesktop.sssd.infopipe.Users.User'
+
+
+class _sssd(object):
+"""
+Auxiliary class for SSSD infopipe DBus.
+"""
+def __init__(self, log):
+"""
+Initialize the Users object and interface.
+
+   :raise RemoteRetrieveError: if DBus error occurs
+"""
+try:
+self.log = log
+self._bus = dbus.SystemBus()
+self._users_obj = self._bus.get_object(
+DBUS_SSSD_NAME, DBUS_SSSD_USERS_PATH)
+self._users_iface = dbus.Interface(
+self._users_obj, DBUS_SSSD_USERS_IF)
+except dbus.DBusException as e:
+self.log.error(
+'Failed to initialize DBus interface {iface}. DBus '
+'exception is {exc}.'.format(iface=DBUS_SSSD_USERS_IF, exc=e)
+)
+raise errors.RemoteRetrieveError(
+reason=_('Failed to connect to sssd over SystemBus. '
+ 'See details in the error_log'))
+
+def list_users_by_cert(self, cert):
+"""
+Look for users matching the cert.
+
+Call Users.ListByCertificate interface and return a dict
+with key = domain, value = list of uids
+corresponding to the users matching the provided cert
+

[Freeipa-devel] [freeipa PR#542][synchronized] Implementation independent interface for CSR generation

[LiptonB]

   URL: https://github.com/freeipa/freeipa/pull/542
Author: LiptonB
 Title: #542: Implementation independent interface for CSR generation
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/542/head:pr542
git checkout pr542
From 6f678a1c68769daf5b2f80cbf65a5b6b1c99f7a1 Mon Sep 17 00:00:00 2001
From: Ben Lipton 
Date: Fri, 7 Oct 2016 10:39:40 -0400
Subject: [PATCH 1/3] csrgen: Add "certmonger" helper to produce simplified
 openssl configs

The resulting file is similar to the config accepted by `openssl req`,
but instead of a section for the subject name, it contains a single
config item, `cm_template_subject`, in the format that certmonger
accepts for its certificate subject names.

https://pagure.io/freeipa/issue/4899
---
 install/share/csrgen/Makefile.am|  1 +
 install/share/csrgen/rules/dataDNS.json |  2 +-
 install/share/csrgen/rules/dataEmail.json   |  2 +-
 install/share/csrgen/rules/dataHostCN.json  |  2 +-
 install/share/csrgen/rules/dataSubjectBase.json |  2 +-
 install/share/csrgen/rules/dataUsernameCN.json  |  2 +-
 install/share/csrgen/rules/syntaxSAN.json   |  2 +-
 install/share/csrgen/rules/syntaxSubject.json   |  4 
 install/share/csrgen/templates/certmonger_base.tmpl | 17 +
 ipaclient/csrgen.py |  7 ++-
 10 files changed, 34 insertions(+), 7 deletions(-)
 create mode 100644 install/share/csrgen/templates/certmonger_base.tmpl

diff --git a/install/share/csrgen/Makefile.am b/install/share/csrgen/Makefile.am
index 12c62c4..53324fe 100644
--- a/install/share/csrgen/Makefile.am
+++ b/install/share/csrgen/Makefile.am
@@ -20,6 +20,7 @@ rule_DATA =\
 templatedir = $(IPA_DATA_DIR)/csrgen/templates
 template_DATA =			\
 	templates/certutil_base.tmpl	\
+	templates/certmonger_base.tmpl	\
 	templates/openssl_base.tmpl	\
 	templates/openssl_macros.tmpl	\
 	$(NULL)
diff --git a/install/share/csrgen/rules/dataDNS.json b/install/share/csrgen/rules/dataDNS.json
index 2663f11..263eae0 100644
--- a/install/share/csrgen/rules/dataDNS.json
+++ b/install/share/csrgen/rules/dataDNS.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "DNS = {{subject.krbprincipalname.0.partition('/')[2].partition('@')[0]}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataEmail.json b/install/share/csrgen/rules/dataEmail.json
index 2eae9fb..5c4dbe8 100644
--- a/install/share/csrgen/rules/dataEmail.json
+++ b/install/share/csrgen/rules/dataEmail.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "email = {{subject.mail.0}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataHostCN.json b/install/share/csrgen/rules/dataHostCN.json
index 5c415bb..8c17e8a 100644
--- a/install/share/csrgen/rules/dataHostCN.json
+++ b/install/share/csrgen/rules/dataHostCN.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "CN={{subject.krbprincipalname.0.partition('/')[2].partition('@')[0]}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataSubjectBase.json b/install/share/csrgen/rules/dataSubjectBase.json
index 309dfb1..489dd49 100644
--- a/install/share/csrgen/rules/dataSubjectBase.json
+++ b/install/share/csrgen/rules/dataSubjectBase.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "{{config.ipacertificatesubjectbase.0}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataUsernameCN.json b/install/share/csrgen/rules/dataUsernameCN.json
index 37e7e01..d294ab2 100644
--- a/install/share/csrgen/rules/dataUsernameCN.json
+++ b/install/share/csrgen/rules/dataUsernameCN.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "CN={{subject.uid.0}}"
 },
 {
diff --git a/install/share/csrgen/rules/syntaxSAN.json b/install/share/csrgen/rules/syntaxSAN.json
index 122eb12..00b1808 100644
--- a/install/share/csrgen/rules/syntaxSAN.json
+++ b/install/share/csrgen/rules/syntaxSAN.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "subjectAltName = @{% call openssl.section() %}{{ datarules|join('\n') }}{% endcall %}",
   "options": {
 "extension": true
diff --git a/install/share/csrgen/rules/syntaxSubject.json b/install/share/csrgen/rules/syntaxSubject.json
index af6ec03..1eb02e9 100644
--- a/install/share/csrgen/rules/syntaxSubject.json
+++ b/install/share/csrgen/rules/syntaxSubject.json
@@ -5,6 +5,10 @@
   "template": "distinguished_name = {% call openssl.section() %}{{ 

[Freeipa-devel] [freeipa PR#542][opened] Implementation independent interface for CSR generation

[LiptonB]

   URL: https://github.com/freeipa/freeipa/pull/542
Author: LiptonB
 Title: #542: Implementation independent interface for CSR generation
Action: opened

PR body:
"""
@HonzaCholasta and everyone, here is where I am so far on the 
[CertificationRequestInfo-based interface for CSR 
generation](https://www.redhat.com/archives/freeipa-devel/2017-February/msg00104.html).

As I see it, there are a few rough edges still, so I'd like to get your 
opinion, especially about these things:
- For feeding to `build_requestinfo` we want a config file, not a script, so I 
needed to add another formatter/helper that omits the bash code that's there 
for other helpers.
- While openssl has a library function for creating cert extensions from the 
config file format, the logic for creating the subject name from the config 
format is implemented within the `openssl req` command rather than the library. 
In `build_requestinfo` I copied [the code from 
certmonger](https://pagure.io/certmonger/blob/master/f/src/csrgen-o.c#_193-223) 
that creates the subject name, which takes a simpler format. So the new 
formatter is called "certmonger" and uses that format.
- I'm not sure where in the freeipa project the code for `build_requestinfo` 
should go, how to work it into the build process, and where it should be 
installed. Right now I just have a TODO to do so. Or did you mean for that code 
to be run via CFFI as well?
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/542/head:pr542
git checkout pr542
From 6f678a1c68769daf5b2f80cbf65a5b6b1c99f7a1 Mon Sep 17 00:00:00 2001
From: Ben Lipton 
Date: Fri, 7 Oct 2016 10:39:40 -0400
Subject: [PATCH 1/3] csrgen: Add "certmonger" helper to produce simplified
 openssl configs

The resulting file is similar to the config accepted by `openssl req`,
but instead of a section for the subject name, it contains a single
config item, `cm_template_subject`, in the format that certmonger
accepts for its certificate subject names.

https://pagure.io/freeipa/issue/4899
---
 install/share/csrgen/Makefile.am|  1 +
 install/share/csrgen/rules/dataDNS.json |  2 +-
 install/share/csrgen/rules/dataEmail.json   |  2 +-
 install/share/csrgen/rules/dataHostCN.json  |  2 +-
 install/share/csrgen/rules/dataSubjectBase.json |  2 +-
 install/share/csrgen/rules/dataUsernameCN.json  |  2 +-
 install/share/csrgen/rules/syntaxSAN.json   |  2 +-
 install/share/csrgen/rules/syntaxSubject.json   |  4 
 install/share/csrgen/templates/certmonger_base.tmpl | 17 +
 ipaclient/csrgen.py |  7 ++-
 10 files changed, 34 insertions(+), 7 deletions(-)
 create mode 100644 install/share/csrgen/templates/certmonger_base.tmpl

diff --git a/install/share/csrgen/Makefile.am b/install/share/csrgen/Makefile.am
index 12c62c4..53324fe 100644
--- a/install/share/csrgen/Makefile.am
+++ b/install/share/csrgen/Makefile.am
@@ -20,6 +20,7 @@ rule_DATA =\
 templatedir = $(IPA_DATA_DIR)/csrgen/templates
 template_DATA =			\
 	templates/certutil_base.tmpl	\
+	templates/certmonger_base.tmpl	\
 	templates/openssl_base.tmpl	\
 	templates/openssl_macros.tmpl	\
 	$(NULL)
diff --git a/install/share/csrgen/rules/dataDNS.json b/install/share/csrgen/rules/dataDNS.json
index 2663f11..263eae0 100644
--- a/install/share/csrgen/rules/dataDNS.json
+++ b/install/share/csrgen/rules/dataDNS.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "DNS = {{subject.krbprincipalname.0.partition('/')[2].partition('@')[0]}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataEmail.json b/install/share/csrgen/rules/dataEmail.json
index 2eae9fb..5c4dbe8 100644
--- a/install/share/csrgen/rules/dataEmail.json
+++ b/install/share/csrgen/rules/dataEmail.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "email = {{subject.mail.0}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataHostCN.json b/install/share/csrgen/rules/dataHostCN.json
index 5c415bb..8c17e8a 100644
--- a/install/share/csrgen/rules/dataHostCN.json
+++ b/install/share/csrgen/rules/dataHostCN.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "CN={{subject.krbprincipalname.0.partition('/')[2].partition('@')[0]}}"
 },
 {
diff --git a/install/share/csrgen/rules/dataSubjectBase.json b/install/share/csrgen/rules/dataSubjectBase.json
index 309dfb1..489dd49 100644
--- a/install/share/csrgen/rules/dataSubjectBase.json
+++ b/install/share/csrgen/rules/dataSubjectBase.json
@@ -1,7 +1,7 @@
 {
   "rules": [
 {
-  "helper": "openssl",
+  "helper": ["openssl", "certmonger"],
   "template": "{{config.ipacertificatesubjectbase.0}}"
   

[Freeipa-devel] [freeipa PR#504][comment] Add SHA256 fingerprints

[tomaskrizek]

  URL: https://github.com/freeipa/freeipa/pull/504
Title: #504: Add SHA256 fingerprints

tomaskrizek commented:
"""
I think this is a translation issue that will resolve itself once we generate 
new translation files. Is that correct, @MartinBasti ?

When using `make install` that regenerates `*.po`, I get this output:

```
Serial number: 1
  Issuing CA: ipa
  Certificate: 
  Subject: CN=Certificate Authority,O=DOM-058-176.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Issuer: CN=Certificate Authority,O=DOM-058-176.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Not Before: Mon Mar 06 17:05:49 2017 UTC
  Not After: Fri Mar 06 17:05:49 2037 UTC
  Fingerprint (SHA1): 
4c:49:28:74:82:94:30:1c:0e:f6:b2:30:2b:91:90:6c:73:bb:c1:d8
  Fingerprint (SHA256): 
52:d3:3b:5e:70:63:d0:6c:6f:4d:90:a4:bf:50:18:0b:7a:0c:ab:11:45:cf:05:7d:98:d6:e8:b1:bc:e0:9e:a9
  Serial number: 1
  Serial number (hex): 0x1
  Revoked: False
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/504#issuecomment-284464681
-- 
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] gssproxy-0.6.2-2 broken

[Robbie Harwood]

Standa Laznicka  writes:

> Hello,
>
> Current gssproxy in Fedora 25 "updates" repository (gssproxy-0.6.2-2) is 
> broken. For a freshly-installed IPA server, the infamous error
>
> "ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may 
> provide more information, Minor (2598845123): No credentials cache 
> found" will appear. 100% reproducible.
>
> Please use the gssproxy-0.6.2-1 from @freeipa/freeipa-master repository 
> instead. Note that downgrade + gssproxy service restart works.

Hi, thanks for letting us know.  In the future it would be better to
provide negative karma to the update and file a bugzilla.

Please try gssproxy-0.6.2-4 from updates, and hopefully it will work
better for you.


signature.asc
Description: PGP signature
-- 
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 PR#433][synchronized] csrgen: Allow some certificate fields to be specified by the user

[LiptonB]

   URL: https://github.com/freeipa/freeipa/pull/433
Author: LiptonB
 Title: #433: csrgen: Allow some certificate fields to be specified by the user
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/433/head:pr433
git checkout pr433
From 3da67abcba6af0409a1195efd60581f6b28ad217 Mon Sep 17 00:00:00 2001
From: Ben Lipton 
Date: Thu, 28 Jul 2016 16:21:44 -0400
Subject: [PATCH 1/3] csrgen: Implement fields that prompt user for data

Allows some data to be user-specified rather than coming out of the
database. The provided data can be formatted with jinja2 rules just as
database values can.

https://fedorahosted.org/freeipa/ticket/4899
---
 install/share/csrgen/Makefile.am   |  1 +
 .../share/csrgen/rules/dataEmailUserSpecified.json | 16 ++
 ipaclient/csrgen.py| 35 --
 ipaclient/plugins/csrgen.py|  9 --
 ipatests/test_ipaclient/test_csrgen.py | 15 +-
 5 files changed, 65 insertions(+), 11 deletions(-)
 create mode 100644 install/share/csrgen/rules/dataEmailUserSpecified.json

diff --git a/install/share/csrgen/Makefile.am b/install/share/csrgen/Makefile.am
index 12c62c4..ad4412e 100644
--- a/install/share/csrgen/Makefile.am
+++ b/install/share/csrgen/Makefile.am
@@ -10,6 +10,7 @@ ruledir = $(IPA_DATA_DIR)/csrgen/rules
 rule_DATA =\
 	rules/dataDNS.json		\
 	rules/dataEmail.json		\
+	rules/dataEmailUserSpecified.json	\
 	rules/dataHostCN.json		\
 	rules/dataUsernameCN.json	\
 	rules/dataSubjectBase.json	\
diff --git a/install/share/csrgen/rules/dataEmailUserSpecified.json b/install/share/csrgen/rules/dataEmailUserSpecified.json
new file mode 100644
index 000..3fb2fb1
--- /dev/null
+++ b/install/share/csrgen/rules/dataEmailUserSpecified.json
@@ -0,0 +1,16 @@
+{
+  "rules": [
+{
+  "helper": "openssl",
+  "template": "email = {{userdata.email}}"
+},
+{
+  "helper": "certutil",
+  "template": "email:{{userdata.email|quote}}"
+}
+  ],
+  "options": {
+"data_source": "userdata.email",
+"prompt": "Email address"
+  }
+}
diff --git a/ipaclient/csrgen.py b/ipaclient/csrgen.py
index 96100ae..f00cc10 100644
--- a/ipaclient/csrgen.py
+++ b/ipaclient/csrgen.py
@@ -345,8 +345,9 @@ class CSRGenerator(object):
 def __init__(self, rule_provider):
 self.rule_provider = rule_provider
 
-def csr_script(self, principal, config, profile_id, helper):
-render_data = {'subject': principal, 'config': config}
+def csr_script(self, principal, config, userdata, profile_id, helper):
+render_data = {
+'subject': principal, 'config': config, 'userdata': userdata}
 
 formatter = self.FORMATTERS[helper]()
 rules = self.rule_provider.rules_for_profile(profile_id, helper)
@@ -360,3 +361,33 @@ def csr_script(self, principal, config, profile_id, helper):
 'Template error when formatting certificate data'))
 
 return script
+
+def get_user_prompts(self, profile_id, helper):
+prompts = {}
+rules = self.rule_provider.rules_for_profile(profile_id, helper)
+
+for field_mapping in rules:
+for rule in field_mapping.data_rules:
+if 'prompt' in rule.options:
+try:
+var = rule.options['data_source']
+except KeyError:
+raise errors.CSRTemplateError(reason=_(
+'Certificate mapping rule %(rule)s has a prompt'
+' but no data_source set') % {'rule': rule.name})
+if var in prompts:
+raise errors.CSRTemplateError(reason=_(
+'More than one data rule in this profile prompts'
+' for the %(item)s data item') % {'item': var})
+var_parts = var.split('.')
+if len(var_parts) != 2 or var_parts[0] != 'userdata':
+raise errors.CSRTemplateError(
+reason=_(
+'Format of variable name in rule %(rule)s is'
+' incorrect. Rules that prompt for data must'
+' use a variable "userdata."') %
+{'rule': rule.name})
+
+prompts[var_parts[1]] = rule.options['prompt']
+
+return prompts
diff --git a/ipaclient/plugins/csrgen.py b/ipaclient/plugins/csrgen.py
index 0d6eca0..e8563e5 100644
--- a/ipaclient/plugins/csrgen.py
+++ b/ipaclient/plugins/csrgen.py
@@ -85,6 +85,9 @@ def execute(self, *args, **options):
 if not backend.isconnected():
 backend.connect()
 
+generator = CSRGenerator(FileRuleProvider())
+prompts = generator.get_user_prompts(profile_id, helper)
+
 

[Freeipa-devel] [freeipa PR#537][comment] test_csrgen: adjusted comparison test scripts for CSRGenerator

[LiptonB]

  URL: https://github.com/freeipa/freeipa/pull/537
Title: #537: test_csrgen: adjusted comparison test scripts for CSRGenerator

LiptonB commented:
"""
Thanks for catching this, sorry about the breakage. The change looks good to me.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/537#issuecomment-284432624
-- 
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] [DISCUSSION] checking *lint at configure time

[Rob Crittenden]

Tomas Krizek wrote:
> On 03/03/2017 09:22 PM, Rob Crittenden wrote:
>> Lukas Slebodnik wrote:
>>> On (03/03/17 17:07), Lukas Slebodnik wrote:
 ehlo,

 This is a small continuation fo discussin from pull request
 "Make pylint and jsl optional" #502[1]

 Pylint and jslint are already optional because some downstream 
 distributions
 does not have such packages. This is a reason why desing document[2]
 mention configuration options for disabling them.
   --disable-pylint --without-jslint

 Previusly (4.4) "pylint was executed" before building rpm packages.
 This strict requirement was changed because "make lint" is executed
 with each pull request in travis.

 It was changed in commits
 master:

 * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix detection of 
 pylint
 * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update help message 
 for jslint
 * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock

 The main intention of PR#502 [1] is to make it even more optional
 and do not fail if pylint is not installed on machine.
 In another words, changing default value from "yes" to "autodetect".
 I think the main reason is that it is not obvious that it is an optional
 dependency if you run just "./configure". But that can be improved with
 better error message. @see attachments.
>> I was going to go into a history of why it was required (we pushed
>> broken changes into master) but in retrospect that doesn't really
>> matter. I've been out of mainline development for some time so don't
>> know your current processes, but I do have a question:
>>
>> Is it expected that ./configure && make && make install will result in
>> the bits in all the right places? We never had that expectation before
>> though I know Christian has been moving in that direction. Is that an
>> end goal? It would be nice for developing in-tree and pushing out micro
>> changes onto the current, live development system.
> If you provide correct paths to ./configure, yes - make && make install
> will place all the bits in the right places. I commonly use it with
> DESTDIR and sshfs, so I can develop locally and deploy to a remote
> machine without building RPMs.
>> If so, does it have checks for all the runtime dependencies or will you
>> still have to do a bunch of work afterward the make install?
> It doesn't check runtime dependencies. I install the freeipa rpms once
> to install dependencies and then use make && make install.
>> I've seen discussions about making freeIPA more accessible to the
>> average developer, which is good, but it is just so more complex than
>> the typical software because it is more about integration than most big
>> projects. So I don't know that this is every going to really be true.
>> Will it help the average dev install it? Sure, but then what? Will you
>> support such an install?
>>
>> If you want to disable the checks for *lint that is certainly your
>> prerogative but I see some downsides:
>>
>> - I used to setup new dev systems all the time and this is definitely
>> something I'd forget to do with some frequency
>> - As I understand it the checks will be executed by upstream before a
>> change is accepted so that's good but it adds a huge delay and the
>> requirement of a roundtrip to fix simple mistakes (happens all the time
>> in OpenStack).
> On-PR checks can handle this. When you need to fix a linter issue, you
> can install the dependencies and run make lint locally.
>> I think my question boils down to how many people will this actually
>> benefit vs how much time will be lost resubmitting patches? I don't
>> think there is an easy answer for the first part but from my own
>> experience I'd expect fairly regularly for lint and pep8 errors.
> If someone often has this issue, the workflow can be modified to address
> it. For example, I've configured my repo to run to run pylint and pep8
> on the modified files before the commit.
>> On the other hand I guess this also will have the additional advantage
>> that make rpms will be significantly faster if you don't enable them.
>>
>> The --disable vs --without is what bugs me most about the current
>> situation :-)
>>
>> So in closing I'd just say that we made those checks mandatory for a
>> reason. Maybe that reason is no longer applicable with all the current
>> automation but I'd personally prefer Lukas's suggestion of requiring
>> them by default but providing clear output on how to disable them if
>> desired. This way the average user can easily work around it and it
>> won't impact current developers (unless they want it to). Is that as
>> simple as configure; make; make install? No, but it isn't a huge leap
>> either.
>>
>> rob
>>
> I prefer Christian's approach that makes the project more upstream-friendly.
> 
> I think changing the default from "yes" to "autodetect" negatively
> affects packagers, but it 

[Freeipa-devel] [freeipa PR#534][comment] Move csrgen templates into ipaclient package

[LiptonB]

  URL: https://github.com/freeipa/freeipa/pull/534
Title: #534: Move csrgen templates into ipaclient package

LiptonB commented:
"""
I think this is a much better way to make it configurable than how I had it, 
and the implementation looks good to me. Thanks!
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/534#issuecomment-284427183
-- 
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 PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias

[rcritten]

  URL: https://github.com/freeipa/freeipa/pull/531
Title: #531: httpinstance: disable system trust module in /etc/httpd/alias

rcritten commented:
"""
Just FYI I'm opening an upstream discussion with the NSS team on this. It is 
very strange that there is a conflict like this, particularly between master 
and replica.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/531#issuecomment-284414651
-- 
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 PR#531][comment] httpinstance: disable system trust module in /etc/httpd/alias

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/531
Title: #531: httpinstance: disable system trust module in /etc/httpd/alias

HonzaCholasta commented:
"""
Yes. That is, once https://pagure.io/freeipa/issue/4639 is fixed.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/531#issuecomment-284404665
-- 
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] [DISCUSSION] checking *lint at configure time

[Tomas Krizek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/06/2017 02:10 PM, Lukas Slebodnik wrote:
> On (06/03/17 13:49), Tomas Krizek wrote:
>> On 03/06/2017 01:44 PM, Lukas Slebodnik wrote:
>>> On (06/03/17 13:35), Tomas Krizek wrote:
 On 03/03/2017 09:22 PM, Rob Crittenden wrote:
> Lukas Slebodnik wrote:
>> On (03/03/17 17:07), Lukas Slebodnik wrote:
>>> ehlo,
>>>
>>> This is a small continuation fo discussin from pull request
>>> "Make pylint and jsl optional" #502[1]
>>>
>>> Pylint and jslint are already optional because some downstream
distributions
>>> does not have such packages. This is a reason why desing document[2]
>>> mention configuration options for disabling them.
>>>   --disable-pylint --without-jslint
>>>
>>> Previusly (4.4) "pylint was executed" before building rpm packages.
>>> This strict requirement was changed because "make lint" is executed
>>> with each pull request in travis.
>>>
>>> It was changed in commits
>>> master:
>>>
>>> * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix
detection of pylint
>>> * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update
help message for jslint
>>> * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock
>>>
>>> The main intention of PR#502 [1] is to make it even more optional
>>> and do not fail if pylint is not installed on machine.
>>> In another words, changing default value from "yes" to "autodetect".
>>> I think the main reason is that it is not obvious that it is an
optional
>>> dependency if you run just "./configure". But that can be
improved with
>>> better error message. @see attachments.
> I was going to go into a history of why it was required (we pushed
> broken changes into master) but in retrospect that doesn't really
> matter. I've been out of mainline development for some time so don't
> know your current processes, but I do have a question:
>
> Is it expected that ./configure && make && make install will result in
> the bits in all the right places? We never had that expectation before
> though I know Christian has been moving in that direction. Is that an
> end goal? It would be nice for developing in-tree and pushing out
micro
> changes onto the current, live development system.
 If you provide correct paths to ./configure, yes - make && make install
 will place all the bits in the right places. I commonly use it with
 DESTDIR and sshfs, so I can develop locally and deploy to a remote
 machine without building RPMs.
> If so, does it have checks for all the runtime dependencies or
will you
> still have to do a bunch of work afterward the make install?
 It doesn't check runtime dependencies. I install the freeipa rpms once
 to install dependencies and then use make && make install.
> I've seen discussions about making freeIPA more accessible to the
> average developer, which is good, but it is just so more complex than
> the typical software because it is more about integration than
most big
> projects. So I don't know that this is every going to really be true.
> Will it help the average dev install it? Sure, but then what? Will you
> support such an install?
>
> If you want to disable the checks for *lint that is certainly your
> prerogative but I see some downsides:
>
> - I used to setup new dev systems all the time and this is definitely
> something I'd forget to do with some frequency
> - As I understand it the checks will be executed by upstream before a
> change is accepted so that's good but it adds a huge delay and the
> requirement of a roundtrip to fix simple mistakes (happens all the
time
> in OpenStack).
 On-PR checks can handle this. When you need to fix a linter issue, you
 can install the dependencies and run make lint locally.
> I think my question boils down to how many people will this actually
> benefit vs how much time will be lost resubmitting patches? I don't
> think there is an easy answer for the first part but from my own
> experience I'd expect fairly regularly for lint and pep8 errors.
 If someone often has this issue, the workflow can be modified to
address
 it. For example, I've configured my repo to run to run pylint and pep8
 on the modified files before the commit.
> On the other hand I guess this also will have the additional advantage
> that make rpms will be significantly faster if you don't enable them.
>
> The --disable vs --without is what bugs me most about the current
> situation :-)
>
> So in closing I'd just say that we made those checks mandatory for a
> reason. Maybe that reason is no longer applicable with all the current
> automation but I'd personally prefer Lukas's suggestion of requiring
> them by default but providing clear 

Re: [Freeipa-devel] [DISCUSSION] checking *lint at configure time

[Lukas Slebodnik]

On (06/03/17 13:49), Tomas Krizek wrote:
>On 03/06/2017 01:44 PM, Lukas Slebodnik wrote:
>> On (06/03/17 13:35), Tomas Krizek wrote:
>>> On 03/03/2017 09:22 PM, Rob Crittenden wrote:
 Lukas Slebodnik wrote:
> On (03/03/17 17:07), Lukas Slebodnik wrote:
>> ehlo,
>>
>> This is a small continuation fo discussin from pull request
>> "Make pylint and jsl optional" #502[1]
>>
>> Pylint and jslint are already optional because some downstream 
>> distributions
>> does not have such packages. This is a reason why desing document[2]
>> mention configuration options for disabling them.
>>   --disable-pylint --without-jslint
>>
>> Previusly (4.4) "pylint was executed" before building rpm packages.
>> This strict requirement was changed because "make lint" is executed
>> with each pull request in travis.
>>
>> It was changed in commits
>> master:
>>
>> * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix detection of 
>> pylint
>> * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update help 
>> message for jslint
>> * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock
>>
>> The main intention of PR#502 [1] is to make it even more optional
>> and do not fail if pylint is not installed on machine.
>> In another words, changing default value from "yes" to "autodetect".
>> I think the main reason is that it is not obvious that it is an optional
>> dependency if you run just "./configure". But that can be improved with
>> better error message. @see attachments.
 I was going to go into a history of why it was required (we pushed
 broken changes into master) but in retrospect that doesn't really
 matter. I've been out of mainline development for some time so don't
 know your current processes, but I do have a question:

 Is it expected that ./configure && make && make install will result in
 the bits in all the right places? We never had that expectation before
 though I know Christian has been moving in that direction. Is that an
 end goal? It would be nice for developing in-tree and pushing out micro
 changes onto the current, live development system.
>>> If you provide correct paths to ./configure, yes - make && make install
>>> will place all the bits in the right places. I commonly use it with
>>> DESTDIR and sshfs, so I can develop locally and deploy to a remote
>>> machine without building RPMs.
 If so, does it have checks for all the runtime dependencies or will you
 still have to do a bunch of work afterward the make install?
>>> It doesn't check runtime dependencies. I install the freeipa rpms once
>>> to install dependencies and then use make && make install.
 I've seen discussions about making freeIPA more accessible to the
 average developer, which is good, but it is just so more complex than
 the typical software because it is more about integration than most big
 projects. So I don't know that this is every going to really be true.
 Will it help the average dev install it? Sure, but then what? Will you
 support such an install?

 If you want to disable the checks for *lint that is certainly your
 prerogative but I see some downsides:

 - I used to setup new dev systems all the time and this is definitely
 something I'd forget to do with some frequency
 - As I understand it the checks will be executed by upstream before a
 change is accepted so that's good but it adds a huge delay and the
 requirement of a roundtrip to fix simple mistakes (happens all the time
 in OpenStack).
>>> On-PR checks can handle this. When you need to fix a linter issue, you
>>> can install the dependencies and run make lint locally.
 I think my question boils down to how many people will this actually
 benefit vs how much time will be lost resubmitting patches? I don't
 think there is an easy answer for the first part but from my own
 experience I'd expect fairly regularly for lint and pep8 errors.
>>> If someone often has this issue, the workflow can be modified to address
>>> it. For example, I've configured my repo to run to run pylint and pep8
>>> on the modified files before the commit.
 On the other hand I guess this also will have the additional advantage
 that make rpms will be significantly faster if you don't enable them.

 The --disable vs --without is what bugs me most about the current
 situation :-)

 So in closing I'd just say that we made those checks mandatory for a
 reason. Maybe that reason is no longer applicable with all the current
 automation but I'd personally prefer Lukas's suggestion of requiring
 them by default but providing clear output on how to disable them if
 desired. This way the average user can easily work around it and it
 won't impact current developers (unless they want it 

[Freeipa-devel] [freeipa PR#476][synchronized] vault: cache the transport certificate on client

[HonzaCholasta]

   URL: https://github.com/freeipa/freeipa/pull/476
Author: HonzaCholasta
 Title: #476: vault: cache the transport certificate on client
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/476/head:pr476
git checkout pr476
From 95fe10800b5d74e610314bfab24d5935c0010a83 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Fri, 17 Feb 2017 11:25:17 +0100
Subject: [PATCH] vault: cache the transport certificate on client

Cache the KRA transport certificate on disk (in ~/.cache/ipa) as well as
in memory.

https://fedorahosted.org/freeipa/ticket/6652
---
 ipaclient/plugins/vault.py   | 205 ++-
 ipaclient/remote_plugins/__init__.py |   3 +-
 ipaclient/remote_plugins/schema.py   |  12 +-
 ipalib/constants.py  |  14 +++
 4 files changed, 170 insertions(+), 64 deletions(-)

diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index 70756df..d677ec0 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -20,30 +20,38 @@
 from __future__ import print_function
 
 import base64
+import collections
+import errno
 import getpass
 import io
 import json
 import os
 import sys
+import tempfile
 
 from cryptography.fernet import Fernet, InvalidToken
 from cryptography.hazmat.backends import default_backend
-from cryptography.hazmat.primitives import hashes
+from cryptography.hazmat.primitives import hashes, serialization
 from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
 from cryptography.hazmat.primitives.asymmetric import padding
 from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
 from cryptography.hazmat.primitives.padding import PKCS7
 from cryptography.hazmat.primitives.serialization import (
 load_pem_public_key, load_pem_private_key)
-from cryptography.x509 import load_der_x509_certificate
 
 from ipaclient.frontend import MethodOverride
+from ipalib import x509
+from ipalib.constants import USER_CACHE_PATH
 from ipalib.frontend import Local, Method, Object
 from ipalib.util import classproperty
 from ipalib import api, errors
 from ipalib import Bytes, Flag, Str
 from ipalib.plugable import Registry
 from ipalib import _
+from ipapython.dnsutil import DNSName
+from ipapython.ipa_log_manager import log_mgr
+
+logger = log_mgr.get_logger(__name__)
 
 
 def validated_read(argname, filename, mode='r', encoding=None):
@@ -550,6 +558,79 @@ def forward(self, *args, **options):
 return response
 
 
+class _TransportCertCache(collections.MutableMapping):
+def __init__(self):
+self._dirname = os.path.join(
+USER_CACHE_PATH, 'ipa', 'kra-transport-certs')
+self._transport_certs = {}
+
+def _get_filename(self, domain):
+basename = DNSName(domain).ToASCII() + '.pem'
+return os.path.join(self._dirname, basename)
+
+def __getitem__(self, domain):
+try:
+transport_cert = self._transport_certs[domain]
+except KeyError:
+transport_cert = None
+
+filename = self._get_filename(domain)
+try:
+try:
+transport_cert = x509.load_certificate_from_file(filename)
+except EnvironmentError as e:
+if e.errno != errno.ENOENT:
+raise
+except Exception:
+logger.warning("Failed to load %s: %s", filename,
+   exc_info=True)
+
+if transport_cert is None:
+raise KeyError(domain)
+
+self._transport_certs[domain] = transport_cert
+
+return transport_cert
+
+def __setitem__(self, domain, transport_cert):
+filename = self._get_filename(domain)
+transport_cert_der = (
+transport_cert.public_bytes(serialization.Encoding.DER))
+try:
+try:
+os.makedirs(self._dirname)
+except EnvironmentError as e:
+if e.errno != errno.EEXIST:
+raise
+fd, tmpfilename = tempfile.mkstemp(dir=self._dirname)
+os.close(fd)
+x509.write_certificate(transport_cert_der, tmpfilename)
+os.rename(tmpfilename, filename)
+except Exception:
+logger.warning("Failed to save %s", filename, exc_info=True)
+
+self._transport_certs[domain] = transport_cert
+
+def __delitem__(self, domain):
+filename = self._get_filename(domain)
+try:
+os.unlink(filename)
+except EnvironmentError as e:
+if e.errno != errno.ENOENT:
+logger.warning("Failed to remove %s", filename, exc_info=True)
+
+del self._transport_certs[domain]
+
+def __len__(self):
+return len(self._transport_certs)
+
+def __iter__(self):
+return iter(self._transport_certs)
+
+

Re: [Freeipa-devel] [DISCUSSION] checking *lint at configure time

[Tomas Krizek]

On 03/06/2017 01:44 PM, Lukas Slebodnik wrote:
> On (06/03/17 13:35), Tomas Krizek wrote:
>> On 03/03/2017 09:22 PM, Rob Crittenden wrote:
>>> Lukas Slebodnik wrote:
 On (03/03/17 17:07), Lukas Slebodnik wrote:
> ehlo,
>
> This is a small continuation fo discussin from pull request
> "Make pylint and jsl optional" #502[1]
>
> Pylint and jslint are already optional because some downstream 
> distributions
> does not have such packages. This is a reason why desing document[2]
> mention configuration options for disabling them.
>   --disable-pylint --without-jslint
>
> Previusly (4.4) "pylint was executed" before building rpm packages.
> This strict requirement was changed because "make lint" is executed
> with each pull request in travis.
>
> It was changed in commits
> master:
>
> * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix detection of 
> pylint
> * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update help message 
> for jslint
> * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock
>
> The main intention of PR#502 [1] is to make it even more optional
> and do not fail if pylint is not installed on machine.
> In another words, changing default value from "yes" to "autodetect".
> I think the main reason is that it is not obvious that it is an optional
> dependency if you run just "./configure". But that can be improved with
> better error message. @see attachments.
>>> I was going to go into a history of why it was required (we pushed
>>> broken changes into master) but in retrospect that doesn't really
>>> matter. I've been out of mainline development for some time so don't
>>> know your current processes, but I do have a question:
>>>
>>> Is it expected that ./configure && make && make install will result in
>>> the bits in all the right places? We never had that expectation before
>>> though I know Christian has been moving in that direction. Is that an
>>> end goal? It would be nice for developing in-tree and pushing out micro
>>> changes onto the current, live development system.
>> If you provide correct paths to ./configure, yes - make && make install
>> will place all the bits in the right places. I commonly use it with
>> DESTDIR and sshfs, so I can develop locally and deploy to a remote
>> machine without building RPMs.
>>> If so, does it have checks for all the runtime dependencies or will you
>>> still have to do a bunch of work afterward the make install?
>> It doesn't check runtime dependencies. I install the freeipa rpms once
>> to install dependencies and then use make && make install.
>>> I've seen discussions about making freeIPA more accessible to the
>>> average developer, which is good, but it is just so more complex than
>>> the typical software because it is more about integration than most big
>>> projects. So I don't know that this is every going to really be true.
>>> Will it help the average dev install it? Sure, but then what? Will you
>>> support such an install?
>>>
>>> If you want to disable the checks for *lint that is certainly your
>>> prerogative but I see some downsides:
>>>
>>> - I used to setup new dev systems all the time and this is definitely
>>> something I'd forget to do with some frequency
>>> - As I understand it the checks will be executed by upstream before a
>>> change is accepted so that's good but it adds a huge delay and the
>>> requirement of a roundtrip to fix simple mistakes (happens all the time
>>> in OpenStack).
>> On-PR checks can handle this. When you need to fix a linter issue, you
>> can install the dependencies and run make lint locally.
>>> I think my question boils down to how many people will this actually
>>> benefit vs how much time will be lost resubmitting patches? I don't
>>> think there is an easy answer for the first part but from my own
>>> experience I'd expect fairly regularly for lint and pep8 errors.
>> If someone often has this issue, the workflow can be modified to address
>> it. For example, I've configured my repo to run to run pylint and pep8
>> on the modified files before the commit.
>>> On the other hand I guess this also will have the additional advantage
>>> that make rpms will be significantly faster if you don't enable them.
>>>
>>> The --disable vs --without is what bugs me most about the current
>>> situation :-)
>>>
>>> So in closing I'd just say that we made those checks mandatory for a
>>> reason. Maybe that reason is no longer applicable with all the current
>>> automation but I'd personally prefer Lukas's suggestion of requiring
>>> them by default but providing clear output on how to disable them if
>>> desired. This way the average user can easily work around it and it
>>> won't impact current developers (unless they want it to). Is that as
>>> simple as configure; make; make install? No, but it isn't a huge leap
>>> either.
>>>
>>> rob
>>>
>> I prefer 

Re: [Freeipa-devel] Please review: V4/AD user short names design draft

[Simo Sorce]

On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote:
> On 03/02/2017 02:54 PM, Simo Sorce wrote:
> > On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote:
> >> In this case it would probably be a good idea to think about "forward
> >> compatibility" and define a new AUX objectclass bringing in
> >> 'ipaDomainResolutionOrder' instead of extending two separate
> >> objectclasses. In this way we may the just extend whathever object we
> >> desire to carry the override in an easy and clean way.
> >
> > I agree.
> > Simo.
> >
> 
> Now the most difficult question remains... How to name this objectclass. 
> I personally am out of ideas but will try my best to come up with 
> something meaningful.

Try to describe what the option ultimately does with as few words as
possible.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] [DISCUSSION] checking *lint at configure time

[Lukas Slebodnik]

On (06/03/17 13:35), Tomas Krizek wrote:
>On 03/03/2017 09:22 PM, Rob Crittenden wrote:
>> Lukas Slebodnik wrote:
>>> On (03/03/17 17:07), Lukas Slebodnik wrote:
 ehlo,

 This is a small continuation fo discussin from pull request
 "Make pylint and jsl optional" #502[1]

 Pylint and jslint are already optional because some downstream 
 distributions
 does not have such packages. This is a reason why desing document[2]
 mention configuration options for disabling them.
   --disable-pylint --without-jslint

 Previusly (4.4) "pylint was executed" before building rpm packages.
 This strict requirement was changed because "make lint" is executed
 with each pull request in travis.

 It was changed in commits
 master:

 * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix detection of 
 pylint
 * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update help message 
 for jslint
 * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock

 The main intention of PR#502 [1] is to make it even more optional
 and do not fail if pylint is not installed on machine.
 In another words, changing default value from "yes" to "autodetect".
 I think the main reason is that it is not obvious that it is an optional
 dependency if you run just "./configure". But that can be improved with
 better error message. @see attachments.
>> I was going to go into a history of why it was required (we pushed
>> broken changes into master) but in retrospect that doesn't really
>> matter. I've been out of mainline development for some time so don't
>> know your current processes, but I do have a question:
>>
>> Is it expected that ./configure && make && make install will result in
>> the bits in all the right places? We never had that expectation before
>> though I know Christian has been moving in that direction. Is that an
>> end goal? It would be nice for developing in-tree and pushing out micro
>> changes onto the current, live development system.
>If you provide correct paths to ./configure, yes - make && make install
>will place all the bits in the right places. I commonly use it with
>DESTDIR and sshfs, so I can develop locally and deploy to a remote
>machine without building RPMs.
>> If so, does it have checks for all the runtime dependencies or will you
>> still have to do a bunch of work afterward the make install?
>It doesn't check runtime dependencies. I install the freeipa rpms once
>to install dependencies and then use make && make install.
>> I've seen discussions about making freeIPA more accessible to the
>> average developer, which is good, but it is just so more complex than
>> the typical software because it is more about integration than most big
>> projects. So I don't know that this is every going to really be true.
>> Will it help the average dev install it? Sure, but then what? Will you
>> support such an install?
>>
>> If you want to disable the checks for *lint that is certainly your
>> prerogative but I see some downsides:
>>
>> - I used to setup new dev systems all the time and this is definitely
>> something I'd forget to do with some frequency
>> - As I understand it the checks will be executed by upstream before a
>> change is accepted so that's good but it adds a huge delay and the
>> requirement of a roundtrip to fix simple mistakes (happens all the time
>> in OpenStack).
>On-PR checks can handle this. When you need to fix a linter issue, you
>can install the dependencies and run make lint locally.
>> I think my question boils down to how many people will this actually
>> benefit vs how much time will be lost resubmitting patches? I don't
>> think there is an easy answer for the first part but from my own
>> experience I'd expect fairly regularly for lint and pep8 errors.
>If someone often has this issue, the workflow can be modified to address
>it. For example, I've configured my repo to run to run pylint and pep8
>on the modified files before the commit.
>> On the other hand I guess this also will have the additional advantage
>> that make rpms will be significantly faster if you don't enable them.
>>
>> The --disable vs --without is what bugs me most about the current
>> situation :-)
>>
>> So in closing I'd just say that we made those checks mandatory for a
>> reason. Maybe that reason is no longer applicable with all the current
>> automation but I'd personally prefer Lukas's suggestion of requiring
>> them by default but providing clear output on how to disable them if
>> desired. This way the average user can easily work around it and it
>> won't impact current developers (unless they want it to). Is that as
>> simple as configure; make; make install? No, but it isn't a huge leap
>> either.
>>
>> rob
>>
>I prefer Christian's approach that makes the project more upstream-friendly.
>
Could you explain what does "more upstream-friendly" mean?
It seems that we have 

Re: [Freeipa-devel] [DISCUSSION] checking *lint at configure time

[Tomas Krizek]

On 03/03/2017 09:22 PM, Rob Crittenden wrote:
> Lukas Slebodnik wrote:
>> On (03/03/17 17:07), Lukas Slebodnik wrote:
>>> ehlo,
>>>
>>> This is a small continuation fo discussin from pull request
>>> "Make pylint and jsl optional" #502[1]
>>>
>>> Pylint and jslint are already optional because some downstream distributions
>>> does not have such packages. This is a reason why desing document[2]
>>> mention configuration options for disabling them.
>>>   --disable-pylint --without-jslint
>>>
>>> Previusly (4.4) "pylint was executed" before building rpm packages.
>>> This strict requirement was changed because "make lint" is executed
>>> with each pull request in travis.
>>>
>>> It was changed in commits
>>> master:
>>>
>>> * 5c18feaa206bbaee692fc3640b7b79c8d9d6a638 CONFIGURE: Fix detection of 
>>> pylint
>>> * 3f91469f327d8d9f3b27e0b67c54a4f47ad845c1 CONFIGURE: Update help message 
>>> for jslint
>>> * b82d285a4a75e11cc9291ecca12d2fcc26f43ed1 SPEC: Fix build in mock
>>>
>>> The main intention of PR#502 [1] is to make it even more optional
>>> and do not fail if pylint is not installed on machine.
>>> In another words, changing default value from "yes" to "autodetect".
>>> I think the main reason is that it is not obvious that it is an optional
>>> dependency if you run just "./configure". But that can be improved with
>>> better error message. @see attachments.
> I was going to go into a history of why it was required (we pushed
> broken changes into master) but in retrospect that doesn't really
> matter. I've been out of mainline development for some time so don't
> know your current processes, but I do have a question:
>
> Is it expected that ./configure && make && make install will result in
> the bits in all the right places? We never had that expectation before
> though I know Christian has been moving in that direction. Is that an
> end goal? It would be nice for developing in-tree and pushing out micro
> changes onto the current, live development system.
If you provide correct paths to ./configure, yes - make && make install
will place all the bits in the right places. I commonly use it with
DESTDIR and sshfs, so I can develop locally and deploy to a remote
machine without building RPMs.
> If so, does it have checks for all the runtime dependencies or will you
> still have to do a bunch of work afterward the make install?
It doesn't check runtime dependencies. I install the freeipa rpms once
to install dependencies and then use make && make install.
> I've seen discussions about making freeIPA more accessible to the
> average developer, which is good, but it is just so more complex than
> the typical software because it is more about integration than most big
> projects. So I don't know that this is every going to really be true.
> Will it help the average dev install it? Sure, but then what? Will you
> support such an install?
>
> If you want to disable the checks for *lint that is certainly your
> prerogative but I see some downsides:
>
> - I used to setup new dev systems all the time and this is definitely
> something I'd forget to do with some frequency
> - As I understand it the checks will be executed by upstream before a
> change is accepted so that's good but it adds a huge delay and the
> requirement of a roundtrip to fix simple mistakes (happens all the time
> in OpenStack).
On-PR checks can handle this. When you need to fix a linter issue, you
can install the dependencies and run make lint locally.
> I think my question boils down to how many people will this actually
> benefit vs how much time will be lost resubmitting patches? I don't
> think there is an easy answer for the first part but from my own
> experience I'd expect fairly regularly for lint and pep8 errors.
If someone often has this issue, the workflow can be modified to address
it. For example, I've configured my repo to run to run pylint and pep8
on the modified files before the commit.
> On the other hand I guess this also will have the additional advantage
> that make rpms will be significantly faster if you don't enable them.
>
> The --disable vs --without is what bugs me most about the current
> situation :-)
>
> So in closing I'd just say that we made those checks mandatory for a
> reason. Maybe that reason is no longer applicable with all the current
> automation but I'd personally prefer Lukas's suggestion of requiring
> them by default but providing clear output on how to disable them if
> desired. This way the average user can easily work around it and it
> won't impact current developers (unless they want it to). Is that as
> simple as configure; make; make install? No, but it isn't a huge leap
> either.
>
> rob
>
I prefer Christian's approach that makes the project more upstream-friendly.

I think changing the default from "yes" to "autodetect" negatively
affects packagers, but it makes it more accessible to upstream developers.

-- 
Tomas Krizek

PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

[Freeipa-devel] [freeipa PR#541][+pushed] We don't offer no quickies

[dkupka]

  URL: https://github.com/freeipa/freeipa/pull/541
Title: #541: We don't offer no quickies

Label: +pushed
-- 
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 PR#541][comment] We don't offer no quickies

[dkupka]

  URL: https://github.com/freeipa/freeipa/pull/541
Title: #541: We don't offer no quickies

dkupka commented:
"""
master:

* 30d7c210a4d153fcb5007651a80d8d53512abba3 We don't offer no quickies
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/541#issuecomment-284380318
-- 
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 PR#541][closed] We don't offer no quickies

[dkupka]

   URL: https://github.com/freeipa/freeipa/pull/541
Author: stlaz
 Title: #541: We don't offer no quickies
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/541/head:pr541
git checkout pr541
-- 
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 PR#541][+ack] We don't offer no quickies

[dkupka]

  URL: https://github.com/freeipa/freeipa/pull/541
Title: #541: We don't offer no quickies

Label: +ack
-- 
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 PR#539][comment] Define errors_by_code in ipalib.errors

[frasertweedale]

  URL: https://github.com/freeipa/freeipa/pull/539
Title: #539: Define errors_by_code in ipalib.errors

frasertweedale commented:
"""
@HonzaCholasta when Dogtag execute the existing cert-request validation logic 
(which will be extracted to a new function), if an exception gets raised Dogtag 
returns it in the response, and IPA reconstructs it, so that there is no change 
to the user experience.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/539#issuecomment-284379517
-- 
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 PR#539][comment] Define errors_by_code in ipalib.errors

[frasertweedale]

  URL: https://github.com/freeipa/freeipa/pull/539
Title: #539: Define errors_by_code in ipalib.errors

frasertweedale commented:
"""
@HonzaCholasta when Dogtag execute the existing cert-request validation logic 
(which will be extracted to a new function), if an exception gets raised Dogtag 
returns it in the response, and IPA reconstructs it, so that there is no change 
to the user experience.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/539#issuecomment-284379517
-- 
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 PR#541][opened] We don't offer no quickies

[stlaz]

   URL: https://github.com/freeipa/freeipa/pull/541
Author: stlaz
 Title: #541: We don't offer no quickies
Action: opened

PR body:
"""
It's not our main priority as developers to offer any forms of quickies
nor guides on how to perform them.

http://www.urbandictionary.com/define.php?term=quickie
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/541/head:pr541
git checkout pr541
From 4ae859aa909c75342e6e21f061d10b5abe82b415 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Mon, 6 Mar 2017 12:23:55 +0100
Subject: [PATCH] We don't offer no quickies

It's not our main priority as developers to offer any forms of quickies
nor guides on how to perform them.
---
 BUILD.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BUILD.txt b/BUILD.txt
index 10b1943..63fe0bf 100644
--- a/BUILD.txt
+++ b/BUILD.txt
@@ -1,4 +1,4 @@
-Here is a quickie guide to get you started in IPA development.
+Here is a quick guide to get you started in IPA development.
 
 Dependencies
 
-- 
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 PR#476][comment] vault: cache the transport certificate on client

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/476
Title: #476: vault: cache the transport certificate on client

HonzaCholasta commented:
"""
Calling `vaultconfig_show` now refreshes the cache, you can call it to download 
and cache the certificate in the main process.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/476#issuecomment-284362437
-- 
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 PR#532][+pushed] Fix cookie with Max-Age processing

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/532
Title: #532: Fix cookie with Max-Age processing

Label: +pushed
-- 
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 PR#532][closed] Fix cookie with Max-Age processing

[HonzaCholasta]

   URL: https://github.com/freeipa/freeipa/pull/532
Author: stlaz
 Title: #532: Fix cookie with Max-Age processing
Action: closed

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/532/head:pr532
git checkout pr532
-- 
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 PR#532][comment] Fix cookie with Max-Age processing

[HonzaCholasta]

  URL: https://github.com/freeipa/freeipa/pull/532
Title: #532: Fix cookie with Max-Age processing

HonzaCholasta commented:
"""
master:

* 24eeb4d6a3be678d652247a4a862ffde037514da Fix cookie with Max-Age processing
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/532#issuecomment-284361733
-- 
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 PR#476][synchronized] vault: cache the transport certificate on client

[HonzaCholasta]

   URL: https://github.com/freeipa/freeipa/pull/476
Author: HonzaCholasta
 Title: #476: vault: cache the transport certificate on client
Action: synchronized

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/476/head:pr476
git checkout pr476
From b35f363fd98dd6959d1dd2f9240dcdf308606ff9 Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Fri, 17 Feb 2017 11:25:17 +0100
Subject: [PATCH] vault: cache the transport certificate on client

Cache the KRA transport certificate on disk (in ~/.cache/ipa) as well as
in memory.

https://fedorahosted.org/freeipa/ticket/6652
---
 ipaclient/plugins/vault.py   | 221 ++-
 ipaclient/remote_plugins/__init__.py |   3 +-
 ipaclient/remote_plugins/schema.py   |  12 +-
 ipalib/constants.py  |  14 +++
 4 files changed, 186 insertions(+), 64 deletions(-)

diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index 70756df..f24ec1e 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -20,30 +20,40 @@
 from __future__ import print_function
 
 import base64
+import collections
+import errno
 import getpass
 import io
 import json
 import os
 import sys
+import tempfile
 
 from cryptography.fernet import Fernet, InvalidToken
 from cryptography.hazmat.backends import default_backend
-from cryptography.hazmat.primitives import hashes
+from cryptography.hazmat.primitives import hashes, serialization
 from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
 from cryptography.hazmat.primitives.asymmetric import padding
 from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
 from cryptography.hazmat.primitives.padding import PKCS7
 from cryptography.hazmat.primitives.serialization import (
 load_pem_public_key, load_pem_private_key)
-from cryptography.x509 import load_der_x509_certificate
+
+import six
 
 from ipaclient.frontend import MethodOverride
+from ipalib import x509
+from ipalib.constants import USER_CACHE_PATH
 from ipalib.frontend import Local, Method, Object
 from ipalib.util import classproperty
 from ipalib import api, errors
 from ipalib import Bytes, Flag, Str
 from ipalib.plugable import Registry
 from ipalib import _
+from ipapython.dnsutil import DNSName
+from ipapython.ipa_log_manager import log_mgr
+
+logger = log_mgr.get_logger(__name__)
 
 
 def validated_read(argname, filename, mode='r', encoding=None):
@@ -550,6 +560,79 @@ def forward(self, *args, **options):
 return response
 
 
+class _TransportCertCache(collections.MutableMapping):
+def __init__(self):
+self._dirname = os.path.join(
+USER_CACHE_PATH, 'ipa', 'kra-transport-certs')
+self._transport_certs = {}
+
+def _get_filename(self, domain):
+basename = DNSName(domain).ToASCII() + '.pem'
+return os.path.join(self._dirname, basename)
+
+def __getitem__(self, domain):
+try:
+transport_cert = self._transport_certs[domain]
+except KeyError:
+transport_cert = None
+
+filename = self._get_filename(domain)
+try:
+try:
+transport_cert = x509.load_certificate_from_file(filename)
+except EnvironmentError as e:
+if e.errno != errno.ENOENT:
+raise
+except Exception:
+logger.warning("Failed to load %s: %s", filename,
+   exc_info=True)
+
+if transport_cert is None:
+raise KeyError(domain)
+
+self._transport_certs[domain] = transport_cert
+
+return transport_cert
+
+def __setitem__(self, domain, transport_cert):
+filename = self._get_filename(domain)
+transport_cert_der = (
+transport_cert.public_bytes(serialization.Encoding.DER))
+try:
+try:
+os.makedirs(self._dirname)
+except EnvironmentError as e:
+if e.errno != errno.EEXIST:
+raise
+fd, tmpfilename = tempfile.mkstemp(dir=self._dirname)
+os.close(fd)
+x509.write_certificate(transport_cert_der, tmpfilename)
+os.rename(tmpfilename, filename)
+except Exception:
+logger.warning("Failed to save %s", filename, exc_info=True)
+
+self._transport_certs[domain] = transport_cert
+
+def __delitem__(self, domain):
+filename = self._get_filename(domain)
+try:
+os.unlink(filename)
+except EnvironmentError as e:
+if e.errno != errno.ENOENT:
+logger.warning("Failed to remove %s", filename, exc_info=True)
+
+del self._transport_certs[domain]
+
+def __len__(self):
+return len(self._transport_certs)
+
+def __iter__(self):
+return iter(self._transport_certs)
+
+

[Freeipa-devel] [freeipa PR#504][comment] Add SHA256 fingerprints

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/504
Title: #504: Add SHA256 fingerprints

stlaz commented:
"""
Please transform `sha256_fingerprint:` into `Fingerprint (SHA-256):`
```
$ ipa cert-show --all
Serial number: 1
  Issuing CA: ipa
  Certificate: 
  Subject: CN=Certificate Authority,O=DOM-245.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Issuer: CN=Certificate Authority,O=DOM-245.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Not Before: Mon Mar 06 08:57:45 2017 UTC
  Not After: Fri Mar 06 08:57:45 2037 UTC
  **Fingerprint (SHA1):** 
25:ea:cb:01:48:68:9e:8d:1c:25:ac:2c:92:d9:75:3f:0a:45:97:2d
  Serial number: 1
  Serial number (hex): 0x1
  Revoked: False
  **sha256_fingerprint:** 
af:09:dd:ae:66:74:cf:af:e2:4f:25:4d:2f:73:4e:a6:f4:d6:f8:32:c4:48:8e:e7:d9:fa:c6:1f:42:f3:09:c4
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/504#issuecomment-284360401
-- 
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 PR#504][comment] Add SHA256 fingerprints

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/504
Title: #504: Add SHA256 fingerprints

stlaz commented:
"""
Please transform `sha256_fingerprint:` into `Fingerprint (SHA1):`
```
$ ipa cert-show --all
Serial number: 1
  Issuing CA: ipa
  Certificate: 
  Subject: CN=Certificate Authority,O=DOM-245.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Issuer: CN=Certificate Authority,O=DOM-245.ABC.IDM.LAB.ENG.BRQ.REDHAT.COM
  Not Before: Mon Mar 06 08:57:45 2017 UTC
  Not After: Fri Mar 06 08:57:45 2037 UTC
  **Fingerprint (SHA1):** 
25:ea:cb:01:48:68:9e:8d:1c:25:ac:2c:92:d9:75:3f:0a:45:97:2d
  Serial number: 1
  Serial number (hex): 0x1
  Revoked: False
  **sha256_fingerprint:** 
af:09:dd:ae:66:74:cf:af:e2:4f:25:4d:2f:73:4e:a6:f4:d6:f8:32:c4:48:8e:e7:d9:fa:c6:1f:42:f3:09:c4
```
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/504#issuecomment-284360401
-- 
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 PR#504][-ack] Add SHA256 fingerprints

[stlaz]

  URL: https://github.com/freeipa/freeipa/pull/504
Title: #504: Add SHA256 fingerprints

Label: -ack
-- 
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] gssproxy-0.6.2-2 broken

[Standa Laznicka]

Hello,

Current gssproxy in Fedora 25 "updates" repository (gssproxy-0.6.2-2) is 
broken. For a freshly-installed IPA server, the infamous error


"ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may 
provide more information, Minor (2598845123): No credentials cache 
found" will appear. 100% reproducible.


Please use the gssproxy-0.6.2-1 from @freeipa/freeipa-master repository 
instead. Note that downgrade + gssproxy service restart works.


Cheers,
Standa

--
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 PR#420][comment] Allow login to WebUI using Kerberos aliases/enterprise principals

[martbab]

  URL: https://github.com/freeipa/freeipa/pull/420
Title: #420: Allow login to WebUI using Kerberos aliases/enterprise principals

martbab commented:
"""
@abbra can you also have a quick look at this PR if it is OK from the trusted 
user login perspective? 
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/420#issuecomment-284329271
-- 
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 PR#444][comment] Allow nsaccountlock to be searched in user-find commands

[abbra]

  URL: https://github.com/freeipa/freeipa/pull/444
Title: #444: Allow nsaccountlock to be searched in user-find commands

abbra commented:
"""
You are correct in the fact that the search filter need to be modified to allow 
matching entries without nsAccountLock attribute set.
"""

See the full comment at 
https://github.com/freeipa/freeipa/pull/444#issuecomment-284327327
-- 
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