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

2016-01-08 Thread John Dennis 

On 01/08/2016 08:22 AM, 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:



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



Leaving aside the whole question of whether re-implementing rpmvercmp in 
Python is a good idea or not because of possible divergence from RPM I 
offer to you an implementation of rpmvercmp written in Python I did 
years ago. It was written based on the published documentation of how 
RPM version comparison is implemented (as close to a spec as I was able 
to find). I believe I also used the C implementation as a guide but my 
memory is fuzzy on that point. I've used it a lot and I've also cross 
checked it's results with librpm and I've never seen a differing result.


Use at your pleasure or displeasure :-)

HTH,

John


--
John
#!/usr/bin/python

import re
rpm_name_re = re.compile(r'^(.+)-([^-]+)-([^-]+)$')

def split_rpm_name(rpm_name):
'''
Split an RPM's NVR returning 
[name, version, release]
'''
match = rpm_name_re.match(rpm_name)
if match:
name= match.group(1)
version = match.group(2)
release = match.group(3)
return name, version, release
else:
raise ValueError("cannot split rpm NVR for '%s'" % rpm_name)

def split_rpm_label(label):
'''
Each label is separated into a list of maximal alphabetic or numeric
components, with separators (non-alphanumeric characters) ignored. 
Alphbetic components are inserted into the list as a Python str object.
Numeric components are inserted into the list as either Python int
or long objects depending on the numeric magnitude of the component.

For example:
'2.0.1' => [2, 0, 1]
'2xFg33.+f.5' => [2, 'xFg', 33, 'f', 5]
'''
components = []
component = None
for c in label:
if c.isalpha():
if component is None:
component = c
else:
if component.isalpha():
component += c
else:
components.append(int(component))
component = c
elif c.isdigit():
if component is None:
component = c
else:
if component.isdigit():
component += c
else:
components.append(component)
component = c
else:
if component is not None:
if component.isdigit():
component = int(component)
components.append(component)
component = None

if component is not None:
if component.isdigit():
component = int(component)
components.append(component)
component = None

return components

def rpm_label_cmp(label1, label2):
'''
The version and release components of a rpm NVR are considered labels.
To compare a label we split the label into components, see split_rpm_label()
for an explanation of how the components are split.

The components in the list are compared one by one using the following
algorithm. If two components are considered to be different, the label with
the newer component wins as the newer label. If the components are
considered to be equal, the next components are compared until we either
reach different components or one of the lists runs out. In case one of

Re: [Freeipa-devel] [PATCH 0398] Allow to use mixed case for sysrestore

2016-01-08 Thread Martin Basti 



On 08.01.2016 16:48, Martin Babinsky wrote:

On 01/07/2016 05:55 PM, Martin Basti wrote:



On 06.01.2016 19:08, Martin Basti wrote:

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

Patch attached.






I missed one occurrence, updated patch attached.



ACK

(also the reason why Martin^2 didn't do it the nice way by subclassing 
SafeConfigParser and overriding optionxform method in the subclass was 
that such approach with combination of imports through six made pylint 
panic massively)



Pushed to master: 129d97c10be570c3327445337c534e57a8c12ef6
Pushed to ipa-4-3: 44796fd275f9a1e577ce62a3fa557ace15ce4d88
Pushed to ipa-4-2: 2fce8fdc0dbb017eeda6bc3986472142cd712fe9


I did rebase for ipa-4-2, please check if I did not break it, also 
please note I had to backport following line to ipa-4-2 otherwise it 
will not work


@@ -373,6 +373,8 @@ class OpenDNSSECInstance(service.Service):
 root_logger.debug(error)
 pass

+self.restore_state("kasp_db_configured")  # just eat state
+
 # disabled by default, by ldap_enable()
 if enabled:
 self.enable()

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

2016-01-08 Thread Martin Babinsky 

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.

--
Martin^3 Babinsky
From 8c87211d0f51f692999b0393de4b795564b87f8a Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Thu, 7 Jan 2016 18:09:41 +0100
Subject: [PATCH] ipa-csreplica-manage: remove extraneous ldap2 connection

https://fedorahosted.org/freeipa/ticket/5583
---
 install/tools/ipa-csreplica-manage | 2 --
 1 file changed, 2 deletions(-)

diff --git a/install/tools/ipa-csreplica-manage b/install/tools/ipa-csreplica-manage
index 96f565839362f268ca15aa904f838ef9927fe7b2..f271863b8f8a6addf630bf8d570adf039db64d89 100755
--- a/install/tools/ipa-csreplica-manage
+++ b/install/tools/ipa-csreplica-manage
@@ -285,8 +285,6 @@ def del_master(realm, hostname, options):
 try:
 if bindinstance.dns_container_exists(options.host, api.env.basedn,
  dm_password=options.dirman_passwd):
-api.Backend.ldap2.connect(bind_dn=DN(('cn', 'Directory Manager')),
-  bind_pw=options.dirman_passwd)
 bind = bindinstance.BindInstance()
 bind.remove_ipa_ca_dns_records(hostname, realm.lower())
 except Exception as e:
-- 
2.5.0

-- 
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 0122-0123] reimplementation of package version comparison code

2016-01-08 Thread Lukas Slebodnik 
On (08/01/16 17:56), Martin Babinsky wrote:
>On 01/08/2016 05:23 PM, Lukas Slebodnik wrote:
>>On (08/01/16 16:59), Martin Babinsky wrote:
>>>Patch 0122 reimplements version checking and fixes
>>>https://fedorahosted.org/freeipa/ticket/5572
>>>
>>>Patch 0123 contains unit test for version checking code.
>>>
>>>Thanks to Martin^1 for the idea of using CFFI for calling rpm C-API directly.
>>>
>>>--
>>>Martin^3 Babinsky
>>
>>>From c7a5d8970d100d071597b4e1d7cef8a27b8cd485 Mon Sep 17 00:00:00 2001
>>>From: Martin Babinsky 
>>>Date: Fri, 8 Jan 2016 15:54:00 +0100
>>>Subject: [PATCH 2/3] tests for package version comparison
>>>
>>>These tests will ensure that our package version handling code can correctly
>>>decide when to upgrade IPA master.
>>>
>>>https://fedorahosted.org/freeipa/ticket/5572
>>>---
>>>ipatests/test_ipaserver/test_version_comparsion.py | 47 
>>>++
>>>1 file changed, 47 insertions(+)
>>>create mode 100644 ipatests/test_ipaserver/test_version_comparsion.py
>>>
>>>diff --git a/ipatests/test_ipaserver/test_version_comparsion.py 
>>>b/ipatests/test_ipaserver/test_version_comparsion.py
>>>new file mode 100644
>>>index 
>>>..51d069b23ba389ffce39e948cdbc7a1faaa84563
>>>--- /dev/null
>>>+++ b/ipatests/test_ipaserver/test_version_comparsion.py
>>>@@ -0,0 +1,47 @@
>>>+#
>>>+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
>>>+#
>>>+
>>>+"""
>>>+tests for correct RPM version comparison
>>>+"""
>>>+
>>>+from ipaplatform.tasks import tasks
>>>+import pytest
>>>+
>>>+version_strings = [
>>>+("3.0.el6", "3.0.0.el6", "older"),
>>>+("3.0.0.el6", "3.0.0.el6_8.2", "older"),
>>>+("3.0.0-42.el6", "3.0.0.el6", "newer"),
>>>+("3.0.0-1", "3.0.0-42", "older"),
>>>+("3.0.0-42.el6", "3.3.3.fc20", "older"),
>>>+("4.2.0-15.el7", "4.2.0-15.el7_2.3", "older"),
>>>+("4.2.0-15.el7_2.3", "4.2.0-15.el7_2.3", "equal"),
>>>+("4.2.0-1.fc23", "4.2.1.fc23", "older"),
>>>+("4.2.3-alpha.fc23", "4.2.3-2.fc23", "older"),  # numeric version 
>>>elements have
>>>+# precedence over letters
>>>+("4.3.90.201601080923GIT55aeea7-0.fc23", "4.3.0-1.fc23", "newer")
>>>+]
>>>+
>>>+
>>>+@pytest.fixture(params=version_strings)
>>>+def versions(request):
>>>+return request.param
>>>+
>>>+class TestVersionComparsion(object):
>>>+
>>>+def test_versions(self, versions):
>>>+version_string1, version_string2, expected_comparison = versions
>>>+
>>>+ver1 = tasks.parse_ipa_version(version_string1)
>>>+ver2 = tasks.parse_ipa_version(version_string2)
>>>+
>>>+if expected_comparison == "newer":
>>>+assert ver1 > ver2
>>>+elif expected_comparison == "older":
>>>+assert ver1 < ver2
>>>+elif expected_comparison == "equal":
>>>+assert ver1 == ver2
>>>+else:
>>>+raise TypeError(
>>>+"Unexpected comparison string: {}", expected_comparison)
>>>--
>>>2.5.0
>>>
>>
>>>From 9677e1a3ca2f5837f1b779780127adf27efa81df Mon Sep 17 00:00:00 2001
>>>From: Martin Babinsky 
>>>Date: Fri, 8 Jan 2016 14:17:14 +0100
>>>Subject: [PATCH 1/3] use FFI call to rpmvercmp function for version 
>>>comparison
>>>
>>>Stop using rpm-python to compare package versions since the implicit NSS
>>>initialization upon  the module import breaks NSS handling in IPA code. Call
>>>rpm-libs C-API function via CFFI instead.
>>>
>>>Big thanks to Martin Kosek  for sharing the code snippet
>>>that spurred this patch.
>>>
>>>https://fedorahosted.org/freeipa/ticket/5572
>>>---
>>>freeipa.spec.in |  2 +-
>>>ipaplatform/redhat/tasks.py | 59 
>>>+
>>>2 files changed, 29 insertions(+), 32 deletions(-)
>>>
>>>diff --git a/freeipa.spec.in b/freeipa.spec.in
>>>index 
>>>7e956538d0f6c24bab636579303e0c7b5eeec199..7f31d41d16b2a26b404c277595f0994a21123f80
>>> 100644
>>>--- a/freeipa.spec.in
>>>+++ b/freeipa.spec.in
>>>@@ -214,7 +214,7 @@ Requires: python-pyasn1
>>>Requires: dbus-python
>>>Requires: python-dns >= 1.11.1
>>>Requires: python-kdcproxy >= 0.3
>>>-Requires: rpm-python
>>>+Requires: rpm-devel
>>/usr/lib64/librpm.so.7 is provided by package rpm-libs
>>
>>
>>sh$ rpm -qf /usr/lib64/librpm.so.7
>>rpm-libs-4.13.0-0.rc1.7.fc23.x86_64
>>
>>It's not very common to depend on devel packages.
>>
>>LS
>>
>
>I was basically trying workaround this  http://fpaste.org/308652/22677521/
>
rpm-libs contains librpm.so.*
and cffi is smart enough to load right library with
C = ffi.dlopen("rpm")
So it's enough to add "Requires: rpm-libs"
but it would be almost noop because rpm-libs is everytime available
od fedora/rhel :-)

"Requires: rpm-devel"
add unnecessary additional runtime dependencies on pkgconfig, popt-devel


>librpm.so.7 belongs to rpm-libs and librpm.so to rpm-devel and I was lazy
>(hey it's friday) to add path to librpm.so.7 to paths and use it i LD loader.
>If you think that it is

Re: [Freeipa-devel] [PATCH 0118] fix Py3 incompatible exception instantiation in replica install code

2016-01-08 Thread Tomas Babej 


On 01/07/2016 05:56 PM, Martin Babinsky wrote:
> On 01/04/2016 09:02 AM, Martin Babinsky wrote:
>>
>>
>>
> I have created ticket to patch and added it to commit message:
> 
> https://fedorahosted.org/freeipa/ticket/5585
> 
> 
> 

ACK for these changes, however, there are additional occurrences in the
code base, attaching a patch.

Tomas
From 7475c1650e5cc5478a65166d853822b93419cd5e Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Fri, 8 Jan 2016 18:23:35 +0100
Subject: [PATCH] py3: Remove py3 incompatible exception handling

---
 doc/guide/guide.org| 4 ++--
 doc/guide/wsgi.py.txt  | 2 +-
 ipaserver/install/server/common.py | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/guide/guide.org b/doc/guide/guide.org
index 55c172535007b71e95f804f1a171fa547cfdf032..6d181559f0af90e7be7089aa94ab4900fa4e90b5 100644
--- a/doc/guide/guide.org
+++ b/doc/guide/guide.org
@@ -752,9 +752,9 @@ def run(api):
 except KeyboardInterrupt:
 print ''
 api.log.info('operation aborted')
-except PublicError, e:
+except PublicError as e:
 error = e
-except Exception, e:
+except Exception as e:
 api.log.exception('%s: %s', e.__class__.__name__, str(e))
 error = InternalError()
 if error is not None:
diff --git a/doc/guide/wsgi.py.txt b/doc/guide/wsgi.py.txt
index eb64f3a8285495ac0131872c99ab05485587556b..8566a25a16baa8c43288eee8bc480ffbd6eadf0b 100644
--- a/doc/guide/wsgi.py.txt
+++ b/doc/guide/wsgi.py.txt
@@ -13,7 +13,7 @@ env._finalize_core(**dict(DEFAULT_CONFIG))
 api.bootstrap(context='server', debug=env.debug, log=None) (ref:wsgi-app-bootstrap)
 try:
 api.finalize() (ref:wsgi-app-finalize)
-except Exception, e:
+except Exception as e:
 api.log.error('Failed to start IPA: %s' % e)
 else:
 api.log.info('*** PROCESS START ***')
diff --git a/ipaserver/install/server/common.py b/ipaserver/install/server/common.py
index 637e5664348bf3b7f2e4f2a867b8ecb224ccf388..08980c60f59ce0599a9bbe1cf53dcb2eedf7808d 100644
--- a/ipaserver/install/server/common.py
+++ b/ipaserver/install/server/common.py
@@ -138,7 +138,7 @@ class BaseServerCA(common.Installable, core.Group, core.Composite):
 for rdn in dn:
 if rdn.attr.lower() not in VALID_SUBJECT_ATTRS:
 raise ValueError("invalid attribute: \"%s\"" % rdn.attr)
-except ValueError, e:
+except ValueError as e:
 raise ValueError("invalid subject base format: %s" % e)
 
 ca_signing_algorithm = Knob(
@@ -243,7 +243,7 @@ class BaseServerDNS(common.Installable, core.Group, core.Composite):
 encoding = 'utf-8'
 value = value.decode(encoding)
 bindinstance.validate_zonemgr_str(value)
-except ValueError, e:
+except ValueError as e:
 # FIXME we can do this in better way
 # https://fedorahosted.org/freeipa/ticket/4804
 # decode to proper stderr encoding
-- 
2.5.0

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

2016-01-08 Thread Martin Basti 



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

--
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: Automatic Empty Zone handling in bind-dyndb-ldap

2016-01-08 Thread Martin Basti 



On 08.01.2016 16:57, Petr Spacek wrote:

Hello,

recent improvements in FreeIPA 4.3.0 (finally) prevent FreeIPA installer from
creating made-up DNS reverse zones, which already exist on some other DNS 
server.

This change uncovered a well-hidden automatic empty zones in BIND 9.9+, which
is now causing problem to users.

It seems that this can be fixed by change to the code which handles forward
DNS zones. Short design document with necessary background is available on:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones

Please be so kind and review it ASAP, so I can write the patch quickly and
make life of our QE guys easier.

Have a nice Friday.


Hello,

IIUC, the differences between default bind behaviour and bind-dyndb-ldap 
behaviour are:


* disable automatic empty zone when policy is 'first' or 'only', instead 
of just 'only'
I liked it more than default behaviour of named, but could be this 
somehow unexpected by users, or they will be happy that it works better 
(?) than in named?


* bind-dyndb-ldap will not recreate automate empty zone
IMO this should not harm at all

so design LGTM, I will thinking about it over this weekend




--
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 0122-0123] reimplementation of package version comparison code

2016-01-08 Thread Martin Babinsky 

On 01/08/2016 05:23 PM, Lukas Slebodnik wrote:

On (08/01/16 16:59), Martin Babinsky wrote:

Patch 0122 reimplements version checking and fixes
https://fedorahosted.org/freeipa/ticket/5572

Patch 0123 contains unit test for version checking code.

Thanks to Martin^1 for the idea of using CFFI for calling rpm C-API directly.

--
Martin^3 Babinsky



From c7a5d8970d100d071597b4e1d7cef8a27b8cd485 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 15:54:00 +0100
Subject: [PATCH 2/3] tests for package version comparison

These tests will ensure that our package version handling code can correctly
decide when to upgrade IPA master.

https://fedorahosted.org/freeipa/ticket/5572
---
ipatests/test_ipaserver/test_version_comparsion.py | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 ipatests/test_ipaserver/test_version_comparsion.py

diff --git a/ipatests/test_ipaserver/test_version_comparsion.py 
b/ipatests/test_ipaserver/test_version_comparsion.py
new file mode 100644
index 
..51d069b23ba389ffce39e948cdbc7a1faaa84563
--- /dev/null
+++ b/ipatests/test_ipaserver/test_version_comparsion.py
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
+#
+
+"""
+tests for correct RPM version comparison
+"""
+
+from ipaplatform.tasks import tasks
+import pytest
+
+version_strings = [
+("3.0.el6", "3.0.0.el6", "older"),
+("3.0.0.el6", "3.0.0.el6_8.2", "older"),
+("3.0.0-42.el6", "3.0.0.el6", "newer"),
+("3.0.0-1", "3.0.0-42", "older"),
+("3.0.0-42.el6", "3.3.3.fc20", "older"),
+("4.2.0-15.el7", "4.2.0-15.el7_2.3", "older"),
+("4.2.0-15.el7_2.3", "4.2.0-15.el7_2.3", "equal"),
+("4.2.0-1.fc23", "4.2.1.fc23", "older"),
+("4.2.3-alpha.fc23", "4.2.3-2.fc23", "older"),  # numeric version elements 
have
+# precedence over letters
+("4.3.90.201601080923GIT55aeea7-0.fc23", "4.3.0-1.fc23", "newer")
+]
+
+
+@pytest.fixture(params=version_strings)
+def versions(request):
+return request.param
+
+class TestVersionComparsion(object):
+
+def test_versions(self, versions):
+version_string1, version_string2, expected_comparison = versions
+
+ver1 = tasks.parse_ipa_version(version_string1)
+ver2 = tasks.parse_ipa_version(version_string2)
+
+if expected_comparison == "newer":
+assert ver1 > ver2
+elif expected_comparison == "older":
+assert ver1 < ver2
+elif expected_comparison == "equal":
+assert ver1 == ver2
+else:
+raise TypeError(
+"Unexpected comparison string: {}", expected_comparison)
--
2.5.0




From 9677e1a3ca2f5837f1b779780127adf27efa81df Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 14:17:14 +0100
Subject: [PATCH 1/3] use FFI call to rpmvercmp function for version comparison

Stop using rpm-python to compare package versions since the implicit NSS
initialization upon  the module import breaks NSS handling in IPA code. Call
rpm-libs C-API function via CFFI instead.

Big thanks to Martin Kosek  for sharing the code snippet
that spurred this patch.

https://fedorahosted.org/freeipa/ticket/5572
---
freeipa.spec.in |  2 +-
ipaplatform/redhat/tasks.py | 59 +
2 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 
7e956538d0f6c24bab636579303e0c7b5eeec199..7f31d41d16b2a26b404c277595f0994a21123f80
 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -214,7 +214,7 @@ Requires: python-pyasn1
Requires: dbus-python
Requires: python-dns >= 1.11.1
Requires: python-kdcproxy >= 0.3
-Requires: rpm-python
+Requires: rpm-devel

/usr/lib64/librpm.so.7 is provided by package rpm-libs


sh$ rpm -qf /usr/lib64/librpm.so.7
rpm-libs-4.13.0-0.rc1.7.fc23.x86_64

It's not very common to depend on devel packages.

LS



I was basically trying workaround this  http://fpaste.org/308652/22677521/

librpm.so.7 belongs to rpm-libs and librpm.so to rpm-devel and I was 
lazy (hey it's friday) to add path to librpm.so.7 to paths and use it i 
LD loader. If you think that it is not optimal I will fix it, but let's 
wait for some more feedback.


--
Martin^3 Babinsky

--
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 0399] Upgrade: fix upgrading of NIS Server configuration

2016-01-08 Thread Martin Basti 



On 08.01.2016 16:22, Martin Basti wrote:



On 08.01.2016 16:19, Petr Vobornik wrote:

On 01/08/2016 02:54 PM, Alexander Bokovoy wrote:

On Wed, 06 Jan 2016, Martin Basti wrote:

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

Patch attached.

Is proposed workaround in ticket enough or should I also prepare a
update that will fix missing maps?

The update you have is good but we need to recover missing maps.
Given that we know which maps exist in the broken setup (those from
50-nis.update), it would make sense to check if only those CNs exist 
and

then remove them and fire recovery.



Could there be a situation where such state would be desired and the 
update would actually break user's setup?

Only if user removed all these maps:

"nis-domain={domain}+nis-map=passwd.byname,{suffix}",
"nis-domain={domain}+nis-map=passwd.byuid,{suffix}",
"nis-domain={domain}+nis-map=group.byname,{suffix}",
"nis-domain={domain}+nis-map=group.bygid,{suffix}",
"nis-domain={domain}+nis-map=netid.byname,{suffix}",
"nis-domain={domain}+nis-map=netgroup,{suffix}",




Updated patch attached.
From 81744590c2570da1e1477b464d3614052cf6d8b1 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Wed, 6 Jan 2016 19:47:22 +0100
Subject: [PATCH] Upgrade: Fix upgrade of NIS Server configuration

Former upgrade file always created the NIS Server container, that caused
the ipa-nis-manage did not set all required NIS maps. Default creation
of container has been removed.

Updating of NIS Server configuration and
NIS maps is done only if the NIS Server container exists.

https://fedorahosted.org/freeipa/ticket/5507
---
 install/share/Makefile.am  |  1 +
 .../50-nis.update => share/nis-update.uldif}   | 19 +
 install/updates/50-nis.update  | 58 +--
 ipaplatform/base/paths.py  |  1 +
 ipaserver/install/plugins/update_nis.py| 86 ++
 5 files changed, 92 insertions(+), 73 deletions(-)
 copy install/{updates/50-nis.update => share/nis-update.uldif} (91%)
 create mode 100644 ipaserver/install/plugins/update_nis.py

diff --git a/install/share/Makefile.am b/install/share/Makefile.am
index 42f3972e1061fda5bfd23b2fa8f63d675f92f5ba..b4cb8312471a68d8cd855f542478afe10d200c39 100644
--- a/install/share/Makefile.am
+++ b/install/share/Makefile.am
@@ -61,6 +61,7 @@ app_DATA =\
 	memberof-task.ldif		\
 	memberof-conf.ldif		\
 	nis.uldif			\
+	nis-update.uldif			\
 	opendnssec_conf.template	\
 	opendnssec_kasp.template	\
 	unique-attributes.ldif		\
diff --git a/install/updates/50-nis.update b/install/share/nis-update.uldif
similarity index 91%
copy from install/updates/50-nis.update
copy to install/share/nis-update.uldif
index 149889ec7bdb38073eb6df88628792526cfe58e6..e602c1de061fbcece349b2d86970c4db5051473b 100644
--- a/install/updates/50-nis.update
+++ b/install/share/nis-update.uldif
@@ -1,20 +1,4 @@
-# NIS Server plugin must be disabled by default
-# command 'ipa-nis-manage enable' enables NIS server
-dn: cn=NIS Server,cn=plugins,cn=config
-default:objectclass: top
-default:objectclass: nsSlapdPlugin
-default:objectclass: extensibleObject
-default:cn: NIS Server
-default:nsslapd-pluginpath: /usr/lib$LIBARCH/dirsrv/plugins/nisserver-plugin.so
-default:nsslapd-plugininitfunc: nis_plugin_init
-default:nsslapd-plugintype: object
-default:nsslapd-pluginbetxn: on
-default:nsslapd-pluginenabled: off
-default:nsslapd-pluginid: nis-server
-default:nsslapd-pluginversion: 0.10
-default:nsslapd-pluginvendor: redhat.com
-default:nsslapd-plugindescription: NIS Server Plugin
-default:nis-tcp-wrappers-name: nis-server
+# Updates for NIS
 
 # Correct syntax error that caused users to not appear
 dn: nis-domain=$DOMAIN+nis-map=netgroup, cn=NIS Server, cn=plugins, cn=config
@@ -52,4 +36,3 @@ default:nis-filter: (&(macAddress=*)(fqdn=*)(objectClass=ipaHost))
 default:nis-keys-format: %mregsub("%{macAddress} %{fqdn}","(..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..) (.*)","%7")
 default:nis-values-format: %mregsub("%{macAddress} %{fqdn}","(..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..)[:\\\|-](..) (.*)","%1:%2:%3:%4:%5:%6 %7")
 default:nis-secure: no
-
diff --git a/install/updates/50-nis.update b/install/updates/50-nis.update
index 149889ec7bdb38073eb6df88628792526cfe58e6..05a166f003aefc50fc25f10f01f7364d752425bc 100644
--- a/install/updates/50-nis.update
+++ b/install/updates/50-nis.update
@@ -1,55 +1,3 @@
-# NIS Server plugin must be disabled by default
-# command 'ipa-nis-manage enable' enables NIS server
-dn: cn=NIS Server,cn=plugins,cn=config
-default:objectclass: top
-default:objectclass: nsSlapdPlugin
-default:objectclass: extensibleObject
-default:cn: NIS Server
-default:nsslapd-pluginpath: /usr/lib$LIBARCH/dirsrv/plugins/nisserver-plugin.so
-default:nsslapd-plugininitfunc: nis_plugin_init
-default:nsslapd-plugintype: object
-default:nsslapd-pluginbetxn: on
-default:nsslapd-pluginenabled: off
-default:nsslapd-pluginid: nis-server

Re: [Freeipa-devel] [PATCH 0122-0123] reimplementation of package version comparison code

2016-01-08 Thread Lukas Slebodnik 
On (08/01/16 16:59), Martin Babinsky wrote:
>Patch 0122 reimplements version checking and fixes
>https://fedorahosted.org/freeipa/ticket/5572
>
>Patch 0123 contains unit test for version checking code.
>
>Thanks to Martin^1 for the idea of using CFFI for calling rpm C-API directly.
>
>-- 
>Martin^3 Babinsky

>From c7a5d8970d100d071597b4e1d7cef8a27b8cd485 Mon Sep 17 00:00:00 2001
>From: Martin Babinsky 
>Date: Fri, 8 Jan 2016 15:54:00 +0100
>Subject: [PATCH 2/3] tests for package version comparison
>
>These tests will ensure that our package version handling code can correctly
>decide when to upgrade IPA master.
>
>https://fedorahosted.org/freeipa/ticket/5572
>---
> ipatests/test_ipaserver/test_version_comparsion.py | 47 ++
> 1 file changed, 47 insertions(+)
> create mode 100644 ipatests/test_ipaserver/test_version_comparsion.py
>
>diff --git a/ipatests/test_ipaserver/test_version_comparsion.py 
>b/ipatests/test_ipaserver/test_version_comparsion.py
>new file mode 100644
>index 
>..51d069b23ba389ffce39e948cdbc7a1faaa84563
>--- /dev/null
>+++ b/ipatests/test_ipaserver/test_version_comparsion.py
>@@ -0,0 +1,47 @@
>+#
>+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
>+#
>+
>+"""
>+tests for correct RPM version comparison
>+"""
>+
>+from ipaplatform.tasks import tasks
>+import pytest
>+
>+version_strings = [
>+("3.0.el6", "3.0.0.el6", "older"),
>+("3.0.0.el6", "3.0.0.el6_8.2", "older"),
>+("3.0.0-42.el6", "3.0.0.el6", "newer"),
>+("3.0.0-1", "3.0.0-42", "older"),
>+("3.0.0-42.el6", "3.3.3.fc20", "older"),
>+("4.2.0-15.el7", "4.2.0-15.el7_2.3", "older"),
>+("4.2.0-15.el7_2.3", "4.2.0-15.el7_2.3", "equal"),
>+("4.2.0-1.fc23", "4.2.1.fc23", "older"),
>+("4.2.3-alpha.fc23", "4.2.3-2.fc23", "older"),  # numeric version 
>elements have
>+# precedence over letters
>+("4.3.90.201601080923GIT55aeea7-0.fc23", "4.3.0-1.fc23", "newer")
>+]
>+
>+
>+@pytest.fixture(params=version_strings)
>+def versions(request):
>+return request.param
>+
>+class TestVersionComparsion(object):
>+
>+def test_versions(self, versions):
>+version_string1, version_string2, expected_comparison = versions
>+
>+ver1 = tasks.parse_ipa_version(version_string1)
>+ver2 = tasks.parse_ipa_version(version_string2)
>+
>+if expected_comparison == "newer":
>+assert ver1 > ver2
>+elif expected_comparison == "older":
>+assert ver1 < ver2
>+elif expected_comparison == "equal":
>+assert ver1 == ver2
>+else:
>+raise TypeError(
>+"Unexpected comparison string: {}", expected_comparison)
>-- 
>2.5.0
>

>From 9677e1a3ca2f5837f1b779780127adf27efa81df Mon Sep 17 00:00:00 2001
>From: Martin Babinsky 
>Date: Fri, 8 Jan 2016 14:17:14 +0100
>Subject: [PATCH 1/3] use FFI call to rpmvercmp function for version comparison
>
>Stop using rpm-python to compare package versions since the implicit NSS
>initialization upon  the module import breaks NSS handling in IPA code. Call
>rpm-libs C-API function via CFFI instead.
>
>Big thanks to Martin Kosek  for sharing the code snippet
>that spurred this patch.
>
>https://fedorahosted.org/freeipa/ticket/5572
>---
> freeipa.spec.in |  2 +-
> ipaplatform/redhat/tasks.py | 59 +
> 2 files changed, 29 insertions(+), 32 deletions(-)
>
>diff --git a/freeipa.spec.in b/freeipa.spec.in
>index 
>7e956538d0f6c24bab636579303e0c7b5eeec199..7f31d41d16b2a26b404c277595f0994a21123f80
> 100644
>--- a/freeipa.spec.in
>+++ b/freeipa.spec.in
>@@ -214,7 +214,7 @@ Requires: python-pyasn1
> Requires: dbus-python
> Requires: python-dns >= 1.11.1
> Requires: python-kdcproxy >= 0.3
>-Requires: rpm-python
>+Requires: rpm-devel
/usr/lib64/librpm.so.7 is provided by package rpm-libs


sh$ rpm -qf /usr/lib64/librpm.so.7
rpm-libs-4.13.0-0.rc1.7.fc23.x86_64

It's not very common to depend on devel packages.

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

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

2016-01-08 Thread Martin Babinsky 

fixes ipa-csreplica-manage del blowing up due

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

for master and ipa-4-3 only.

--
Martin^3 Babinsky

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

2016-01-08 Thread Petr Spacek 
On 8.1.2016 16:57, Christian Heimes wrote:
> On 2016-01-08 16:49, Petr Spacek wrote:
>> On 8.1.2016 13:56, 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
>>
>> HMAC-SHA1 reminded me recently published paper:
>> http://www.mitls.org/pages/attacks/SLOTH
>>
>> It claims that all MD5 and SHA1 uses should be eliminated if feasible.
> 
> MD5 and SHA-1 should no longer be used for signatures. MACs are a
> completely different story. HMAC-SHA1 and even HMAC-MD5 are still fine
> and believed to be secure.
> 
> https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security


Christian, have you read the page (or even better the paper) I linked above?

The page starts with this:
> Introduction
> 
> In response to recent high-profile attacks that exploit hash function 
> collisions, software vendors have started to phase out the use of MD5 and 
> SHA1 in third-party digital signature applications such as X.509 
> certificates. However, weak hash functions continue to be used in various 
> cryptographic constructions within mainstream protocols such as TLS, IKE, and 
> SSH, because practitioners argue that their use in these protocols relies 
> only on second preimage resistance, and hence is unaffected by collisions. We 
> systematically investigate and debunk this argument.
> 
> We identify a new class of transcript collision attacks on popular 
> cryptographic protocols such as TLS, IKE, and SSH, that significantly reduce 
> their expected security. Our attacks rely on the use of obsolete hash 
> constructions in these protocols. 


If you open the paper, it has this on the very first page:
[...]
> This leaves open the question of what to do about
> other uses of MD5 and SHA-1 in popular crypto-
> graphic protocols. Practitioners commonly believe that
> collisions only affect non-repudiable signatures (like
> certificates), but that signatures and MACs used within
> protocols are safe as long as they include unpredictable
> contents, such as nonces [16], [15].In these cases,
> protocol folklore says that a second preimage attack
> would be required to break these protocols, and such
> attacks are still considered hard, even for MD5.
> Conversely, theoretical cryptographers routinely as-
> sume collision-resistance in proofs of security for
> these protocols. For example, various recent proofs of
>
> TLS [17], [22], [11] assume collision-resistance even
> though the most popular hash functions used in TLS
> are MD5 and SHA-1. Whom shall we believe? Either it
> is the case that cryptographic proofs of these protocols
> are based on too-strong (i.e. false) assumptions that
> should be weakened, or that practitioners are wrong and
> collision resistance is required for protocol security.
> This paper seeks to clarify this situation by systemat-
> ically investigating the use of hash functions in the key
> exchanges underlying various versions of TLS, IPsec,
> and SSH. We demonstrate that, contrary to common
> belief, collisions can be used to break fundamental secu-
> rity guarantees of these protocols.


One thing I remember from my cryptography courses I had on university is that
I should not try to outsmart professional cryptographers when it comes to
assessing security properties :-D

Judging from this: Claims on the Wikipedia page are not sufficient guarantee
for me, sorry.

-- 
Petr^2 Spacek

-- 
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 0122-0123] reimplementation of package version comparison code

2016-01-08 Thread Martin Babinsky 

Patch 0122 reimplements version checking and fixes
https://fedorahosted.org/freeipa/ticket/5572

Patch 0123 contains unit test for version checking code.

Thanks to Martin^1 for the idea of using CFFI for calling rpm C-API 
directly.


--
Martin^3 Babinsky
From c7a5d8970d100d071597b4e1d7cef8a27b8cd485 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 15:54:00 +0100
Subject: [PATCH 2/3] tests for package version comparison

These tests will ensure that our package version handling code can correctly
decide when to upgrade IPA master.

https://fedorahosted.org/freeipa/ticket/5572
---
 ipatests/test_ipaserver/test_version_comparsion.py | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 ipatests/test_ipaserver/test_version_comparsion.py

diff --git a/ipatests/test_ipaserver/test_version_comparsion.py b/ipatests/test_ipaserver/test_version_comparsion.py
new file mode 100644
index ..51d069b23ba389ffce39e948cdbc7a1faaa84563
--- /dev/null
+++ b/ipatests/test_ipaserver/test_version_comparsion.py
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2015  FreeIPA Contributors see COPYING for license
+#
+
+"""
+tests for correct RPM version comparison
+"""
+
+from ipaplatform.tasks import tasks
+import pytest
+
+version_strings = [
+("3.0.el6", "3.0.0.el6", "older"),
+("3.0.0.el6", "3.0.0.el6_8.2", "older"),
+("3.0.0-42.el6", "3.0.0.el6", "newer"),
+("3.0.0-1", "3.0.0-42", "older"),
+("3.0.0-42.el6", "3.3.3.fc20", "older"),
+("4.2.0-15.el7", "4.2.0-15.el7_2.3", "older"),
+("4.2.0-15.el7_2.3", "4.2.0-15.el7_2.3", "equal"),
+("4.2.0-1.fc23", "4.2.1.fc23", "older"),
+("4.2.3-alpha.fc23", "4.2.3-2.fc23", "older"),  # numeric version elements have
+# precedence over letters
+("4.3.90.201601080923GIT55aeea7-0.fc23", "4.3.0-1.fc23", "newer")
+]
+
+
+@pytest.fixture(params=version_strings)
+def versions(request):
+return request.param
+
+class TestVersionComparsion(object):
+
+def test_versions(self, versions):
+version_string1, version_string2, expected_comparison = versions
+
+ver1 = tasks.parse_ipa_version(version_string1)
+ver2 = tasks.parse_ipa_version(version_string2)
+
+if expected_comparison == "newer":
+assert ver1 > ver2
+elif expected_comparison == "older":
+assert ver1 < ver2
+elif expected_comparison == "equal":
+assert ver1 == ver2
+else:
+raise TypeError(
+"Unexpected comparison string: {}", expected_comparison)
-- 
2.5.0

From 9677e1a3ca2f5837f1b779780127adf27efa81df Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 14:17:14 +0100
Subject: [PATCH 1/3] use FFI call to rpmvercmp function for version comparison

Stop using rpm-python to compare package versions since the implicit NSS
initialization upon  the module import breaks NSS handling in IPA code. Call
rpm-libs C-API function via CFFI instead.

Big thanks to Martin Kosek  for sharing the code snippet
that spurred this patch.

https://fedorahosted.org/freeipa/ticket/5572
---
 freeipa.spec.in |  2 +-
 ipaplatform/redhat/tasks.py | 59 +
 2 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 7e956538d0f6c24bab636579303e0c7b5eeec199..7f31d41d16b2a26b404c277595f0994a21123f80 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -214,7 +214,7 @@ Requires: python-pyasn1
 Requires: dbus-python
 Requires: python-dns >= 1.11.1
 Requires: python-kdcproxy >= 0.3
-Requires: rpm-python
+Requires: rpm-devel
 
 %description -n python2-ipaserver
 IPA is an integrated solution to provide centrally managed Identity (users,
diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index a0b4060cb26bab66248c4397c24b4d58bf1bf8d6..938e0720768c9eb4fe8b3bd31884472495a6be28 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -30,13 +30,13 @@ import stat
 import socket
 import sys
 import base64
+from cffi import FFI
 from functools import total_ordering
 
 from subprocess import CalledProcessError
 from nss.error import NSPRError
 from pyasn1.error import PyAsn1Error
 from six.moves import urllib
-import rpm
 
 from ipapython.ipa_log_manager import root_logger, log_mgr
 from ipapython import ipautil
@@ -49,33 +49,30 @@ from ipaplatform.redhat.authconfig import RedHatAuthConfig
 from ipaplatform.base.tasks import BaseTaskNamespace
 
 
-# copied from rpmUtils/miscutils.py
-def stringToVersion(verstring):
-if verstring in [None, '']:
-return (None, None, None)
-i = verstring.find(':')
-if i != -1:
-try:
-epoch = str(long(verstring[:i]))
-except ValueError:
-# look, garbage in the epoch field, how fun, kill it
-epoch = '0' # this is our fallback, deal
-else:
-

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

2016-01-08 Thread Christian Heimes 
On 2016-01-08 16:49, Petr Spacek wrote:
> On 8.1.2016 13:56, 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
> 
> HMAC-SHA1 reminded me recently published paper:
> http://www.mitls.org/pages/attacks/SLOTH
> 
> It claims that all MD5 and SHA1 uses should be eliminated if feasible.

MD5 and SHA-1 should no longer be used for signatures. MACs are a
completely different story. HMAC-SHA1 and even HMAC-MD5 are still fine
and believed to be secure.

https://en.wikipedia.org/wiki/Hash-based_message_authentication_code#Security




signature.asc
Description: OpenPGP digital 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] Design: Automatic Empty Zone handling in bind-dyndb-ldap

2016-01-08 Thread Petr Spacek 
Hello,

recent improvements in FreeIPA 4.3.0 (finally) prevent FreeIPA installer from
creating made-up DNS reverse zones, which already exist on some other DNS 
server.

This change uncovered a well-hidden automatic empty zones in BIND 9.9+, which
is now causing problem to users.

It seems that this can be fixed by change to the code which handles forward
DNS zones. Short design document with necessary background is available on:
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones

Please be so kind and review it ASAP, so I can write the patch quickly and
make life of our QE guys easier.

Have a nice Friday.

-- 
Petr^2 Spacek

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

2016-01-08 Thread Petr Spacek 
On 8.1.2016 13:56, 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

HMAC-SHA1 reminded me recently published paper:
http://www.mitls.org/pages/attacks/SLOTH

It claims that all MD5 and SHA1 uses should be eliminated if feasible.

> TL;DR
> ... So, if you can afford to do so, get rid of MD5 and SHA1 in all your 
> protocol configurations. 

I have no idea if we can do that, but we should at least try ...

-- 
Petr^2 Spacek

-- 
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 0398] Allow to use mixed case for sysrestore

2016-01-08 Thread Martin Babinsky 

On 01/07/2016 05:55 PM, Martin Basti wrote:



On 06.01.2016 19:08, Martin Basti wrote:

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

Patch attached.






I missed one occurrence, updated patch attached.



ACK

(also the reason why Martin^2 didn't do it the nice way by subclassing 
SafeConfigParser and overriding optionxform method in the subclass was 
that such approach with combination of imports through six made pylint 
panic massively)


--
Martin^3 Babinsky

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

2016-01-08 Thread Martin Babinsky 

On 01/08/2016 04:10 PM, Lukas Slebodnik wrote:

On (08/01/16 14:18), 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.

--
Martin^3 Babinsky



From 32ebf02d38b7174816f81579aab6ebbe26e80f64 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 14:17:14 +0100
Subject: [PATCH] use rpmvercmp via python-cffi for version comparison

---
ipaplatform/redhat/tasks.py | 45 ++---
1 file changed, 14 insertions(+), 31 deletions(-)

diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index a0b4060..66ca3ad 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -36,7 +36,7 @@ from subprocess import CalledProcessError
from nss.error import NSPRError
from pyasn1.error import PyAsn1Error
from six.moves import urllib
-import rpm
+from cffi import FFI

from ipapython.ipa_log_manager import root_logger, log_mgr
from ipapython import ipautil
@@ -49,33 +49,16 @@ from ipaplatform.redhat.authconfig import RedHatAuthConfig
from ipaplatform.base.tasks import BaseTaskNamespace


-# copied from rpmUtils/miscutils.py
-def stringToVersion(verstring):
-if verstring in [None, '']:
-return (None, None, None)
-i = verstring.find(':')
-if i != -1:
-try:
-epoch = str(long(verstring[:i]))
-except ValueError:
-# look, garbage in the epoch field, how fun, kill it
-epoch = '0' # this is our fallback, deal
-else:
-epoch = '0'
-j = verstring.find('-')
-if j != -1:
-if verstring[i + 1:j] == '':
-version = None
-else:
-version = verstring[i + 1:j]
-release = verstring[j + 1:]
-else:
-if verstring[i + 1:] == '':
-version = None
-else:
-version = verstring[i + 1:]
-release = None
-return (epoch, version, release)
+def compare_rpm_versions(ver1, ver2):
+ffi = FFI()
+ffi.cdef("""
+int rpmvercmp (const char *a, const char *b);
+""")
+C = ffi.dlopen("rpmlib.so.3")

rpmlib.so.3 does not exist.

It is is librpm.so.3
But as I mentioned in different mail. The soname was bumped in fedora 23.

So please use only 'ffi.dlopen("rpm")'

It would be also good to write unit test for this function.
So you can detect issues with cffi is any.


a = '4.2.0-15.el7'
b = '4.2.0-15.el7_2.3'
c = '4.2.0-16.el7'
compare_rpm_versions(a, b)
compare_rpm_versions(b, b)
compare_rpm_versions(c, b)

LS



Thank you for suggestions Lukas, I have patch and unit tests ready. They 
will land on the list shortly.


--
Martin^3 Babinsky

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

2016-01-08 Thread 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] [PATCH 0399] Upgrade: fix upgrading of NIS Server configuration

2016-01-08 Thread Alexander Bokovoy 

On Fri, 08 Jan 2016, Petr Vobornik wrote:

On 01/08/2016 02:54 PM, Alexander Bokovoy wrote:

On Wed, 06 Jan 2016, Martin Basti wrote:

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

Patch attached.

Is proposed workaround in ticket enough or should I also prepare a
update that will fix missing maps?

The update you have is good but we need to recover missing maps.
Given that we know which maps exist in the broken setup (those from
50-nis.update), it would make sense to check if only those CNs exist and
then remove them and fire recovery.



Could there be a situation where such state would be desired and the 
update would actually break user's setup?

It is highly unlikely someone would want to remove all maps but
ethers.byaddr and ethers.byname. That's our bug right now.
--
/ Alexander Bokovoy

--
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 0399] Upgrade: fix upgrading of NIS Server configuration

2016-01-08 Thread Martin Basti 



On 08.01.2016 16:19, Petr Vobornik wrote:

On 01/08/2016 02:54 PM, Alexander Bokovoy wrote:

On Wed, 06 Jan 2016, Martin Basti wrote:

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

Patch attached.

Is proposed workaround in ticket enough or should I also prepare a
update that will fix missing maps?

The update you have is good but we need to recover missing maps.
Given that we know which maps exist in the broken setup (those from
50-nis.update), it would make sense to check if only those CNs exist and
then remove them and fire recovery.



Could there be a situation where such state would be desired and the 
update would actually break user's setup?

Only if user removed all these maps:

"nis-domain={domain}+nis-map=passwd.byname,{suffix}",
"nis-domain={domain}+nis-map=passwd.byuid,{suffix}",
"nis-domain={domain}+nis-map=group.byname,{suffix}",
"nis-domain={domain}+nis-map=group.bygid,{suffix}",
"nis-domain={domain}+nis-map=netid.byname,{suffix}",
"nis-domain={domain}+nis-map=netgroup,{suffix}",


-- 
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 0399] Upgrade: fix upgrading of NIS Server configuration

2016-01-08 Thread Petr Vobornik 

On 01/08/2016 02:54 PM, Alexander Bokovoy wrote:

On Wed, 06 Jan 2016, Martin Basti wrote:

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

Patch attached.

Is proposed workaround in ticket enough or should I also prepare a
update that will fix missing maps?

The update you have is good but we need to recover missing maps.
Given that we know which maps exist in the broken setup (those from
50-nis.update), it would make sense to check if only those CNs exist and
then remove them and fire recovery.



Could there be a situation where such state would be desired and the 
update would actually break user's setup?

--
Petr Vobornik

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

2016-01-08 Thread Lukas Slebodnik 
On (08/01/16 14:18), 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.
>
>-- 
>Martin^3 Babinsky

>From 32ebf02d38b7174816f81579aab6ebbe26e80f64 Mon Sep 17 00:00:00 2001
>From: Martin Babinsky 
>Date: Fri, 8 Jan 2016 14:17:14 +0100
>Subject: [PATCH] use rpmvercmp via python-cffi for version comparison
>
>---
> ipaplatform/redhat/tasks.py | 45 ++---
> 1 file changed, 14 insertions(+), 31 deletions(-)
>
>diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
>index a0b4060..66ca3ad 100644
>--- a/ipaplatform/redhat/tasks.py
>+++ b/ipaplatform/redhat/tasks.py
>@@ -36,7 +36,7 @@ from subprocess import CalledProcessError
> from nss.error import NSPRError
> from pyasn1.error import PyAsn1Error
> from six.moves import urllib
>-import rpm
>+from cffi import FFI
> 
> from ipapython.ipa_log_manager import root_logger, log_mgr
> from ipapython import ipautil
>@@ -49,33 +49,16 @@ from ipaplatform.redhat.authconfig import RedHatAuthConfig
> from ipaplatform.base.tasks import BaseTaskNamespace
> 
> 
>-# copied from rpmUtils/miscutils.py
>-def stringToVersion(verstring):
>-if verstring in [None, '']:
>-return (None, None, None)
>-i = verstring.find(':')
>-if i != -1:
>-try:
>-epoch = str(long(verstring[:i]))
>-except ValueError:
>-# look, garbage in the epoch field, how fun, kill it
>-epoch = '0' # this is our fallback, deal
>-else:
>-epoch = '0'
>-j = verstring.find('-')
>-if j != -1:
>-if verstring[i + 1:j] == '':
>-version = None
>-else:
>-version = verstring[i + 1:j]
>-release = verstring[j + 1:]
>-else:
>-if verstring[i + 1:] == '':
>-version = None
>-else:
>-version = verstring[i + 1:]
>-release = None
>-return (epoch, version, release)
>+def compare_rpm_versions(ver1, ver2):
>+ffi = FFI()
>+ffi.cdef("""
>+int rpmvercmp (const char *a, const char *b);
>+""")
>+C = ffi.dlopen("rpmlib.so.3")
rpmlib.so.3 does not exist.

It is is librpm.so.3
But as I mentioned in different mail. The soname was bumped in fedora 23.

So please use only 'ffi.dlopen("rpm")'

It would be also good to write unit test for this function.
So you can detect issues with cffi is any.


a = '4.2.0-15.el7'
b = '4.2.0-15.el7_2.3'
c = '4.2.0-16.el7'
compare_rpm_versions(a, b)
compare_rpm_versions(b, b)
compare_rpm_versions(c, b)

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] import rpm causes failure during IPA caless install

2016-01-08 Thread Tomas Babej 


On 01/08/2016 03:31 PM, Lukas Slebodnik wrote:
> On (08/01/16 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").
>>
> CentOS 7 has librpm.so.3
> but fedora 23+ has librpm.so.7
> 
> So if it is possible it will be good to avoid using specific vertsion.
> 
> LS
> 

Yes.

I think it should be quite possible to not use specific version, the
interface signature itself is not likely to change.

Even if it did, the problem would be detected immediately with the most
basic of tests ()installation&run).

Tomas

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

2016-01-08 Thread Lukas Slebodnik 
On (08/01/16 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").
>
CentOS 7 has librpm.so.3
but fedora 23+ has librpm.so.7

So if it is possible it will be good to avoid using specific vertsion.

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] FreeIPA and modern requirements on certificates

2016-01-08 Thread Rob Crittenden 
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

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] [PATCH 0399] Upgrade: fix upgrading of NIS Server configuration

2016-01-08 Thread Alexander Bokovoy 

On Wed, 06 Jan 2016, Martin Basti wrote:

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

Patch attached.

Is proposed workaround in ticket enough or should I also prepare a 
update that will fix missing maps?

The update you have is good but we need to recover missing maps.
Given that we know which maps exist in the broken setup (those from
50-nis.update), it would make sense to check if only those CNs exist and
then remove them and fire recovery.

--
/ Alexander Bokovoy

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

2016-01-08 Thread Martin Babinsky 

On 01/08/2016 02:40 PM, Martin Kosek wrote:

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



No problem, we can even send it as two authors 
(http://stackoverflow.com/questions/7442112/attributing-a-single-commit-to-multiple-developers). 
You would be the second one, as ideamakers usually are in academic 
papers :).


--
Martin^3 Babinsky

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

2016-01-08 Thread Jan Cholasta 

On 8.1.2016 14:34, Martin Kosek wrote:

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:



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.


Loading a library and going through cffi just to call ~20 lines of code 
seems like an overkill to me.


(TBH I don't care how this is implemented, relying on linear versioning 
is broken by design, one way or another.)


--
Jan Cholasta

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

2016-01-08 Thread 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] import rpm causes failure during IPA caless install

2016-01-08 Thread Martin Babinsky 

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.



It is not and the version comparison using rpmvercmp call through CFFI 
makes CA-less install and replica prepare work again.


--
Martin^3 Babinsky

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

2016-01-08 Thread 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] FreeIPA and modern requirements on certificates

2016-01-08 Thread Alexander Bokovoy 

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.

--
/ Alexander Bokovoy

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

2016-01-08 Thread 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:
>> 
> 
> 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

2016-01-08 Thread 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:
> 

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] import rpm causes failure during IPA caless install

2016-01-08 Thread Alexander Bokovoy 

On Fri, 08 Jan 2016, Jan Cholasta wrote:

I would be surprised if NSS was used in this particular function.


I will try it


No NSS here: 


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

Still, we need to be careful in a case where RPM team would decide to
upgrade rpm version comparison algorithm. It has been fixed for quite
some years (the core wasn't changed since 2008) but occasionally there
are additions that expand supported formats like addition of dpkg-style
versions in 2012.
--
/ Alexander Bokovoy

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

2016-01-08 Thread 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] FreeIPA and modern requirements on certificates

2016-01-08 Thread Christian Heimes 
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

Christian



signature.asc
Description: OpenPGP digital 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

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

2016-01-08 Thread Alexander Bokovoy 

On Fri, 08 Jan 2016, 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.

This function does not use NSS so it should be fine. python-rpm, on
other side, initializes itself with access to NSS database on mere
import of 'rpm' module.
--
/ Alexander Bokovoy

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

2016-01-08 Thread Jan Cholasta 

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: 



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


--
Jan Cholasta

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

2016-01-08 Thread Martin Babinsky 

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.


--
Martin^3 Babinsky
From 32ebf02d38b7174816f81579aab6ebbe26e80f64 Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 8 Jan 2016 14:17:14 +0100
Subject: [PATCH] use rpmvercmp via python-cffi for version comparison

---
 ipaplatform/redhat/tasks.py | 45 ++---
 1 file changed, 14 insertions(+), 31 deletions(-)

diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index a0b4060..66ca3ad 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -36,7 +36,7 @@ from subprocess import CalledProcessError
 from nss.error import NSPRError
 from pyasn1.error import PyAsn1Error
 from six.moves import urllib
-import rpm
+from cffi import FFI
 
 from ipapython.ipa_log_manager import root_logger, log_mgr
 from ipapython import ipautil
@@ -49,33 +49,16 @@ from ipaplatform.redhat.authconfig import RedHatAuthConfig
 from ipaplatform.base.tasks import BaseTaskNamespace
 
 
-# copied from rpmUtils/miscutils.py
-def stringToVersion(verstring):
-if verstring in [None, '']:
-return (None, None, None)
-i = verstring.find(':')
-if i != -1:
-try:
-epoch = str(long(verstring[:i]))
-except ValueError:
-# look, garbage in the epoch field, how fun, kill it
-epoch = '0' # this is our fallback, deal
-else:
-epoch = '0'
-j = verstring.find('-')
-if j != -1:
-if verstring[i + 1:j] == '':
-version = None
-else:
-version = verstring[i + 1:j]
-release = verstring[j + 1:]
-else:
-if verstring[i + 1:] == '':
-version = None
-else:
-version = verstring[i + 1:]
-release = None
-return (epoch, version, release)
+def compare_rpm_versions(ver1, ver2):
+ffi = FFI()
+ffi.cdef("""
+int rpmvercmp (const char *a, const char *b);
+""")
+C = ffi.dlopen("rpmlib.so.3")
+arg1 = ffi.new("char[]", ver1)
+arg2 = ffi.new("char[]", ver2)
+
+return C.rpmvercmp(arg1, arg2)
 
 
 log = log_mgr.get_logger(__name__)
@@ -101,15 +84,15 @@ def selinux_enabled():
 class IPAVersion(object):
 
 def __init__(self, version):
-self.version_tuple = stringToVersion(version)
+self.version = version
 
 def __eq__(self, other):
 assert isinstance(other, IPAVersion)
-return rpm.labelCompare(self.version_tuple, other.version_tuple) == 0
+return compare_rpm_versions(self.version, other.version) == 0
 
 def __lt__(self, other):
 assert isinstance(other, IPAVersion)
-return rpm.labelCompare(self.version_tuple, other.version_tuple) == -1
+return compare_rpm_versions(self.version, other.version) == -1
 
 
 class RedHatTaskNamespace(BaseTaskNamespace):
-- 
2.5.0

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

2016-01-08 Thread Fraser Tweedale 
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.

Cheers,
Fraser

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

2016-01-08 Thread Martin Basti 



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

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

2016-01-08 Thread Jan Cholasta 

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.

--
Jan Cholasta

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

2016-01-08 Thread 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] import rpm causes failure during IPA caless install

2016-01-08 Thread Martin Basti 



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


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

2016-01-08 Thread Alexander Bokovoy 

On Fri, 08 Jan 2016, Tomas Babej 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




I guess this needs to be fixed on the RPM side, so we should file a
ticket there, referencing ours. As we discussed, this is most likely
insufficient cleanup performed on their side.

It will not be fixed on RPM side because they need access to
certificate's store and NSS library is just not designed to be a library
with multiple uncoordinated users inside the same application.


As far as the fix goes, I'd leverage the external tool in this situation.

Yes, go with external tool, really.
--
/ Alexander Bokovoy

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

2016-01-08 Thread 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

2016-01-08 Thread 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

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

2016-01-08 Thread Fraser Tweedale 
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

> 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] import rpm causes failure during IPA caless install

2016-01-08 Thread Tomas Babej 


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

I guess this needs to be fixed on the RPM side, so we should file a
ticket there, referencing ours. As we discussed, this is most likely
insufficient cleanup performed on their side.

As far as the fix goes, I'd leverage the external tool in this situation.

Tomas

-- 
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] import rpm causes failure during IPA caless install

2016-01-08 Thread Martin Basti 

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
From bc665a86825c6fb5654eb3446a85ecc08ef7eefd Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Fri, 8 Jan 2016 13:24:20 +0100
Subject: [PATCH] fix rpm import

---
 ipaplatform/redhat/tasks.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ipaplatform/redhat/tasks.py b/ipaplatform/redhat/tasks.py
index a0b4060cb26bab66248c4397c24b4d58bf1bf8d6..e5cce42af286826ec8cb7e4266eef7cd691fce23 100644
--- a/ipaplatform/redhat/tasks.py
+++ b/ipaplatform/redhat/tasks.py
@@ -36,7 +36,6 @@ from subprocess import CalledProcessError
 from nss.error import NSPRError
 from pyasn1.error import PyAsn1Error
 from six.moves import urllib
-import rpm
 
 from ipapython.ipa_log_manager import root_logger, log_mgr
 from ipapython import ipautil
@@ -105,10 +104,12 @@ class IPAVersion(object):
 
 def __eq__(self, other):
 assert isinstance(other, IPAVersion)
+import rpm
 return rpm.labelCompare(self.version_tuple, other.version_tuple) == 0
 
 def __lt__(self, other):
 assert isinstance(other, IPAVersion)
+import rpm
 return rpm.labelCompare(self.version_tuple, other.version_tuple) == -1
 
 
-- 
2.5.0

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

2016-01-08 Thread 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

[Freeipa-devel] Fix ipa-replica-prepare after DNS check patches

2016-01-08 Thread David Kupka 

https://fedorahosted.org/freeipa/ticket/5563
--
David Kupka
From 7d8bf4809059f97ff62f4b9a73a486ed7d19d6bb Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Tue, 22 Dec 2015 13:53:41 +
Subject: [PATCH] ipa-replica-prepare: Add '--auto-reverse' and
 '--allow-zone-overlap' options

Opiton should be added to ipa-replica-prepare when it was added to
ipa-{server,replica,dns}-install but was forgotten.

https://fedorahosted.org/freeipa/ticket/5563
---
 ipaserver/install/ipa_replica_prepare.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/ipaserver/install/ipa_replica_prepare.py b/ipaserver/install/ipa_replica_prepare.py
index cef0228..e9fd2d9 100644
--- a/ipaserver/install/ipa_replica_prepare.py
+++ b/ipaserver/install/ipa_replica_prepare.py
@@ -80,6 +80,11 @@ class ReplicaPrepare(admintool.AdminTool):
 parser.add_option("--no-reverse", dest="no_reverse",
 action="store_true", default=False,
 help="do not create reverse DNS zone")
+parser.add_option("--auto-reverse", dest="auto_reverse", default=False,
+action="store_true", help="create necessary DNS zones")
+parser.add_option("--allow-zone-overlap", dest="allow_zone_overlap",
+action="store_true", default=False, help="create DNS "
+"zone even if it already exists")
 parser.add_option("--no-pkinit", dest="setup_pkinit",
 action="store_false", default=True,
 help="disables pkinit setup steps")
-- 
2.5.0

From 95657910e6918e3134a20244ce3def28150ced8e Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Tue, 22 Dec 2015 14:05:57 +
Subject: [PATCH] installer: Change reverse zones question to better reflect
 reality.

https://fedorahosted.org/freeipa/ticket/5563
---
 ipaserver/install/bindinstance.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index 8daca55..3574699 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -73,7 +73,10 @@ named_conf_include_template = "include \"%(path)s\";\n"
 
 
 def create_reverse():
-return ipautil.user_input("Do you want to configure the reverse zone?", True)
+return ipautil.user_input(
+"Do you want to search for missing reverse zones?",
+True
+)
 
 def named_conf_exists():
 try:
-- 
2.5.0

From 0acf98c3eb649f4d76e0f962bbc3901813343d98 Mon Sep 17 00:00:00 2001
From: David Kupka 
Date: Fri, 8 Jan 2016 11:26:53 +
Subject: [PATCH] Fix: Use unattended parameter instead of options.unattended

Attribute 'unattended' is not always present in 'options' so function
parameter 'unattended' should be used.

https://fedorahosted.org/freeipa/ticket/5563
---
 ipaserver/install/bindinstance.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ipaserver/install/bindinstance.py b/ipaserver/install/bindinstance.py
index be55f6c..3d4900e 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -463,7 +463,7 @@ def check_reverse_zones(ip_addresses, reverse_zones, options, unattended,
 ipautil.check_zone_overlap(rz)
 except ValueError as e:
 msg = "Reverse zone %s will not be used: %s" % (rz, e)
-if options.unattended:
+if unattended:
 sys.exit(msg)
 else:
 root_logger.warning(msg)
-- 
2.5.0

-- 
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] [PATCHES] 0752-0757, 0759 Enable pylint --py3k

2016-01-08 Thread Petr Viktorin 
On 01/06/2016 03:28 PM, Petr Viktorin wrote:
> Hello,
> 
> Patches 0753-0757 fix remaining warnings from `pylint --py3k`, except
> "no-absolute-import" (which seems redundant to me) and the ones in
> contrib/RHEL4.

> The last patch adds py3k lint check  to make-lint. It's a bit
> cumbersome, since pylint doesn't allow running regular checkers and the
> py3k ones at the same time, but it allows you to run the check. As for
> whether to enable --py3k by default, or run it on every package build,
> I'd like to defer the decision to core devs. (Is CI good enough nowadays
> to only run it there?)
> 
> 
> [0] https://www.redhat.com/archives/freeipa-users/2013-July/msg00055.html

Here's a new version of the patchset, updated to current master.
The last patch requires 0758 (removing contrib/RHEL4) which is being
reviewed in another thread.

-- 
Petr Viktorin

From b9979f6fae741382d17f90381496819be86b9bee Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Tue, 5 Jan 2016 13:19:25 +0100
Subject: [PATCH] Use explicit truncating division

In Python 3, the truncating division operator, //, is needed to
get C-style "int division".
---
 ipalib/plugins/dns.py| 6 +++---
 ipalib/plugins/pwpolicy.py   | 4 ++--
 ipalib/plugins/trust.py  | 2 +-
 ipaserver/install/ipa_otptoken_import.py | 4 ++--
 ipatests/test_integration/util.py| 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/ipalib/plugins/dns.py b/ipalib/plugins/dns.py
index 59cb0ea3982256e9d98b8216207514e28e229d03..3b4b204d9640a4f130db687991cb35e18ab6e6e0 100644
--- a/ipalib/plugins/dns.py
+++ b/ipalib/plugins/dns.py
@@ -361,9 +361,9 @@ def _reverse_zone_name(netstr):
 net = netaddr.IPNetwork(netstr)
 items = net.ip.reverse_dns.split('.')
 if net.version == 4:
-return u'.'.join(items[4 - net.prefixlen / 8:])
+return u'.'.join(items[4 - net.prefixlen // 8:])
 elif net.version == 6:
-return u'.'.join(items[32 - net.prefixlen / 4:])
+return u'.'.join(items[32 - net.prefixlen // 4:])
 else:
 return None
 
@@ -3428,7 +3428,7 @@ class dnsrecord(LDAPObject):
 resolver = dns.resolver.Resolver()
 resolver.set_flags(0)  # disable recursion (for NS RR checks)
 max_attempts = int(self.api.env['wait_for_dns'])
-warn_attempts = max_attempts / 2
+warn_attempts = max_attempts // 2
 period = 1  # second
 attempt = 0
 log_fn = self.log.debug
diff --git a/ipalib/plugins/pwpolicy.py b/ipalib/plugins/pwpolicy.py
index 4710b48cc83a257d4f85f0de5c5e348f54d959fc..86c559b7dfeb7dffaa6c777876c6e65caab02075 100644
--- a/ipalib/plugins/pwpolicy.py
+++ b/ipalib/plugins/pwpolicy.py
@@ -380,11 +380,11 @@ class pwpolicy(LDAPObject):
 if not options.get('raw', False):
 if 'krbmaxpwdlife' in entry_attrs:
 entry_attrs['krbmaxpwdlife'][0] = unicode(
-int(entry_attrs['krbmaxpwdlife'][0]) / 86400
+int(entry_attrs['krbmaxpwdlife'][0]) // 86400
 )
 if 'krbminpwdlife' in entry_attrs:
 entry_attrs['krbminpwdlife'][0] = unicode(
-int(entry_attrs['krbminpwdlife'][0]) / 3600
+int(entry_attrs['krbminpwdlife'][0]) // 3600
 )
 
 def convert_time_on_input(self, entry_attrs):
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index bc347675aa36cd628b3e34fc7102028431b829c2..19d8b53fd0e4e413d289893ec9867c9c281d8fb2 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -396,7 +396,7 @@ def add_range(myapi, trustinstance, range_name, dom_sid, *keys, **options):
 max_id = int(max(max_uid, max_gid)[0])
 
 base_id = int(info.get('msSFU30OrderNumber')[0])
-range_size = (1 + (max_id - base_id) / DEFAULT_RANGE_SIZE)\
+range_size = (1 + (max_id - base_id) // DEFAULT_RANGE_SIZE)\
  * DEFAULT_RANGE_SIZE
 
 # Second, options given via the CLI options take precedence to discovery
diff --git a/ipaserver/install/ipa_otptoken_import.py b/ipaserver/install/ipa_otptoken_import.py
index 8ea67fce144f5058ed152378bd677e3f937583eb..89cb2accc38495a96e0a4f20cfa0fff1b021dc30 100644
--- a/ipaserver/install/ipa_otptoken_import.py
+++ b/ipaserver/install/ipa_otptoken_import.py
@@ -246,9 +246,9 @@ class XMLDecryptor(object):
 # Decrypt the data.
 slot = nss.get_best_slot(mech)
 key = nss.import_sym_key(slot, mech, nss.PK11_OriginUnwrap, nss.CKA_ENCRYPT, self.__key)
-iv = nss.param_from_iv(mech, nss.SecItem(data[0:ivlen/8]))
+iv = nss.param_from_iv(mech, nss.SecItem(data[0:ivlen//8]))
 ctx = nss.create_context_by_sym_key(mech, nss.CKA_DECRYPT, key, iv)
-out = ctx.cipher_op(data[ivlen / 8:])
+out = ctx.cipher_op(data[ivlen // 8:])
 out += ctx.digest_final()
 return out
 
diff --git

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

2016-01-08 Thread 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] 0048 Decode HTTP reason phrase as iso-8859-1

2016-01-08 Thread Fraser Tweedale 
On Thu, Jan 07, 2016 at 08:00:51PM +1000, Fraser Tweedale wrote:
> On Thu, Jan 07, 2016 at 07:56:15AM +0100, Jan Cholasta wrote:
> > Hi,
> > 
> > On 6.1.2016 05:26, Fraser Tweedale wrote:
> > >Happy new year, all.
> > >
> > >The attached patch fixes a unicode decode error triggered in some
> > >locales, which causes failure of installation (and probably other
> > >oprations, if locale is changed under an existing server).
> > >
> > >https://fedorahosted.org/freeipa/ticket/5578
> > 
> > It seems like this fixes only part of the issue - the installer won't crash
> > anymore. But what happens if the reason phrase uses characters which are not
> > in iso-8859-1 (e.g. "č", a character commonly used in Czech)? Shouldn't we
> > always specify the encoding in requests, so that Dogtag does not have to
> > guess?
> > 
> In this case it will not throw an exception, but it will decode
> nonsense.  However, in my investigation just now of how Tomcat
> decides what to send in the reason phrase, it turns out that in
> future releases they will not send a reason phrase[1] at all!
> 
> [1] 
> https://github.com/apache/tomcat/commit/707ab1c77f3bc189e1c3f29b641506db4c8bce37
> 
> (Nice to know about this in advance - I will not be surprised if
> some clients break)
> 
> I'll cut a new patch tomorrow that just ignores the reason phrase
> rather than trying to decode and log it.  All the info is in the
> status code, after all.
> 
> Thanks for reviewing,
> Fraser
> 
Promised new patch attached - removes the reason phrase and updates
call sites accordingly.

Cheers,
Fraser

> 
> > Honza
> > 
> > -- 
> > Jan Cholasta
> 
> -- 
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
From 3d860dbb660844b76b9343d3c0908af89f0327ac Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Wed, 6 Jan 2016 14:50:42 +1100
Subject: [PATCH] Do not decode HTTP reason phrase from Dogtag

The HTTP reason phrase sent by Dogtag is assumed to be encoded in
UTF-8, but the encoding used by Tomcat is dependent on system
locale, causing decode errors in some locales.

The reason phrase is optional and will not be sent in a future
version of Tomcat[1], so do not bother decoding and returning it.

[1] 
https://github.com/apache/tomcat/commit/707ab1c77f3bc189e1c3f29b641506db4c8bce37

Fixes: https://fedorahosted.org/freeipa/ticket/5578
---
 ipapython/dogtag.py | 23 +++
 ipaserver/install/certs.py  |  7 +++
 ipaserver/plugins/dogtag.py | 44 ++--
 3 files changed, 36 insertions(+), 38 deletions(-)

diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
index 
010e49652687680444d18e2e8f784fb6167a0df5..1cb74719c4ce2cc97c54dc7bebfa4b32ceee14a1
 100644
--- a/ipapython/dogtag.py
+++ b/ipapython/dogtag.py
@@ -118,14 +118,14 @@ def ca_status(ca_host=None, use_proxy=True):
 ca_port = 443
 else:
 ca_port = 8443
-status, reason, headers, body = unauthenticated_https_request(
+status, headers, body = unauthenticated_https_request(
 ca_host, ca_port, '/ca/admin/ca/getStatus')
 if status == 503:
 # Service temporarily unavailable
-return reason
+return status
 elif status != 200:
 raise errors.RemoteRetrieveError(
-reason=_("Retrieving CA status failed: %s") % reason)
+reason=_("Retrieving CA status failed with status %d") % status)
 return _parse_ca_status(body)
 
 
@@ -136,8 +136,8 @@ def https_request(host, port, url, secdir, password, 
nickname,
 :param url: The path (not complete URL!) to post to.
 :param body: The request body (encodes kw if None)
 :param kw:  Keyword arguments to encode into POST body.
-:return:   (http_status, http_reason_phrase, http_headers, http_body)
-   as (integer, unicode, dict, str)
+:return:   (http_status, http_headers, http_body)
+   as (integer, dict, str)
 
 Perform a client authenticated HTTPS request
 """
@@ -165,8 +165,8 @@ def http_request(host, port, url, **kw):
 """
 :param url: The path (not complete URL!) to post to.
 :param kw: Keyword arguments to encode into POST body.
-:return:   (http_status, http_reason_phrase, http_headers, http_body)
-as (integer, unicode, dict, str)
+:return:   (http_status, http_headers, http_body)
+as (integer, dict, str)
 
 Perform an HTTP request.
 """
@@ -179,8 +179,8 @@ def unauthenticated_https_request(host, port, url, **kw):
 """
 :param url: The path (not complete URL!) to post to.
 :param kw: Keyword arguments to encode into POST body.
-:return:   (http_status, http_reason_phrase, http_headers, http_body)
-as (integer, unicode, dict, str)
+:return:   (http_status, http_headers, http_body)
+as (integer, dict, str)
 
 Perform a

Re: [Freeipa-devel] [PATCH] 0758

2016-01-08 Thread Petr Viktorin 
On 01/07/2016 03:55 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 01/06/2016 03:47 PM, Rob Crittenden wrote:
>>> Petr Viktorin wrote:
 Hello,

 Patches 0753-0757 fix remaining warnings from `pylint --py3k`, except
 "no-absolute-import" (which seems redundant to me) and the ones in
 contrib/RHEL4.

 As for contrib/RHEL4, I found a mail [0] from 2013 saying it hasn't been
 used for a long time and probably doesn't work. Since then it's for
 example been changed to use ipapython.dn, which I'd bet no one checks
 for Python 2.5 compatibility. Since this seems to be untested and
 non-working code, so I'm sending a patch to remove it. But if that's not
 wanted tell me, and I'll skip pylint --py3k checks there instead.

 The last patch adds py3k lint check  to make-lint. It's a bit
 cumbersome, since pylint doesn't allow running regular checkers and the
 py3k ones at the same time, but it allows you to run the check. As for
 whether to enable --py3k by default, or run it on every package build,
 I'd like to defer the decision to core devs. (Is CI good enough nowadays
 to only run it there?)


 [0] https://www.redhat.com/archives/freeipa-users/2013-July/msg00055.html



>>>
>>> My only nit would be to remove contrib/RHEL4 as being deprecated rather
>>> than lack of testing against some old version. It just configures ldap
>>> and Kerberos via authconfig so unless the discovery failed it would
>>> likely still work fairly well, but clearly it isn't being maintained so
>>> I'd remove it for that reason for historical purposes.
>>
>> It uses ipapython (ipapython.dn and the log manager, specifically),
>> which don't maintain compatibility with old Python versions. I don't
>> have old Python versions around to check empirically, but a quick look
>> at ipapython.dn says it won't import on anything lower than 2.6 nowadays.
>>
> 
> Sure, kill it. Please just change the commit message.

A patch with an changed commit message is attached. It can be
reviewed/pushed before the others.


-- 
Petr Viktorin
From 15a1e951e16297c5b45e4e6b40c82346fe66fade Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Tue, 5 Jan 2016 14:37:57 +0100
Subject: [PATCH] Remove deprecated contrib/RHEL4

This code is no longer maintained.
---
 contrib/RHEL4/Makefile.am  |  13 --
 contrib/RHEL4/configure.ac |  55 -
 contrib/RHEL4/ipa-client-setup | 355 
 contrib/RHEL4/ipa-client.spec  |  54 -
 contrib/RHEL4/ipa.conf |   3 -
 contrib/RHEL4/ipachangeconf.py | 456 -
 contrib/RHEL4/setup.py |  74 ---
 7 files changed, 1010 deletions(-)
 delete mode 100644 contrib/RHEL4/Makefile.am
 delete mode 100644 contrib/RHEL4/configure.ac
 delete mode 100644 contrib/RHEL4/ipa-client-setup
 delete mode 100644 contrib/RHEL4/ipa-client.spec
 delete mode 100644 contrib/RHEL4/ipa.conf
 delete mode 100644 contrib/RHEL4/ipachangeconf.py
 delete mode 100644 contrib/RHEL4/setup.py

diff --git a/contrib/RHEL4/Makefile.am b/contrib/RHEL4/Makefile.am
deleted file mode 100644
index f42303c477f2dcc8b9dd4fceddce45fb65786354..
--- a/contrib/RHEL4/Makefile.am
+++ /dev/null
@@ -1,13 +0,0 @@
-NULL =
-
-sbin_SCRIPTS =			\
-	ipa-client-setup	\
-	$(NULL)
-
-EXTRA_DIST =			\
-	$(sbin_SCRIPTS)		\
-	$(NULL)
-
-MAINTAINERCLEANFILES =		\
-	*~			\
-	Makefile.in
diff --git a/contrib/RHEL4/configure.ac b/contrib/RHEL4/configure.ac
deleted file mode 100644
index 1fd3fd23973d739bfa016cfd56af575c2e497010..
--- a/contrib/RHEL4/configure.ac
+++ /dev/null
@@ -1,55 +0,0 @@
-AC_PREREQ(2.59)
-AC_INIT([ipa-client],
-[0.99.0],
-[http://www.freeipa.org/])
-
-AM_INIT_AUTOMAKE([foreign])
-
-AC_SUBST(VERSION)
-
-dnl ---
-dnl - Check for Python
-dnl ---
-
-AC_MSG_NOTICE([Checking for Python])
-have_python=no
-AM_PATH_PYTHON([2.3])
-
-if test "x$PYTHON" = "x" ; then
-  AC_MSG_ERROR([Python not found])
-fi
-
-dnl ---
-dnl - Set the data install directory since we don't use pkgdatadir
-dnl ---
-
-IPA_DATA_DIR="$datadir/ipa"
-AC_SUBST(IPA_DATA_DIR)
-
-dnl ---
-dnl Finish
-dnl ---
-
-# Files
-
-AC_CONFIG_FILES([
-Makefile
-])
-
-AC_OUTPUT
-
-echo "
-IPA client $VERSION
-
-
-	prefix:   ${prefix}
-	exec_prefix:  ${exec_prefix}
-libdir:   ${libdir}
-bindir:

Re: [Freeipa-devel] [PATCH 0083-0084] Fix DNS zone overlap check to allow ipa-replica-install to worFix dns_is_enabled() API command to throw exceptions as appropriat

2016-01-08 Thread Martin Basti 



On 08.01.2016 09:59, David Kupka wrote:

On 07/01/16 16:26, Petr Spacek wrote:

Hello,

Fix DNS zone overlap check to allow ipa-replica-install to work.

My review script claims that
"No problems detected using lint, pep8, ./make{api,aci}, and VERSION"

Please review.


Thanks, looks good and works as expected for me, ACK.


Pushed to:
master: 3d1a8d31343ce0a71d3236e9d8457a06e12c07a9
ipa-4-3: b9f2a7c523f27c09ef31573d174cdb6f3456a23b

--
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 0082] Fix --auto-reverse option in --unattended mode

2016-01-08 Thread Martin Basti 



On 08.01.2016 09:59, David Kupka wrote:

On 07/01/16 11:25, Petr Spacek wrote:

Hello,

Fix --auto-reverse option in --unattended mode.

Oleg, this should fix your particular environment.

Unfortunately it is not a complete fix for
https://fedorahosted.org/freeipa/ticket/5559 , stay tuned - I will 
send other

patches related to this.


Thanks, looks good and works as expected for me, ACK.


Pushed to:
master: aab190cc5d38edf3f4fbf0a6c12911dfc8f37fd3
ipa-4-3: 2c0dc779f5d92dd21912868b243f64a23936

--
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] [TEST] Workaround for ticket N 5559

2016-01-08 Thread Oleg Fayans 
Passes lint, fixes an issue with replica installation failures due to
absence of corresponding reverse zone on master.

-- 
Oleg Fayans
Quality Engineer
FreeIPA team
RedHat.
From 8d905385ae16d5227248f8ebb98abf0a6b9ee932 Mon Sep 17 00:00:00 2001
From: Oleg Fayans 
Date: Fri, 8 Jan 2016 09:46:55 +0100
Subject: [PATCH] A workaround for ticket 5559

In some evironments, specifically - under test environment in RedHat's lab,
the reverse zones for VM's are managed centrally and do not get dynamically
updated during IPA  master and client installallation, which causes failures in
replica installation. This patch enables explicit reverse zone creation for
every installed client.
---
 ipatests/test_integration/tasks.py | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/ipatests/test_integration/tasks.py b/ipatests/test_integration/tasks.py
index e7984f35fc6b3d3fec93f303b1022136c325db71..08fd088181b7e833445151e7552529d45a87cc9b 100644
--- a/ipatests/test_integration/tasks.py
+++ b/ipatests/test_integration/tasks.py
@@ -68,6 +68,7 @@ def prepare_reverse_zone(host, ip):
 host.run_command(["ipa",
   "dnszone-add",
   zone], raiseonerr=False)
+return zone
 
 def prepare_host(host):
 if isinstance(host, Host):
@@ -296,6 +297,13 @@ def install_master(host, setup_dns=True, setup_kra=False):
 
 kinit_admin(host)
 
+# Workaround for ticket N 5559
+zone = prepare_reverse_zone(host, host.ip)
+token = host.ip.split(".")[-1:][0]
+host.run_command(["ipa", "dnsrecord-add", zone, token,
+  "--ptr-hostname=%s." % host.hostname
+])
+# End of workaround
 
 def get_replica_filename(replica):
 return os.path.join(replica.config.test_dir, 'replica-info.gpg')
@@ -316,10 +324,11 @@ def domainlevel(host):
 def replica_prepare(master, replica):
 apply_common_fixes(replica)
 fix_apache_semaphores(replica)
-prepare_reverse_zone(master, replica.ip)
+zone = prepare_reverse_zone(master, replica.ip)
 master.run_command(['ipa-replica-prepare',
 '-p', replica.config.dirman_password,
 '--ip-address', replica.ip,
+"--reverse-zone=%s" % zone,
 replica.hostname])
 replica_bundle = master.get_file_contents(
 paths.REPLICA_INFO_GPG_TEMPLATE % replica.hostname)
@@ -331,7 +340,7 @@ def install_replica(master, replica, setup_ca=True, setup_dns=False,
 setup_kra=False):
 replica.collect_log(paths.IPAREPLICA_INSTALL_LOG)
 replica.collect_log(paths.IPAREPLICA_CONNCHECK_LOG)
-allow_sync_ptr(master)
+
 # Otherwise ipa-client-install would not create a PTR
 # and replica installation would fail
 args = ['ipa-replica-install', '-U',
@@ -378,6 +387,10 @@ def install_client(master, client, extra_args=()):
 client.collect_log(paths.IPACLIENT_INSTALL_LOG)
 
 apply_common_fixes(client)
+allow_sync_ptr(master)
+zone = prepare_reverse_zone(master, client.ip)
+master.run_command(["ipa", "dnszone-mod", zone,
+"--dynamic-update=TRUE"], raiseonerr=False)
 
 client.run_command(['ipa-client-install', '-U',
 '--domain', client.domain.name,
-- 
2.4.3

-- 
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] 943 webui: pwpolicy cospriority field was marked as required

2016-01-08 Thread Martin Basti 



On 08.01.2016 10:09, Martin Basti wrote:



On 22.12.2015 14:23, Petr Vobornik wrote:

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



Pushed to:
master: af0e0e5153afdcdf5b8165162ae4ef5d60ecbe0b
ipa-4-3: 574a637c730e62b741c9f901e51ff324b57bb781




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

Re: [Freeipa-devel] [PATCH] 943 webui: pwpolicy cospriority field was marked as required

2016-01-08 Thread Martin Basti 



On 22.12.2015 14:23, Petr Vobornik wrote:

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



Pushed to:
master: af0e0e5153afdcdf5b8165162ae4ef5d60ecbe0b
ipa-4-3: 574a637c730e62b741c9f901e51ff324b57bb781

-- 
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 0083-0084] Fix DNS zone overlap check to allow ipa-replica-install to worFix dns_is_enabled() API command to throw exceptions as appropriat

2016-01-08 Thread David Kupka 

On 07/01/16 16:26, Petr Spacek wrote:

Hello,

Fix DNS zone overlap check to allow ipa-replica-install to work.

My review script claims that
"No problems detected using lint, pep8, ./make{api,aci}, and VERSION"

Please review.


Thanks, looks good and works as expected for me, ACK.

--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0082] Fix --auto-reverse option in --unattended mode

2016-01-08 Thread David Kupka 

On 07/01/16 11:25, Petr Spacek wrote:

Hello,

Fix --auto-reverse option in --unattended mode.

Oleg, this should fix your particular environment.

Unfortunately it is not a complete fix for
https://fedorahosted.org/freeipa/ticket/5559 , stay tuned - I will send other
patches related to this.


Thanks, looks good and works as expected for me, ACK.

--
David Kupka

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 942 webui: add examples to network address validator error message

2016-01-08 Thread Martin Basti 



On 22.12.2015 14:33, Gabe Alford wrote:

LGTM.

Gabe

On Tue, Dec 22, 2015 at 6:06 AM, Petr Vobornik > wrote:


https://fedorahosted.org/freeipa/ticket/5532
-- 
Petr Vobornik


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





ACK

Pushed to:
master: a291ca87803c1cbaeaba60006b52596ad77b7f4b
ipa-4-3: 77f9a3a669d109a54eaee896c7fc2ebe741c81cd

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