From edewata at redhat.com Sat Dec 1 05:44:13 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 30 Nov 2012 23:44:13 -0600 Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template. In-Reply-To: <50A3A960.5040104@redhat.com> References: <50A3A960.5040104@redhat.com> Message-ID: <50B9992D.8020403@redhat.com> On 11/14/2012 8:23 AM, Endi Sukma Dewata wrote: > The messages in ProfileList.template in CA EE has been extracted > into a properties file which can be translated separately. > > The original messages in the template have been marked as follows: > ...message... > > When the page is loaded into the browser, the original message will > be replaced with the translated message. > > Ticket #406 Just to clarify, this patch demonstrates how message customization could be done. A full solution will require many incremental patches due to the number of messages to be customized. Here is how it works. Previously a theme consist of HTML/Velocity templates, JS files, images and CSS files. The HTML/Velocity templates contain HTML code, JS code, paths to images/CSS files, and text messages. To create a custom theme we had to clone the default Dogtag theme, then customize the files as needed. Most of the time we'll only be changing the images, CSS, and messages, but we still have to duplicate everything in the theme. This becomes a maintenance issue because if we change anything in the default theme, the custom theme will not be updated automatically, and it could be hard to merge the changes. Recently we've been moving the templates and JS files out of the theme packages into the core packages because they are less likely to be changed, leaving just the images and CSS files in the theme. However, the messages are still part of the templates. To support customization we need to separate the messages from the templates. JQuery and jquery-i18n-properties are tools that we can use to load custom messages from a separate properties file and then replace the original messages in the template. Suppose we have a template which contains the following HTML code: Dogtag The Dogtag Certificate System is an enterprise-class open source Certificate Authority. To make the messages customizable we need to mark them. Here we are using a which shouldn't be visible in the browser: Dogtag The Dogtag Certificate System is an enterprise-class open source Certificate Authority. The element is assigned a class "message" which will be used to locate all messages. The element is also assigned a name which will be used as message key. The original message itself is left intact within the to help visualize the page. Then we create a Messages.properties that maps the message keys to the actual messages: title = Dogtag description = The Dogtag Certificate System is an enterprise-class\ open source Certificate Authority. The messages in the properties file can be customized as needed. Then we'll use the tools to load the custom messages and replace the original messages in the template: $.i18n.properties({ name: 'Messages', ... callback: function() { var key; for (key in $.i18n.map) { var message = $.i18n.prop(key); $('span.message[name='+key+']').html(message); } } }); After the browser finishes loading the page the $.i18n.properties() will run to load the custom messages from Messages.properties. Once they are loaded the callback() will run to replace all marked messages with the custom messages. There are 2 different purposes for message customization which require different strategies: branding and translation. If we're doing branding only, like the current implementation, we need to use separate properties for each theme, for example: Messages.properties - Dogtag theme Messages.properties - Other theme If we're doing translation only we need to use separate properties file for each language, for example: Messages.properties - Dogtag theme in English Messages_es.properties - Dogtag theme in Spanish Messages_fr.properties - Dogtag theme in French If we're doing both branding and translation the number of files will be multiplied: Messages.properties - Dogtag theme in English Messages_es.properties - Dogtag theme in Spanish Messages_fr.properties - Dogtag theme in French Messages.properties - Other theme in English Messages_es.properties - Other theme in Spanish Messages_fr.properties - Other theme in French One possible solution is to do the translation and branding separately using different message markers: Dogtag The Dogtag Certificate System is an enterprise-class open source Certificate Authority. Here we can load the translated "message" first, then load the untranslated "product" after that. This solution doesn't require as many properties files: Messages.properties - English messages Messages_es.properties - Spanish messages Messages_fr.properties - French messages Product.properties - Dogtag theme Product.properties - Other theme If we can assume the messages are fixed, we can actually include the messages in the core packages and leave the branding in the theme packages. We could also stack the theme files, similar to the sections in the configuration file, so the custom theme only needs to store the files that are different from the default theme. This will require the ability to install multiple themes and deploy the custom theme on top of the default theme. -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 02:55:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 02 Dec 2012 20:55:57 -0600 Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts. In-Reply-To: <1354255161.2654.24.camel@aleeredhat.laptop> References: <50B53B6F.7020906@redhat.com> <1354255161.2654.24.camel@aleeredhat.laptop> Message-ID: <50BC14BD.2010709@redhat.com> On 11/29/2012 11:59 PM, Ade Lee wrote: > Looks good - and is the right idea. What makes you think that cfg.pl is > not used? There are functions that are defined there that are used in > the esc cgi scripts. > > Please restore cfg.pl. As discussed on IRC, there are 2 cfg.pl files, one in the TPS core page and the other in the TPS theme package. In the original code before the patch, the code in pkicreate:2064 copies the cfg.pl in theme to override the cfg.pl in core: return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path, $default_dir_permissions, $default_file_permissions, $pki_user, $pki_group); So the original cfg.pl in core package was never actually used. In the updated #192 this code no longer exists since the TPS theme has being removed. -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 02:56:00 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 02 Dec 2012 20:56:00 -0600 Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files. In-Reply-To: <1354255334.2654.27.camel@aleeredhat.laptop> References: <50B53B74.6050305@redhat.com> <1354255334.2654.27.camel@aleeredhat.laptop> Message-ID: <50BC14C0.5080002@redhat.com> On 11/30/2012 12:02 AM, Ade Lee wrote: > Looks good in general. > > I noticed that you moved dogtag/tps-ui/shared/docroot/esc/style.css -> > dogtag/common-ui/shared/style.css instead of > dogtag/common-ui/shared/esc/style.css. Why is this? This was an error. It has been fixed in the attached revised patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0191-1-Reorganized-TPS-CSS-files.patch Type: text/x-patch Size: 23708 bytes Desc: not available URL: From edewata at redhat.com Mon Dec 3 02:56:05 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Sun, 02 Dec 2012 20:56:05 -0600 Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages. In-Reply-To: <1354256740.2654.40.camel@aleeredhat.laptop> References: <50B53B79.5090003@redhat.com> <1354256740.2654.40.camel@aleeredhat.laptop> Message-ID: <50BC14C5.30109@redhat.com> On 11/30/2012 12:25 AM, Ade Lee wrote: > 1. There are cgi scripts which are explicitly set to have execute > permissions by the build script. Is this not needed? Can you confirm > this? Are you referring to the removal of this code? chmod 755 %{buildroot}%{_datadir}/pki/tps-ui/cgi-bin/sow/cfg.pl There are codes in pkicreate:2076-2090 that set the permissions: set_permissions("${cgibin_instance_path}/sow/*.pl", $default_exe_permissions); So the above chmod code is not necessary. > 2. As mentioned in a previous review, cfg.pl is needed. This is discussed in my response for #190. > 3. Are there really no changes required in pkicreate and pkiremove? > Surely there must be code that copies stuff from /usr/share/pki/tps-ui > and /usr/share/pki/ra-ui. There may even be a programmatic check for > the ui package. And don't we need code to copy the relevant bits from > common-ui? The original code already has some codes to copy the subsystem theme files and common theme files (see pkicreate:2064): # Copy /usr/share/pki/-ui to return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path, $default_dir_permissions, $default_file_permissions, $pki_user, $pki_group); # Copy /usr/share/pki/common-ui to /docroot/pki return 0 if !copy_directory( $common_ui_subsystem_path, "$docroot_instance_path/pki", $default_dir_permissions, $default_file_permissions, $pki_user, $pki_group); In the attached revised patch the code to copy -ui has been removed because the RA/TPS themes don't exist anymore. The copy_directory() would ignore missing folders, but it's better to remove unused code. The code to copy the common-ui is left intact. > 4. How was this tested? Do you pkicreate and configure RA and TPS > instances? Yes, the UI seems to be working fine, I didn't see any broken page/links/images, but I'm not familiar with these subsystems to test the functionality. > When the instances are created, are all the relevant files > where you expect them to be ?-- ie. compare the layout of old/new > instances. Yes, they seem to be deployed to the same locations. > Did you configure the instances and check the UI to make sure it looks > the same? Yes, they looked fine. > Did you look at the security officer workstation stuff ? > Or configure a token? No, I'm not familiar with this UI, please let me know how to test it. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0192-1-Removed-RA-and-TPS-theme-packages.patch Type: text/x-patch Size: 8974 bytes Desc: not available URL: From alee at redhat.com Mon Dec 3 14:13:39 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Dec 2012 09:13:39 -0500 Subject: [Pki-devel] [PATCH] 93, 94 - changes for a common admin user In-Reply-To: <1354312886.2317.18.camel@aleeredhat.laptop> References: <1354226974.2654.8.camel@aleeredhat.laptop> <50B8D721.30000@redhat.com> <1354312886.2317.18.camel@aleeredhat.laptop> Message-ID: <1354544020.2317.19.camel@aleeredhat.laptop> Changes made as discussed. Pushed to master. On Fri, 2012-11-30 at 17:01 -0500, Ade Lee wrote: > On Fri, 2012-11-30 at 09:56 -0600, Endi Sukma Dewata wrote: > > Some issues: > > > > 1. The pki_use_common_admin_user is set to true in [Common] but > > overwritten to false in [CA]: > > > > [Common] > > pki_use_common_admin_user=true > > > > [CA] > > pki_use_common_admin_user=false > > > > If I understood correctly it's done this way to make sure that if we use > > a common admin user, only CA will generate the certificate file, but not > > the other subsystems: > > > > if not config.str2bool(master['pki_clone']) and \ > > not config.str2bool(master['pki_use_common_admin_user']): > > > > ... create cert file ... > > > > Having conflicting pki_use_common_admin_users in the same config file is > > confusing to users because we are actually using a common admin user for > > all subsystems including CA so the value should be "true". I think it > > would be better to check for CA explicitly in the code: > > > > [Common] > > pki_use_common_admin_user=true > > > > if not config.str2bool(master['pki_clone']): > > if not config.str2bool(master['pki_use_common_admin_user']) or > > master['pki_subsystem'] == 'CA': > > > > ... create cert file ... > > > > The thing is - someone might install a subordinate CA and want to use > this mechanism to import an admin cert. So we dont really want to > exclude this simply because its a CA. Maybe we can change the name of > the directive to import_admin_cert = true/false ? This makes it clearer > what we are doing. Sound reasonable? > > > 2. The location of the admin cert was changed from pki_client_dir to > > pki_database_path. I think we should keep it in pki_client_dir because > > the certificate belongs to the admin, not the instance, so it should be > > in the admin's home directory. As long as the other subsystems are > > created by the same admin the code should be able to read the cert from > > the admin's home directory. > > > > So the following parameters should point to the admin's home directory: > > - pki_client_admin_cert_p12 > > - pki_admin_cert_file > > > I agree with you that the cert belongs to the admin and not the > instance. The problem is that we purge the client database by default. > And we should purge it once we have generated the p12 file, because it > includes the nss database and password files and so on. I suppose we > could be a little smarter about exactly what it is that we purge. > > > 3. The default pki_admin_nickname is too long: > > > > PKI Administrator's example.com Security Domain ID > > > > It can be simplified without losing information: > > > > PKI Administrator of example.com > > OK - will change. > > > > 4. The common cert files are called ca_admin.*. I think we should remove > > the "ca_" to reflect that the cert works on all subsystems. > > > Well along the lines of my response to above, if we change the name of > the directive to import_admin_cert - then its clearer that we are > importing a cert that was generated during the CA install for the admin > user on all subsystems. > > In that case, using ca_admin is probably OK. > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Mon Dec 3 15:36:27 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Dec 2012 10:36:27 -0500 Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts. In-Reply-To: <50BC14BD.2010709@redhat.com> References: <50B53B6F.7020906@redhat.com> <1354255161.2654.24.camel@aleeredhat.laptop> <50BC14BD.2010709@redhat.com> Message-ID: <1354548988.2317.22.camel@aleeredhat.laptop> On Sun, 2012-12-02 at 20:55 -0600, Endi Sukma Dewata wrote: > On 11/29/2012 11:59 PM, Ade Lee wrote: > > Looks good - and is the right idea. What makes you think that cfg.pl is > > not used? There are functions that are defined there that are used in > > the esc cgi scripts. > > > > Please restore cfg.pl. > > As discussed on IRC, there are 2 cfg.pl files, one in the TPS core page > and the other in the TPS theme package. In the original code before the > patch, the code in pkicreate:2064 copies the cfg.pl in theme to override > the cfg.pl in core: > > return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path, > $default_dir_permissions, $default_file_permissions, > $pki_user, $pki_group); > > So the original cfg.pl in core package was never actually used. > > In the updated #192 this code no longer exists since the TPS theme has > being removed. > ACK. Whats troubling is that neither version appears to be correct. The correct version is in the 8.1 branch. We don't have to fix this here. You can commit your patch, but please open a ticket to fix the security officer workstation cgi scripts in dogtag 10. From alee at redhat.com Mon Dec 3 15:36:50 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Dec 2012 10:36:50 -0500 Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files. In-Reply-To: <50BC14C0.5080002@redhat.com> References: <50B53B74.6050305@redhat.com> <1354255334.2654.27.camel@aleeredhat.laptop> <50BC14C0.5080002@redhat.com> Message-ID: <1354549010.2317.23.camel@aleeredhat.laptop> ACK On Sun, 2012-12-02 at 20:56 -0600, Endi Sukma Dewata wrote: > On 11/30/2012 12:02 AM, Ade Lee wrote: > > Looks good in general. > > > > I noticed that you moved dogtag/tps-ui/shared/docroot/esc/style.css -> > > dogtag/common-ui/shared/style.css instead of > > dogtag/common-ui/shared/esc/style.css. Why is this? > > This was an error. It has been fixed in the attached revised patch. > From alee at redhat.com Mon Dec 3 15:38:16 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Dec 2012 10:38:16 -0500 Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages. In-Reply-To: <50BC14C5.30109@redhat.com> References: <50B53B79.5090003@redhat.com> <1354256740.2654.40.camel@aleeredhat.laptop> <50BC14C5.30109@redhat.com> Message-ID: <1354549097.2317.25.camel@aleeredhat.laptop> On Sun, 2012-12-02 at 20:56 -0600, Endi Sukma Dewata wrote: > On 11/30/2012 12:25 AM, Ade Lee wrote: > > 1. There are cgi scripts which are explicitly set to have execute > > permissions by the build script. Is this not needed? Can you confirm > > this? > > Are you referring to the removal of this code? > > chmod 755 %{buildroot}%{_datadir}/pki/tps-ui/cgi-bin/sow/cfg.pl > > There are codes in pkicreate:2076-2090 that set the permissions: > > set_permissions("${cgibin_instance_path}/sow/*.pl", > $default_exe_permissions); > > So the above chmod code is not necessary. > > > 2. As mentioned in a previous review, cfg.pl is needed. > > This is discussed in my response for #190. > > > 3. Are there really no changes required in pkicreate and pkiremove? > > Surely there must be code that copies stuff from /usr/share/pki/tps-ui > > and /usr/share/pki/ra-ui. There may even be a programmatic check for > > the ui package. And don't we need code to copy the relevant bits from > > common-ui? > > The original code already has some codes to copy the subsystem theme > files and common theme files (see pkicreate:2064): > > # Copy /usr/share/pki/-ui to > return 0 if !copy_directory($ui_subsystem_path, $pki_instance_path, > $default_dir_permissions, $default_file_permissions, > $pki_user, $pki_group); > > # Copy /usr/share/pki/common-ui to /docroot/pki > return 0 if !copy_directory( > $common_ui_subsystem_path, > "$docroot_instance_path/pki", > $default_dir_permissions, $default_file_permissions, > $pki_user, $pki_group); > > In the attached revised patch the code to copy -ui has been > removed because the RA/TPS themes don't exist anymore. The > copy_directory() would ignore missing folders, but it's better to remove > unused code. > > The code to copy the common-ui is left intact. > > > 4. How was this tested? Do you pkicreate and configure RA and TPS > > instances? > > Yes, the UI seems to be working fine, I didn't see any broken > page/links/images, but I'm not familiar with these subsystems to test > the functionality. > > > When the instances are created, are all the relevant files > > where you expect them to be ?-- ie. compare the layout of old/new > > instances. > > Yes, they seem to be deployed to the same locations. > > > Did you configure the instances and check the UI to make sure it looks > > the same? > > Yes, they looked fine. > > > Did you look at the security officer workstation stuff ? > > Or configure a token? > > No, I'm not familiar with this UI, please let me know how to test it. > As noted for the other patch, the Security Officer workstation is probably broken (for reasons not related to your patch). ACK. From alee at redhat.com Mon Dec 3 16:38:42 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 03 Dec 2012 11:38:42 -0500 Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template. In-Reply-To: <50B9992D.8020403@redhat.com> References: <50A3A960.5040104@redhat.com> <50B9992D.8020403@redhat.com> Message-ID: <1354552723.2317.27.camel@aleeredhat.laptop> Great explanation. thanks! Lets use the latest jquery -- and find out a little more about any license requirements. ACK. Ade On Fri, 2012-11-30 at 23:44 -0600, Endi Sukma Dewata wrote: > On 11/14/2012 8:23 AM, Endi Sukma Dewata wrote: > > The messages in ProfileList.template in CA EE has been extracted > > into a properties file which can be translated separately. > > > > The original messages in the template have been marked as follows: > > ...message... > > > > When the page is loaded into the browser, the original message will > > be replaced with the translated message. > > > > Ticket #406 > > Just to clarify, this patch demonstrates how message customization could > be done. A full solution will require many incremental patches due to > the number of messages to be customized. Here is how it works. > > Previously a theme consist of HTML/Velocity templates, JS files, images > and CSS files. The HTML/Velocity templates contain HTML code, JS code, > paths to images/CSS files, and text messages. > > To create a custom theme we had to clone the default Dogtag theme, then > customize the files as needed. Most of the time we'll only be changing > the images, CSS, and messages, but we still have to duplicate everything > in the theme. This becomes a maintenance issue because if we change > anything in the default theme, the custom theme will not be updated > automatically, and it could be hard to merge the changes. > > Recently we've been moving the templates and JS files out of the theme > packages into the core packages because they are less likely to be > changed, leaving just the images and CSS files in the theme. However, > the messages are still part of the templates. To support customization > we need to separate the messages from the templates. > > JQuery and jquery-i18n-properties are tools that we can use to load > custom messages from a separate properties file and then replace the > original messages in the template. > > Suppose we have a template which contains the following HTML code: > > > Dogtag > > The Dogtag Certificate System is an enterprise-class open > source Certificate Authority. > > > > To make the messages customizable we need to mark them. Here we are > using a which shouldn't be visible in the browser: > > > > Dogtag > > > The Dogtag Certificate > System is an enterprise-class open source Certificate > Authority. > > > > The element is assigned a class "message" which will be used to > locate all messages. The element is also assigned a name which will be > used as message key. The original message itself is left intact within > the to help visualize the page. Then we create a > Messages.properties that maps the message keys to the actual messages: > > title = Dogtag > description = The Dogtag Certificate System is an enterprise-class\ > open source Certificate Authority. > > The messages in the properties file can be customized as needed. Then > we'll use the tools to load the custom messages and replace the original > messages in the template: > > $.i18n.properties({ > name: 'Messages', > ... > callback: function() { > var key; > for (key in $.i18n.map) { > var message = $.i18n.prop(key); > $('span.message[name='+key+']').html(message); > } > } > }); > > After the browser finishes loading the page the $.i18n.properties() will > run to load the custom messages from Messages.properties. Once they are > loaded the callback() will run to replace all marked messages with the > custom messages. > > There are 2 different purposes for message customization which require > different strategies: branding and translation. > > If we're doing branding only, like the current implementation, we need > to use separate properties for each theme, for example: > > Messages.properties - Dogtag theme > Messages.properties - Other theme > > If we're doing translation only we need to use separate properties file > for each language, for example: > > Messages.properties - Dogtag theme in English > Messages_es.properties - Dogtag theme in Spanish > Messages_fr.properties - Dogtag theme in French > > If we're doing both branding and translation the number of files will be > multiplied: > > Messages.properties - Dogtag theme in English > Messages_es.properties - Dogtag theme in Spanish > Messages_fr.properties - Dogtag theme in French > > Messages.properties - Other theme in English > Messages_es.properties - Other theme in Spanish > Messages_fr.properties - Other theme in French > > One possible solution is to do the translation and branding separately > using different message markers: > > > > Dogtag > > > The class="product" name="long_title">Dogtag Certificate > System is an enterprise-class open source Certificate > Authority. > > > > Here we can load the translated "message" first, then load the > untranslated "product" after that. This solution doesn't require as many > properties files: > > Messages.properties - English messages > Messages_es.properties - Spanish messages > Messages_fr.properties - French messages > > Product.properties - Dogtag theme > Product.properties - Other theme > > If we can assume the messages are fixed, we can actually include the > messages in the core packages and leave the branding in the theme packages. > > We could also stack the theme files, similar to the sections in the > configuration file, so the custom theme only needs to store the files > that are different from the default theme. This will require the ability > to install multiple themes and deploy the custom theme on top of the > default theme. > From edewata at redhat.com Mon Dec 3 17:05:39 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Dec 2012 11:05:39 -0600 Subject: [Pki-devel] [PATCH] 189 Reorganized RA templates and scripts. In-Reply-To: <1354255028.2654.22.camel@aleeredhat.laptop> References: <50B53B68.1010404@redhat.com> <1354255028.2654.22.camel@aleeredhat.laptop> Message-ID: <50BCDBE3.9060101@redhat.com> On 11/29/2012 11:57 PM, Ade Lee wrote: > ACK, but please check in once all the changes in patches 189 - 192 are > verified. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 17:05:49 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Dec 2012 11:05:49 -0600 Subject: [Pki-devel] [PATCH] 190 Reorganized TPS templates and scripts. In-Reply-To: <1354548988.2317.22.camel@aleeredhat.laptop> References: <50B53B6F.7020906@redhat.com> <1354255161.2654.24.camel@aleeredhat.laptop> <50BC14BD.2010709@redhat.com> <1354548988.2317.22.camel@aleeredhat.laptop> Message-ID: <50BCDBED.4080307@redhat.com> On 12/3/2012 9:36 AM, Ade Lee wrote: > ACK. > > Whats troubling is that neither version appears to be correct. The > correct version is in the 8.1 branch. We don't have to fix this here. > You can commit your patch, but please open a ticket to fix the security > officer workstation cgi scripts in dogtag 10. Pushed to master. Ticket for SOW: https://fedorahosted.org/pki/ticket/429 -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 17:05:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Dec 2012 11:05:53 -0600 Subject: [Pki-devel] [PATCH] 191 Reorganized TPS CSS files. In-Reply-To: <1354549010.2317.23.camel@aleeredhat.laptop> References: <50B53B74.6050305@redhat.com> <1354255334.2654.27.camel@aleeredhat.laptop> <50BC14C0.5080002@redhat.com> <1354549010.2317.23.camel@aleeredhat.laptop> Message-ID: <50BCDBF1.6040908@redhat.com> On 12/3/2012 9:36 AM, Ade Lee wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 17:05:57 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Dec 2012 11:05:57 -0600 Subject: [Pki-devel] [PATCH] 192 Removed RA and TPS theme packages. In-Reply-To: <1354549097.2317.25.camel@aleeredhat.laptop> References: <50B53B79.5090003@redhat.com> <1354256740.2654.40.camel@aleeredhat.laptop> <50BC14C5.30109@redhat.com> <1354549097.2317.25.camel@aleeredhat.laptop> Message-ID: <50BCDBF5.7010804@redhat.com> On 12/3/2012 9:38 AM, Ade Lee wrote: > ACK. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Dec 3 17:06:03 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 03 Dec 2012 11:06:03 -0600 Subject: [Pki-devel] [PATCH] 184 I18n for ProfileList.template. In-Reply-To: <1354552723.2317.27.camel@aleeredhat.laptop> References: <50A3A960.5040104@redhat.com> <50B9992D.8020403@redhat.com> <1354552723.2317.27.camel@aleeredhat.laptop> Message-ID: <50BCDBFB.509@redhat.com> On 12/3/2012 10:38 AM, Ade Lee wrote: > ACK. Pushed to master. -- Endi S. Dewata From nkinder at redhat.com Tue Dec 4 04:25:34 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 03 Dec 2012 20:25:34 -0800 Subject: [Pki-devel] [PATCH] 1 Run restorecon on top-level log directory Message-ID: <50BD7B3E.1050303@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-nkinder-0001-Run-restorecon-on-top-level-log-directory.patch Type: text/x-patch Size: 1383 bytes Desc: not available URL: From alee at redhat.com Tue Dec 4 07:32:56 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 02:32:56 -0500 Subject: [Pki-devel] [PATCH] 95 use interpolation to build default parameters Message-ID: <1354606377.2317.30.camel@aleeredhat.laptop> Use interpolation to build default parameters This patch replaces the code in pkiparser with defaults that are built up using ConfigParser interpolation. The patch gets most (but not all) default parameters. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0095-Use-interpolation-to-build-default-parameters.patch Type: text/x-patch Size: 67250 bytes Desc: not available URL: From alee at redhat.com Tue Dec 4 16:43:56 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 11:43:56 -0500 Subject: [Pki-devel] [PATCH] 96 corrections for interpolation review Message-ID: <1354639437.2317.32.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0096-Interpolation-correction-patch-based-on-review-comme.patch Type: text/x-patch Size: 16104 bytes Desc: not available URL: From alee at redhat.com Tue Dec 4 17:13:15 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 12:13:15 -0500 Subject: [Pki-devel] [PATCH] 95 use interpolation to build default parameters In-Reply-To: <1354606377.2317.30.camel@aleeredhat.laptop> References: <1354606377.2317.30.camel@aleeredhat.laptop> Message-ID: <1354641196.2317.33.camel@aleeredhat.laptop> acked by Endi. Pushed to master. On Tue, 2012-12-04 at 02:32 -0500, Ade Lee wrote: > Use interpolation to build default parameters > > This patch replaces the code in pkiparser with defaults that are > built up using ConfigParser interpolation. The patch gets most > (but not all) default parameters. > > Please review. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Dec 4 17:19:05 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 12:19:05 -0500 Subject: [Pki-devel] [PATCH] 96 corrections for interpolation review In-Reply-To: <1354639437.2317.32.camel@aleeredhat.laptop> References: <1354639437.2317.32.camel@aleeredhat.laptop> Message-ID: <1354641546.29745.0.camel@aleeredhat.laptop> acked by Endi. Pushed to master. On Tue, 2012-12-04 at 11:43 -0500, Ade Lee wrote: > Please review. > > Ade > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From edewata at redhat.com Tue Dec 4 18:23:41 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 04 Dec 2012 12:23:41 -0600 Subject: [Pki-devel] [PATCH] 197 Archiving default deployment configuration. Message-ID: <50BE3FAD.9010707@redhat.com> The default deployment configuration has been renamed and moved to /etc/pki/default.cfg to make it more accessible to users. The pkispawn has been modified to archive the default deployment configuration along with the user-provided configuration in the registry. The pkidestroy will now use both archived configuration files to ensure proper removal of the subsystem. Ticket #399 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0197-Archiving-default-deployment-configuration.patch Type: text/x-patch Size: 37659 bytes Desc: not available URL: From alee at redhat.com Tue Dec 4 20:27:35 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 15:27:35 -0500 Subject: [Pki-devel] [PATCH] 197 Archiving default deployment configuration. In-Reply-To: <50BE3FAD.9010707@redhat.com> References: <50BE3FAD.9010707@redhat.com> Message-ID: <1354652856.29745.2.camel@aleeredhat.laptop> ack On Tue, 2012-12-04 at 12:23 -0600, Endi Sukma Dewata wrote: > The default deployment configuration has been renamed and moved to > /etc/pki/default.cfg to make it more accessible to users. The pkispawn > has been modified to archive the default deployment configuration > along with the user-provided configuration in the registry. The > pkidestroy will now use both archived configuration files to ensure > proper removal of the subsystem. > > Ticket #399 > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Dec 4 20:26:20 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 15:26:20 -0500 Subject: [Pki-devel] [PATCH] 1 Run restorecon on top-level log directory In-Reply-To: <50BD7B3E.1050303@redhat.com> References: <50BD7B3E.1050303@redhat.com> Message-ID: <1354652781.29745.1.camel@aleeredhat.laptop> ACK - pushed to master. On Mon, 2012-12-03 at 20:25 -0800, Nathan Kinder wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Tue Dec 4 20:51:50 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 04 Dec 2012 15:51:50 -0500 Subject: [Pki-devel] [PATCH] 197 Archiving default deployment configuration. In-Reply-To: <1354652856.29745.2.camel@aleeredhat.laptop> References: <50BE3FAD.9010707@redhat.com> <1354652856.29745.2.camel@aleeredhat.laptop> Message-ID: <1354654311.29745.3.camel@aleeredhat.laptop> pushed to master On Tue, 2012-12-04 at 15:27 -0500, Ade Lee wrote: > ack > > On Tue, 2012-12-04 at 12:23 -0600, Endi Sukma Dewata wrote: > > The default deployment configuration has been renamed and moved to > > /etc/pki/default.cfg to make it more accessible to users. The pkispawn > > has been modified to archive the default deployment configuration > > along with the user-provided configuration in the registry. The > > pkidestroy will now use both archived configuration files to ensure > > proper removal of the subsystem. > > > > Ticket #399 > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Wed Dec 5 06:31:44 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 04 Dec 2012 22:31:44 -0800 Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA Message-ID: <50BEEA50.9080108@redhat.com> The attached patch addresses the following PKI issues: * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle external CA This code has been successfully tested on a slightly earlier version of the source tree, although the attached patch has been re-based to the 'master'. To test this code, the following procedure was followed on an x86_64 machine running 64-bit Fedora 18: * First, a standard CA was created to be used as an "External CA" using the following command and file ('# mv typescript typescript.external' once finished): o script -c 'pkispawn -s CA -f /tmp/pki/external.cfg -vvv' # cat external.cfg [Common] pki_admin_password= pki_backup_password= pki_client_pkcs12_password= pki_ds_password= pki_security_domain_password= [Tomcat] pki_ajp_port=18009 pki_http_port=18080 pki_https_port=18443 pki_instance_name=pki-external-tomcat pki_tomcat_server_port=18005 * Next, Step 1 for a CA which depended upon this External CA was created using the following command and file('# mv typescript typescript.step_1' once finished): o script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv' # cat ca_1.cfg [Common] pki_admin_password= pki_backup_password= pki_client_pkcs12_password= pki_ds_password= pki_security_domain_password= [CA] pki_external=True pki_external_csr_path=/tmp/pki/ca_signing.csr * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr' was utilzed to create a certificate using the "External CA" using the following procedure: o External CA: EE: Enrollment/Renewal Tab * Use 'Manual Certificate Manager Signing Certificate Enrollment' AGENT: Approve request by pressing 'submit' EE: Retrieval Tab * Use 'Check Request Status' to obtain the base 64 encoded certificate * Store this blob into the file specified by the value of 'pki_external_ca_cert_path'in ca_2.cfg EE: Retrieval Tab * Use 'Import CA Certificate Chain' and select the radio button entitled 'Display certificates in the CA certificate chain for importing individually into a server' to obtain the base 64 encoded certificate chain * Store this blob into the file specified by the value of 'pki_external_ca_cert_chain_path'in ca_2.cfg * Finally, Step 2 for a CA which depended upon this External CA was created using the following command and file('# mv typescript typescript.step_2' once finished): o script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv' # cat ca_2.cfg [Common] pki_admin_password= pki_backup_password= pki_client_pkcs12_password= pki_ds_password= pki_security_domain_password= [CA] pki_external=True pki_external_ca_cert_chain_path=/tmp/pki/ca_signing_chain.cert pki_external_ca_cert_path=/tmp/pki/ca_signing.cert pki_external_step_two=True -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20121204-Implemented-ability-to-utilize-an-external-CA.patch Type: text/x-patch Size: 19244 bytes Desc: not available URL: From alee at redhat.com Wed Dec 5 18:32:30 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 05 Dec 2012 13:32:30 -0500 Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA In-Reply-To: <50BEEA50.9080108@redhat.com> References: <50BEEA50.9080108@redhat.com> Message-ID: <1354732351.29745.18.camel@aleeredhat.laptop> Comments: 1. In pkiparser, you add: if not len(config.pki_master_dict['pki_security_domain_name']): config.pki_master_dict['pki_security_domain_name'] =\ "External CA Security Domain" We no longer distinguish security domains like this. The default as defined by interpolation is fine. 2. I think we can remove the comment: # always set 'pki_skip_installation' true using a 'string' in initialization.py 3. In pkijython.py, you do: elif config.str2bool(self.master['pki_external']) and\ config.str2bool(self.master['pki_external_step_two']): # always remove pki_external DS data from external CA step 1 data.setRemoveData("true") This means that we'll set up the database and then blow it away and set it up again in step 2. Even more troubling, the request for the CA cert is probably stored in the database during step 1 and is blown away in step 2. The better way to do this would be to modify the configuration servlet to skip database population if we are doing external CA step 2. 4. In pkijython.py, you extract the pin from CS.cfg and overwrite the existing pin. But perhaps a better thing to do would be to move this code to pkiparser where the original pin is generated. Ade On Tue, 2012-12-04 at 22:31 -0800, Matthew Harmsen wrote: > The attached patch addresses the following PKI issues: > * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle > external CA > This code has been successfully tested on a slightly earlier version > of the source tree, although the attached patch has been re-based to > the 'master'. > > To test this code, the following procedure was followed on an x86_64 > machine running 64-bit Fedora 18: > * First, a standard CA was created to be used as an "External > CA" using the following command and file ('# mv typescript > typescript.external' once finished): > * script -c 'pkispawn -s CA -f /tmp/pki/external.cfg > -vvv' > > # cat external.cfg > [Common] > pki_admin_password= > pki_backup_password= > pki_client_pkcs12_password= > pki_ds_password= > pki_security_domain_password= > [Tomcat] > pki_ajp_port=18009 > pki_http_port=18080 > pki_https_port=18443 > pki_instance_name=pki-external-tomcat > pki_tomcat_server_port=18005 > > * Next, Step 1 for a CA which depended upon this External CA was > created using the following command and file ('# mv typescript > typescript.step_1' once finished): > * script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv' > > # cat ca_1.cfg > [Common] > pki_admin_password= > pki_backup_password= > pki_client_pkcs12_password= > pki_ds_password= > pki_security_domain_password= > [CA] > pki_external=True > pki_external_csr_path=/tmp/pki/ca_signing.csr > > * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr' > was utilzed to create a certificate using the "External CA" > using the following procedure: > * External CA: > > EE: Enrollment/Renewal Tab > * Use 'Manual Certificate Manager Signing > Certificate Enrollment' > > AGENT: Approve request by pressing 'submit' > > EE: Retrieval Tab > * Use 'Check Request Status' to obtain the > base 64 encoded certificate > * Store this blob into the file specified by > the value of 'pki_external_ca_cert_path' in ca_2.cfg > > EE: Retrieval Tab > * Use 'Import CA Certificate Chain' and select > the radio button entitled 'Display certificates in the > CA certificate chain for > importing individually into a server' to > obtain the base 64 encoded certificate chain > * Store this blob into the file specified by > the value of 'pki_external_ca_cert_chain_path' in > ca_2.cfg > > * Finally, Step 2 for a CA which depended upon this External CA > was created using the following command and file ('# mv > typescript typescript.step_2' once finished): > * script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv' > > # cat ca_2.cfg > [Common] > pki_admin_password= > pki_backup_password= > pki_client_pkcs12_password= > pki_ds_password= > pki_security_domain_password= > [CA] > pki_external=True > pki_external_ca_cert_chain_path=/tmp/pki/ca_signing_chain.cert > pki_external_ca_cert_path=/tmp/pki/ca_signing.cert > pki_external_step_two=True > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Thu Dec 6 22:37:29 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 06 Dec 2012 14:37:29 -0800 Subject: [Pki-devel] [PATCH] Implemented ability to use an external CA In-Reply-To: <1354732351.29745.18.camel@aleeredhat.laptop> References: <50BEEA50.9080108@redhat.com> <1354732351.29745.18.camel@aleeredhat.laptop> Message-ID: <50C11E29.9040200@redhat.com> A revised patch has been attached to this email which addresses all of the issues below. All tests documented below have been run successfully against this patch. NOTE: The tests have been modified slightly to comply with the latest PKI source code. On 12/05/12 10:32, Ade Lee wrote: > Comments: > 1. In pkiparser, you add: > if not len(config.pki_master_dict['pki_security_domain_name']): > config.pki_master_dict['pki_security_domain_name'] =\ > "External CA Security Domain" > > We no longer distinguish security domains like this. The default as > defined by interpolation is fine. > > 2. I think we can remove the comment: > # always set 'pki_skip_installation' true using a 'string' > in initialization.py > > 3. In pkijython.py, you do: > elif config.str2bool(self.master['pki_external']) and\ > config.str2bool(self.master['pki_external_step_two']): > # always remove pki_external DS data from external CA step 1 > data.setRemoveData("true") > > This means that we'll set up the database and then blow it away and set > it up again in step 2. Even more troubling, the request for the CA cert > is probably stored in the database during step 1 and is blown away in > step 2. > > The better way to do this would be to modify the configuration servlet > to skip database population if we are doing external CA step 2. > > 4. In pkijython.py, you extract the pin from CS.cfg and overwrite the > existing pin. But perhaps a better thing to do would be to move this > code to pkiparser where the original pin is generated. > > Ade > > On Tue, 2012-12-04 at 22:31 -0800, Matthew Harmsen wrote: >> The attached patch addresses the following PKI issues: >> * TRAC Ticket #231 - Dogtag 10: Update PKI Deployment to handle >> external CA >> This code has been successfully tested on a slightly earlier version >> of the source tree, although the attached patch has been re-based to >> the 'master'. >> >> To test this code, the following procedure was followed on an x86_64 >> machine running 64-bit Fedora 18: >> * First, a standard CA was created to be used as an "External >> CA" using the following command and file ('# mv typescript >> typescript.external' once finished): >> * script -c 'pkispawn -s CA -f /tmp/pki/external.cfg >> -vvv' >> >> # cat external.cfg >> [Common] >> pki_admin_password= >> pki_backup_password= >> pki_client_pkcs12_password= >> pki_ds_password= >> pki_security_domain_password= pki_http_port=18080 pki_https_port=18443 pki_instance_name=pki-external-tomcat >> [Tomcat] >> pki_ajp_port=18009 >> pki_tomcat_server_port=18005 >> >> * Next, Step 1 for a CA which depended upon this External CA was >> created using the following command and file ('# mv typescript >> typescript.step_1' once finished): >> * script -c 'pkispawn -s CA -f /tmp/pki/ca_1.cfg -vvv' >> >> # cat ca_1.cfg >> [Common] >> pki_admin_password= >> pki_backup_password= >> pki_client_pkcs12_password= >> pki_ds_password= >> pki_security_domain_password= >> [CA] >> pki_external=True >> pki_external_csr_path=/tmp/pki/config/ca_signing.csr pki_ca_signing_subject_dn=CA Signing Certificate,o=%{pki_security_domain_name)s External >> >> * Next, the CSR contained in the file '/tmp/pki/ca_signing.csr' >> was utilzed to create a certificate using the "External CA" >> using the following procedure: >> * External CA: >> >> EE: Enrollment/Renewal Tab >> * Use 'Manual Certificate Manager Signing >> Certificate Enrollment' >> >> AGENT: Approve request by pressing 'submit' >> >> EE: Retrieval Tab >> * Use 'Check Request Status' to obtain the >> base 64 encoded certificate >> * Store this blob into the file specified by >> the value of 'pki_external_ca_cert_path' in ca_2.cfg >> >> EE: Retrieval Tab >> * Use 'Import CA Certificate Chain' and select >> the radio button entitled 'Display certificates in the >> CA certificate chain for >> importing individually into a server' to >> obtain the base 64 encoded certificate chain >> * Store this blob into the file specified by >> the value of 'pki_external_ca_cert_chain_path' in >> ca_2.cfg >> >> * Finally, Step 2 for a CA which depended upon this External CA >> was created using the following command and file ('# mv >> typescript typescript.step_2' once finished): >> * script -c 'pkispawn -s CA -f /tmp/pki/ca_2.cfg -vvv' >> >> # cat ca_2.cfg >> [Common] >> pki_admin_password= >> pki_backup_password= >> pki_client_pkcs12_password= >> pki_ds_password= >> pki_security_domain_password= >> [CA] >> pki_external=True >> pki_external_ca_cert_chain_path=/tmp/pki/config/ca_signing_chain.cert >> pki_external_ca_cert_path=/tmp/pki/config/ca_signing.cert >> pki_external_step_two=True pki_ca_signing_subject_dn=CA Signing Certificate,o=%{pki_security_domain_name)s External >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > * Additionally, as a final sanity test, a default KRA was created re-utilizing the 'ca_1.cfg' file ('# mv typescript typescript.kra' once finished): o script -c 'pkispawn -s KRA -f /tmp/pki/ca_1.cfg -vvv' -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20121206-Implemented-ability-to-utilize-an-external-CA.patch Type: text/x-patch Size: 21847 bytes Desc: not available URL: From edewata at redhat.com Fri Dec 7 00:57:31 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Dec 2012 18:57:31 -0600 Subject: [Pki-devel] [PATCH] 198 Parameterizing RESTEasy paths. Message-ID: <50C13EFB.7060801@redhat.com> The paths to RESTEasy jar files have been modified such that it can be configured globally at build time using the spec file to support different distributions, and at deployment time using a system-wide configuration in /etc/pki/pki.conf. Ticket #422, #423. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-edewata-0198-Parameterizing-RESTEasy-paths.patch Type: text/x-patch Size: 31013 bytes Desc: not available URL: From edewata at redhat.com Fri Dec 7 02:24:53 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 06 Dec 2012 20:24:53 -0600 Subject: [Pki-devel] [PATCH] 198 Parameterizing RESTEasy paths. In-Reply-To: <50C13EFB.7060801@redhat.com> References: <50C13EFB.7060801@redhat.com> Message-ID: <50C15375.1090606@redhat.com> On 12/6/2012 6:57 PM, Endi Sukma Dewata wrote: > The paths to RESTEasy jar files have been modified such that it can > be configured globally at build time using the spec file to support > different distributions, and at deployment time using a system-wide > configuration in /etc/pki/pki.conf. > > Ticket #422, #423. ACKed by Ade, pushed to master. -- Endi S. Dewata From alee at redhat.com Fri Dec 7 05:55:43 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Dec 2012 00:55:43 -0500 Subject: [Pki-devel] [PATCH] 97 - Remove-server-code-from-CertSearchRequest Message-ID: <1354859743.29745.36.camel@aleeredhat.laptop> Pretty straightforward. Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0097-Remove-server-code-from-CertSearchRequest.patch Type: text/x-patch Size: 26621 bytes Desc: not available URL: From alee at redhat.com Fri Dec 7 06:02:43 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Dec 2012 01:02:43 -0500 Subject: [Pki-devel] [PATCH] 97 - Remove-server-code-from-CertSearchRequest In-Reply-To: <1354859743.29745.36.camel@aleeredhat.laptop> References: <1354859743.29745.36.camel@aleeredhat.laptop> Message-ID: <1354860164.29745.37.camel@aleeredhat.laptop> Acked by Matt. Pushed to master. On Fri, 2012-12-07 at 00:55 -0500, Ade Lee wrote: > Pretty straightforward. Please review. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From akoneru at redhat.com Fri Dec 7 14:59:56 2012 From: akoneru at redhat.com (Abhishek Koneru) Date: Fri, 07 Dec 2012 09:59:56 -0500 Subject: [Pki-devel] [PATCH] 35 Fix for ticket 214 - Proper error message while adding duplicate user Message-ID: <1354892396.32653.3.camel@akoneru.redhat.com> Please review the patch which fixes the ticket 214. It requires Patch 34 which is also attached to be applied first. --Abhishek -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0034-Ticket-191-Mapping-HTTP-Exception-to-their-proper-HT.patch Type: text/x-patch Size: 72524 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-akoneru-0035-Ticket-214-Proper-error-message-when-adding-a-duplic.patch Type: text/x-patch Size: 4233 bytes Desc: not available URL: From alee at redhat.com Fri Dec 7 20:38:51 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Dec 2012 15:38:51 -0500 Subject: [Pki-devel] [PATCH] 98 - man page edits Message-ID: <1354912731.29745.38.camel@aleeredhat.laptop> -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0098-Added-more-detail-to-man-page-for-pki-1.patch Type: text/x-patch Size: 8591 bytes Desc: not available URL: From alee at redhat.com Fri Dec 7 20:54:08 2012 From: alee at redhat.com (Ade Lee) Date: Fri, 07 Dec 2012 15:54:08 -0500 Subject: [Pki-devel] [PATCH] 98 - man page edits In-Reply-To: <1354912731.29745.38.camel@aleeredhat.laptop> References: <1354912731.29745.38.camel@aleeredhat.laptop> Message-ID: <1354913649.29745.39.camel@aleeredhat.laptop> more edits. On Fri, 2012-12-07 at 15:38 -0500, Ade Lee wrote: > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0098-1-Added-more-detail-to-man-page-for-pki-1.patch Type: text/x-patch Size: 8545 bytes Desc: not available URL: From alee at redhat.com Mon Dec 10 18:42:23 2012 From: alee at redhat.com (Ade Lee) Date: Mon, 10 Dec 2012 13:42:23 -0500 Subject: [Pki-devel] [PATCH] 99 - man page updates Message-ID: <1355164943.10814.0.camel@aleeredhat.laptop> -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0099-More-edits-to-man-pages.patch Type: text/x-patch Size: 19553 bytes Desc: not available URL: From awnuk at redhat.com Tue Dec 11 00:47:37 2012 From: awnuk at redhat.com (Andrew Wnuk) Date: Mon, 10 Dec 2012 16:47:37 -0800 Subject: [Pki-devel] [PATCH] authentication plugin Message-ID: <50C682A9.30504@redhat.com> This patch provides authentication plugin avoiding anonymous access. Bug 861467. -------------- next part -------------- A non-text attachment was scrubbed... Name: authentication-plugin.patch Type: text/x-patch Size: 18160 bytes Desc: not available URL: From mharmsen at redhat.com Tue Dec 11 00:53:33 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Mon, 10 Dec 2012 16:53:33 -0800 Subject: [Pki-devel] [PATCH] authentication plugin In-Reply-To: <50C682A9.30504@redhat.com> References: <50C682A9.30504@redhat.com> Message-ID: <50C6840D.4010306@redhat.com> On 12/10/12 16:47, Andrew Wnuk wrote: > This patch provides authentication plugin avoiding anonymous access. > > Bug 861467. > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel ACK Received demo of this patch for Dogtag 9. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Tue Dec 11 19:11:24 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 11 Dec 2012 14:11:24 -0500 Subject: [Pki-devel] Announcing Dogtag 10.0 Release Candidate 1 Message-ID: <1355253084.2513.59.camel@aleeredhat.laptop> The Dogtag team is proud to announce version Dogtag v10.0.0 Release Candidate 1. A build is available for Fedora 18 in the updates-testing repo. Please try it out and provide karma to move it to the F18 stable repo. Daily developer builds for Fedora 17 and 18 are available at http://nkinder.fedorapeople.org/dogtag-devel/fedora/ == Build Versions == pki-core-10.0.0-2.fc18 pki-ra-10.0.0-1.fc18 pki-tps-10.0.0-1.fc18 dogtag-pki-10.0.0-1.fc18 dogtag-pki-theme-10.0.0-1.fc18 pki-console-10.0.0-1.fc18 == Highlights since Dogtag v. 10.0.0 beta 2 (Oct 30 2012) == * Simplified and enhanced pkispawn. ** Added detailed man pages to document use of pkispawn, pkidestroy and the command line utility pki. ** Removed --dry-run option and unused respawn() code. ** Replaced links of scriptlets with lists ** Modified the way pkispawn parses configuration files. pkispawn now reads a template file for default settings, and a much smaller and simpler user-defined configuration file for customizations and overrides. Moreover, pkispawn uses interpolation to substitute in values. See the man pages for details. ** Added the ability to import an admin cert into the administrative user created for each subsystem. This allows multiple subsystems within the same instance to be more easily managed within the same browser. ** Implemented ability to install a subordinate CA using pkispawn. ** Implemented ability to install an externally signed CA using pkispawn. * Simplified the structure of the UI packages ** All images and css files have been moved to dogtag-pki-server-theme for all subsystems. ** Removed unused and duplicated files. ** Template files have been moved to the underlying subsystem files. In future, all theme related messages in those files will be parameterized and placed in dogtag-pki-server-theme. This will significantly simplify the process of customizing or internationalizing an instance and its theme. ** Retired all the subsystem specific UI packages, reducing the number of UI packages from 7 to 1. * Security fixes for CVE-2012-4543 Certificate System: Multiple cross-site scripting flaws by displaying CRL or processing. * Memory fixes for the TPS * Updated to latest version of cmake, removing obsolete modules. == Notes for F17 == * Only developer builds are available for F17. * F17 tomcat used to have a bug in the way it handles pid files. https://bugzilla.redhat.com/show_bug.cgi?id=863307. Make sure that you have at least tomcat-7.0.32-1.fc17. == Feedback == Please provide comments, bugs and other feedback via the pki-devel mailing list: http://www.redhat.com/mailman/listinfo/pki-devel == Detailed Changelog == akoneru (2): 0667896 Fix for improper crl retrieval from CA. f400f3b Invalid ACL resources Fix in KRA for certServer.kra.keys alee (25): 6e77f33 Updated pki-core spec file to 10.0.0-2 a505c8c fix typo in spec file f73a662 Update to rc1 build 1e46576 Added more detail to man page for pki(1) cbfdae8 Remove server code from CertSearchRequest cd279e3 Modified section on sample.cfg a3f7d58 Interpolation correction patch based on review comments 065d883 Use interpolation to build default parameters 35dc100 Change the structure of the client directory. 03a6350 Common User: pkispawn changes 6be1194 Common admin user: config servlet changes 871b442 Misc changes to get rhel 7 build to work 40e58f9 Link to resteasy-base on rhel systems when running pkispawn 96af71d Removed obsolete cmake modules, updated spec files 9862a04 Updating cmake variables 440a9e7 removed obsolete cmake modules 1de7c91 Change cmake projects from Java to NONE 2efc66e spec file changes 999a0f1 Added missing Provides eb74b11 update to b3 64eaca2 Fix issue with pki_external being referenced for non-CA 318716f removed dry_run from pkispawn 019a933 Remove unused respawn code. a80e994 Convert admin cert from a to b before importing to certdb db9537d Set paths for default instance awnuk(1): 883e0ec number verification edewata (52): 9996d71 Parameterizing RESTEasy paths. 81bb209 Archiving default deployment configuration. 66c519f I18n for ProfileList.template. a4c95c3 Removed RA and TPS theme packages. 3dfee91 Reorganized TPS CSS files. d8f56d8 Reorganized TPS templates and scripts. 538dee3 Reorganized RA templates and scripts. 083e130 Fixed permission problem in TKS. 6344d6e Replaced links of scriptlets with lists. 471a493 Simplified the configuration file using defaults. 5e93dc2 Reorganized sensitive parameters. cef7a77 Fixed issuedOn parameters for cert-find. ba1e743 Fixed default security domain user. 68751fb Refactored pkiparser.py into PKIConfigParser. 9bb7143 Removed CA, KRA, OCSP, TKS theme packages. 46fda5d Reorganized CA, KRA, OCSP, TKS templates. edf9c22 Reorganized common templates. c8336ea Renamed pki-common-theme to pki-server-theme. 105ffbd Reorganized ESC images. 545b796 Removed unused files in tps-ui. f3e20fc Removed unused files in ra-ui. 6197b95 Removed unused files in tks-ui. b45fc00 Removed unused files in ocsp-ui. d248593 Removed unused files in kra-ui. 42f48ab Removed unused files in ca-ui. 41e061f Removed unused files in common-ui. fb80a25 Updated tools to deploy combined images and CSS files. 4109bc3 Combined theme images and CSS files into common-ui. 515e882 Fixed pkisilent build problem. cb209df Added ACLInterceptor. 87556b7 Update pki-base.css paths. 386d703 Updated rootca.gif and sub.gif paths. 6a1302a Updated icon-software.gif paths. 1ca3b21 Updated icon_crit_update.gif paths. d7306c4 Updated clearpixel.gif paths. 599a3e7 Updated certificate.png and no-certificate.png paths. 5a14647 Updated bigrotation2.gif paths. d5802a7 Updated lgRightTab2.gif paths. 33746d8 Updated dgRightTab2.gif paths. 918764d Updated lgRightTab.gif paths. 6e836a6 Updated lgLeftTab.gif paths. 792becd Updated goto-tall.gif paths. 3b4a7e4 Updated dgRightTab.gif paths. 122b650 Updated dgLeftTab.gif paths. 45aff6c Updated spacer.gif paths. 137d8f9 Updated hr.gif paths. 810ecfe Updated gray90.gif paths. f077cf4 Updated logo_header.gif paths. a959d7d Updated favicon.ico paths. 70a0dd8 Merged theme files. d9a9e23 Fixed problem finding SHA-256 message digest. 8eb2ccf Fixed PrettyPrintCert and PrettyPrintCrl. jmagne(1): 6180bb1 Latest TPS memory related fixes. mharmsen (9): 70938da More edits to man pages including spell checking via 'aspell'. 34851bb Revised 'pki_default.cfg5' man page. e7b7d98 Added man pages. 8d5eb93 Implemented ability to utilize an external CA 6a1cf64 Removed 'pki/base/silent/templates/subca_silent.template'. af58413 Move default location for client cert database (pkisilent) cfcd015 Move default location for client certificate database 1e15712 Enable Subordinate CA 906acfd Enable building on ARM architecture. From cfu at redhat.com Wed Dec 12 00:51:21 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 11 Dec 2012 16:51:21 -0800 Subject: [Pki-devel] Review Request: CMC ECC support Message-ID: <50C7D509.7090007@redhat.com> The following code is ready for review for task https://fedorahosted.org/pki/ticket/362 Feature: CMC ECC which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well as CMC Response checking support needed HTTPClient ECC support. It should inherently fix the following existing bugs: https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC CRMF https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC revoke attachment: https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff Code changes involve both server and several tools. I will do some writeup and provide example on how to test in the task comment later. thanks! Christina From alee at redhat.com Tue Dec 18 18:23:17 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 18 Dec 2012 13:23:17 -0500 Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc. Message-ID: <1355854998.15924.11.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0107-Revert-to-using-default-config-file-for-pkidestroy.patch Type: text/x-patch Size: 3573 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0106-Hardcode-setting-of-resteasy-lib-for-instance.patch Type: text/x-patch Size: 3143 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0105-interpolate-more-paths.patch Type: text/x-patch Size: 27609 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0104-interpolated-jars.patch Type: text/x-patch Size: 28539 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0102-Removed-duplicate-pki_instance_id-parameter.patch Type: text/x-patch Size: 34172 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0101-Replace-file-dependencies-with-package-dependencies.patch Type: text/x-patch Size: 1730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0103-interpolation-for-paths-part-1.patch Type: text/x-patch Size: 16840 bytes Desc: not available URL: From alee at redhat.com Tue Dec 18 21:38:46 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 18 Dec 2012 16:38:46 -0500 Subject: [Pki-devel] [PATCH] More fixes to pkispawn - 108, 109 Message-ID: <1355866726.15924.13.camel@aleeredhat.laptop> Please review. Ade -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0109-Make-admin-cert-p12-file-location-configurable.patch Type: text/x-patch Size: 6980 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pki-vakwetu-0108-pkispawn-modified-to-not-relabel-when-selinux-is-dis.patch Type: text/x-patch Size: 4419 bytes Desc: not available URL: From mharmsen at redhat.com Tue Dec 18 22:53:44 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 18 Dec 2012 14:53:44 -0800 Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc. In-Reply-To: <1355854998.15924.11.camel@aleeredhat.laptop> References: <1355854998.15924.11.camel@aleeredhat.laptop> Message-ID: <50D0F3F8.5040908@redhat.com> On 12/18/12 10:23, Ade Lee wrote: > Please review. > > Ade > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel *ACK* Performed the following tests on x86_64 Fedora 18: * Existing CA (from legacy 'pkispawn CA') * Update 'pki-core' packages - *SUCCESS* * stop/start CA - *SUCCESS* * enroll using 'Manual User Dual-Use Certificate Enrollment ' - *SUCCESS* * pkispawn KRA - *SUCCESS* o filed *TRAC Ticket #463 - **Dogtag 10: Choose either 'DRM' or 'KRA' for nicknames (not both)* * enroll using 'Manual User Signing & Encryption Certificates Enrollment ' - *SUCCESS* * pkidestroy KRA - *SUCCESS* * enroll using 'Manual User Dual-Use Certificate Enrollment ' - *SUCCESS* * enroll using 'Manual User Signing & Encryption Certificates Enrollment ' o The Certificate System has encountered an unrecoverable error. Error Message: /java.lang.NullPointerException/ Please contact your local administrator for assistance. o related to*TRAC Ticket #367 -pkidestroy doesn't remove connector* * pkidestroy CA - *SUCCESS* * pkispawn CA - *SUCCESS* * enroll using 'Manual User Dual-Use Certificate Enrollment ' - *SUCCESS* * pkispawn KRA - *SUCCESS* * enroll using 'Manual User Signing & Encryption Certificates Enrollment ' - *SUCCESS* * pkidestroy KRA - *SUCCESS* * enroll using 'Manual User Dual-Use Certificate Enrollment ' - *SUCCESS* * pkidestroy CA - *SUCCESS* -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Wed Dec 19 02:43:57 2012 From: alee at redhat.com (Ade Lee) Date: Tue, 18 Dec 2012 21:43:57 -0500 Subject: [Pki-devel] [PATCH] 101-107 Various fixes for pkispawn etc. In-Reply-To: <50D0F3F8.5040908@redhat.com> References: <1355854998.15924.11.camel@aleeredhat.laptop> <50D0F3F8.5040908@redhat.com> Message-ID: <1355885038.15924.15.camel@aleeredhat.laptop> Thanks. Pushed to master. Also pushed a patch with punctuation and formatting changes to the man pages from Deon. Ade On Tue, 2012-12-18 at 14:53 -0800, Matthew Harmsen wrote: > On 12/18/12 10:23, Ade Lee wrote: > > > Please review. > > > > Ade > > > > > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > ACK > > Performed the following tests on x86_64 Fedora 18: > * Existing CA (from legacy 'pkispawn CA') > * Update 'pki-core' packages - SUCCESS > * stop/start CA - SUCCESS > * enroll using 'Manual User Dual-Use Certificate Enrollment' - > SUCCESS > * pkispawn KRA - SUCCESS > * filed TRAC Ticket #463 - Dogtag 10: Choose either > 'DRM' or 'KRA' for nicknames (not both) > * enroll using 'Manual User Signing & Encryption Certificates > Enrollment' - SUCCESS > * pkidestroy KRA - SUCCESS > * enroll using 'Manual User Dual-Use Certificate Enrollment' - > SUCCESS > * enroll using 'Manual User Signing & Encryption Certificates > Enrollment' > * The Certificate System has encountered an > unrecoverable error. > > Error Message: > java.lang.NullPointerException > > Please contact your local administrator for > assistance. > > * related to TRAC Ticket #367 -pkidestroy doesn't remove > connector > * pkidestroy CA - SUCCESS > * pkispawn CA - SUCCESS > * enroll using 'Manual User Dual-Use Certificate Enrollment' - > SUCCESS > * pkispawn KRA - SUCCESS > * enroll using 'Manual User Signing & Encryption Certificates > Enrollment' - SUCCESS > * pkidestroy KRA - SUCCESS > * enroll using 'Manual User Dual-Use Certificate Enrollment' - > SUCCESS > * pkidestroy CA - SUCCESS > From mharmsen at redhat.com Wed Dec 19 03:36:40 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Tue, 18 Dec 2012 19:36:40 -0800 Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . . Message-ID: <50D13648.5070400@redhat.com> The attached patch addresses the following PKI issue: * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in 'pkidaemon' . . . -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20121218-TRAC-Ticket-271-Dogtag-10-Fix-status-command-in-pkid.patch Type: text/x-patch Size: 14693 bytes Desc: not available URL: From cfu at redhat.com Wed Dec 19 04:44:27 2012 From: cfu at redhat.com (Christina Fu) Date: Tue, 18 Dec 2012 20:44:27 -0800 Subject: [Pki-devel] Review Request: CMC ECC support In-Reply-To: <50C7D509.7090007@redhat.com> References: <50C7D509.7090007@redhat.com> Message-ID: <50D1462B.9090206@redhat.com> Please find a newer patch which now also includes support for CMC revocation within the CMCRequest tool and op flags for EC key generation in CRMFPopClient and PKCS10Client. https://fedorahosted.org/pki/ticket/362 You will also find various Examples on how to test different scenarios in regards to CMC request issuance. thanks, Christina On 12/11/2012 04:51 PM, Christina Fu wrote: > The following code is ready for review for task > https://fedorahosted.org/pki/ticket/362 > Feature: CMC ECC > which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well > as CMC Response checking support needed HTTPClient ECC support. > It should inherently fix the following existing bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC > CRMF > https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC > revoke > > attachment: > https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff > > Code changes involve both server and several tools. > > I will do some writeup and provide example on how to test in the task > comment later. > > thanks! > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Dec 19 05:09:21 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Dec 2012 00:09:21 -0500 Subject: [Pki-devel] [PATCH] More fixes to pkispawn - 108, 109 In-Reply-To: <1355866726.15924.13.camel@aleeredhat.laptop> References: <1355866726.15924.13.camel@aleeredhat.laptop> Message-ID: <1355893762.15924.16.camel@aleeredhat.laptop> Acked by Matt. Pushed to master. On Tue, 2012-12-18 at 16:38 -0500, Ade Lee wrote: > Please review. > > Ade > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Dec 19 17:29:05 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Dec 2012 12:29:05 -0500 Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . . In-Reply-To: <50D13648.5070400@redhat.com> References: <50D13648.5070400@redhat.com> Message-ID: <1355938146.15924.33.camel@aleeredhat.laptop> I found the following issues: Issue 1: Lets say I have the following setup: instance A with subsystems CA, KRA, OCSP instance B with subsystem CA, KRA Then for instance B, I see the following error message: grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory pki-tomcat27 Configuration Definitions not found for ocsp It appears that if any instance has a subsystem, then it is assumed that all instances have that subsystem because you use a global list of subsystems. Issue 2: This may be a pkidestroy problem. I did a pkidestroy of the OCSP on instance A. Now I see the following: [CA Status Definitions] Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca Tomcat Port = 8225 (for shutdown) [DRM Status Definitions] Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra Tomcat Port = 8225 (for shutdown) Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp Tomcat Port = 8225 (for shutdown) That is -- I still see definitions from the removed OCSP. Ditto if I remove the KRA. Maybe this is a weird instance. Still testing .. On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote: > The attached patch addresses the following PKI issue: > * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in > 'pkidaemon' . . . > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From alee at redhat.com Wed Dec 19 17:46:34 2012 From: alee at redhat.com (Ade Lee) Date: Wed, 19 Dec 2012 12:46:34 -0500 Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . . In-Reply-To: <1355938146.15924.33.camel@aleeredhat.laptop> References: <50D13648.5070400@redhat.com> <1355938146.15924.33.camel@aleeredhat.laptop> Message-ID: <1355939195.15924.38.camel@aleeredhat.laptop> OK -- I tried this -- 1. Install instance A with CA, KRA 2. Install instance B with CA. At this point, status shows me error on not being able to find KRA files on instance B. 3. Install OCSP on instance A. 4. Remove OCSP on instance A. Other than problem mentioned above, all looks ok. 5. Install OCSP on instance B. I see this for B: Status for pki-tomcat28: pki-tomcat28 is running .. [CA Status Definitions] Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca Secure Agent Port = https://alee-workpc.redhat.com:8283/ca/agent/ca Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca Secure Admin Port = https://alee-workpc.redhat.com:8283/ca/services EE Client Auth Port = https://alee-workpc.redhat.com:8283/ca/eeca/ca PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ca Tomcat Port = 8285 (for shutdown) Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra Secure Agent Port = https://alee-workpc.redhat.com:8283/kra/agent/kra Secure EE Port = https://alee-workpc.redhat.com:8283/kra/ee/kra Secure Admin Port = https://alee-workpc.redhat.com:8283/kra/services PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/kra Tomcat Port = 8285 (for shutdown) [OCSP Status Definitions] Unsecure Port = http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp Secure Agent Port = https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp Secure EE Port = https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp Secure Admin Port = https://alee-workpc.redhat.com:8283/ocsp/services PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ocsp Tomcat Port = 8285 (for shutdown) Looks like you are not parsing the server.conf correctly. On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote: > I found the following issues: > > Issue 1: > > Lets say I have the following setup: > instance A with subsystems CA, KRA, OCSP > instance B with subsystem CA, KRA > > Then for instance B, I see the following error message: > > grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory > pki-tomcat27 Configuration Definitions not found for ocsp > > It appears that if any instance has a subsystem, then it is assumed that > all instances have that subsystem because you use a global list of > subsystems. > > Issue 2: > > This may be a pkidestroy problem. I did a pkidestroy of the OCSP on > instance A. Now I see the following: > > [CA Status Definitions] > Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca > Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca > Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca > Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services > EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca > Tomcat Port = 8225 (for shutdown) > > [DRM Status Definitions] > Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra > Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra > Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra > Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra > Tomcat Port = 8225 (for shutdown) > Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp > Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp > Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp > Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp > Tomcat Port = 8225 (for shutdown) > > That is -- I still see definitions from the removed OCSP. Ditto if I > remove the KRA. > > Maybe this is a weird instance. Still testing .. > > > > On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote: > > The attached patch addresses the following PKI issue: > > * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in > > 'pkidaemon' . . . > > > > _______________________________________________ > > Pki-devel mailing list > > Pki-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/pki-devel > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel From mharmsen at redhat.com Wed Dec 19 19:35:18 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 19 Dec 2012 11:35:18 -0800 Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . . In-Reply-To: <1355939195.15924.38.camel@aleeredhat.laptop> References: <50D13648.5070400@redhat.com> <1355938146.15924.33.camel@aleeredhat.laptop> <1355939195.15924.38.camel@aleeredhat.laptop> Message-ID: <50D216F6.30302@redhat.com> Ade, The attached patch should address these issues. -- Matt On 12/19/12 09:46, Ade Lee wrote: > OK -- I tried this -- > > 1. Install instance A with CA, KRA > 2. Install instance B with CA. At this point, status shows me error on > not being able to find KRA files on instance B. > 3. Install OCSP on instance A. > 4. Remove OCSP on instance A. Other than problem mentioned above, all > looks ok. > 5. Install OCSP on instance B. > > I see this for B: > Status for pki-tomcat28: pki-tomcat28 is running .. > > [CA Status Definitions] > Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca > Secure Agent Port = https://alee-workpc.redhat.com:8283/ca/agent/ca > Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca > Secure Admin Port = https://alee-workpc.redhat.com:8283/ca/services > EE Client Auth Port = https://alee-workpc.redhat.com:8283/ca/eeca/ca > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ca > Tomcat Port = 8285 (for shutdown) > Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra > Secure Agent Port = https://alee-workpc.redhat.com:8283/kra/agent/kra > Secure EE Port = https://alee-workpc.redhat.com:8283/kra/ee/kra > Secure Admin Port = https://alee-workpc.redhat.com:8283/kra/services > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/kra > Tomcat Port = 8285 (for shutdown) > > [OCSP Status Definitions] > Unsecure Port = http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp > Secure Agent Port = https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp > Secure EE Port = https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp > Secure Admin Port = https://alee-workpc.redhat.com:8283/ocsp/services > PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8283/ocsp > Tomcat Port = 8285 (for shutdown) > > Looks like you are not parsing the server.conf correctly. > > > On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote: >> I found the following issues: >> >> Issue 1: >> >> Lets say I have the following setup: >> instance A with subsystems CA, KRA, OCSP >> instance B with subsystem CA, KRA >> >> Then for instance B, I see the following error message: >> >> grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or directory >> pki-tomcat27 Configuration Definitions not found for ocsp >> >> It appears that if any instance has a subsystem, then it is assumed that >> all instances have that subsystem because you use a global list of >> subsystems. >> >> Issue 2: >> >> This may be a pkidestroy problem. I did a pkidestroy of the OCSP on >> instance A. Now I see the following: >> >> [CA Status Definitions] >> Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca >> Secure Agent Port = https://alee-workpc.redhat.com:8223/ca/agent/ca >> Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca >> Secure Admin Port = https://alee-workpc.redhat.com:8223/ca/services >> EE Client Auth Port = https://alee-workpc.redhat.com:8223/ca/eeca/ca >> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ca >> Tomcat Port = 8225 (for shutdown) >> >> [DRM Status Definitions] >> Unsecure Port = http://alee-workpc.redhat.com:8220/kra/ee/kra >> Secure Agent Port = https://alee-workpc.redhat.com:8223/kra/agent/kra >> Secure EE Port = https://alee-workpc.redhat.com:8223/kra/ee/kra >> Secure Admin Port = https://alee-workpc.redhat.com:8223/kra/services >> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/kra >> Tomcat Port = 8225 (for shutdown) >> Unsecure Port = http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp >> Secure Agent Port = https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp >> Secure EE Port = https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp >> Secure Admin Port = https://alee-workpc.redhat.com:8223/ocsp/services >> PKI Console Port = pkiconsole https://alee-workpc.redhat.com:8223/ocsp >> Tomcat Port = 8225 (for shutdown) >> >> That is -- I still see definitions from the removed OCSP. Ditto if I >> remove the KRA. >> >> Maybe this is a weird instance. Still testing .. >> >> >> >> On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote: >>> The attached patch addresses the following PKI issue: >>> * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in >>> 'pkidaemon' . . . >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: 20121219-TRAC-Ticket-271-Dogtag-10-Fix-status-command-in-pkid.patch Type: text/x-patch Size: 15314 bytes Desc: not available URL: From mharmsen at redhat.com Wed Dec 19 19:53:33 2012 From: mharmsen at redhat.com (Matthew Harmsen) Date: Wed, 19 Dec 2012 11:53:33 -0800 Subject: [Pki-devel] [PATCH] Fix 'status' command in 'pkidaemon' . . . In-Reply-To: <50D216F6.30302@redhat.com> References: <50D13648.5070400@redhat.com> <1355938146.15924.33.camel@aleeredhat.laptop> <1355939195.15924.38.camel@aleeredhat.laptop> <50D216F6.30302@redhat.com> Message-ID: <50D21B3D.8090006@redhat.com> ACKed by alee and checked-in (with the collapsed conditional discussed). commit 01bbfc224a228206fbe18318b2a23363fa9663cc Author: Matthew Harmsen Date: Wed Dec 19 11:49:57 2012 -0800 TRAC Ticket #271 - Dogtag 10: Fix 'status' command in 'pkidaemon' . . . On 12/19/12 11:35, Matthew Harmsen wrote: > Ade, > > The attached patch should address these issues. > > -- Matt > > On 12/19/12 09:46, Ade Lee wrote: >> OK -- I tried this -- >> >> 1. Install instance A with CA, KRA >> 2. Install instance B with CA. At this point, status shows me error on >> not being able to find KRA files on instance B. >> 3. Install OCSP on instance A. >> 4. Remove OCSP on instance A. Other than problem mentioned above, all >> looks ok. >> 5. Install OCSP on instance B. >> >> I see this for B: >> Status for pki-tomcat28: pki-tomcat28 is running .. >> >> [CA Status Definitions] >> Unsecure Port = http://alee-workpc.redhat.com:8280/ca/ee/ca >> Secure Agent Port = >> https://alee-workpc.redhat.com:8283/ca/agent/ca >> Secure EE Port = https://alee-workpc.redhat.com:8283/ca/ee/ca >> Secure Admin Port = >> https://alee-workpc.redhat.com:8283/ca/services >> EE Client Auth Port = >> https://alee-workpc.redhat.com:8283/ca/eeca/ca >> PKI Console Port = pkiconsole >> https://alee-workpc.redhat.com:8283/ca >> Tomcat Port = 8285 (for shutdown) >> Unsecure Port = http://alee-workpc.redhat.com:8280/kra/ee/kra >> Secure Agent Port = >> https://alee-workpc.redhat.com:8283/kra/agent/kra >> Secure EE Port = >> https://alee-workpc.redhat.com:8283/kra/ee/kra >> Secure Admin Port = >> https://alee-workpc.redhat.com:8283/kra/services >> PKI Console Port = pkiconsole >> https://alee-workpc.redhat.com:8283/kra >> Tomcat Port = 8285 (for shutdown) >> >> [OCSP Status Definitions] >> Unsecure Port = >> http://alee-workpc.redhat.com:8280/ocsp/ee/ocsp >> Secure Agent Port = >> https://alee-workpc.redhat.com:8283/ocsp/agent/ocsp >> Secure EE Port = >> https://alee-workpc.redhat.com:8283/ocsp/ee/ocsp >> Secure Admin Port = >> https://alee-workpc.redhat.com:8283/ocsp/services >> PKI Console Port = pkiconsole >> https://alee-workpc.redhat.com:8283/ocsp >> Tomcat Port = 8285 (for shutdown) >> >> Looks like you are not parsing the server.conf correctly. >> >> >> On Wed, 2012-12-19 at 12:29 -0500, Ade Lee wrote: >>> I found the following issues: >>> >>> Issue 1: >>> >>> Lets say I have the following setup: >>> instance A with subsystems CA, KRA, OCSP >>> instance B with subsystem CA, KRA >>> >>> Then for instance B, I see the following error message: >>> >>> grep: /var/lib/pki/pki-tomcat27/conf/ocsp/CS.cfg: No such file or >>> directory >>> pki-tomcat27 Configuration Definitions not found for ocsp >>> >>> It appears that if any instance has a subsystem, then it is assumed >>> that >>> all instances have that subsystem because you use a global list of >>> subsystems. >>> >>> Issue 2: >>> >>> This may be a pkidestroy problem. I did a pkidestroy of the OCSP on >>> instance A. Now I see the following: >>> >>> [CA Status Definitions] >>> Unsecure Port = http://alee-workpc.redhat.com:8220/ca/ee/ca >>> Secure Agent Port = >>> https://alee-workpc.redhat.com:8223/ca/agent/ca >>> Secure EE Port = https://alee-workpc.redhat.com:8223/ca/ee/ca >>> Secure Admin Port = >>> https://alee-workpc.redhat.com:8223/ca/services >>> EE Client Auth Port = >>> https://alee-workpc.redhat.com:8223/ca/eeca/ca >>> PKI Console Port = pkiconsole >>> https://alee-workpc.redhat.com:8223/ca >>> Tomcat Port = 8225 (for shutdown) >>> >>> [DRM Status Definitions] >>> Unsecure Port = >>> http://alee-workpc.redhat.com:8220/kra/ee/kra >>> Secure Agent Port = >>> https://alee-workpc.redhat.com:8223/kra/agent/kra >>> Secure EE Port = >>> https://alee-workpc.redhat.com:8223/kra/ee/kra >>> Secure Admin Port = >>> https://alee-workpc.redhat.com:8223/kra/services >>> PKI Console Port = pkiconsole >>> https://alee-workpc.redhat.com:8223/kra >>> Tomcat Port = 8225 (for shutdown) >>> Unsecure Port = >>> http://alee-workpc.redhat.com:8220/ocsp/ee/ocsp >>> Secure Agent Port = >>> https://alee-workpc.redhat.com:8223/ocsp/agent/ocsp >>> Secure EE Port = >>> https://alee-workpc.redhat.com:8223/ocsp/ee/ocsp >>> Secure Admin Port = >>> https://alee-workpc.redhat.com:8223/ocsp/services >>> PKI Console Port = pkiconsole >>> https://alee-workpc.redhat.com:8223/ocsp >>> Tomcat Port = 8225 (for shutdown) >>> >>> That is -- I still see definitions from the removed OCSP. Ditto if I >>> remove the KRA. >>> >>> Maybe this is a weird instance. Still testing .. >>> >>> >>> >>> On Tue, 2012-12-18 at 19:36 -0800, Matthew Harmsen wrote: >>>> The attached patch addresses the following PKI issue: >>>> * TRAC Ticket #271 - Dogtag 10: Fix 'status' command in >>>> 'pkidaemon' . . . >>>> >>>> _______________________________________________ >>>> Pki-devel mailing list >>>> Pki-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/pki-devel >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> > > > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Fri Dec 21 22:46:54 2012 From: jmagne at redhat.com (John Magne) Date: Fri, 21 Dec 2012 17:46:54 -0500 (EST) Subject: [Pki-devel] Review Request: CMC ECC support In-Reply-To: <50D1462B.9090206@redhat.com> Message-ID: <1671068218.50795685.1356130014374.JavaMail.root@redhat.com> Review Comments: PKCS10Client.java 1. Typo, I think: 50 + System.out.println(" -x \n"); 2. When parsing the command line args, it looks like we assume an even number or args, with the first arg being the switch and the second one being the value. When you check the switch, there is no code to handle the case when the switch is not in the list. Also, it appears that not every value is checked. For instance, if an ecc curve is specified, I don't see a check for null. 3. We have the following piece of code in two places near each other: if (dbdir == null) 141 dbdir = "."; 4. The following block: try { 170 + token.login(pass); 171 + System.out.println("PKCS10Client: token "+ tokenName + " logged in..."); 172 + } catch (Exception e) { 173 + System.out.println("PKCS10Client: login Exception: " + e.toString()); 174 + if (!token.isLoggedIn()) { 175 + System.out.println("PKCS10Client: token not logged in, calling initPassword..."); 176 + token.initPassword(pass, pass); 177 + } 178 + } What are we doing here? If the password is wrong, should we not bomb out? 5. Code: if (alg.equals("rsa")) { 182 + KeyPairGenerator kg = token.getKeyPairGenerator(KeyPairAlgorithm.RSA); 183 + kg.initialize(rsa_keylen); 184 + pair = kg.genKeyPair(); 185 + } else if (alg.equals("ec")) { 186 + // used with SSL server cert that doe What if the alg is some bogus value? The tool seems to happily skip over the entire block and keep going. Maybe some quick check? 6. certRequest = new CertificationRequest(certReqInfo, If certRequest is null, we just log the fact to the screen but keep going. 7. PublicKey pubk = pair.getPublic(); Here , I do not think we ever check to see if "pair" is generated without a null. Maybe that is taken care of with the exceptions. But, also "pubk" is used later without a check for null. 8. Same as #6, with the value of "certReq". CRMFPopClient.java 1. Check for the same argument parsing concerts as in the previous tool. 2. This check here: try { 599 + CryptoManager.initialize( DB_DIR ); 600 + } catch (Exception e) { 601 + // it is ok if it is already initialized 602 + System.out.println("CRMFPopClient: INITIALIZATION ERROR: " + e.toString()); 603 + //return; 604 + } Is it possible this would fail for some other reason besides that it was already initialized? 3. Same concern in the previous tool about what happens when token.login fails. CMCRequest.java 1. Same concern here about checking the password. HttpClient.java 1. This code: + X509Certificate cert = 1803 + cm.findCertByNickname(certname.toString()); 1804 if (cert == null) 1805 System.out.println("client cert is null"); 1806 else 1807 System.out.println("client cert is not null"); Do we care if there is no client cert? The code proceeds happily from this point on. ----- Original Message ----- From: "Christina Fu" To: pki-devel at redhat.com Sent: Tuesday, 18 December, 2012 8:44:27 PM Subject: Re: [Pki-devel] Review Request: CMC ECC support Please find a newer patch which now also includes support for CMC revocation within the CMCRequest tool and op flags for EC key generation in CRMFPopClient and PKCS10Client. https://fedorahosted.org/pki/ticket/362 You will also find various Examples on how to test different scenarios in regards to CMC request issuance. thanks, Christina On 12/11/2012 04:51 PM, Christina Fu wrote: > The following code is ready for review for task > https://fedorahosted.org/pki/ticket/362 > Feature: CMC ECC > which includes support for CMC CRMF, CMC PKCS10, CMC Revoke, as well > as CMC Response checking support needed HTTPClient ECC support. > It should inherently fix the following existing bugs: > https://bugzilla.redhat.com/show_bug.cgi?id=805738 ECC support for CMC > CRMF > https://bugzilla.redhat.com/show_bug.cgi?id=837892 ECC support for CMC > revoke > > attachment: > https://fedorahosted.org/pki/attachment/ticket/362/CMC-ECC-forReview1.diff > > Code changes involve both server and several tools. > > I will do some writeup and provide example on how to test in the task > comment later. > > thanks! > Christina > > _______________________________________________ > Pki-devel mailing list > Pki-devel at redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel at redhat.com https://www.redhat.com/mailman/listinfo/pki-devel