[PATCH] 219-222 Fix formatting etc. in server python code
by Ade Lee
Had a bit of time on the plane and wanted to clean things up.
These patches address PEP 8 issues (mostly formatting) and some others
as identified by pycharm in the server code.
Cuts down about a thousand errors/warnings to about 170.
Please review,
Ade
9 years, 10 months
[pki-devel][Patch] 0013-Initial-enrollment-progress.patch
by John Magne
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.
9 years, 10 months
[PATCH] pki-cfu-0009-TPS-Token-Profile-Resolver-Plugin-Framework-Ticket-4.patch
by Christina Fu
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
9 years, 10 months
[PATCH] 95 Fixes for comments for patches 92-2, 93, 94(CertClient and ProfileClient python implementations)
by Abhishek Koneru
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
9 years, 10 months
lightweight sub-CAs?
by Fraser Tweedale
Hi all,
In order to support more fine-grained security domains in FreeIPA
(Puppet is one of many use cases; see
http://www.freeipa.org/page/IPA_as_external_Puppet_CA and
http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/), I
am beginning to explore whether there is any current or potential
capability in Dogtag for "lightweight" intermediate CAs.
A Dogtag `ca' subsystem can be set up as an intermediate CA, but
AFAICT, this will run as a separate instance, on its own network
ports, etc. Leveraging this capability from FreeIPA would be
complex, to say the least, as it would involve spawning whole new
Dogtag instances.
So, I am wondering if there is any capability in Dogtag for creating
an intermediate CAs *within* a single instance? And if not, are
there any comments or suggestions about whether there is scope to
add such a feature or how it might be used - particularly in
relation to profiles?
Cheers,
Fraser
9 years, 10 months
