May 2014 - Pki-devel - Dogtag PKI List Archives

[PATCH] 96 Updated man page for pki key CLI commands (Ticket 945)
by Abhishek Koneru 25 Jul '14

25 Jul '14

Please review the patch which updates the man pages for the pki key CLI commands. --Abhishek

2 4

[pki-devel][Patch] 0013-Initial-enrollment-progress.patch
by John Magne 06 Jun '14

06 Jun '14

Initial enrollment operation progress. 1. Changed the names of some message classes for convenience. 2. Did some minor refactoring of methods needed by both the enroll and tps processor. 3. Created classes to handle the parsing and archival of PKCS#11 token data. 4. Created prep code for enrollment that reads in a bunch of config params and creates convenience objects to carry the data instead of the lengthy parameter lists we have had before.

2 4

[PATCH] pki-cfu-0009-TPS-Token-Profile-Resolver-Plugin-Framework-Ticket-4.patch
by Christina Fu 04 Jun '14

04 Jun '14

This patch implements a Token Profile Resolver Plugin Framework for TPS. It allows a site to implement its own token profile resolver. The TokenProfileResolverManager initializes the token Resolver plugin framework from the following configuration files: - <instance patch>/conf/registry.cfg - <instance patch>/conf/CS.cfg The existing mapping method "getTokenType" was extracted into the default plugin code: MappingTokenProfileResolver. All resolver plugin codes will extend from BaseTokenProfileResolver. The most visible change from sites running previous versions of TPS is that the mapping related config params e.g. op.format.mapping.xxx have now being extracted into token resolver instance params e.g. tokenProfileResolver.formatMappingResolver.mapping.xxxx where "class_id" defines the plugin implementation name defined in the registry.cfg and op.format.tokenProfileResolver points to the defined resolver instance e.g. op.format.tokenProfileResolver=formatMappingResolver A separate ticket will be filed to provide actual plugin writing instruction as well as a sample plugin. Finally, even though this patch does not directly address https://fedorahosted.org/pki/ticket/447 RFE: Mapping tokens to tokentype, where the request was to figure out the tokenType (Token profile) by uid instead of the current mapping method, it provides the means for one to write any customized plugins. thanks, Christina

3 10

[Freeipa-devel] faster ways to build/test dogtag?
by Fraser Tweedale 04 Jun '14

04 Jun '14

Hi all, I've been working on a fix for a profile issue (https://fedorahosted.org/freeipa/ticket/2915) Unfortunately I find the scripts/compose_pki_core_packages -> yum install -> test cycle frustratingly slow on idm.lab.bos. Is there a quicker way to build and test the software - particularly as part of the larger IPA/certmonger/dogtag ecosystem? Cheers, Fraser _______________________________________________ Freeipa-devel mailing list Freeipa-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel

2 2

[PATCH] 95 Fixes for comments for patches 92-2, 93, 94(CertClient and ProfileClient python implementations)
by Abhishek Koneru 03 Jun '14

03 Jun '14

Please review the patch which addresses the review comments given by Ade and Fraser for patches 92-2, 93, 94. 92-2 has been checked in already. 94 has been rebased to fix conflicts with Ade's checkins. I removed the changes to account.py and client.py form 94 to fix the conflicts. So update the master and apply patches 93, 94, 95. Following are the review comments addressed in this patch - ** No. 4 in the list is not included in this patch. It will be done in a separate patch. 1) Copy pasta error in ProfileData.from_json; ``policy_sets`` used instead of ``inputs``/``outputs`` when processing json_value['Input'] or json_value['Output'] lists. 2) Could you please make ProfileDataInfoCollection an iterable? It doesn't make sense to be to have to access the ``profile_data_list`` attribute just to iterate the ProfileDataInfo objects. 3) Could you please add a ``repr`` method to ProfileData that includes at least the profile_id? Maybe summary information about whether it is visible/active as well, but I think just the ID should be fine. Same goes for other classes that show up in lists, please. 4) I'm a little concerned about having the properties set/get top-level attributes, e.g. ``enabled_by`` sets/gets ``enabledBy``. Following this pattern where you wish to use the same name as in the JSON would result in infinite loop; indeed you do treat some keys different to avoid this, e.g. ``description``. This inconsistency makes me wonder if there's a better pattern. My suggestion would be to stash the JSON dict in a top-level attribute (the constructor would have to initialise it to an empty dict before other attributes are assigned) and then have the properties set/get items in that dict. You could further cut down boilerplate and duplication by definite a descriptor for this purpose, e.g.: class JSONProperty(object): def __init__(self, attr): self.attr def __get__(self, instance, owner) return obj.json_value[self.attr] def __set__(self, instance, value) obj.json_value[self.attr] = value Then, most of the assignments in ``from_json`` go away , and the corresponding property declarations follow the new pattern: enabled_by = JSONProperty('enabledBy') You would still need to treat Input, Output and PolicySets differently, but you could also abstract over this pattern with yet another class, i.e. a "JSON list property". Anyhow, 4) isn't a show-stopper, just a (lengthy) nit-pick. *** Will fix this in a separate patch. 5. Here you could iterate the (key, value) pairs to save keystrokes and a bit of CPU doing ``cert_search_params[param]`` in all those places below. e.g.: for param, value in cert_search_params.viewitems(): ... ``dict.viewitems()`` returns a *dictview* iterator-like object that avoids creating an intermediate list as ``dict.items()`` would. 6. Here and in a few other places below it might improve readability to test for set membership, e.g.: if param in { 'email', 'common_name', 'user'_id', 'org_unit', 'org', ... }: 7. pycharm appears to be set to 120 columns width by default. We need to set to 80 and reformat accordingly. Please check in a pycharm settings file. All new code should follow PEP8. 8. In CertRevokeRequest, a number of constants are defined for possible reason settings. You should group those, and test for invalid reasons. 9. Do we use CertID anywhere? --- Removed CertID 10. list_entrollment_templates has a print r statement in it. Is that supposed to be there? 11. get_enrollment_template should check for None for the profileID. 12. CertRequestInfoCollection has an element - cert_info_list, should be cert_request_info_list 13. ProfileConstraint -- why is id renamed to name? Why not just use "id" -- pycharm and pylint throw a warning when using id as an attribute name -- Abhishek

3 8

patches for pycharm cleanup and security domain python client api
by Ade Lee 29 May '14

29 May '14

This is mostly the same patches that were reviewed before with fixes for the issues identified. I ended up making these changes over Abhishek's first cert patch, so please apply that first when reviewing. This patch is: 05e9fa7 Implemented CertResource methods in CertClient. Please review, Ade

2 3

profile constraint being replaced with NoConstraint
by Fraser Tweedale 29 May '14

29 May '14

Hi all, I've been chipping away at the profile changes required for https://fedorahosted.org/freeipa/ticket/2915. I've encountered a problem where the EKU extension constraint is being replaced by NoConstraint for validation. The profile does read the constraint correctly, i.e. it appears in the "Manage Certificate Profiles" table in the web UI, but when it comes to performing the validation, it is instead using ``com.netscape.cms.profile.constraint.NoConstraint``. I am using a modified caServerCert profile; the only changed part being: policyset.serverCertSet.7.constraint.class_id=extendedKeyUsageExtConstraintImpl policyset.serverCertSet.7.constraint.name=Extended Key Usage Extension policyset.serverCertSet.7.constraint.params.exKeyUsageCritical=false policyset.serverCertSet.7.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 policyset.serverCertSet.7.default.class_id=extendedKeyUsageExtDefaultImpl policyset.serverCertSet.7.default.name=Extended Key Usage Extension Default policyset.serverCertSet.7.default.params.exKeyUsageCritical=false policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2 (This change was made to the caServerCert profile). This is occurring on master (989e5d3). A minimal patch that adds the logging which demonstrates this behaviour (for me) is attached. Any help in understanding this behaviour is appreciated :) Cheers, Fraser

1 1

[PATCH] 94 Initial patch with implementation for ProfileClient
by Abhishek Koneru 23 May '14

23 May '14

Please review the attached patch with the implementation of ProfileClient. The following methods are implemented in this patch - list_profiles - Returns a list of profiles. get_profile - Retrieves information of a profile. enable_profile - Enables a profile disable_profile - disables a profile. Also includes some cosmetic changes account.py and client.py. Thanks, Abhishek

3 3

[PATCH] 93 Add methods for CertRequestResource to CertClient in the python client
by Abhishek Koneru 23 May '14

23 May '14

Please review the attached patch which adds methods to deal with the CertRequest resource in CertClient on the python side. These methods provide functionality like - -Fetching the enrollment templates. -Creating an enrollment request from a dictionary of input key-value pairs. -Submitting an enrollment request. -Reviewing the request. -Performing an action on a request(approve/reject/cancel/etc.) Also defined all the classes needed for data representation. --Abhishek

2 1

[PATCH] 92 Implemented the methods for Cert resource in the CertClient on the python side(Dogtag 10)
by Abhishek Koneru 23 May '14

23 May '14

Please review the attached patch which implements the Cert resource methods in CertClient on the python side. --Abhishek

3 3