Re: [Freeipa-devel] [PATCH 0315] CI: backup&restore with KRA installed
On 09/11/2015 04:42 PM, Martin Basti wrote: Patch mbasti-0312-2 Patch attached. LGTM, ack Milan -- 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] Scope of ECC support in FreeIPA/Dogtag
On Thu, Sep 24, 2015 at 01:19:51PM +0200, Martin Kosek wrote: > On 09/15/2015 03:26 PM, Fraser Tweedale wrote: > > On Tue, Sep 15, 2015 at 02:10:57PM +0200, Martin Kosek wrote: > >> Hi Nathan and others, > >> > >> I am now going through FreeIPA 4.4 items and I am thinking about ECC > >> support in > >> FreeIPA: > >> > >> https://fedorahosted.org/freeipa/ticket/3951 > >> > >> AFAIK, ECC should be already supported in Dogtag. Could you please advise > >> what > >> is the scope of expected changes in FreeIPA? > >> > >> My understanding is that following parts are required: > >> 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to > >> me > >> though, if this task can be easily done during upgrade. > >> > > Lightweight (sub)CAs should allow it easily - once they support > > specifying the key type and size/curve (currently subCAs are > > hardcoded to rsa2048 but the subCAs are still a WIP; there is a > > separate ticket[1] to track it). > > > > There will also be a small amount of work on the IPA side - and > > maybe some on Dogtag side - to allow new installation to use ECC > > root. > > > > [1] https://fedorahosted.org/pki/ticket/1589 > > > >> 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and > >> adding respective EC algorithms support to "signingAlgsAllowed", as noted > >> in > >> https://fedorahosted.org/freeipa/ticket/3951#comment:1. > >> > > Yes, we will need to update the included profiles. I have been > > thinking about how to get more flexibility for profile updates; I > > think versioning profiles is desirable but that will be a separate > > design proposal. > > > > Anyhow, I am happy to own these efforts. > > Ok, thanks you for all the information - please do :-) > I became owner of #3951 and also filed #5323 "Mechanism to update included certprofiles". Thanks, Fraser > > > > Cheers, > > Fraser > > > >> Is that correct or more is needed to make that working and supported in > >> FreeIPA? > >> > >> -- > >> Martin Kosek > >> Supervisor, 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] [PATCHSET] Replica promotion patches
On 24/09/15 04:43, Martin Basti wrote: On 09/24/2015 02:25 AM, Martin Basti wrote: On 09/22/2015 10:45 AM, Jan Cholasta wrote: Hi, On 9.9.2015 20:25, Simo Sorce wrote: On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: This patchset implements https://fedorahosted.org/freeipa/ticket/2888 and introduces a number of required changes and dependencies to achieve this goal. This work requires the custodia project to securely transfer keys between ipa servers. This work is not 100% complete, it still misses the ability to install kra instances and the ability to install a CA (via ipa-ca-install) with externally signed certs. However it is massive enough that warrants review and pushing, the resat of the changes can be applied later as this work should not disrupt the classic install methods. In order to build my previous patches (530-533) are needed as well as a number of updated components. I used the following coprs for testing: simo/jwcrypto simo/custodia abbra/sssd-kkdcproxy (for sssd 1.13.1) lkrispen/389-ds-current (for 389 > 1.3.4.4) vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) mkosek/freeipa-4.2-fedora-22 (misc) fedora/updates-testing (python-gssapi 1.1.2) Ludwig's copr is necessary to have a functional DNA plugin in replicas, eventually his patches should be committed in 389-ds-base 1.3.4.4 when it will be released. We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 that may cause installation issues in some case (re-install of a replica). The domain must be raised to level 1 in order to use replica promotion. In order to promote a replica the server must be first joined as a regular client to the domain. This is the flow I usually use for testing: # ipa-client-install # kinit admin # ipa-replica-install --promote --setup-ca These patches are also available in this git tree rebnase on current master: https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review FYI: I rebased this branch on top of master and applied minor changes to one of the DNS patches. I also added the missing support to install KRA. DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not needed anymore. Dogtag's ticket is not fixed yet so running both --setup-ca and --setup-kra at the same time will still yield an error and install will fail. Please let me know if there are any major issues with this patchset, I'd like to push it to master and attack the remaining issues as add ons (install with external certs not supported yet for example) So far I have only read through the code without running it (mostly). "Remove unused arguments": ACK "Simplify the install_replica_ca function": ACK "IPA Custodia Daemon": 1) Instead of putting the code in "ipakeys" package, could you put it in "ipapython.keys"? This way it would be consistent with DNSSEC, which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. 2) Is it safe to create cn=custodia in update file only? Updates are executed late in ipa-server-install. Is is guaranteed that nothing will try to access cn=custodia before the updates are run? (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) 3) Shouldn't cn=custodia be created only when domain level >= 1? 4) pylint fails with: daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), IPAKEMKeys.__init__] Use of super on an old style class) daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no 'config' member) daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) 5) There are some PEP8 transgressions: ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank lines, found 1 ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:14:13: E251 unexpec
[Freeipa-devel] [PATCH 0012-0019] CA ACL tracker and functional test
Hi all,
an update for CA ACL tests!
I, with help from M. Babinsky, managed to find a way how to change the
identity during acceptance cest run, which allows
to test CA ACLs (and perhaps other areas with some form of access controll).
This allowed me to write a test for CA ACLs and certificate profiles
that checks if the ACL/profile is being used and enforced.
The first several tests are based on Fraser's blogpost using SMIME
profile [1].
The master and ipa-4-2 branches diverged a bit, so I had to change two
commits when rebasing to ipa-4-2 branch.
Commits should be applied in the order (including rebased patches I sent
in an earlier email):
master:
* 12 - 17
ipa-4-2:
* 18, 13 - 15, 19, 17
For convenience:
patches on top of master:
https://github.com/apophys/freeipa/tree/acl-profile-functional
patches on top of ipa-4-2: https://github.com/apophys/freeipa/tree/acl-42
[1]:
https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/
Cheers,
Milan
From c25482bc366945591be40a3dbb14ec5022d59e21 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?=
Date: Fri, 17 Jul 2015 14:42:23 +0200
Subject: [PATCH 1/6] ipatests: add fuzzy instances for CA ACL DN and RDN
https://fedorahosted.org/freeipa/ticket/57
---
ipatests/test_xmlrpc/xmlrpc_test.py | 8
1 file changed, 8 insertions(+)
diff --git a/ipatests/test_xmlrpc/xmlrpc_test.py b/ipatests/test_xmlrpc/xmlrpc_test.py
index 56ddad9b8a0a1164c29f38970e0a97513d1a8d1f..c8be6160bdca0a95622ce5f8e4752e609f73dec5 100644
--- a/ipatests/test_xmlrpc/xmlrpc_test.py
+++ b/ipatests/test_xmlrpc/xmlrpc_test.py
@@ -77,6 +77,14 @@ fuzzy_sudocmddn = Fuzzy(
'(?i)ipauniqueid=%s,cn=sudocmds,cn=sudo,%s' % (uuid_re, api.env.basedn)
)
+# Matches caacl dn
+fuzzy_caacldn = Fuzzy(
+'(?i)ipauniqueid=%s,cn=caacls,cn=ca,%s' % (uuid_re, api.env.basedn)
+)
+
+# Matches fuzzy ipaUniqueID DN group (RDN)
+fuzzy_ipauniqueid = Fuzzy('(?i)ipauniqueid=%s' % uuid_re)
+
# Matches a hash signature, not enforcing length
fuzzy_hash = Fuzzy('^([a-f0-9][a-f0-9]:)+[a-f0-9][a-f0-9]$', type=six.string_types)
--
2.5.3
From 80df2016c0e6f180ca0f8caebd434a0e15d4b03f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?=
Date: Tue, 30 Jun 2015 17:00:18 +0200
Subject: [PATCH 2/6] ipatests: Add initial CAACLTracker implementation
The patch implements the tracker for CA ACL feature.
The basic CRUD checkers has been implemented. The methods
for adding and removing the association of the resources
with the ACL do not have the check methods. These will be provided
as a separate test suite.
https://fedorahosted.org/freeipa/ticket/57
---
ipatests/test_xmlrpc/objectclasses.py | 5 +
ipatests/test_xmlrpc/test_caacl_plugin.py | 318 ++
2 files changed, 323 insertions(+)
create mode 100644 ipatests/test_xmlrpc/test_caacl_plugin.py
diff --git a/ipatests/test_xmlrpc/objectclasses.py b/ipatests/test_xmlrpc/objectclasses.py
index 1cd77c7f885fe408d0d9d48fc6d8284900c91b7f..134a08803f3abca1124c4d26274d9e3fc981b941 100644
--- a/ipatests/test_xmlrpc/objectclasses.py
+++ b/ipatests/test_xmlrpc/objectclasses.py
@@ -217,3 +217,8 @@ certprofile = [
u'top',
u'ipacertprofile',
]
+
+caacl = [
+u'ipaassociation',
+u'ipacaacl'
+]
diff --git a/ipatests/test_xmlrpc/test_caacl_plugin.py b/ipatests/test_xmlrpc/test_caacl_plugin.py
new file mode 100644
index ..ba3408813d5d47f7f6261f187129fbee645c5ef7
--- /dev/null
+++ b/ipatests/test_xmlrpc/test_caacl_plugin.py
@@ -0,0 +1,318 @@
+#
+# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
+#
+
+"""
+Test the `ipalib.plugins.caacl` module.
+"""
+
+import os
+
+import pytest
+
+from ipapython import ipautil
+from ipalib import errors, x509
+from ipapython.dn import DN
+from ipatests.test_xmlrpc.ldaptracker import Tracker
+from ipatests.test_xmlrpc.xmlrpc_test import (XMLRPC_test, fuzzy_caacldn,
+ fuzzy_uuid, fuzzy_ipauniqueid,
+ raises_exact)
+from ipatests.test_xmlrpc import objectclasses
+from ipatests.util import assert_deepequal
+
+
+class CAACLTracker(Tracker):
+"""Tracker class for CA ACL LDAP object."""
+# TODO: more documentation for this class
+# TODO: find a way how to restore the ACL
+# after delete. Simple `ensure_exists`
+# won't be enough here as the services,
+# hosts, etc. are added after the ACL
+# itself is created.
+
+member_keys = {
+u'memberuser_user', u'memberuser_group',
+u'memberhost_host', u'memberhost_hostgroup',
+u'memberservice_service',
+u'ipamembercertprofile_certprofile'}
+retrieve_keys = {
+u'dn', u'cn', u'description', u'ipaenabledflag',
+u'ipacacategory', u'ipamemberca',
+u'ipacertprofilecategory', u'ipamembercertprofile',
+u'usercategory', u'memb
Re: [Freeipa-devel] Scope of ECC support in FreeIPA/Dogtag
On 09/15/2015 03:26 PM, Fraser Tweedale wrote: > On Tue, Sep 15, 2015 at 02:10:57PM +0200, Martin Kosek wrote: >> Hi Nathan and others, >> >> I am now going through FreeIPA 4.4 items and I am thinking about ECC support >> in >> FreeIPA: >> >> https://fedorahosted.org/freeipa/ticket/3951 >> >> AFAIK, ECC should be already supported in Dogtag. Could you please advise >> what >> is the scope of expected changes in FreeIPA? >> >> My understanding is that following parts are required: >> 1) Generating ECC signing certificate for FreeIPA CA. This is not clear to me >> though, if this task can be easily done during upgrade. >> > Lightweight (sub)CAs should allow it easily - once they support > specifying the key type and size/curve (currently subCAs are > hardcoded to rsa2048 but the subCAs are still a WIP; there is a > separate ticket[1] to track it). > > There will also be a small amount of work on the IPA side - and > maybe some on Dogtag side - to allow new installation to use ECC > root. > > [1] https://fedorahosted.org/pki/ticket/1589 > >> 2) Updating FreeIPA Certificate Profiles (which should be now in LDAP) and >> adding respective EC algorithms support to "signingAlgsAllowed", as noted in >> https://fedorahosted.org/freeipa/ticket/3951#comment:1. >> > Yes, we will need to update the included profiles. I have been > thinking about how to get more flexibility for profile updates; I > think versioning profiles is desirable but that will be a separate > design proposal. > > Anyhow, I am happy to own these efforts. Ok, thanks you for all the information - please do :-) > > Cheers, > Fraser > >> Is that correct or more is needed to make that working and supported in >> FreeIPA? >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Replace StandardError with Exception
On 09/17/2015 05:35 PM, Petr Viktorin wrote: > Hello, > In Python 2, Exception has only two built-in subclasses: StandardError, > and StopIteration. > This makes StandardError pretty useless, and Python 3 removes it. > > This patch replaces StandardError with Exception. It has no effect on > IPA code. However, it could theoretically affect external plugins (e.g. > if they do "except StandardError"). ping, anybody for review of this patch? -- Petr Viktorin -- 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] [PATCHSET] Replica promotion patches
On 09/24/2015 02:25 AM, Martin Basti wrote: On 09/22/2015 10:45 AM, Jan Cholasta wrote: Hi, On 9.9.2015 20:25, Simo Sorce wrote: On Wed, 2015-08-26 at 17:27 -0400, Simo Sorce wrote: This patchset implements https://fedorahosted.org/freeipa/ticket/2888 and introduces a number of required changes and dependencies to achieve this goal. This work requires the custodia project to securely transfer keys between ipa servers. This work is not 100% complete, it still misses the ability to install kra instances and the ability to install a CA (via ipa-ca-install) with externally signed certs. However it is massive enough that warrants review and pushing, the resat of the changes can be applied later as this work should not disrupt the classic install methods. In order to build my previous patches (530-533) are needed as well as a number of updated components. I used the following coprs for testing: simo/jwcrypto simo/custodia abbra/sssd-kkdcproxy (for sssd 1.13.1) lkrispen/389-ds-current (for 389 > 1.3.4.4) vakwetu/dogtag_10.2.7_test_builds (for dogtag 10.2.7) mkosek/freeipa-4.2-fedora-22 (misc) fedora/updates-testing (python-gssapi 1.1.2) Ludwig's copr is necessary to have a functional DNA plugin in replicas, eventually his patches should be committed in 389-ds-base 1.3.4.4 when it will be released. We are aware of a dogtag bug https://fedorahosted.org/pki/ticket/1580 that may cause installation issues in some case (re-install of a replica). The domain must be raised to level 1 in order to use replica promotion. In order to promote a replica the server must be first joined as a regular client to the domain. This is the flow I usually use for testing: # ipa-client-install # kinit admin # ipa-replica-install --promote --setup-ca These patches are also available in this git tree rebnase on current master: https://fedorapeople.org/cgit/simo/public_git/freeipa.git/log/?h=custodia-review FYI: I rebased this branch on top of master and applied minor changes to one of the DNS patches. I also added the missing support to install KRA. DS 1.3.4.4 is also in Fedora updates testing, so ludwig's copr is not needed anymore. Dogtag's ticket is not fixed yet so running both --setup-ca and --setup-kra at the same time will still yield an error and install will fail. Please let me know if there are any major issues with this patchset, I'd like to push it to master and attack the remaining issues as add ons (install with external certs not supported yet for example) So far I have only read through the code without running it (mostly). "Remove unused arguments": ACK "Simplify the install_replica_ca function": ACK "IPA Custodia Daemon": 1) Instead of putting the code in "ipakeys" package, could you put it in "ipapython.keys"? This way it would be consistent with DNSSEC, which has binaries in daemons/dnssec/ and modules in ipapython/dnssec/. 2) Is it safe to create cn=custodia in update file only? Updates are executed late in ipa-server-install. Is is guaranteed that nothing will try to access cn=custodia before the updates are run? (Nevermind, it is added to bootstrap-template.ldif 2 commits below.) 3) Shouldn't cn=custodia be created only when domain level >= 1? 4) pylint fails with: daemons/ipa-custodia/ipakeys/kem.py:156: [E1002(super-on-old-class), IPAKEMKeys.__init__] Use of super on an old style class) daemons/ipa-custodia/ipakeys/kem.py:178: [E1101(no-member), IPAKEMKeys.generate_server_keys] Instance of 'IPAKEMKeys' has no 'config' member) daemons/ipa-custodia/ipakeys/kem.py:187: [E1101(no-member), IPAKEMKeys.server_keys] Instance of 'IPAKEMKeys' has no 'config' member) 5) There are some PEP8 transgressions: ./daemons/ipa-custodia/ipakeys/kem.py:202:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/kem.py:203:80: E501 line too long (82 > 79 characters) ./daemons/ipa-custodia/ipakeys/store.py:33:1: E302 expected 2 blank lines, found 1 ./daemons/ipa-custodia/setup.py:8:9: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:8:11: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:9:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:12: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:10:14: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:15: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:11:17: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:21: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:12:23: E251 unexpected spaces around keyword / parameter equals ./daemons/ipa-custodia/setup.py:14:13: E251 unex
